[Image-SIG] python PIL 16-bit tiff files

jcupitt at gmail.com jcupitt at gmail.com
Mon Apr 19 12:13:39 CEST 2010

On 12 April 2010 13:48, Dan Blacker <dan.blacker at googlemail.com> wrote:
> It is the CCD in this that is capturing the information:
> http://www.epson.com/cgi-bin/Store/consumer/consDetail.jsp?oid=63056499
> Are you saying that scanning at 48bit is pointless? Surley to advertise that
> feature on the scanner it must yeild more color information than at 24bit.

My background: I used to design and build high-end (>$20,000) cameras
and scanners. I did the software. It's 5 years now since I worked in
the area, but I don't think it's changed that much.

You could almost certainly use 8-bit images from the scanner with no
loss of colour detail or resolution. It's quite easy to see how many
bits you need: scan a very gentle gradient at a high resolution, look
through your image bitplane by bitplane, see how far down the 16 bits
you have to go before all the structure vanishes in a sea of noise.

I had a look at the sample image you posted earlier, and from a quick
look I'd say the bottom 7 bits of your image is just noise, so you
have about 9 bits of real data. You can easily represent 9 bits of
typical CCD data in an 8-bit byte if you use a gamma function.

People like 16-bit source data (and manufactures oblige) for two main reasons:

*) You can use linear encoding in 16-bit pixels without losing
precision, 8-bit pixels need a companding curve (eg. a gamma) of some
sort. Linear encoding can make downstream processing simpler.

*) The extra bits, although they contain no signal, are great for
avoiding rounding and banding in subsequent processing.

But for archiving, there's no point keeping them. You can just throw
the bottom 8 bits away and recreate them when you load the image.

Anyway, I'm getting off-topic, ahem. As Sebastian says, a quick
workaround would be to use imagemagick or equivalent to convert to
three 16-bit mono images and then load.


More information about the Image-SIG mailing list