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.
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. [Hey! Olympus has just started using this code for the IFD's in the maker notes of their new Camera models! - 2007/03/08]
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).
All these shortcomings make TIFF a very non-extensible format which by design will result in the loss of non-standard information.
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.
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.
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 odd quirks. 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.
The official TIFF recommendation is to delete unknown information when rewriting an image[1], 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.
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). [Update: In February 2009 CIPA released the MPF format specification which allows storage of preview images larger than 64kB, but unfortunately this specification has problems of its own.]
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). [According to the November 2014 XMP specification (part 3, page 13), Adobe allows multi-segment EXIF, and this is supported by ExifTool 10.97 and later.]
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.
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.
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.
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.
...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. [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.]
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. [July 2017: PNG adopts eXIf chunk to allow EXIF metadata to be stored in native binary format. This is useful, but still doesn't allow storage of arbitrary binary metadata.]
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.
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.
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.
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?
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.
This is not a meta information format, but since many format specifications are imprisoned by the ISO it deserves mentioning...
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.
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.
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.
... but there are some significant problems with the QuickTime specification:
0) The biggest problem with some QuickTime-based files (ie. MOV, MP4, HEIC) is that atoms may store absolute offsets into the media data, and these pointers are easily invalidated by editing the file. This puts a huge burdon on the editing application to update all necessary pointers, and makes it much, much harder than it should be to edit these files (it takes significant effort to just determine which atoms may containing pointers).
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).
2) The length of 'udta' text strings with language codes is written incorrectly by many (most?) utilities, 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.
3) Cameras without time zone information are forced to write date/time tags as local time, even though the specification says these should be UTC. This leads to an unresolvable inconsistency in the time offset because one can not distinguish between these two cases.
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.
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:
The specification for this format can be found here, and is implemented in Image::ExifTool::MIE.pm
OK. Flame away. I can take it.