2007.01.15 01:09 "[Tiff] bigtiff", by Albert Cahalan

2007.01.15 09:43 "Re: [Tiff] bigtiff", by Joris Van Damme


There is an easy way to implement your GUID based tag. Ask Adobe for a

single private tag, lets name it the GUIDTAG. In this GUIDTAG you can

have an array of your guid based tags. You just publish the layout /
structure of your private tag, Joris keeps a list on his website, and
anyone can use it.

Applications are free to support them and there is no break with the


In a similar way one could make an XMLTAG, to embed an XML file

describing metadata (or whatever) in a Tiff file.

You are of course perfectly correct, in that this is a perfectly legit thing to do.

However, I can't resist giving my personal reasons for disliking such a scheme.

TIFF is a hierarchical system of directories, with each directory being a key-value pair pile. That's its very core. Thanks to private tags that can point to private IFDs, it's 100% extendible and in those private IFDs you no longer have the tag-registring overhead. Adding your own secondary different key-value pair pile encoding to that, is just redundant. It means more code is needed, for decoding and encoding what was essentially already covered. More maintenance, more bugs, more cruft... And a less beautiful and consistent total picture.

I much dislike the XMLTAG for the same reasons, as well as the Photoshop tag. We *have* an encoding for key-value pair pile already, guys, and it's extendible in any direction. If 'strength' of a file format or any particular file encoding is defined as the width of the data that can go in there divided by the width of the spec that is needed to describe that data, this XMLTAG, Photoshop tag, and GUIDTAG weakens the scheme for no reason at all.

That said, again, please don't take me the wrong way. What you propose is beyond doubt a perfectly valid and legit thing to do.

Best regards,