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
January 2007

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

2007.01.15 01:09 "bigtiff", by Albert Cahalan
2007.01.15 03:42 "Re: bigtiff", by Frank Warmerdam
2007.01.15 06:00 "Re: bigtiff", by Albert Cahalan
2007.01.15 08:01 "Re: bigtiff", by Joris Van Damme
2007.01.15 09:13 "Re: bigtiff", by Rob Van Den Tillaart
2007.01.15 09:43 "Re: bigtiff", by Joris Van Damme
2007.01.15 16:12 "Re: bigtiff", by Albert Cahalan
2007.01.15 17:22 "Re: bigtiff", by Frank Warmerdam
2007.01.15 17:34 "Re: bigtiff", by Joris Van Damme
2007.01.16 06:17 "Re: bigtiff", by Albert Cahalan
2007.01.16 09:25 "Re: bigtiff", by Joris Van Damme

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

Rob,

Tillaart, Rob van den wrote:
> 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
> TiffSpec.
>
> 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,

Joris