2004.05.27 01:15 "[Tiff] large TIFF - two alternatives", by Steve Carlsen

2004.05.27 15:02 "Re: [Tiff] large TIFF - two alternatives", by Steve Carlsen

I think that we must avoid ASCII numbers. It is very easy to fall into localization nightmare.

No, I'm just talking about tags/keys here. The user will see none of it. Localization is just as irrelevant as it would be for localizing the keywords of C and C++.

Of course, end-user strings, like filenames, user names, etc, can and should certainly support UNICODE values.

Also some numerical metadata we may want to save into the tags can be quite large (almost as large as image itself)

Sure, and for that, binary is definitely the way to go. StripOffsets is one good example. this alternative wouldn't rule out binary; it would just make it used less frequently.

Do you mean that the directory entry can be large enough to hold the any data value?

Yes; but also that you can have more than 64K directory (dictionary) entries. Not that this is likely to be very useful, but who knows?

The second approach looks nice in long term. But why not to implement both ones? The first technique will be powered by existing implementations, so we can achieve our goal (large files) shortly.

I'm inclined to only have one 8-byte implementation, for future simplicity.