Hi Fredrik,<br><br>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.<br><br>When running my script, I no longer get errors when reading my 16-bit tiff file in.<br>
<br>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):<br><br><div style="margin-left: 40px;"><i> File "16bittest.py", line 147, in <module><br>
im1 = im0.convert ("L", dither=Image.NONE)<br> File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 654, in convert<br> self.load()<br> File "/usr/lib/python2.6/dist-packages/PIL/ImageFile.py", line 180, in load<br>
d = Image._getdecoder(self.mode, d, a, self.decoderconfig)<br> File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 374, in _getdecoder<br> return apply(decoder, (mode,) + args + extra)<br>ValueError: unknown raw mode</i><br>
</div><br>Am I missing a value to pass into convert() to tell it to make an 8bit file?<br><br>Thanks,<br><br><br><div class="gmail_quote">On 25 April 2010 13:48, Fredrik Lundh <span dir="ltr"><<a href="mailto:fredrik@pythonware.com" target="_blank">fredrik@pythonware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Oops, that patch was broken, due to pilot error. Here's an incremental fix:<br>
<br>
<a href="http://hg.effbot.org/pil-2009-raclette/changeset/c3fb89aa181e" target="_blank">http://hg.effbot.org/pil-2009-raclette/changeset/c3fb89aa181e</a><br>
<br>
Alternatively, just grab the latest PIL/TiffImagePlugin.py and<br>
libImaging/Unpack.c and drop them on top of the existing versions.<br>
<font color="#888888"><br>
</F><br>
</font><div><div></div><div><br>
On Sun, Apr 25, 2010 at 1:07 PM, Fredrik Lundh <<a href="mailto:fredrik@pythonware.com" target="_blank">fredrik@pythonware.com</a>> wrote:<br>
> This isn't really a full solution, but the following patch at least<br>
> allows PIL to read 3x16-bit RGB TIFF files, converting them on the fly<br>
> to 24-bit RGB. Note that it requires new binaries to handle little<br>
> endian (intel) files:<br>
><br>
> <a href="http://hg.effbot.org/pil-2009-raclette/changeset/45c2debe0fc3" target="_blank">http://hg.effbot.org/pil-2009-raclette/changeset/45c2debe0fc3</a><br>
><br>
> Unfortunately, your sample use "contiguous" pixel storage, which makes<br>
> the descriptor manipulation tricks I mentioned harder to implement<br>
> efficiently for PIL 1.1.7. I played a bit with libtiff's tiffcp<br>
> utility to see if that could be used as a preprocessor (which is<br>
> otherwise a great way to handle more "obscure" TIFF flavours), but at<br>
> least the version I have doesn't handle 16-bit images well either. I<br>
> need to think a bit more about this, I think...<br>
><br>
> </F><br>
><br>
> On Thu, Apr 22, 2010 at 10:57 PM, Fredrik Lundh <<a href="mailto:fredrik@pythonware.com" target="_blank">fredrik@pythonware.com</a>> wrote:<br>
>> Oh, missed that there was one in your first post. I'm a bit busy<br>
>> right now, but I'll take a look when I find some spare time.<br>
>><br>
>> </F><br>
>><br>
>> On Thu, Apr 22, 2010 at 10:56 PM, Fredrik Lundh <<a href="mailto:fredrik@pythonware.com" target="_blank">fredrik@pythonware.com</a>> wrote:<br>
>>> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker<br>
>>> <<a href="mailto:dan.blacker@googlemail.com" target="_blank">dan.blacker@googlemail.com</a>> wrote:<br>
>>>> Hey guys,<br>
>>>><br>
>>>> Thanks for your input,<br>
>>>><br>
>>>> The image is only of a tiny cropped area of a long strip of color kodachrome<br>
>>>> film - I will send a better example with some more color in it when I get a<br>
>>>> chance.<br>
>>>><br>
>>>> I was under the impression that PIL handled 16 bit images (experimentally)<br>
>>>> but does this only apply to 16-bit grayscale images?<br>
>>>><br>
>>>> Am I going up a dead end trying to read my images with PIL?<br>
>>><br>
>>> The current PIL release only supports 8 and 32-bit/pixel internal<br>
>>> storage; that's enough to hold e.g. RGB triplets or 32-bit signed<br>
>>> integers, but not 3x16 bit pixels. I'd love to support more storage<br>
>>> formats (machines are a lot bigger now than when the internal,<br>
>>> intentionally very simple storage model was designed) including HDR<br>
>>> formats (float16 etc), but rearchitecting the internals without<br>
>>> breaking all existing code is a pretty big project...<br>
>>><br>
>>> There is some limited support for 16-bit storage, by packing two<br>
>>> pixels per 32-bit storage unit, but not all operations support this<br>
>>> (it's mainly intended to support working with huge, memory mapped<br>
>>> single-layer images, such as satellite data).<br>
>>><br>
>>> There are some non-standard tricks that may help you with your<br>
>>> specific case, though. All codecs do things in two steps; the first<br>
>>> is to identify the file format and build a descriptor of where the<br>
>>> image data is in the file (the "tile" map). The second step then<br>
>>> loads pixel data on demand, using that descriptor. You might be able<br>
>>> to tweak the descriptor before loading the image, to load one layer at<br>
>>> a time. Do you have any samples?<br>
>>><br>
>>> </F><br>
>>><br>
>><br>
><br>
</div></div></blockquote></div><br>