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

2005.01.30 16:34 "Re: [Tiff] almost finished hacking libtiff into a convivial shape", by Antoine

I have managed to disable/change the things I need except for one - the offset to the first IFD. I need it to be 8. I have replaced the lines in 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. When I open with the gimp (2.0) it tells me

...
Tiff: /home/antt/programming/tiff-3.7.1/tools/well.tif: Premature EOL at scanline 199 (got 0, expected 2248)
Tiff: /home/antt/programming/tiff-3.7.1/tools/well.tif: Premature EOL at scanline 200 (got 2247, expected 2248)
Tiff: /home/antt/programming/tiff-3.7.1/tools/well.tif: Bad code word at scanline 201 (x 0)
Tiff: /home/antt/programming/tiff-3.7.1/tools/well.tif: Premature EOL at scanline 201 (got 0, expected 2248)
Tiff: /home/antt/programming/tiff-3.7.1/tools/well.tif: Line length mismatch at scanline 202 (got 2249, expected 2248)

I think I have found the problem... instead of looking for the end of the IFD to start putting image data in it must be hardcoded to start at the end of the header, thus giving:

antt@tux tools $ tiffdump ooo.tif

ooo.tif:
Magic: 0x4949 <little-endian> Version: 0x2a
Directory 0: offset 19030 (0x4a56) next 0 (0)
SubFileType (254) LONG (4) 1 <0>
ImageWidth (256) SHORT (3) 1 <2248>
ImageLength (257) SHORT (3) 1 <3120>
BitsPerSample (258) SHORT (3) 1 <1>
Compression (259) SHORT (3) 1 <4>
Photometric (262) SHORT (3) 1 <0>
FillOrder (266) SHORT (3) 1 <1>
StripOffsets (273) LONG (4) 1 <8>
Orientation (274) SHORT (3) 1 <1>
SamplesPerPixel (277) SHORT (3) 1 <1>
RowsPerStrip (278) LONG (4) 1 <100000>
StripByteCounts (279) LONG (4) 1 <19021>
XResolution (282) RATIONAL (5) 1 <300>
YResolution (283) RATIONAL (5) 1 <300>
PlanarConfig (284) SHORT (3) 1 <1>
ResolutionUnit (296) SHORT (3) 1 <2>

antt@tux tools $ tiffdump ooo2.tif

ooo2.tif:
Magic: 0x4949 <little-endian> Version: 0x2a
Directory 0: offset 8 (0x8) next 0 (0)
SubFileType (254) LONG (4) 1 <0>
ImageWidth (256) SHORT (3) 1 <2248>
ImageLength (257) SHORT (3) 1 <3120>
BitsPerSample (258) SHORT (3) 1 <1>
Compression (259) SHORT (3) 1 <4>
Photometric (262) SHORT (3) 1 <0>
FillOrder (266) SHORT (3) 1 <1>
StripOffsets (273) LONG (4) 1 <8>
Orientation (274) SHORT (3) 1 <1>
SamplesPerPixel (277) SHORT (3) 1 <1>
RowsPerStrip (278) LONG (4) 1 <100000>
StripByteCounts (279) LONG (4) 1 <19021>
XResolution (282) RATIONAL (5) 1 <300>
YResolution (283) RATIONAL (5) 1 <300>
PlanarConfig (284) SHORT (3) 1 <1>
ResolutionUnit (296) SHORT (3) 1 <2>

In the second file both the IFD and the image start at the same place. Now clearly the IFD is there, so that means that the image isn't - or at least doesn't start there. This is no real problem for uncompressed data, as unless I magnify right to the pixel level the first half or so of the first line is all that will be borked. Software knows nothing about this either cos all values are legal. A different story with fax-compressed, and even moreso with T.6, as a single bit error can ruin a whole image. The file size with one row is also telling - there is 19021 bytes of image, 8 bytes of header and another hundred or so of IFD. Alas the total file size for the second file is only 19029... If anyone has any good ideas on where I should look to tell libtiff to start after the IFD and not at the first possible byte, then I would be much obliged... I *really* don't want to tell my boss to get an expensive external software place to do it after all my promises about open source!

Cheers
Antoine