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
October 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.10.24 16:51 "TIFFWriteEncodedTile() space overhead", by Eugene Shebeko
2005.10.24 20:23 "Re: TIFFWriteEncodedTile() space overhead", by Andrey Kiselev
2005.10.25 06:56 "Re: TIFFWriteEncodedTile() space overhead", by Eugene Shebeko

2005.10.24 16:51 "TIFFWriteEncodedTile() space overhead", by Eugene Shebeko

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.