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 <fred...@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 <fred...@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 <fred...@pythonware.com> >> wrote: >>> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker >>> <dan.blac...@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> >>> >> > _______________________________________________ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
