Oh, missed that there was one in your first post. I'm a bit busy right now, but I'll take a look when I find some spare time.
</F> On Thu, Apr 22, 2010 at 10:56 PM, Fredrik Lundh <fred...@pythonware.com> wrote: > 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
