
Thread
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.
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.
Eugene,
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.
Regards,
Andrey
--
Andrey V. Kiselev
Home phone: +7 812 5970603 ICQ# 26871517