AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2011.03.28 18:22 "[Tiff] TIFFReadCustomDirectory and TIFFWriteCustomDirectory", by Steve Underwood
2011.03.28 19:32 "Re: [Tiff] TIFFReadCustomDirectory and TIFFWriteCustomDirectory", by Andreas Kleinert
2011.03.29 00:59 "Re: [Tiff] TIFFReadCustomDirectory and TIFFWriteCustomDirectory", by Steve Underwood
2011.03.29 13:28 "Re: [Tiff] TIFFReadCustomDirectory and TIFFWriteCustomDirectory", by Andreas Kleinert

2011.03.29 00:59 "Re: [Tiff] TIFFReadCustomDirectory and TIFFWriteCustomDirectory", by Steve Underwood

Hi,

Thanks. That gets me a little bit further. TIFFCurrentDirOffset() does give me the offset of the custom directory. However, the actual directory information being written into IFD block seems to be garbage. So, the next question is how do I control what goes into that custom directory section? TIFFWriteCustomDirectory() seems to scan the current directory info in memory, and output anything which is set and which has the FIELD_CUSTOM tag. However, what I see in the file doesn't seem to make any sense as a TIFF directory.

Steve

On 03/29/2011 03:32 AM, Andreas Kleinert wrote:

when writing a new directory, TIFFWriteCustomDirectory() puts it to the end of the file. Furthermore, the offset return value (in&offset) seems to be equivalent to tif->tif_nextdiroff - as the new directory is the last one in the file, zero IMHO makes perfect sense?!

I just wonder if the API intentionally was designed this way, or whether it's a bug. However, when just following this logic then TIFFCurrentDirOffset() should return what you expect.

Is there any error output?

I have started using TIFFReadCustomDirectory to access some special IFD blocks in TIFF-FX files. That seems to be working OK, but I can't find a way to do the opposite, and write similar special IFD blocks. I found TIFFWriteCustomDirectory, but it doesn't seem to be documented, and doesn't seem to be a corollary of TIFFReadCustomDirectory. When I try calling TIFFWriteCustomDirectory(tiff_file,&offset); it always returns zero for the offset, and I can't seem to find a related block of tags in the resulting file, if I do a hex dump of that file. Can anyone help?