- 2004.09.16 14:44 "Re: [Tiff] reading private subdirs", by Bob Friesenhahn
-
2004.09.16 14:55 "Re: [Tiff] reading private subdirs", by Frank Warmerdam
- 2004.09.16 15:09 "Re: [Tiff] reading private subdirs", by Bob Friesenhahn
-
2004.10.01 19:07 "[Tiff] Re: reading private subdirs", by Chris Losinger
- 2004.10.01 22:52 "Re: [Tiff] Re: reading private subdirs", by Bob Friesenhahn
- 2004.10.02 14:27 "Re: [Tiff] Re: reading private subdirs", by Chris Losinger
2004.10.03 16:09 "Re: [Tiff] Re: reading private subdirs", by Frank Warmerdam
I think that the pdsdirread.c can be moved to the core at some point. And it is very easy to add this item to the developers' TODO: you should just create appropriate Bugzilla report ;-)
Andrey,
The pdfdirread.c code depends on the caller providing a list of TIFFFieldInfo definitions for all the fields they want to be able to read. I feel this is contrary to the newer concept of libtiff "auto-defining" previously undefined fields. I also think that having to provide your own "setField" function to is ackward, and contrary to the simplifying assumptions that libtiff tries to provide.
Instead, I would prefer to leave the pds stuff in the contrib section rather that being part of the core API, and work towards a mechanism to call TIFFReadDirectory() in a special "non-image" mode that doesn't require any particular fields but can still take advantage of the new auto-define approach.
So, for the time being, I would like to keep the pds code working but aim for a better approach... possibly after we finish the BigTIFF transition.
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