2004.02.24 00:28 "Re: [Tiff] Request for new functions", by Vladimir Pastukhov
- 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.
- 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).