2005.01.29 15:42 "[Tiff] almost finished hacking libtiff into a convivial shape", by Antoine

2005.01.30 23:30 "Re: [Tiff] almost finished hacking libtiff into a convivial shape", by Sherlog

tif_dirwrite.c:

    tif->tif_diroff = (TIFFSeekFile(tif, (toff_t) 0, SEEK_END)+1) &~ 1;
    diroff = tif->tif_diroff;

for

    if (tif->tif_header.tiff_diroff == 0)
        tif->tif_diroff = 8;
    else
        tif->tif_diroff = (TIFFSeekFile(tif, (toff_t) 0, SEEK_END)+1) &~ 1;

    diroff = 8; //tif->tif_diroff;

And it seems to be working to a point. The problem is that it borks the first couple of hundred scanlines.

The code takes tif_diroff 0 to mean 'append to end of file' but you put a nonzero value there and so libtiff scribbled the IFD over the strip data, just like you told it to.

The libtiff write logic is roughly this:
   <append strip/tile data to existing file>
   <append IFD>
   <append out-of-line IFD values>

In particular, libtiff flushes any remaining strip/tile data before it starts writing the IFD, and when it is done writing the IFD it sets its internal state to a blank new sub-image (i.e. next page).

What you want is
   <append IFD>
   <append all the rest>

But libtiff just doesn't work this way. You could try to hack libtiff so that it buffers the strip/tile data and emits it after the IFD, but this is non-trivial, especially as the libtiff core code is very tightly coupled but basically undocumented and only sparsely commented.

Another - probably easier - way would be to take a libtiff-produced TIFF file and rearrange its contents so that the IFD precedes the data. This is not entirely trivial but to do this you need only some basic knowledge about the TIFF format, since libtiff does all the hard stuff like compressing data, figuring out correct values for the tags and so on. The 'rearrangment' code only needs to bump an offset here and there while it writes the data. An added advantage is that you can 'vet' the IFD and drop (or rewrite) unwanted tags as your particular application dictates, without distorting/disrupting the mature and debugged code in libtiff itself in order to match your particular requirements.

Note: if you have particular requirements regarding the TIFF file layout then there is basically no chance to use off-the-shelf kits, because they all do what they want and tend to insert plenty of extra tags for advertising or just in order to show that they have heard of those tags (NewSubFileType). So you'd have to write custom code in any case in order to postprocess the result. libtiff is the most flexible since you get the source and so you can reuse parts of libtiff for your postprocessing.

Luck++,
Sherlog

Sherlog [Personenkennzahl 250866413515 / Stefan Otto / SO1801-RIPE]