2004.09.17 13:47 "Re: [Tiff] BigTIFF Tag Value Count issue", by Joris Van Damme

I expect that will be sooner as one wants to keep 'fluxdata' in sync with the image-data. However in o0ption 3 the number of tags grows to 4G, so extra tags for "fluxtiled" and "fluxstriped" is not the problem.

Oh, yes, it is. Unless you completely duplicate tiling/striping facilities inside that tag, and next do the same for compression, and next have to operate heavilly on libtiff to essentially get out of tags what it is designed to get out of image channels... ending up, in the end, with functionality that was already there: the extra channel.

As I have not much experience with additional channels, I trust you that an extra channel could also solve the example.

It is the reason even why there is the possibility of any number of channels. There's a (virtually?) unlimited number of extra channels that could be included, and a perfect means of marking them as 'meaningless to main-stream apps that expect an image to contain color', by setting their ExtraSamples value to EXTRASAMPLE_UNSPECIFIED = 0 (see http://www.awaresystems.be/imaging/tiff/tifftags/extrasamples.html)

The example was to show the added value of a bigger 4-byte "TAG-space".

I don't wish to contradict option 3 might be the best, in general, not at all. I don't dissagree with the principle of allowing the 'anything' to grow beyond 4 gig in a file format that itself is designed because we recognize the need for TIFF to grow beyond 4 gig.

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