LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
April 2010
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
Thread
2010.04.01 21:49 "Re: TIFFReadScanline and large compressed one-strip files", by Olivier Paquet
On Thu, Apr 1, 2010 at 5:12 PM, Frank Warmerdam <warmerdam@pobox.com> wrote: > My client is finding that in some cases on 32bit systems there isn't 290MB > of contiguous memory available and would like a way avoiding prereading the > whole strip. > > Does anyone have any suggestions for this? You mean 290 MB of address space? Or are you on a system without virtual memory? If it's the former, you could decode the file in a separate process. Something simple like tiffcp or some program you'd write which would send the decoded pixels back through IPC. > I see that currently TIFFReadScanline() calls TIFFSeek() which loads the > appropriate data into the working buffer. I'm wondering if I could load > just part of the data into the raw buffer based on knowledge of what > scanline I want. Perhaps loading enough raw data that I'm guaranteed to > satisfy all the raw data needed for one scanline (say 2*uncompressed size > plus 500 bytes). That might do for the first scanline but as you move further in the file, you'll still need all the data from the start to run the decoder up to the point where it produces your scanline. > I'm concerned that I would need to complicate the management of the currently > loaded raw data considerably to handle this sort of rolling buffering. Does > it seem ill advised to even try? I think so as it would involve also changing the decompressor interface and code as far as I can tell. I second Tom's comment about a good whack :) Olivier