AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 2005

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2005.01.29 15:42 "almost finished hacking libtiff into a convivial shape", by <melser.anton@gmail.com>
2005.01.30 09:00 "Re: almost finished hacking libtiff into a convivial shape", by Ross A Finlayson
2005.01.30 10:00 "Re: almost finished hacking libtiff into a convivial shape", by <melser.anton@gmail.com>
2005.01.30 16:34 "Re: almost finished hacking libtiff into a convivial shape", by <melser.anton@gmail.com>
2005.01.30 23:30 "Re: almost finished hacking libtiff into a convivial shape", by <sherlog@t-online.de>
2005.01.31 00:17 "Re: almost finished hacking libtiff into a convivial shape", by <melser.anton@gmail.com>

2005.01.30 23:30 "Re: almost finished hacking libtiff into a convivial shape", by <sherlog@t-online.de>

> 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]