Re: python PIL 16-bit tiff files

Oops, that patch was broken, due to pilot error.  Here's an incremental fix:

http://hg.effbot.org/pil-2009-raclette/changeset/c3fb89aa181e

Alternatively, just grab the latest PIL/TiffImagePlugin.py and
libImaging/Unpack.c and drop them on top of the existing versions.

</F>

On Sun, Apr 25, 2010 at 1:07 PM, Fredrik Lundh <[email protected]> wrote:
> This isn't really a full solution, but the following patch at least
> allows PIL to read 3x16-bit RGB TIFF files, converting them on the fly
> to 24-bit RGB.  Note that it requires new binaries to handle little
> endian (intel) files:
>
> http://hg.effbot.org/pil-2009-raclette/changeset/45c2debe0fc3
>
> Unfortunately, your sample use "contiguous" pixel storage, which makes
> the descriptor manipulation tricks I mentioned harder to implement
> efficiently for PIL 1.1.7.  I played a bit with libtiff's tiffcp
> utility to see if that could be used as a preprocessor (which is
> otherwise a great way to handle more "obscure" TIFF flavours), but at
> least the version I have doesn't handle 16-bit images well either.  I
> need to think a bit more about this, I think...
>
> </F>
>
> On Thu, Apr 22, 2010 at 10:57 PM, Fredrik Lundh <[email protected]> wrote:
>> 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 <[email protected]> wrote:
>>> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
>>> <[email protected]> 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  -  [email protected]
http://mail.python.org/mailman/listinfo/image-sig