[Image-SIG] python PIL 16-bit tiff files
fredrik at pythonware.com
Sun Apr 25 13:07:05 CEST 2010
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:
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...
On Thu, Apr 22, 2010 at 10:57 PM, Fredrik Lundh <fredrik at pythonware.com> 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.
> 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
>>> 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?
More information about the Image-SIG