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

[Dan Blacker]

I'm a bit unfamiliar with updating / installing things in Linux.

I downloaded the latest source for imaging (which I assume contains the
latest 'libImaging/Unpack.c') from here:

$ hg clone http://hg.effbot.org/pil-2009-raclette

and ran the setup.py install over my existing version.

Have I done this correctly, or am I missing something to rebuild the imaging
module?

Thanks again




On 25 April 2010 19:04, Fredrik Lundh <fredrik at pythonware.com> wrote:

> I'm afraid you need to rebuild the _imaging module; the patch touches
> libImaging/Unpack.c too (without that, you can only read big-endian 48-bit
> RGB files; that is, files that start with MM instead of II).
>
> </F>
>
>
> On Sun, Apr 25, 2010 at 5:53 PM, Dan Blacker <dan.blacker at googlemail.com>wrote:
>
>> Hi Fredrik,
>>
>> Thanks for taking a look at this, I have downloaded the latest PIL source
>> and installed it, and replaced the TiffImagePlugin.py that was in pyShared
>> with the latest one.
>>
>> When running my script, I no longer get errors when reading my 16-bit tiff
>> file in.
>>
>> I do however now get an error when I try and convert and make a grayscale
>> copy of my file, in the middle of my script. (this should be 8bit):
>>
>> *  File "16bittest.py", line 147, in <module>
>>     im1 = im0.convert ("L", dither=Image.NONE)
>>   File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 654, in
>> convert
>>     self.load()
>>   File "/usr/lib/python2.6/dist-packages/PIL/ImageFile.py", line 180, in
>> load
>>     d = Image._getdecoder(self.mode, d, a, self.decoderconfig)
>>   File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 374, in
>> _getdecoder
>>     return apply(decoder, (mode,) + args + extra)
>> ValueError: unknown raw mode*
>>
>> Am I missing a value to pass into convert() to tell it to make an 8bit
>> file?
>>
>> Thanks,
>>
>>
>>
>> On 25 April 2010 13:48, Fredrik Lundh <fredrik at pythonware.com> wrote:
>>
>>> 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 <fredrik at pythonware.com>
>>> 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 <
>>> 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.
>>> >>
>>> >> </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>
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100426/966b7f52/attachment.html>