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
January 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.01.02 08:55 "tiff question - performance on large files", by Natalya Katz
2005.01.03 14:25 "Re: tiff question - performance on large files", by Frank Warmerdam
2005.01.21 09:32 "Re: tiff question - performance on large files", by <sherlog@t-online.de>
2005.01.05 21:49 "Re: tiff question - performance on large files", by Ian Ameline

2005.01.03 14:25 "Re: tiff question - performance on large files", by Frank Warmerdam

On Sun, 2 Jan 2005 10:55:23 +0200, Natalya_Katz@amat.com wrote:
>  
> I tried to use libtiff for win32 (I'm working on Windows 2000, VC 6). The
> problem is the poor performance in case of very large files (for example,
> appending 100 more gray images 64x64 to tiff file with 60000 images - all of
> them are gray 64x64 takes about 15 minutes). I tried to use
> TIFFWriteScanline or TIFFWriteRawStrip, I tried to open the file with "am"
> flag for memory map files - nothing helped. 
>  
> The question is can I improve the performance significantly (I'm not talking
> about 10-20%)? Can the misusage of libtiff be a reason of poor performance,
> or oppositely it's a well-known problem on win 2000 platform? 

Natalya, 

I suspect the problem is due to the way libtiff just "walks" the list
of images when doing various kinds of operations rather than 
maintaining a master in-memory list of all availalbe image directories.
The current approach isn't really a problem with only a few images, 
but might well result in some quadratic performance problems when
working with as many as 60000 appended images.  

If you could prepare a test mainline that internally generated 60000
images, and that demonstrated particularly bad performance then we
might be able to look into the issue but I am not really interested in
substantially changing libtiff for this use case which is very uncommon
(in my world at least).  You might find you need to do a few hacks
on libtiff or be very careful in how you use it to get decent performance
with so many appended images. 

It is also possible that if you images are very small that the problem
is just the amount of overhead in how libtiff processes image
directories.   But without a working program to check it is hard to 
know what is hitting you. 

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent