ExifTool attempts to simplify this situation as much as possible by making reasonable decisions about where to write the information you specify, yet it maintains flexibility by allowing you to configure its priorities if necessary, or even override the decision making process entirely.
1. I designed an interface that I think is easy to use for people who don't want to know the details of the file structure, yet powerful enough for people who want to do very specific things to the information.
2. I isolated all of the writing code as much as possible into separate files which autoload as required. This keeps the compilation fast for people who don't require the write feature. Also, I have left the reading routines unchanged, so they aren't slowed down by the extra code needed when writing information. Unfortunately, this meant I couldn't borrow a lot of code from the read routines (even more work for me!), but it had the advantage that I could perform additional optimizations in the write routines that I couldn't do otherwise. Although the startup costs of this implementation are fairly high (for writing only), it should be quite fast for batch writing of multiple files.
3. I decided to bite the bullet and invest the time required (...guess what I did for my Christmas vacation!). Although I thought that a big project like this would be better suited to C++ (faster execution and a broader potential user base), after programming this so far in Perl I have grown to really appreciate the automatic memory handling and other great features of Perl such as hash lookups and incredible flexibility in text manipulations afforded by regular expressions.
It is possible for you to write nonsense into a file, which could cause other image readers to throw up their hands in despair and refuse to read the image. For this reason, it is best to always preserve the original copy of your image file. The 'exiftool' script does this for you automatically by renaming the original file and always working on a copy.
The writing logic for ExifTool is the reverse of the reading logic. You provide human-readable values and ExifTool will perform the conversions for you. For instance, you can set 'WhiteBalance' to 'Daylight' and ExifTool will change the value of WhiteBalance in the image wherever the tag is found provided that 'Daylight' is a valid value for that location. ExifTool will even do some simple matching so that you could even just set it to 'day', and ExifTool will search through the valid values and will choose the one that contains the string 'day'. If the value is ambiguous, the tag will not be set. If no tags can be set with the specified value, ExifTool returns an error message.
The tag values can also be specified at a numerical level by disabling the print conversions that are normally applied. This can be done on a tag-by-tag basis via the API, or on a global basis with the exiftool application using the -n option.
As well as changing tag values wherever they are found in the image, exiftool will also create the tag in the preferred group if it didn't exist there before. By default, the preferred group is the first of the following where the tag is found: 1) EXIF, 2) GPS, 3) IPTC, 4) XMP, 5) MakerNotes. Alternatively, the desired group (in family 0 or 1) can be specified so ExifTool only writes the tag to a single location.
If a tag is added to a group that doesn't exist, the new group is created in the file, and required mandatory tags may be created. Conversely, if the last non-mandatory tag is deleted from a group, the group is removed from the file.
Alternatively, a group name may be specified to write information only to a desired group. For example, with the command line interface, this is done using a syntax like "EXIF:WhiteBalance".
Rant: Let me say that the whole concept of mandatory tags is flawed. Instead of mandatory tags, the standard should specify default values to be assumed if the tags don't exist. A robust reader has to do this anyway, so it is redundant to require that this information must be written. In the case where there is no simple default value, the reader must be able to deal with the missing tag, otherwise it places the burden on the writer to magically pull a reasonable value out of thin air. Of course, you may say that the writer could get this information from the user, but conditions like this add an unnecessary level complexity to the user interface.
JPEG comments may also exceed the size of a single COM segment. If
necessary, comments are automatically split into separate segments when writing.
However, when reading they are not joined together because some utilities store
distinctly different comments in separate segments. To extract all JPEG
comments into a single file, and combine any comments that may have been split
into multiple segments, use "exiftool -a -b -comment src.jpg >
comment.out
".
However, as of ExifTool version 5, the preview images are handled properly when writing EXIF information in JPEG files. But for reasons of efficiency, the EXIF segment is not edited when writing information unless some EXIF tags are being changed (ie. if only XMP or IPTC information is being edited). In this case, the preview image pointers could be invalidated because the length of the data between the EXIF segment (which comes near the start of the file) and the preview image (at the end of the file) is likely to change. ExifTool gets around this when reading JPEG images by looking for the preview at the end of the file and updating pointers if necessary, but the preview image may not be readable by other software (it should be noted though that very few image readers even know the preview image exists). However, the preview pointers in such a file can be fixed if necessary by simply using ExifTool to edit any EXIF information.