AWARE [SYSTEMS]
AWare Systems, , Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
February 2004

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



New Datamatrix section



Valid HTML 4.01!



Thread

2004.02.09 17:02 "Photoshop 8.0 and libtiff", by Don Ellis
2004.02.09 17:46 "Re: Photoshop 8.0 and libtiff", by Bob Friesenhahn
2004.02.09 18:07 "Re: Photoshop 8.0 and libtiff", by Frank Warmerdam
2004.02.09 19:42 "Re: Photoshop 8.0 and libtiff", by Don Ellis
2004.02.09 19:51 "Re: Photoshop 8.0 and libtiff", by Bob Friesenhahn
2004.02.09 19:58 "Re: Photoshop 8.0 and libtiff", by Frank Warmerdam
2004.02.09 19:59 "Re: Photoshop 8.0 and libtiff", by Thomas J Kacvinsky
2004.02.09 20:18 "Re: Photoshop 8.0 and libtiff", by Chris Cox
2004.02.09 19:48 "Re: Photoshop 8.0 and libtiff", by Bob Friesenhahn
2004.02.09 19:59 "Re: Photoshop 8.0 and libtiff", by Frank Warmerdam
2004.02.09 20:12 "Re: Photoshop 8.0 and libtiff", by Bob Friesenhahn
2004.02.09 20:36 "Re: Photoshop 8.0 and libtiff", by Don Ellis
2004.02.09 20:25 "Re: Photoshop 8.0 and libtiff", by Don Ellis
2004.02.09 20:50 "Re: Photoshop 8.0 and libtiff", by Bob Friesenhahn
2004.02.11 18:39 "Re: Photoshop 8.0 and libtiff", by Don Ellis
2004.02.13 19:11 "Re: Photoshop 8.0 and libtiff", by Don Ellis

2004.02.09 19:59 "Re: Photoshop 8.0 and libtiff", by Frank Warmerdam

Bob Friesenhahn wrote:
> I am sure that this change could be accomplished, however, before any
> steps are taken, the API should be looked at to verify there is any
> advantage from doing so.  32-bit operating systems commonly reserve
> 1GB, or 2GB of the process address space for their own use.  For
> example, Windows provides the application with a maximum 2GB of usable
> address space.  This range is handled by the existing signed size
> type.
> 
> If the API provides access to the strip via a single memory
> allocation, then it will certainly be impossible to access more than a
> 2GB strip on a typical 32-bit OS.  A 64-bit application on a 64-bit OS
> could deal with this just fine except there would be thrashing if
> there is not enough RAM.
> 
> Improving the API to support iterative access to a strip would be a
> superior solution.  Then an unsigned 32-bit offset type and a signed
> 32-bit size type would be more than sufficient.  Does this iterative
> interface already exist?

Bob,

Your point is good, but the "trick" is that libtiff already "auto-splits"
single strip files into more managable strips under some circumstances (it
has to be uncompressed I think).  So, it should be practical to work with
these large one-strip files as long as they aren't compressed.

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