LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
November 2008
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2008.11.16 00:39 "Re: example of (standalone) TIFFRegisterCODEC", by Frank Warmerdam
Brad Hards wrote: > 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. It will mean that any application registering >> 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? Brad, 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