2008.11.01 07:10 "[Tiff] example of (standalone) TIFFRegisterCODEC", by Brad Hards

2008.11.16 00:39 "Re: [Tiff] example of (standalone) TIFFRegisterCODEC", by Frank Warmerdam

On Saturday 15 November 2008 03:18:09 am you wrote:

I believe you will just need to manually install tiffiop.h and any other include files you need. mean that any application registering It will

custom codecs will not be able to use "standard" libtiff sdk packages on things like linux which lack the tiffiop.h include file.

That is a problem. I'm trying to provide the MODI_VECTOR codec (which requires an EMF renderer) for the Okular viewer in KDE. We ship sources, not binaries. Distributions turn those into packages (with a dependency on a single copy of the libtiff shared library).

I can live with "any version of libtiff after X", but I can't live with "specific version X", because libtiff gets upgraded in different cycles to okular generators.

I'm also very reluctant to include a specific version of libtiff into okular.

I think I understand why you don't want to always install tiffiop.h (or otherwise expose the struct tiff definition) - it is internal, and subject to change.

I think the way to fix this is to complete the abstraction in libtiff. My current thinking is that there should be accessors for each thing that a codec needs to do (e.g. to set function pointers or obtain data). Those accessors would go into tiffio.h or perhaps into a new tiffcodec.h. This would be intended for external codecs (although there wouldn't be anything stopping built-in codecs using the API additions if desired).

Does this look like a reasonable way forward?


I have not reviewed the details of the interface between libtiff and codecs. Generally speaking making CODECs pluggable without private knowledge of the internals of libtiff seems like a good idea. From what I have seen, some of the CODECs end up dipping quite deep into libtiff - perhaps mostly because of hacky things about the bugs related to the compression formats. So I'm not sure how achievable it is to abstract the interface cleanly.

Assuming the plan makes sense, there is still the issue who of will do the work and who will take responsibility for integrating the changes into libtiff. I am concerned it may imply a lot of work, and churn at a time when we are not doing so well at making the leap to bigtiff with some other major internal overhauls done at the same time. But if you want to take a crack at it, I'm confident that the team would at least consider the changes.

Best regards,


I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam

and watch the world go round - Rush    | Geospatial Programmer for Rent