123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319 |
- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
- "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
- <html>
- <head>
- <title>Commentary on Meta Information Formats</title>
- <link rel=stylesheet type='text/css' href='style.css' title='Style'>
- <style type="text/css">
- <!--
- a.ref { text-decoration: none; font-size: x-small;
- font-weight: normal; vertical-align: super; }
- .norm { font-weight: normal }
- -->
- </style>
- </head>
- <body>
- <div class='index'>
- <b>What sucks:</b>
- <br><a href="#EXIF">EXIF / TIFF</a>
- <br><a href="#Maker">EXIF Maker notes</a>
- <br><a href="#JPEG">JPEG</a>
- <br><a href="#IPTC">IPTC IIM</a>
- <br><a href="#XMP">XMP</a>
- <br><a href="#PDF">PDF</a>
- <br><a href="#PNG">PNG</a>
- <br><a href="#PICT">PICT</a>
- <br><a href="#FlashPix">FlashPix</a>
- <br><a href="#DICOM">DICOM</a>
- <br><a href="#AVCHD">AVCHD</a>
- <br><a href="#ISO">ISO</a>
- <br><b>What doesn't:</b>
- <br><a href="#CRW">CRW (CIFF)</a>
- <br><a href="#QuickTime">QuickTime</a>
- <br><a href="#MIE">MIE</a>
- </div>
- <h2 class='up'>Commentary on Meta Information Formats<br>
- <span class='sm'>(or <i>"Why this or that Format Sucks"</i>)</span></h2>
- <a name='EXIF'></a>
- <h3>EXIF / TIFF</h3>
- <p>EXIF uses the TIFF format to store information. The biggest problem with
- this format is that all pointers are absolute (ie. relative to the start of
- the file). This means that the pointers need fixing up if the position of
- any information changes. This is significant because pointers are often
- hidden inside proprietary structures which should remain opaque (such as
- maker notes). The result is that some EXIF information is easily corrupted
- when editing a file. This problem is ignored by many software packages.
- Much effort was required in the development of ExifTool to avoid the loss of
- information such as this.</p>
- <p>A significant problem is that an IFD (image file directory) pointer has
- the same format code as a long integer, so information in any non-recognized
- IFD is lost when the image is rewritten. There is a seldom-used format
- code of 13 that has been proposed to indicate an IFD, but this is not part
- of the EXIF/TIFF specification and is not in common usage. <i class=lt>[Hey!
- Olympus has just started using this code for the IFD's in the maker notes of
- their new Camera models! - 2007/03/08]</i></p>
- <p>Also, it was wrong to specify a count instead of a size for each
- directory entry because this makes it impossible to add new format types
- without requiring that older readers simply discard data of unknown type
- (since the data size isn't known, the old readers don't know how to copy the
- data).</p>
- <p>All these shortcomings make TIFF a very non-extensible format which by
- design will result in the loss of non-standard information.</p>
- <p>And we don't learn from our mistakes (OK, maybe some of us can, but
- apparently not big corporations like Adobe or Microsoft), because the new
- DNG and WDP formats are TIFF-based too.</p>
- <p>The EXIF specification also has some significant shortcomings to add to the
- TIFF problems, like minimal special character abilities, no language support,
- and no way to specify time zone.</p>
- <a name='Maker'></a>
- <h3>EXIF Maker Notes</h3>
- <p>Maker notes are a can of worms. The EXIF specification unfortunately
- made no mention about the information format of the maker notes. If
- properly designed, the specification would have provided a maker note IFD
- tag to allow IFD-style maker notes to be used. Many manufacturers
- implemented it this way, but each with a different technique and many with
- <a href="idiosyncracies.html">odd quirks</a>. This deficiency combined with
- problems in the TIFF (EXIF) format mean that most software will quite
- unknowingly scramble your maker notes when an image is rewritten. To
- prevent this, specific knowledge about files written by individual
- manufacturers is necessary, and of course the manufacturers are not prone to
- divulging this information to the public so it must all be reverse
- engineered.</p>
- <p>The official TIFF recommendation is to delete unknown information when
- rewriting an image<a class=ref href="#ref1">[1]</a>, and this irresponsible
- strategy has been adopted by some applications such as Adobe Photoshop,
- resulting in a total loss of maker note information. This is very
- unfortunate because even corrupted maker notes contain useful information,
- and smart utilities (like ExifTool) are often able to recover the
- information from damaged maker notes.</p>
- <a name='JPEG'></a>
- <h3>JPEG</h3>
- <p>The JPEG format acts only as a container for meta information, and
- defines no meta information format itself. But it sucks just a as a
- container format because it limits the maximum contiguous block size to
- 64kB. This causes problems because many cameras store more than 64kB of
- additional information in their JPEG images. Usually, this is due to the
- medium-sized JPEG image that many cameras embed for preview purposes. It
- would have been nice if there was a standard way to embed this preview in
- JPEG images (without the 64kB limitation). <i class=lt>[Update: In February
- 2009 CIPA released the MPF format specification which allows storage of
- preview images larger than 64kB, but unfortunately this specification
- <a href="standards.html#MPF">has problems of its own</a>.]</i></p>
- <p>Aside: The EXIF specification could have easily allowed the information
- to span multiple JPEG segments, which would have been smart, but still
- wouldn't have solved the problem entirely since it could result in a
- non-contiguous preview image (this would be a problem for cameras since they
- typically want to use this image for quick review of pictures, and
- re-mapping the image into a contiguous memory space would be costly).</p>
- <a name='IPTC'></a>
- <h3>IPTC IIM</h3>
- <p>IPTC IIM earns a few points because it is the easiest to process of the
- common meta information formats. However, the format is overly restrictive
- and not very extensible. Format information and human-readable tag names
- are not part of the specification, so it is not possible to meaningfully
- interpret unknown values. Also, there are many interdependencies between
- tags that make it very annoying for writing, and the special character
- support is ill-conceived.</p>
- <a name='XMP'></a>
- <h3>XMP</h3>
- <p>The XMP format is a good example of a designed-by-committee
- specification. It is based on XML, which is much more complicated than
- necessary and tries to make everyone happy by providing a multitude of
- format styles and features (shorthand format, etc, etc). This makes it very
- difficult to properly implement the complete specification. Not even the
- Adobe software supports all of the format options of their own XMP
- specification. And the format is exceedingly verbose, wasting disk space,
- bandwidth and time.</p>
- <p>Also, XMP only supports textual information. Binary information must be
- text-encoded if stored in XMP. This makes it very bulky, slow and
- completely unsuitable for storage of binary information.</p>
- <p>Mainly because of the complexity of the specification, and despite
- Adobe's best efforts, XMP still isn't very well supported by meta
- information editing tools. The best hope for small application developers
- is to link against an off-the-shelf XMP or XML library. Apparently Adobe
- realizes this and is now providing an XMP development kit, but this solution
- is only useful for those platforms and computer languages that they choose
- to support.</p>
- <a name='PDF'></a>
- <h3>PDF</h3>
- <p>...and I thought XMP was too complicated. PDF is just insane. Because
- of this, it is unlikely that ExifTool will ever support this format for
- writing. <i class=lt>[Dec. 18, 2007 Update: I have just added PDF write support
- using the incremental update feature of PDF. It was still a bit of work, but
- somewhat simpler (and MUCH faster!) than rewriting the entire PDF. But there
- are disadvantages: The resulting PDF is not "linearized", and there are privacy
- and security issues with leaving old metadata in the file.]</i></p>
- <a name='PNG'></a>
- <h3>PNG</h3>
- <p>PNG sucks because meta information can be stored only in text format.
- This was a huge mistake, and as a work-around software (eg. ImageMagick)
- must encode binary information in ASCII-hex, then compress it to offset the
- increase in size, and store it as a compressed text block. This adds
- unnecessary complexity, greatly slows down processing, and makes it much
- harder to develop software which supports PNG meta information.</p>
- <a name='PICT'></a>
- <h3>PICT</h3>
- <p>The PICT format just plain sucks. It is one of the worst-designed image
- formats in existence, second only to FlashPix. I don't believe that it was
- originally designed as a file format. Instead it appears to have emerged
- from the internal Apple QuickDraw structures. The files are not designed to
- be processed by any software other than the Mac OS. Intimate knowledge of
- the QuickDraw structures is required just to parse the PICT image, even if
- the reader doesn't care about the contained information. Because of this,
- PICT images are very fragile and a simple data error or programming bug will
- invalidate an entire image. Possibly for these reasons the PICT format
- never gained popularity outside the Apple world. Also, the concept of meta
- information is all but ignored in the PICT design.</p>
- <a name='FlashPix'></a>
- <h3>FlashPix</h3>
- <p>Oh. My. God. Don't get me started on this one. Let's just say that basing
- an image file format on the File Allocation Table (FAT) structure of a floppy
- disk with fixed 512-byte sectors is monumentally idiotic. Microsoft Word,
- Excel and PowerPoint documents also use this insane format.</p>
- <a name='DICOM'></a>
- <h3>DICOM Medical Images</h3>
- <p>The DICOM format is reasonably well designed. The UID's are cumbersome,
- but achieve their purpose. The biggest bungle in the design is the implicit
- VR syntax, which presumably exists for historical reasons to provide
- backward compatibility with pre-existing ACR-NEMA images. The DICOM
- specification document is horrible and obviously written by committee, and
- was possibly the single largest impediment to implementing support for this
- format.</p>
- <p>Technical: The files would be easier to parse if the transfer syntax
- became effective immediately after the transfer syntax data element instead
- of at the end of the meta information group. Also, the deflated data should
- have contained the zlib header, as in PNG and PDF images. This would make
- it easier to read and allow CRC validation of the datastream. -- Can you
- tell I wrote this just after adding DICOM support to ExifTool?</p>
- <a name='AVCHD'></a>
- <h3>AVCHD (.M2TS) <span class='sm norm'><i class=lt>(added 2009-10-29)</i></span></h3>
- <p>This format is used in .M2TS video files (and Blu-Ray HD DVD's). It is
- painfully obvious that this was never designed as a storage format. It uses
- MPEG-2 transport stream (M2TS) container, which is a communications protocol
- and never should have been used for storage. The M2TS format is based on a
- 188-byte packet size which makes no sense for modern filesystems. And to
- make things worse, metadata in AVCHD files is stored in the H.264 video
- stream (!!) which uses insane and convoluted data structures such as the
- variable-bit-length exponential-Golomb which are painful and inefficient to
- parse in software, and as far as I can tell the format for the metadata
- stored in these streams is proprietary and undocumented.</p>
- <a name='ISO'></a>
- <h3>ISO Considered Harmless</h3>
- <p>This is not a meta information format, but since many format
- specifications are imprisoned by the ISO it deserves mentioning...</p>
- <p>In my experience, the International Standards Organization is extremely
- counter-productive. Their goal is to promote standardization, but by
- charging too much money for copies of the standards documents they defeat
- their own purpose. The effect is that small companies and individuals
- developing software (including open source software such as ExifTool) do not
- have access to the official standard. Instead, software is often based on
- old, obsolete documents or drafts which are sometimes publicly available, or
- on 3rd party descriptions which are often incomplete. To sum things up: ISO
- sucks.</p>
- <hr>
- <h2>OK. So all those formats suck. What doesn't?</h2>
- <a name='CRW'></a>
- <h3>Canon CRW Images (CIFF format)</h3>
- <p>This format uses a directory structure similar to TIFF, but all offsets
- are relative and unknown information can handled properly when rewriting.
- Because of this, it is much more extensible than TIFF, but the format is
- still limited by 16-bit integer tag ID's among other TIFF weaknesses. It
- isn't great, but at least it doesn't suck.</p>
- <a name='QuickTime'></a>
- <h3>QuickTime Videos</h3>
- <p>The Apple QuickTime MOV format is very nice format. (Which is a breath
- of fresh air after the Apple PICT travesty.) It was a smart move to use
- this format for the MP4 specification. I would only change 2 things about
- this format: 1) Use longer tag names instead of the current 4 characters (I
- know that 4 characters is convenient because it can be used as an integer in
- lookup tables, but it would be nice if the tag names were a bit more
- meaningful). 2) Add a format code to the Atom definition so simple unknown
- information could be decoded properly. These changes would allow some
- unknown information to be interpreted, which would make it possible for
- information added by 3rd parties to be useful.</p>
- <p>I only have 2 problems with the QuickTime specification:</p>
- <p>1) The metadata organization is a mess because tags may be stored in more
- than one location (eg. UserData vs. InfoList), and conflicting metadata
- directories may exist, even in the same location (as written by iTunes).</p>
- <p>2) The length of 'udta' text strings with language codes is written
- incorrectly by many (most?) utilties, including Apple iTunes. The language
- strings are supposed to use a "small integer atom format" where the first
- two bytes give the size of the string including the length word and language
- codes. But often the size doesn't include these 4 bytes, which sort of
- defeats the purpose of the multiple languages because it is difficult to
- parse past the first entry if you don't know the size.</p>
- <a name='MIE'></a>
- <h3>My Format (Meta Information Encapsulation, or "MIE")</h3>
- <p>Now it is time to put my money where my mouth is: I have designed a
- format which doesn't suck. It is called "MIE", which stands for Meta
- Information Encapsulation.</p>
- <p>The MIE format is hierarchical like QuickTime, but it uses meaningful tag
- names and specifies a data format for all values. As well, this format
- offers a number of other features:</p>
- <ul>
- <li>Can be used as a wrapper around any type of file, as a trailer appended
- to other formats, or as a stand-alone meta information format
- <li>Extensible
- <li>Compact
- <li>Meaningful tag ID's
- <li>Streamable (and single-pass writing possible)
- <li>Relocatable data elements (ie. no fixed offsets)
- <li>Relatively simple to implement reader/writer
- <li>Supports large data lengths (up to 4GB*4GB)
- <li>Localized text feature
- <li>Built-in support for numerical units of measure
- <li>Multiple documents in a single file
- </ul>
- <p>The specification for this format can be found
- <a href="MIE1.1-20070121.pdf">here</a>, and is implemented in
- <a href="http://search.cpan.org/dist/Image-ExifTool/lib/Image/ExifTool/MIE.pm">Image::ExifTool::MIE.pm</a></p>
- <p>OK. Flame away. I can take it.</p>
- <a name="refs"></a>
- <h3>References</h3>
- <ol>
- <li><a name="ref1" href="http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf">http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf</a>, page 26</li>
- </ol>
- <hr>
- <i>Created Nov. 15, 2005</i><br>
- <i>Last revised July 29, 2010</i>
- <p class='lf'><a href="index.html"><-- Back to ExifTool home page</a></p>
- </body>
- </html>
|