2005.10.24 16:51 "[Tiff] TIFFWriteEncodedTile() space overhead", by Шебеко Евгений

2005.10.24 16:51 "[Tiff] TIFFWriteEncodedTile() space overhead", by Шебеко Евгений

Hello.

I write uncompressed RGB image using TIFFWriteEncodedTile() And I get mostly double space overhead in result tiff file. If keep in mind that file should be 800MB but I get 1600MB it is a subject to think.

Why it happens.

I write same tile twice. And I think it's normal. I have at one time one part of tile and in other time another part of the tile. So I should call TIFFWriteEncodedTile() twice for a same tile.

Looking inside libtiff code.

tsize_t
TIFFWriteEncodedTile(TIFF* tif, ttile_t tile, tdata_t data, tsize_t cc)
{
  ...

        // it is the source of my problems
        if( td->td_stripbytecount[tile] > 0 )
        {
            /* if we are writing over existing tiles, zero length. */
            td->td_stripbytecount[tile] = 0;

            /* this forces TIFFAppendToStrip() to do a seek */
            tif->tif_curoff = 0;
        }
  ...
}

This is a question. Why I need to seek a new space for my tile if the actual size of tile not changed?

Then looking at the function that actually write tile to disk

static int
TIFFAppendToStrip(TIFF* tif, tstrip_t strip, tidata_t data, tsize_t cc)
{
  ...
  //now tif->tif_curoff is 0 and we need to seek a new space
  if (td->td_stripoffset[strip] == 0 || tif->tif_curoff == 0) {
  ....
    if (td->td_stripoffset[strip] != 0) {
       /*

       * Prevent overlapping of the data chunks. We need
       * this to enable in place updating of the compressed
       * images. Larger blocks will be moved at the end of
       * the file without any optimization of the spare
       * space, so such scheme is not too much effective.
       */
       if (td->td_stripbytecountsorted) {

          if (strip == td->td_nstrips - 1
              || td->td_stripoffset[strip + 1] <
                 td->td_stripoffset[strip] + cc) {
                 td->td_stripoffset[strip] =
                     TIFFSeekFile(tif, (toff_t)0,
                                        SEEK_END);
                  }
       ....
       }
       ....
}

It is another question. In which conditions
  td->td_stripbytecountsorted flag is set?
And why we try to seek a new place beliving that there is no more data
 between td->td_stripoffset[strip] and td->td_stripoffset[strip + 1]
 ???

It is against the TIFF6 standart, isn't it?

And maybe it could happens. If I write tile in order like this [strip]

[strip+1]
[strip+3]
[strip+1] - tile need more data (go at the end of file)
[strip] -tile need more data. It is [strip+3] inside
         [strip] and [strip+1]. But this algorithm does not detect it.

Buy the way. It is not hard to fix it if first consulting with developers of libtiff library.