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 05:55 "Re: [Tiff] RFC: fast 'copy free' tiff decoding", by Ron
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 07:54 "Re: [Tiff] RFC: fast 'copy free' tiff decoding", by Joris

Ron,

How to handle subsets of the available data is probably the most pressing one. Without handling them more than necessary and without losing data that I have incomplete knowledge about.

May I resume your goal like this...?

LibTiff offers no generic access to TIFF (Tag) data as it is. Instead, it goes a long way interpreting (checking tag datatype and count for starters), and next offers tag specific access that may be substantially different from the original tag data (like is the case with the Colormap tag, or even the count of the BitsPerSample tag). That is fine if your code at some point really needs a convinient single value for specifically the BitsPerSample tag, but it is a bridge too far if you really need more generic access to the exact TIFF (Tag) data of any tag, in any TIFF.

What is needed is something like 'two layers' of data access here. The bottom one being the one you propose to add, that simply offers exactly what is there without doing any sorts of interpreting. This layer does not even need tag definitions, it is tag ignorant. The next layer, is the layer we're used to in LibTiff, the layer that is friendly in checking the tag values and interpreting them, offering access to more higher level structures depending on the specific tag in question.

If this is your actual goal, I must say I find it a good and natural and correct thought... At the risk of sounding boring: I've done the same in my native Delphi TIFF codec. But it is a major rewrite to get it into LibTiff...

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.

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html