[Image-SIG] Group4 Tiff Decoder?

[Glenn Linderman]

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 <gtaylor at 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