On approximately 5/20/2009 5:34 AM, came the following characters from
the keyboard of Fredrik Lundh:
On Tue, May 19, 2009 at 9:52 PM, Greg Taylor <gtay...@clemson.edu> wrote:
Googling around, I keep seeing mention over the years that PIL has no Group4
tiff decoder. I saw mention of a patch for PIL 1.1.4, but it doesn't look
like this ever made it into upstream. Perhaps I haven't dug deep enough, but
can anyone enlighten me to what the situation is currently with Group4 Tiff
decoding? I'd love to be able to use PIL for some mission critical stuff at
work, but this is a show-stopper due to our setup.
The patch depended on too many libtiff internals for me to feel
confident that it was a good idea to add it to PIL's standard
distribution;
So if a patch were produced that depended only on published libtiff
APIs, would it be likely to be accepted? I'm not sure I'm capable of
producing such a patch, unfortunately, because I've never looked at PIL
internals, and I've shuddered every time I've looked at libtiff APIs...
but if it would be considered a useful addition to PIL, perhaps someone
would, or perhaps someday I would. I mean, it would certainly be useful
to me, but there is no point in thinking further along this line if it
is already known that the any TIFF G4 patch would be rejected because of
some negative perspective regarding the utility of adding support for G4
to PIL.
there are a few other bindings, but none that feels
complete enough.
I don't understand this remark. What are the other bindings, and what
feels incomplete about them? Were someone to want to follow up, to
produce a PIL-G4 capability, to see if it would be better to start from
scratch, or start from one of these bindings, it would be good to better
understand these "feelings".
In addition to the solution already posted, you can use "tiffcp -c
none -r -1 %s %s" % (myfilename, tempfilename) to unpack to a
temporary file; this is fairly efficient since PIL can then memory map
the resulting image file. The tiffcp utility is shipped with libtiff.
This solution seems to produce a way to read TIFF G4 files, but not to
write them; clearly one could write a temporary TIFF, and then construct
a tiffcp command to compress it. But does that then mean shipping
tiffcp with the application, or depending on its separate installation
and being able to find it from the application? If so, that is somewhat
cumbersome, and error prone. Also, it adds a requirement for extra disk
storage, since the compressed files are quite small compared to the
uncompressed files... I'm not sure I can endorse the "fairly efficient"
comment, because of the need to write the large uncompressed files to
disk, if using such a technique. Of course, for small files (a few
letter size pages at 300-600 dpi), one at a time, it is not noticeable
compared to user interaction, but when doing batch processing of book
files containing hundreds of pages, it is definitely noticeable.
I'm presently using this sort of technique, but only for my own use on
my own computer, and using ImageMagick which is probably less efficient
than using tiffcp (but since ImageMagick has a decent Perl API, and I'm
coming from that background, in Perl I could use ImageMagick APIs rather
than file manipulations via the command line and the system API). From
Python, I should likely convert to using tiffcp for these conversions,
for a bit of increased performance, but that doesn't solve the
cumbersome API nor the temporary file issues.
--
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
_______________________________________________
Image-SIG maillist - Image-SIG@python.org
http://mail.python.org/mailman/listinfo/image-sig
