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 <fred...@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.blac...@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 <fred...@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 <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
