2005.01.31 00:17 "Re: [Tiff] almost finished hacking libtiff into a convivial shape", by Antoine

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.

Thanks heaps Sherlog,

I have spent the day reading up on the tiff format and ccitt T.6 and now would say I have a pretty good idea of both. I will have a go at what you suggest as opposed to trying to change the way libtiff works. I am very new to this sort of stuff, and new to c so am doing lots of time wasting... certainly any extra pointers on how you think it would be best to proceed would be great. I will be able to do some pretty dodgy things like putting all the data in one strip so pointers to offsets shouldn't be too much work.

My understanding of your suggestion is that I should load the files into memory and then be directly accessing memory locations - probably by copying into char pointers and then recopying back to get what I want in the right places. I will have a talk to the guys at work, though it has been some years since any of them have touched anything as low level as c. At least I will be able to tell the boss that it isn't just me, and that in fact trying to go with libtiff instead of going for a package like imagegear, which we have, btw, and can not do this anyway, or going outside the organisation.

Thanks again, and if you have any other great suggestions (this email has helped me heaps...) then fire away!

Cheers
Antoine