Scanning 4x5 on epson 4870 at 16-bits/channel

  • Thread starter Thread starter Roger N. Clark (change username to rnclark)
  • Start date Start date
"David J. Littleboy" said:
I'm quite sure that if you scanned the same frame (35mm or MF) with a Nikon
4000 dpi scanner and the 4870, and downsampled both to 2400 dpi, the Nikon
scan would look a lot better.
Click to expand...

Downsampling is destructive. Why not scan to suit the output?
 
jjs said:
Since I can't see the program code, I have to guess that the image size
will be larger than addressable memory (plus program size.)

Do you really need 4800spi/48-bit? You can't use it with any conventional
imaging software. You can't print it, either. I'd suggest you lower the
bit sample to something manageable. You will always have the transparency
in the future when/if digital catches up.
Click to expand...

No, I don't need 4800 ppi, but I need at least 3200 ppi, and I want
48-bit. Of course for printing the bits come down, but not the
size. I've printed 4x5 at 4 x 5 FEET at 305 ppi on lightjet 500.
That works out to 4*12*305 x 5*12*305 = 14,640 x 18,300 pixels
= 804 mbytes. But processing at 16 bits/channel is a file
size of 1.6 gbytes.

Regarding the epson 4870, in tests I did yesterday, I was seeing
about 50 to 60 line pairs per mm, so either I have a good unit,
previous reports were with bad units, or newer units are better.

My testing showed only a little difference between 3200 and 4800 dpi,
but a big difference at 2400 dpi. So I need to get at least 3200 dpi
at 48-bits, which gives an 800 mbyte file.

I turned off ICE, but there was no difference in my error message.
Shortly I'll test with 2 gbytes ram.

Roger
 
David said:
But not downsampling is silly. The scanner simply isn't capturing 4800 dpi
of real data; it's a 30 lp/mm x 40 lp/mm resolution device, and at the
Nyquist frequency, that's 1500 dpi x 2000 dpi.
Click to expand...

David,
Nyquist is a commonly misunderstood theorem. The theorem is valid when
the signal and sampling are in phase. In an image, image detail
is not necessarily in phase with the sampling. Thus you need higher
sampling to recover the information. For example, with 2 samples
per cycle (Nyquist), you can set the phase to give zero response.
Typically, you see good improvement with sampling at 2x Nyquist, or
4x the frequency, and there are still gains in going higher, although
not as fast. See:
http://www.clarkvision.com/imagedetail/sampling1.html

Then, I've tested my particular epson 4870 and I see 50 to 60 lpm.
I get better image detail if I scan at 3200 ppi versus 2400 ppi, but
only small improvement at 4800 ppi.

Roger
 
First, I don't believe it's truely 64-bit yet. But regardless, CS can't
address more than 2gb of RAM, and in fact you will probably find it
addressing only 1.8gb. A significant performance factor in CS will be
found in using multiple spindles for work files. CS uses its own
proprietary paging scheme and will page regardless of the amount of RAM
but of course more is better because you can have other applications in
the remaining space.
Click to expand...

Indeed. That's the point of having >2 gigs, even if one process can't exceed
that. The OS will use some, and if you're loading large images into CS, you
may well want to handle large images in another application simultaneously
too.

My lowly G4 can only handle 2 gigs of physical RAM, of course, but there's
no prospect of me scanning anything larger than 6*6s in the near future. I'd
be interested to see if Panotools could cope with multiple 6*6 scans on a 2
gig machine though - when I last used it to stitch "lowly" 6 megapixel
images on a machine with 512 megs, the VM started thrashing pretty badly
(looked like it had a working set in excess of 1 gigabyte at some points).
 
message SNIP
Then, I've tested my particular epson 4870 and I see 50 to 60 lpm.
I get better image detail if I scan at 3200 ppi versus 2400 ppi, but
only small improvement at 4800 ppi.
Click to expand...

If you say 50-60 lpm, do you mean lines- or line-pairs/mm. I assume the
latter, because my 2400ppi flatbed can resolve in excess of 30 lp/mm @ 10%
modulation.

What many, given some of the suggestions, apparently do not realise is that,
scanning below the native scanner resolution will skip pixels in the sensor
array and change the characteristic of the scanner to more of a point
sampler rather than an area sampler. That will not only increase (grain)
aliasing, but also make fine lines and edges at a slant, fade or even snap
in-and-out of visiblility, which can look ugly.

It is better to downsize (using a proper algorithm for downsizing if you
don't want to make matters worse again ! ):
<http://www.xs4all.nl/~bvdwolf/main/foto/down_sample/down_sample.htm>

Bart
 
Roger said:
No, I don't need 4800 ppi, but I need at least 3200 ppi, and I want
48-bit. Of course for printing the bits come down, but not the
size. I've printed 4x5 at 4 x 5 FEET at 305 ppi on lightjet 500.
That works out to 4*12*305 x 5*12*305 = 14,640 x 18,300 pixels
= 804 mbytes. But processing at 16 bits/channel is a file
size of 1.6 gbytes.

Regarding the epson 4870, in tests I did yesterday, I was seeing
about 50 to 60 line pairs per mm, so either I have a good unit,
previous reports were with bad units, or newer units are better.

My testing showed only a little difference between 3200 and 4800 dpi,
but a big difference at 2400 dpi. So I need to get at least 3200 dpi
at 48-bits, which gives an 800 mbyte file.
Click to expand...

As I noted previously, I routinely scan 4 x 5 at 16 bits per channel and
3200 ppi, using my Epson 3200. Of course, it is not clear what the
4870 will actually do if you tell it to scan at 3200. Perhaps it scans
and 4870 and downsamples somehow in software. In that case, it is
quite disappointing in that it can't be used at more than 2400 ppi for
16 bits per channel.

I have 1.5 Gb of ram.

Let us know what you finally figure out.
 
Tim said:
This is a programming restriction because the EPSON Scan transfers RGB
information in one go rather than individually (probably a Twain
requirement). There is normally a limitation of 74Kb of data per line
of scanned data that can be transferred (hardware limitation).
Click to expand...

Tim,
It seems you have the correct answer, but a buffer of only 65KB.
I installed another 1 GB ram for a total of 2 gb, and there was no
change in the error.

I found that I could scan at 3200 ppi, 16 bits:
3.4 inches wide = 3.4*3200*48/8 = 65280 kbytes / line (WORKS)
but not:
3.5 inches wide = 3.5*3200*48/8 = 67200 kbytes / line (DOES NOT WORK)

Thus the line length can probably be no more than 65 kbytes.

Roger
 
Bart said:
message SNIP



If you say 50-60 lpm, do you mean lines- or line-pairs/mm. I assume the
latter, because my 2400ppi flatbed can resolve in excess of 30 lp/mm @ 10%
modulation.
Click to expand...

line-pairs/mm

Roger
 
message SNIP
Tim,
It seems you have the correct answer, but a buffer of only 65KB.
I installed another 1 GB ram for a total of 2 gb, and there was no
change in the error.
Click to expand...

I don't recall, but have you tried VueScan? It supports my humble Epson 2450
(used mainly for document scanning) just fine, and the 4870 is also
supported by VueScan. Knowing that you look for the ultimate that a given
device can provide, VueScan seems to be a logical tool.

Bart
 
This is a programming restriction because the EPSON Scan transfers RGB
This might be why some people using a 4870 + Vuescan (non TWAIN software)
have reported they can scan larger files?

Maybe my feeble mind is just not grasping the concepts presented in this
thread correctly so late in the afternoon, but in theory, shouldn't you be
able to scan a 4x5 at a slightly higher dpi if it is in vertical orientation
instead of horizontal orientation since not as much data would be
transferred through with each "step" (4 in inches wide instead of 5)?

Comments from the scanner "rocket scientists" here to set me straight? :)

Doug
 
I found that I could scan at 3200 ppi, 16 bits:
3.4 inches wide = 3.4*3200*48/8 = 65280 kbytes / line (WORKS)
but not:
3.5 inches wide = 3.5*3200*48/8 = 67200 kbytes / line (DOES NOT WORK)

Thus the line length can probably be no more than 65 kbytes.
Click to expand...

To be exact, it looks like the program has a variable limited to 2^16
(65536 or 65535 depending upon how the programmer handled it).
 
My testing showed only a little difference between 3200 and 4800 dpi,
but a big difference at 2400 dpi. So I need to get at least 3200 dpi
at 48-bits, which gives an 800 mbyte file.
Click to expand...


The alleged need for 48 bit scans has been debated often
on this and many other forums, and by luminaries such as
Jeff Schewe and Dan Margulis. I side with Dan.

If you do the coarsest of your tonal manipulations in the
scanner driver - and do them well - the resulting 24-bit file
will be robust enough to withstand (or thrive on) fine tweaks
later on in Photoshop.

48 bit capture simply allows you to carry noise and trash
data further up the signal stream. Sooner or later you
have to make tonal manipulations that pare away the
useless codes and noise.

IMO, the need for 48 bit capture is hugely overrated.
Using 24-bit capture simply means doing the paring
earlier rather than later.


rafe b.
http://www.terrapinphoto.com
 
Bart said:
message SNIP



I don't recall, but have you tried VueScan? It supports my humble Epson 2450
(used mainly for document scanning) just fine, and the 4870 is also
supported by VueScan. Knowing that you look for the ultimate that a given
device can provide, VueScan seems to be a logical tool.
Click to expand...

I endorse trying Vuescan. I use it with the Epson 3200 under Linux. It
works fine. I haven't tried the Epson software recently.
 
And for those of us on 32bit systems, that 4GB may be more theoretical than
practical. I assume that Photoshop uses 32 bit word that then somehow maps
to virtual memory. If it uses virtual memory directly, then 32bits = 4 GB
minus virtual memory allocated to "other things." Performance is going to go
down hill quickly as we x86ers are limit to 4GB of phycial memory for now.

Todd
 
"konabear" said:
And for those of us on 32bit systems, that 4GB may be more theoretical than
practical. I assume that Photoshop uses 32 bit word that then somehow maps
to virtual memory. If it uses virtual memory directly, then 32bits = 4 GB
minus virtual memory allocated to "other things." Performance is going to go
down hill quickly as we x86ers are limit to 4GB of phycial memory for now.
Click to expand...

Photoshop won't use more than 2gb no matter how much RAM you have,
regardless of the operating system, OS-X or Windoze. Set the preferences
to use 100% of RAM when you have 4gb of RAM and see for yourself.
 
Photoshop won't use more than 2gb no matter how much RAM you have,
regardless of the operating system, OS-X or Windoze. Set the preferences
to use 100% of RAM when you have 4gb of RAM and see for yourself.
Click to expand...

Correct.
And CS is buggy with RAM to boot. Most folks with 2GB are having to set
PS CS to only use 45-50% of RAM. PS also uses scratch disk as main memory
with RAM as cache.

Of course, assuming you have 2GB of RAM or less, it's always been a good
idea to set PS to use no more than 75% RAM anyway, as OS needs a good bit
also.

Mac
 
jjs said:
To be exact, it looks like the program has a variable limited to 2^16
(65536 or 65535 depending upon how the programmer handled it).
Click to expand...

There are two different modes for reading pixels from the scanner,
one reads all three colors per line, and another reads one color
at a time. VueScan uses the former on the 3170 and the latter
on the 4870.

The limit in VueScan on the 4870 is pixel_width*bytes_per_sample <= 32752
The limit on the 3170 is bytes_per_line <= 65520 bytes.

On the 4870, for 16 bits per sample, the maximum pixel width in
VueScan is 16376, and at 4800 dpi this is 3.411 inches.
At 8 bits per sample, this is 6.822 inches.

On the 3170, for 16 bits per sample, the maximum pixel width
in VueScan is 10920, and at 3200 dpi this is 3.413 inches.
At 8 bits per sample, this is 6.826 inches.

If the requested scan area is too wide, VueScan
first tries to reduce the bits per sample to 8 bits. If this
is still too wide, VueScan reduces the scan resolution one
step.

Regards,
Ed Hamrick
 
Roger,
Your system memory is not going to make a difference here.

The restriction is:

a) In the scanner itself there is a phisical limit to the information
that can be captured at a specific moment, eg. 1 scan line.
b) There is a software limitation on how the driver transfers this
information, either one colour at a time or all at once.

So the limit on the Perfection 4870 with the EPSON Twain Compliant
driver is 64Kb per scan line. This equates to approximatly a 2.25 inch
scan width at 4800 dpi and 48 bit colour.

Ed Hamrick's VueScan can deliver a 3.411 inches inch scan width at
4800 dpi and 48 bit colour.

This is because of the difference in the way each driver collects the
information. EPSON will only ship Twain compliant drivers with its
products, perhaps this is what dictates the way the driver is written.

However we are now near the territory of drum scanners (5 inch scan
widths at 4800 dpi and 48 bit colour) and this level of performance
cannot really be expected from a home scanner at the price it is
offered.

This does not help if you need the resolution as demonstrated by your
explanation.

You could try scanning as two parts and stitching, but you would have
to lock the exposure and be very careful not to jog the scanner
between scanning the two Marquees (you can program the two jobs in one
scan).

Best of luck...
 
Back
Top