On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker <dan.blac...@googlemail.com> wrote: > Hey guys, > > Thanks for your input, > > The image is only of a tiny cropped area of a long strip of color kodachrome > film - I will send a better example with some more color in it when I get a > chance. > > I was under the impression that PIL handled 16 bit images (experimentally) > but does this only apply to 16-bit grayscale images? > > Am I going up a dead end trying to read my images with PIL?
The current PIL release only supports 8 and 32-bit/pixel internal storage; that's enough to hold e.g. RGB triplets or 32-bit signed integers, but not 3x16 bit pixels. I'd love to support more storage formats (machines are a lot bigger now than when the internal, intentionally very simple storage model was designed) including HDR formats (float16 etc), but rearchitecting the internals without breaking all existing code is a pretty big project... There is some limited support for 16-bit storage, by packing two pixels per 32-bit storage unit, but not all operations support this (it's mainly intended to support working with huge, memory mapped single-layer images, such as satellite data). There are some non-standard tricks that may help you with your specific case, though. All codecs do things in two steps; the first is to identify the file format and build a descriptor of where the image data is in the file (the "tile" map). The second step then loads pixel data on demand, using that descriptor. You might be able to tweak the descriptor before loading the image, to load one layer at a time. Do you have any samples? </F> _______________________________________________ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig