Epson scanner - 48-bit worse than 24-bit?!

  • Thread starter Thread starter Lorenzo J. Lucchini
  • Start date Start date
L

Lorenzo J. Lucchini

I've bought an Epson RX500 all-in-one.
If I scan the same picture (actually the same slide, using the
built-in transparency adaptor) at 8 bits per channel twice, and then
use pnmpsnr from NetPBM to measure the signal-to-noise ratio, I get
something like

pnmpsnr: Y color component: 46.24 dB
pnmpsnr: Cb color component: 46.93 dB
pnmpsnr: Cr color component: 47.43 dB

If I scan at 16 bits per channel, I get

pnmpsnr: Y color component: 24.06 dB
pnmpsnr: Cb color component: 26.49 dB
pnmpsnr: Cr color component: 27.29 dB

And indeed, the 48-bit image looks *much* noisier at first sight!
How is this possible? I didn't expect that the scanner made full use
of all 48 bits, but this is completely counter-intuitive!

By the way, if I multi-scan four times at 16 bits per channel and then
combine the results, I get better results than with a single 16-bit
scan, but still much worse than scanning once at 8-bit:

pnmpsnr: Y color component: 29.05 dB
pnmpsnr: Cb color component: 32.48 dB
pnmpsnr: Cr color component: 33.23 dB

I'm using the Epson-Kowa drivers on Linux with scanimage.

by LjL
(e-mail address removed)
 
Lorenzo J. Lucchini said:
I've bought an Epson RX500 all-in-one.
If I scan the same picture (actually the same slide, using the
built-in transparency adaptor) at 8 bits per channel twice, and then
use pnmpsnr from NetPBM to measure the signal-to-noise ratio, I get
something like

pnmpsnr: Y color component: 46.24 dB
pnmpsnr: Cb color component: 46.93 dB
pnmpsnr: Cr color component: 47.43 dB

If I scan at 16 bits per channel, I get

pnmpsnr: Y color component: 24.06 dB
pnmpsnr: Cb color component: 26.49 dB
pnmpsnr: Cr color component: 27.29 dB

And indeed, the 48-bit image looks *much* noisier at first sight!
How is this possible? I didn't expect that the scanner made full use
of all 48 bits, but this is completely counter-intuitive!
Click to expand...

When the 16 bit samples are rounded to 8 bits what is thrown away is almost
all noise, so that each time you scan you get almost exactly the same
results, assuming that the noise doesn't affect the higher 8 bits. As an
analogy if you measure your height to mm you will get a different answer
each time, but to the cm you should get the same answer every time.

What does increase with 8 bits is the quantisation noise but your method
wont calculate this.
 
Ken said:
When the 16 bit samples are rounded to 8 bits what is thrown away is almost
all noise, so that each time you scan you get almost exactly the same
results, assuming that the noise doesn't affect the higher 8 bits. As an
analogy if you measure your height to mm you will get a different answer
each time, but to the cm you should get the same answer every time.

What does increase with 8 bits is the quantisation noise but your method
wont calculate this.
Click to expand...
All fine and correct, but it doesn't explain why the 16-bit image
*looks* noisier, since Lorenzo shouldn't be able to see 8-bit
quantisation noise, let alone any random noise which is less than this
at 16-bits.

I am not sure what the cause of this is, but would ask Lorenzo to take
another look at the images and confirm that is the case, then convert
the 16-bit image to 8-bits in Photoshop or some other application and
compare that with the original 8-bit scan. It may be that his
application just does a particularly poor job of displaying the 16-bit
data.
 
When the 16 bit samples are rounded to 8 bits what is thrown away is almost
all noise, so that each time you scan you get almost exactly the same
results, assuming that the noise doesn't affect the higher 8 bits. As an
analogy if you measure your height to mm you will get a different answer
each time, but to the cm you should get the same answer every time.

What does increase with 8 bits is the quantisation noise but your method
wont calculate this.
Click to expand...
All fine and correct, but it doesn't explain why the 16-bit image
*looks* noisier, since Lorenzo shouldn't be able to see 8-bit
quantisation noise, let alone any random noise which is less than this
at 16-bits.
[/QUOTE]

I had a rethink and there is a problem. When a sample is half way
between two 8 bit levels then noise will randomly push it either way
producing an error. Although this is only a small fraction of pixels,
they do contribute a fair amount to the noise. Some quick simulation
show that the noise is higher with 8 bits. It would be interesting to
see the actual values from the scanner.
 
I've bought an Epson RX500 all-in-one.
If I scan the same picture (actually the same slide, using the
built-in transparency adaptor) at 8 bits per channel twice, and then
use pnmpsnr from NetPBM to measure the signal-to-noise ratio, I get
something like

[snip]

And indeed, the 48-bit image looks *much* noisier at first sight!
How is this possible?

[snip]
Click to expand...

Solved.
It was a driver problem. Apparently, the Epson Kowa driver applies
some default color correction coefficients to every scan, and
apparently it gets the maths wrong when dealing with 16-bit data.

Giving scanimage the following options:
--cct-1 1 --cct-2 0 --cct-3 0 --cct-4 0 --cct-5 1 --cct-6 0 --cct-7 0
--cct-8 0 --cct-9 1
disables color correction and removes the problem with added noise in
16-bit images.

However, pnmpsnr now reports the same SNR no matter what the bit depth
of the scanned images.

Although the considerations that have been made in reply to my
original post may explain this, I am left with the uncomfortable
feeling that my scanner may add no usedful data in a 16-bit scan
compared to an 8-bit scan.

I hope this isn't the case.

by LjL
(e-mail address removed)
 
Lorenzo J. Lucchini said:
However, pnmpsnr now reports the same SNR no matter what the bit depth
of the scanned images.
Click to expand...

What's pnmpsnr?
Although the considerations that have been made in reply to my
original post may explain this, I am left with the uncomfortable
feeling that my scanner may add no usedful data in a 16-bit scan
compared to an 8-bit scan.

I hope this isn't the case.
Click to expand...

If pnmpsnr is looking at the grain noise (as it probably is), then it should
report the same snr regardless of the bit depth.

You might try a dark area of a slide with just a touch of detail (since the
grain is less apparent than it is in brighter areas) and see if 16 bit scans
help. Try _four_ scans: both single scans and multisampling scans (8x or 16x
if possible) and both 8-bit and 16-bit scans.

There have been discussions here extoling the virtues of and need for
getting the low-order bit in 16-bit scans correct. Given that the grain
noise has an amplitude on the order of 2^10 higher than that bit, I wonder
about the utility of said bit.

David J. Littleboy
Tokyo, Japan
 
What's pnmpsnr?
Click to expand...

It's a tool from the NetPBM command line utilities for image
manipulation ( http://netpbm.sf.net ).
It can "compute the difference between two portable anymaps" - more
precisely, it "Reads two PBM, PGM, or PPM files, or PAM
equivalents, as input. Prints the peak signal-to-noise ratio (PSNR)
difference between the two images. This metric is typically used in
image compression papers to rate the distortion between original and
decoded image."

This is from the man page.

I've just realized that the way I'm using it is actually quite
different from the one described (hey, I've read like 20 manpages just
in the last two days...). So maybe its response isn't meaningful at
all; however, the manpage goes on saying:

"The PSNR of a given component is the ratio of the mean square
difference of the component for the two images to the maximum mean
square difference that can exist betwee any two images. It is
expressed as a decibel value."

I can't decode this, but maybe you can :-) It also says something that
sounds somewhat more straight-forward to me:

"So the higher the PSNR, the closer the images are. A luminance PSNR
of 20 means the mean square difference of the luminances of the pixels
is 100 times less than the maximum possible difference, i.e. 0.01."

One thing that suggests that this tool does indeed estimate the SNR of
my scanner is that it did give me much worse values for those very
noisy 16-bit images plagued by the driver's bug I found.
[snip]
Click to expand...

If pnmpsnr is looking at the grain noise (as it probably is), then it
should
report the same snr regardless of the bit depth.
Click to expand...

Whatever it is doing, no, I don't think it has much to do with the
grain noise.
You might try a dark area of a slide with just a touch of detail (since
the
grain is less apparent than it is in brighter areas) and see if 16 bit
scans
help.
Click to expand...

That's what I did (among other thing): there's a really underexposed
slide I've been trying to extract some detail from.
There, not only pnmpsnr's response doesn't change depending on
bitdepth, but visual examination of the 8-bit and 16-bit images
doesn't reveal (to me at least) any more detail in the 16-bit version
-- of course, the histogram-stretched 16-bit scan *does* look
different from the respective 8-bit scan, but all I can see is random
noise where 8-bit would show a uniform color: no actual detail.
Try _four_ scans: both single scans and multisampling scans (8x or
16x
if possible) and both 8-bit and 16-bit scans.
Click to expand...

Tried. pnmpsnr gives better SNR values for 2x multiscans (multiple
passes, my scanner can't do multisampling) than for single scans, but
then the SNR usually gets worse for 4x multiscans and beyond.
I suppose it's a matter of misalignment, which, after more than two
scans, adds up too much.

Anyway, I can certainly believe that averaging multiple 16-bit scans
together gives better results (SNR) than doing the same thing with
8-bit scans. However, that doesn't make my scanner's 16-bit output any
more useful: I could just as well scan at 8-bit, convert to 16-bit and
only then average the images together.
There have been discussions here extoling the virtues of and need for
getting the low-order bit in 16-bit scans correct.
Click to expand...

You mean low-order *byte*? Getting the rightmost *bit* correct would
sound more like a miracle than anything else :-)
Or maybe you mean then 9-th bit (that is, the one that comes
immediately after the standard 8 bits)?
If this is what you mean, well, either I can get that bit correct, or
my scanner's manifacturer used a 16-bit ADC just to be able to tell me
"it's 16-bit, buy it!", without the scanner actually being able to
pick up anything more than 256 shades of color.
Given that the grain
noise has an amplitude on the order of 2^10 higher than that bit, I
wonder
about the utility of said bit.
Click to expand...

Underexposed pictures, for example. In any case, I've read everywhere
that film can record more densities than a standard 24-bit pixel can
represent... is that wrong?


by LjL
(e-mail address removed)
 
Lorenzo J. said:
"The PSNR of a given component is the ratio of the mean square
difference of the component for the two images to the maximum mean
square difference that can exist betwee any two images. It is
expressed as a decibel value."

I can't decode this, but maybe you can :-)
Click to expand...

It means the following:
Calculate the pixel difference between the two images in the relevant
component (luminance, Cr, Cb etc.). ie. d(pix) = A(pix) - B(pix)
where A(pix) is the value of the component for pixel pix in image A, and
B(pix) is the value of the component for pixel pix in image B.
Square each of these pixel differences. ie. s(pix) = d(pix)^2
Calculate the mean of these squares. ie. M = sum(s(pix))/N where N is
the total number of pixels in the image.
Calculate the maximum possible mean square difference, which is simply
P=s(pix) where A(pix) is maximum and B(pix) is minimum, thus for
luminance this would be (255-0)^2.
Calculate the ratio M/P and express in decibels,
ie PSNR= 20log(M/P) *
It also says something that
sounds somewhat more straight-forward to me:

"So the higher the PSNR, the closer the images are. A luminance PSNR
of 20 means the mean square difference of the luminances of the pixels
is 100 times less than the maximum possible difference, i.e. 0.01."
Click to expand...
* This last step would appear to be an error in terms of estimating the
true PSNR, since the factor to get decibels from the mean square
difference should be 10log(M/P), since the square has already been
applied in the estimate of the differences. The calculation they use
would be correct if M and P were the rms values, ie. "root mean square".
Whether the function itself is in error or the description is flawed
would require some test examples. Thus a luminance PSNR of 20 means the
root mean square differences should be 100 times less than maximum, but
the mean square differences should be 10,000 times less than maximum.
One thing that suggests that this tool does indeed estimate the SNR of
my scanner is that it did give me much worse values for those very
noisy 16-bit images plagued by the driver's bug I found.
Click to expand...
It only estimates the PSNR if the only difference between the images is
indeed noise, in one form or another. If there are other differences,
such as a displacement or scale difference then the estimated PSNR will
be artificially high. To eliminate this, as a first step, the images
should be as free from any detail as possible, ie. uniform in colour and
tone. A better solution is to compare many such scans and calculate the
noise as the mean standard deviation of the component in the images. The
PSNR is then the ratio between this noise and the maximum difference -
using the 20log(M/P) because the standard deviation is the root of the
average of the square of the deviations.
 
Back
Top