AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2004.09.08 02:15 "[Tiff] TIFF Property Sheet Shell Extension beta", by Ross A. Finlayson
[...]
2004.09.16 19:36 "Re: [Tiff] BigTIFF Tag Value Count issue", by Joris
2004.09.16 19:38 "Re: [Tiff] BigTIFF Tag Value Count issue", by Frank Warmerdam
2004.09.17 00:32 "Re: [Tiff] BigTIFF Tag Value Count issue", by Joris
2004.09.16 19:12 "[Tiff] BigTIFF Tag Value Count issue", by Joris
2004.09.17 01:54 "Re: [Tiff] BigTIFF Tag Value Count issue", by Bob Friesenhahn
2004.09.17 06:35 "Re: [Tiff] BigTIFF Tag Value Count issue", by Rob van den Tillaart
2004.09.17 14:53 "Re: [Tiff] BigTIFF Tag Value Count issue", by Joris
[...]

2004.09.17 00:32 "Re: [Tiff] BigTIFF Tag Value Count issue", by Joris

> > This may be a poor argument, since alignment inside a file really might not be

> > that important.
>

> My opinion on this is that alignment inside a file is just as > important/useful as alignment in memory since the file may be memory

> mapped, and then all the limitations which apply to memory access also > apply to file access via that memory map.

Partially true. Well, completely true, I guess, if memory mapping is involved. However, memory mapping of files of a format that is specifically designed to be >4 gig, might not be a good idea. In windows, you can have a 'window' of a file memory mapped, called 'view' IIRC, limiting stress on address space, but this too, will not be a good idea in the BigTIFF case, since TIFF is inherently completely random access and so with this scheme you might have to swap to another 'window' for just about every new read.

As a sidenote, slightly of topic as to this particular BigTIFF issue, but on topic as to the memory mapping... I've never quite understood why anyone would want to memory map a TIFF file for use in eg LibTiff. I believe that there is no speed or system advantage. The main advantage of memory mapping, I believe, is merely the convenience of accessing memory instead of having to do IO all the time, which is a bit less troublesome code logic... but, if your codec is build to accommodate all this IO, why would one next essentially wire IO routines to accommodate memory mapping?

Or am I wrong in thinking there is no actual speed/system/cache/management advantage?

> It is not necessary to declare that at the value needs to be 8 bytes

> in order to accomplish desired alignment since you can simply add in 4 > unused pad bytes.

The value in question needs to be *4* bytes in order to accomplish alignment of the next 8 byte value. I take it you mean that it doesn't need to be *4* bytes in order to accomplish alignment, since one can make it 8 bytes instead, plus add another 4 padding bytes.

That is indeed the case, so there is an extra option. Allow me to resume and index all three options, then

Option 0: stick with 4 byte tag count members (alignment, tag data <= 4 gig, Frank's choice)

Option 1: make it an 8 byte tag count (no alignment, tag data > 4 gig allowed) Option 2, courtesy of Bob: make it 8 byte tag count, add 4 padding bytes (alignment, tag data > 4 gig allowed)

Can I put you down as an option 2 vote, or were you merely signalling the option?

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