AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2005.03.30 10:19 "Re: [Tiff] RFC: fast 'copy free' tiff decoding", by Priyanshu Sharma
[...]
2005.03.30 07:54 "Re: [Tiff] RFC: fast 'copy free' tiff decoding", by Joris
2005.03.30 11:38 "Re: [Tiff] RFC: fast 'copy free' tiff decoding", by Ron
2005.03.30 15:17 "Re: [Tiff] RFC: fast 'copy free' tiff decoding", by Bob Friesenhahn
[...]

2005.03.30 15:17 "Re: [Tiff] RFC: fast 'copy free' tiff decoding", by Bob Friesenhahn

If I'm interpreting your goals correctly, I'm afraid you might be confusing the issue with all this talk about memory maps and other implementation issues. I've personally always considered memory mapping TIFFs a bad idea. There's no telling what size files you might need to handle, especially with the new BigTIFF format. You could need to eat 8 gig of address space on a machine that is theoretically limited to 2 gig for memory maps, and shares this 2 gig with other applications, like I think is the case on common windows systems. Moreover, there seems very little benefit to abusing address space like this, as opposed to good ol' plain file IO, especially given the fact that you'll need to aling and byteswap in seperately allocated memory blocks anyhow.

It is not necessary to map the entire file at once. A relatively small "peephole" of memory mapping (e.g. 256K) may be used to access large files. There is not much overhead associated with the map/unmap process. The key thing is if the memory mapping API is able to support large files. For POSIX mmap(), this is determined by the size of the off_t type. For Large File System (LFS) builds, or POSIX operating systems which support large files by default, off_t has at least 63 usable bits.

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/