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

[Fredrik Lundh]

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 <fredrik at pythonware.com> wrote:
> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
> <dan.blacker at 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>
>