2004.02.23 12:55 "[Tiff] Request for new functions", by Vladimir Pastukhov

2004.02.24 00:28 "Re: [Tiff] Request for new functions", by Vladimir Pastukhov


  1. Why not just implement all image access (on a block by block basis) for PIL with libtiff? It seems to me there has been a longstanding desire for a libtiff based PIL TIFF driver in addition to the existing custom one.

This will require much more resources than I can afford at this time. On the other hand, current codecs-based patch is rather simple and is being used by a considerable amount of people for seven months already. The only problem with it seen so far is its dependence on the libtiff internals.

Another cause is that inside PIL file/IO manipulation and codecs are separated, so writing full plugin would require direct access to libtiff codecs alike. Doing it in another way can accidentally turn into a tricky task.

  1. If not building a fully libtiff based plugin, why not just adapt the codec code you need from libtiff into the pil plugin instead of using a full libtiff just for the codecs.

This will need additional work to adapt new codecs and features in the future.

Also I prefer library linking over copy&paste solutions. I have seen several application containing (almost) the same tif_fax3 files and this suggested me that allowing people to link codecs from the library is good in general.

I guess my general concern is that libtiff wasn't really intended to be a "codec engine" for applications that want to use the codecs in

A separate codec engine would be a big plus, but is does not exist yet. Then, why not to isolate libtiff codecs into such a library one day?

Perhaps it is this chunking I don't understand. Lots of applications want to read TIFF files in chunks, but libtiff generally requires them to read a whole strip or block at a time, with a special case for line by line reading I think.

I'll look into this, and it seems like PNG plugin already does something like that. Though, AFAIR, I've seen some (large) TIFF files consisting of a single "strip", which is not memory-friendly (still, acceptable in most cases).

Best regards,

Vladimir Pastukhov