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
May 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.05.27 01:15 "large TIFF - two alternatives", by Steve Carlsen
2004.05.27 07:30 "Re: large TIFF - two alternatives", by Andrey Kiselev
2004.05.27 15:02 "Re: large TIFF - two alternatives", by Steve Carlsen
2004.05.27 09:25 "Re: large TIFF - two alternatives", by Rob Tillaart
2004.05.27 14:00 "Re: large TIFF - two alternatives", by Steve Carlsen
2004.05.27 10:43 "Re: large TIFF - two alternatives", by John Aldridge
2004.05.27 12:49 "Re: large TIFF - two alternatives", by Andrey Kiselev
2004.05.27 13:05 "Re: large TIFF - two alternatives", by Frank Warmerdam
2004.05.27 18:31 "Re: large TIFF - two alternatives", by Chris Cox
2004.06.01 11:50 "Re: large TIFF - two alternatives", by John Aldridge
2004.06.01 15:46 "Re: large TIFF - two alternatives", by Steve Carlsen
2004.06.01 16:27 "Re: large TIFF - two alternatives", by Ed Grissom
2004.06.02 14:20 "Re: large TIFF - two alternatives", by Steve Carlsen
2004.06.03 06:40 "Re: large TIFF - two alternatives", by Rob Tillaart
2004.05.27 16:37 "Re: large TIFF - two alternatives", by Frank Warmerdam
2004.05.27 18:41 "Re: large TIFF - two alternatives", by Chris Cox
2004.05.27 19:15 "Re: large TIFF - two alternatives", by Frank Warmerdam
2004.06.04 13:31 "Re: large TIFF - two alternatives", by Ed Grissom
2004.06.04 14:01 "Re: large TIFF - two alternatives", by Frank Warmerdam
2004.06.04 15:03 "Re: large TIFF - two alternatives", by Ed Grissom
2004.06.09 20:33 "Re: large TIFF - two alternatives", by Steve Carlsen
2004.06.10 07:37 "Re: large TIFF - two alternatives", by Rob Tillaart
2004.06.10 20:41 "Re: large TIFF - two alternatives", by Chris Cox
2004.06.10 21:11 "Re: large TIFF - two alternatives", by Phillip Crews

2004.06.10 07:37 "Re: large TIFF - two alternatives", by Rob Tillaart

Steve Carlsen wrote:
> 
> At 18:15 -0700 5/26/04, Steve Carlsen wrote:
> 
> It seems like the prevailing opinion is for making "Large TIFF" be
> mostly just like existing TIFF except for supporting 8-byte addresses.
> 
> Making the "Alternative 1" proposal a bit more concrete, then, and
> adding some 8-byte alignment language and a hook for future expansion:
> 
> ============================= 8-Byte TIFF =======================
> 
> A. The ID, in header bytes 2-3, formerly decimal 42, now changes to
> 0x4242.
>  ( I really like the '42', and this seems like a nice way to have my
> cake and eat it, too.)

0x42 is a 'B' so 0x4242 = "BB" (BIG BLOB? :)

> B. Header bytes 4-5 contain the decimal number 8. (If there is some
> other number here, a reader should give up.)
>   (to provide a nice way to move to 16-byte pointers some day.)'

You mean 0x0008; leaves room to grow to 0x1000 (4096) byte pointers
giving an address space of 2**32768 ~ 10**9864 bytes. You're thinking
really big.

> C. Header bytes 6-7 are reserved and must be zero. (If they're not, a
> reader should give up.)

I think the reader should notice but can proceed at own risk.

> D. Header bytes 8-15 contain the 8-byte offset to the 0th IFD.
> 
> E. Value/Offset fields are 8 bytes long, and take up bytes 8-15 in an
> IFD entry.
>   (If the value is <= 8 bytes, it must be stored in the field.)
>   (All values must begin at an 8-byte-aligned address.)
> 
> F. 8-byte offset to the Next_IFD, at the end of an IFD.
> 
> G. to keep IFD entries 8-byte-aligned, we begin with an 8-byte
> (instead of 2-byte) count of the number of directory entries.
> 
> H. add TIFFTypes of LONG8 (= 13), an 8 byte (unsigned) int, and SLONG8
> (= 14).

please also add:
- RATIONAL8     LONG8/ LONG8   	(16 bytes)
- COMPLEX       LONG8, LONG8	(16 bytes)

> I. StripOffsets and TileOffsets and ByteCounts can be LONG8.

I would like to make a must of that. keep things 8 bytes aligned.

> J.The extension is ".tf8", and the format is called "8-Byte TIFF".

Breaking the file-extention is imho not alternative 1. 
The file extention should still be .tif or .tiff

> Otherwise, it's just like "original TIFF." ("TIFF Classic?")
> 
> ===================================================================
> 
> Are we close to general agreement? 

Guess so,

> Am I missing something?

See above.


I know that there does not exist an average TIFF file but a tickling
question 
is how much an average (<2GB) tiff file would increase by using this
scheme.

IFD entry is 		now		new
	tag		2		8
	type		2		8
	count n		4		8
	value/offset	4 		8
	--------------------------------------------
	total		8 + n x 4	24 + n x 8

The size of an IFD will grow by a factor 32/12 < 3. (when no tiles are
used) 
but when tiles are used the growth factor will be closer to 2. (due to 8
byte alignment).


> Regards,
> Steve Carlsen

Regards,
rob.