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

2005.10.24 20:23 "Re: [Tiff] TIFFWriteEncodedTile() space overhead", by Andrey Kiselev

On Mon, Oct 24, 2005 at 07:51:05PM +0300, Шебеко Евгений wrote:

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.

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,

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


Your analisys is quite reasonable. There is a flaw in this pretty dumb updating scheme (my fault, of course). I will think, how to improve this algorithm for your case.


Andrey V. Kiselev

Home phone: +7 812 5970603 ICQ# 26871517