2004.04.20 08:29 "Re: [Tiff] Large TIFF files", by Rob van den Tillaart

[the discussion continues]

Hi,

The discussions of the 64 bit TIFF bring up some good insights (requirements?)

There are in essence only 2 routes for 64 bit tiff

• compatibility with existing
• breaking with existing (but keeping as many good things as possible)

The first leads to all kinds of trouble as mentioned in earlier mails. Frank proposed a new 64 bit format BTIFF (or BIF: Big Image File or BIg File) and for now this seems to me the most promissing way. BIF could inherit the tag structure of TIFF with some 'minor' changes.

Who are the stakeholders for 64 bit.

1. applications that make huge images or (eg www.jumboscan.com)
2. applications that make huge multipage images (eg highres video camera)
3. applications that do both.

It seems to me that many applications will not need 64 bit.

PRELIM. PROPOSAL BIF

All types will be mapped upon signed 64 bit, alignment to 64 bit or 8 bytes

TYPES

1       = ASCII         string 0 terminated
2       = BLOB          bytearray
3       = DOUBLE
4       = LONG64
5       = RATIONAL64    LONG64/LONG64   (16 bytes)
6       = COMPLEX       LONG64-LONG64   (16 bytes)

All nummeric types are signed, this would make files max. 2^63 bytes in stead of 2^64

seems large enough for now. 2^63 = 9.223.372.036.854.775.808

All (tiff32) types are mapped upon long64 (even boolean) This seems a waste of bytes but if we talk about files >> 4GB these few bytes won't matter too much I assume.

HEADER

Bytes 0-1: endianess            // must we keep this ?
Bytes 2-7: SAM 64               // in ASCII
Bytes 8-15: 64 bit IFD offset   // 0000000 for last IFD

The number of directory entries is also a LONG64;

TAGS

Byte 0-7:       tag
Byte 8-15:      type
Byte 16-23:     value           (type=3-6)      length          (type=1,2)
Byte 24-31:     opt. value      (type=5,6)      64bit offset    (type=1,2)

Tag's are the same as in the TIFF 6.0 spec. preceded with 0's. The range with the first 32 bit a 0 are reserved for this 'compatibility'

The range with the first 32 bit a 1 are reserved for 'the commitee' (whoever ...)

METATAG

There is one new TAG the metaTAG

        FFFFFFFF-00000001       // Metatag
        00000000-00000001       // ASCII
        some length
        offset --> data

        data = "XXXXXXXX-XXXXXXXX:description"
        X = value of a new tag used in this file

        example data: "11111111-00000001: A tag for internal use of application X only."

this way applications can extend the metadata in a documented way. Note that the tag is not registered in any way and only valid for this file.

END PRELIM PROPOSAL

I didn't think about the image data yet but for now compressions are just same, tiles and stripes are just as usual only they have a 64 bit offset/count. I think it is good practice to keep tiles small.

So far my thinking about the large tiff files for now,

Please shoot: comments, remarks, questions, ideas, improvements, alternatives,...

best regards,
rob tillaart

[and the discussion continues ...]