Several but not all Linux photographic applications write out XMP sidecar files in violation of the XMP sidecar naming specification promulgated by Adobe and used today in a large number of applications on multiple operating systems.
That is, instead of image1.CR2 and image1.XMP, several applications write out image1.CR2.XMP or some variation of that.
Naming the XMP file image1.CR2.XMP instead of image1.XMP represents a decisive break with both historical practice and also with how the great majority of other XMP aware applications operate.
Sidecar type files existed for quite some years before XMP appeared on the scene. To take two examples:
- THM files that contain a thumbnail of a video file, e.g. movie1.MPG and movie1.THM.
- WAV files that contain audio that accompanies photos, e.g. image1.CR2 and image1.WAV
From the spec:
“XMP is not directly embedded within MPEG-2 files, but is specified as a sidecar file. This is a separate file containing just the XMP packet, which is stored at the same location as the MPEG-2 file, and uses the same filename, with the file extension .xmp replacing the original file extension.”
“For applications that need to find external XMP files, look in the same directory for a file with the same name as the main document but with an .xmp extension. (This is called a sidecar XMP file.)”
Major photographic applications follow this naming convention, i.e. filename.xmp, not filename.ext.xmp. For example we read at Photo Metadata that “For file formats that have no internal support for XMP data, the data is stored in separate .xmp files with the same base file name. Many photo cataloging applications have support for this file format.”
Some discussion as to how some Linux applications came to default to filename.ext.xmp is available online, e.g. for Digikam. To me caulier.gilles’ justification for going with filename.ext.xmp is wholly unsatisfying. With respect to PNG and JPEG files, the XMP specification says to write the XMP metadata into the file itself, not as sidecar files. Moreover, unless I’m mistaken, Adobe developed the XMP spec itself to handle the use case of the same base file name with different extensions. See for instance the tag dc:format.
One might ask why does this all matter? Does it matter that some Linux applications have gone off in a different direction to the rest of the photographic software world?* Personally I think it does matter, because standards really do matter. Conflicting standards make life difficult for users and for applications developers. In my case I wrote Rapid Photo Downloader to follow the standard, but some Linux photography application users who use Rapid Photo Downloader as a file renaming tool are justifiably bewildered by the fact that Rapid Photo Downloader doesn’t detect their non-standard XMP files.
So as an application developer I face a dilemma:
- forget the XMP standard and make life easier for those exclusively in the Linux photographic community, or
- go with the standard and ignore non-standard XMP files, suggesting to users that they use ExifTool or Exiv2 to rename their existing collection of files.
I’m yet to decide what to do.
*Bibble Pro used to write out files using the filename.ext.xmp convention, but as I recall its successor Corel Aftershot offers the option to step back from that and follow industry standard practice.