On 12 April 2010 13:48, Dan Blacker <dan.blac...@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. John _______________________________________________ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
