2002.03.21 09:00 "insert and replace in multipage TIFFs", by Fred Wobus
I am currently trying to construct a TIFF coder that writes multipage TIFF image files using libtiff 3.5.7.
I have with no problem at all implementing the simple "append" action. The existing TIFF file is opened with mode "a" and the TIFFTags and data are written as usual.
The new IFD is properly chained on the end when I call TIFFClose();
What I am now trying to add are the multipage actions "insert" and "replace". They are planned to do this:
"insert at the pagenumber P"
Encode the image in a new IFD as usual, but now it needs to be linked into the IFD chain, that it will end up at position P. The actual data for the new image can be appended to the end of the file, I just need to adjust the nextdir offset
of the image at position P and the new nextdiroffset of the new IFD need to point to the image at position P+1.
As an addition, it would be logical for empty IFDs to be created if the requested pagenumbers is greater than the current number of images in the file. For example I want to insert an image at page 8 (start counting at 1) to a TIFF file that has only 6 images. I would end up with a IFD #6 linking to an empty IFD, and this empty IFD would link to the new image at position 8.
Do the commonly used multipage capable decoders deal with empty IFDs? Are they legal by the spec?
"replace the image at pagenumber P"
As with "insert" above, the image IFD will be appended to the end, but the IFD at page P-1 has to be adjusted to point to the new image which in turn will point to the image at page P+1. The original image at position P is therefor lost from the chain and can no longer be accessed. I do not attempt to do any garbagecollection on the fly, as I am dealing with TIFFs that potentially store 1000's of images in one file.
I found the API function UnlinkDirectory() in tif_dir.c which could help me with the second part, but again I am stuck to adjust an IFD nextdiroffset right in the middle of the chain.
Any suggestions in libtiff-style C or pseudocode would be much appreciated.
Thanks, Fred Wobus
This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted.