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



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:48 "Re: Photoshop 8.0 and libtiff", by Bob Friesenhahn

On Mon, 9 Feb 2004, Frank Warmerdam wrote:
>
> Bob,
>
> My first thought was, "hey, we already work fine with 4GB files".  But upon
> a bit of review I realize we use unsigned int for toff_t, but a signed int
> for tsize_t.  The comments in tiffio.h mention that tsize_t is int32 and not
> uint32 because some functions return -1.   So, I think that is why uint32
> isn't used now.
>
> I do kind of wonder if the code could be changed somehow to use uint32 for
> tsize_t but recognise 0xffffffff as end-of-file, instead of -1.  There
> couldn't be something 0xffffffff bytes long in a file of 4GB or less anyways
> since there is always some other overhead.

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
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us
http://www.simplesystems.org/users/bfriesen