It really is surprising how stupid some (...many, ...most?) manufacturers seem to be when it comes to writing what should be a fairly simple file format.
One positive thing is that most manufacturers seem to have standardized on an EXIF-like IFD (Image File Directory) structure for their maker notes. But many problems arise because of a fundamental design flaw in the EXIF/TIFF format. Values longer than 4 bytes are stored at a location referenced by an offset from an absolute position in the file (where offset 0 is the start of the EXIF/TIFF information).
The difficulty is that these offsets must be recalculated when a file is rewritten, but in general this is not possible (particularly for the maker notes) because the format of all information is not known. Some manufacturers have attempted to avoid this problem using offsets which are relative to the start of the maker note IFD instead of the usual start of EXIF. This is a good idea if implemented properly, but this is not done consistently. (And some manufacturers are not even consistent about how the offsets are calculated from one camera model to the next!)
Technical aside:
If EXIF were designed properly, all offsets would be relative to 4 bytes after the end of the IFD, which is the normal position for values to be stored, and all value data for the IFD would be stored in a block at this location. If this was done, an entire IFD could be relocated easily without causing problems.
Below is a list of idiosyncracies in files written by the digital cameras or software from various manufacturers. Many of these quirks relate to the offset problem mentioned above.
Canon: The 350D (firmware 1.0.1) gets the size of the thumbnail image wrong and reports it to be 10 bytes too long. This can cause the reported thumbnail image data to run off the end of the APP1 segment. A bug in version 1.0.4 of the 40D firmware causes it to write a maker note entry count that is one greater than it should be.
Casio: The preview image is referenced by two different offsets (the PreviewImage tag plus a PreviewImageStart/PreviewImageLength pair). Also, the offset for the PrintIM information is relative to the start of the IFD entry even though other offsets aren't.
Concord: Some models write PrintIM information with an entry-based offset like Casio.
General Electric: A number of GE cameras store zero offsets for some maker note tags (possibly to indicate that the tags do not exist), and other offsets are 12 bytes too high for some models (like the A1230, E1035 and G2).
Hewlett-Packard: The PhotoSmart 720 (one of the few HP models to use EXIF-format maker notes) uses a format code of 5 (rational64u) for tag 0x0204, but stores a rational32u value. Other models show about as much standardization as the Kodak point-and-shoot lineup. Also, some models (C945, M22, M23, R507, R607, R707, R717, R725, R727, R817, R818, R827, R927 and R960) write the EXIF ComponentsConfiguration incorrectly as ASCII characters (like the Leica M8 and M9).
Kodak: Professional DCS Photo Desk software writes a cyclical EXIF directory such that the InteropIFD pointer points back to IFD0. Point-and-shoot models show little standardization in maker note format. Some models with IFD-format maker notes store incorrect count values for a number of tags (this is particularly nasty), and may contain blank IFD entries which are filled with 0xff's (not zeros like other makes).
Konica: The KD-300Z writes all maker notes offsets relative to the start of the individual IFD entry.
Kyocera: A number of models write all maker notes offsets relative to the start of the individual IFD entry.
Leica: The M8 and M9 write the EXIF ComponentsConfiguration value in ASCII instead of binary. The M8 writes EXIF ExposureCompensation and ShutterSpeedValue incorrectly as a unsigned rationals when they should be signed. This leads to crazy values like "+65536" for small negative exposure compensations, and "0 s" for long exposure times. (NOTE: These are all EXIF idiosyncracies since the values are in the standard EXIF, not the maker notes.) In DNG images, the M8 uses maker note offsets relative to the start of the maker notes in JPEG images (very reasonable), but relative to the end of the maker note header in DNG images. I think this was a mistake because this is changed in M9 DNG images to be the same as JPEG images.
The Leica S2 maker note format is the MOST idiotic I have seen, and has the following peculiarities:
Strike that. The most idiotic award now goes to the Leica M (Typ 240), which adds these quirks (firmware 1.1.0.2):
OK, I give up on Leica. The new Leica S (Typ 007) attains a new level of stupidity by storing the preview image in the JPG file using a completely nonsensical technique (in IFD2 of the EXIF segment, with the data being stored outside the EXIF segment after the JPEG EOI), as well as various other brainless blunders. [@Leica: Try reading the MPF specification.]
Minolta: An obvious bug in the firmware of the Z2 writes an incorrect offset for the 'MinoltaCameraSettings2' information -- it writes the offset of the offset itself instead of the offset of the value (hahaha!). Other offsets are correct.
Nikon: D2H NEF files have huge blocks with all zero data (3.7 MB in my test file!).
Olympus: The E-1 and E-300 have subdirectories in the maker notes, but not only does the data size of these subdirectories exclude the subdirectory value data, but also it is 2 bytes too small for the directory information itself (doh! -- they forgot to include the entry count). Similarly, the stored size of the maker note data block is too small for many models, which results in a loss of data if the maker notes are copied as a block when an image is rewritten.
Pentax: The Optio 330 uses an offset for the PrintIM information which is relative to the start of the IFD entry (hmmm, like some Casio models...). Also, preview image offsets in the maker notes are given relative to the EXIF base rather than the maker note base (like all other maker notes offsets).
The Optio 550, 555, 33WR and 43WR all specify a PrintIM directory at a the same offset of 0x29a with length 40 bytes, but the only PrintIM information in the file is nowhere near that offset and is 128 bytes long. Also for these models, tag 0x002e has a constant value of 0x6a6 even though its position changes. Finally, all of these models plus the Optio WP waste many kilobytes of space in each image with large unused data blocks in the EXIF information.
The Optio 330RS and 430RS double reference the preview image information.
Note that the worst problems are with the Optio 230, 330, and 430, which carry the Asahi brand name.
Photoshop and Nikon Capture: Both of these packages write TIFF IPTC information as 'int32u' (or 'LONG'). This is wrong (see reference). Nikon Capture goes one step further and simply ignores IPTC that is written correctly as 'undef' or 'int8u'. (So for compatibility, ExifTool also writes this incorrectly as 'int32u'.) Photoshop completely deletes the maker notes when an image is edited.
Ricoh: There is an IFD subdirectory in the Ricoh maker notes of both the Caplio RR30 and RR1. The RR30 uses standard EXIF offsets (relative to the start of the EXIF data), but for the RR1 the offsets are relative to the start of the subdirectory. The G700 uses MPF offsets relative to the start of the file, instead of the start of the MPF segment as per the MPF spec. The HX15 uses a standard EXIF maker note structure, but there are 2 extra padding bytes between the IFD entry count and the 1st IFD entry. The HZ15 and Pentax XG-1 (by Ricoh) both have an extra 2 bytes after the IFD entry counts. All value offsets are erroneously 0 for the HZ15, and there are other problems with the offsets stored by the XG-1.
Rollei: The DK4010 writes all maker notes offsets relative to the start of the individual IFD entry.
Sanyo: The offsets written in the maker notes of the J1, J2, J3, S1, S3 and S4 have very little to do with reality. Apparently the Sanyo programmers have no understanding of the concept of an IFD offset.
Skanhex: With some Skanhex models (SX-210Z3, SX-330Z3, SX3300, SX410Z3), the 264-byte makernotes block contains no useful information, and overlaps values from the ExifIFD. For these models there is also a large block (typically 1195 bytes) of unreferenced information in the EXIF data immediately following the IteropIFD. This block begins with the character sequence "SKANH\0", and contains exactly the same information in all 20 of my sample images that contain this block (except for a variable amount of padding at the end with 0xff bytes). These quirks also affect some Gateway, Jenoptik, Medion, Samsung and Yakumo models built by Skanhex.
Toshiba: The PDR-3310 writes all maker notes offsets relative to the start of the individual IFD entry. (very similar to Konica KD-300Z)
Minolta MRW: The A200 stores the thumbnail image offset in IFD0 relative to the start of file, while all other offsets are relative to the start of the TIFF header, which is 48 bytes into the file. Also, the A200 stores the StripOffsets and the StripByteCounts values in the wrong byte order.
Sony ARW: The maker notes of ARW images are not self-contained, so some information is lost when the images are rewritten by other software (including the Adobe DNG converter). The A100 with firmware 1.00 sets the high word of the thumbnail image offset to zero, but it should sometimes be 0x0001. (This problem is fixed for firmware 1.01.) Also with the A100, the JpgFromRawLength stored in IFD0 may be wrong (although this value is also stored in the MakerNotes and is correct here). As well, much information in these images is encrypted, which complicates things somewhat. Even the Sony IDC utility can't properly rewrite ARW files -- it corrupts the embedded MRW record when used to edit ARW images. Even funnier: IDC v3.0 will crash when loading some original A100 firmware 1.00 images, but no longer crashes if the images are first edited with ExifTool (probably because ExifTool fixes the above mentioned problems when it rewrites the image).
Leica DNG: The makernote offsets for the M8 are relative to the start of the makernote IFD in JPEG images, but relative to the start of the makernote header (8 bytes earlier) in DNG images. [2009-09-09: This is fixed for the M9 which has offsets relative to the start of the makernote header for both JPEG and DNG.]
Nikon NEF: Aside from the encryption that Nikon uses to try to hide some information in their maker notes, the NEF files in general seem fairly well behaved. Even so, the Nikon Transfer utility (version 1.3) still manages to corrupt some information in the 0th SubIFD when it is used to process NEF images. (Beware that other Nikon utilities may have this same problem if they use the same NEF writing routines.) But luckly the lost information isn't very important. (Only a few tags from the embedded full-sized preview image are lost: XResolution, YResolution and YCbCrPositioning.) Also, Nikon Transfer and Nikon Capture both write an incorrect size for the maker notes, which could cause loss of MakerNote information if the file is edited by other software (but this isn't a problem with ExifTool, which will fix this type of problem automatically when writing).
Nikon NRW: Nikon should have just called this NEF with a different version number -- there should be no need to pollute the universe with zillions of unnecessary file extensions. Oh right, they weren't smart enough to include a file identifier containing a version number in their NEF images -- Doh! In these images, CFAPattern2 is written incorrectly with UNDEFINED instead of BYTE format.
Phase One IIQ: Many values are referenced from more than one location in the TIFF structure of these images. For instance, the IFD0 strip data actually exists within the MakerNotes data block. This is a poor design, and leads to duplicated information when the image is rewritten.
Ricoh DNG: The GR Digital IV (firmware 1.14) stores an incorrect length for the JPEG preview in SubIFD1.
Samsung SRW: Yet another TIFF-based RAW image with no proper file identifier. In these images the thumbnail is stored inside a SubIFD of IFD1 instead of directly in IFD1 (dumb, dumb...). Also, the NX200 (firmware NX200_011181) uses a base offset for the X/YResolution values that is different from the PreviewImageStart pointer, both in the MakerNotes PreviewIFD. (Note that the NX100 uses the same base for both, so this is certainly a firmware bug for the NX200. [2012-06-21: This problem now also affects the EX1, NX20 and WB2000] [2013-07-25: Add the NX2000 to this list])