If you search for it you’ll find it. It’s mentioned in a couple of places. I doubt the author was trained in technical writing because the wording is not all that great. But it’s there.
Alternatively: the standards folks are not idiots. They know what they’re doing. Funny how the entire rest of the industry gets along just fine with file.xmp.
JPEG embeds XMP in the header. As does TIFF. No sidecars for them.
2 Likes
Unless you’re working with a non-destructive editor in which case leave the original image alone and you need a separate sidecar.
1 Like
I already searched and gave the answer above. The XMP standard doesn’t support file.xmp.
So unless you prove me wrong, by effectively pointing to the applicable paragraph in the standard, you cannot say it’s required by XMP standard. It’s just a commercial SW use initiated by whatever corporation and adopted by other firms.
And again perhaps FOSS SW should have a “commercial” mode.
Are you concerned about edits or metadata?
Both can be contained in the xmp but it helps to separate the concerns. I really can’t see how its good practice to save two different image files, describing two different things, in the same folder with the identical name. Extensions conventionally describe file format not content. File names are only there to convey identifying information to humans.
All the concerns about edits, multiple files etc are solved by the magick of subfolders or rename.
Those of you who find the filename.ext.xmp important do you actually tag your images and manage/use the metadata?
I just don’t understand how anyone would want to tag the jpeg and the raw of a raw+jpeg pair separately. Fixing face tags twice? It doubles the already tedious workload.
Yes. Both. Titles and descriptions are part of the metadata and I might wish to give the OOC JPEG a different description for example) than the RAW and I might wish to process and export both, using the metadata to distinguish between them. Neither of these should be added to the original files as all of my edits should be non-destructive.
There are also workflows that process images twice (e.g. RAW > TIFF > Export) and again, you might want to include different metadata in all of these files. At least the user should not be unreasonably restricted from doing so.
Either way my understanding is that Adobe just doesn’t bother handling the RAW+JPEG scenario and just has a single xmp including edits - presumably that’s because you can’t edit JPEGs in their software?
Are you suggesting the company the wrote the standard does not know how to implement it? Seriously?
I’ll link to various elements in the docs.
Metadata is embedded directly into dynamic media files whenever possible. (When the file format or usage model does not allow embedding, the metadata can be in a sidecar file.)
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.)
(emphasis is mine)
1 Like
This is in a section explicitly devoted to MPEG-2 files. Where does it specify that this is a general rule?
This isn’t explicit enough to make the argument you’re making
1 Like
But all this is solved by renaming the file or putting it in another folder. Why insist on keeping the same name as the master raw file after they have diverged? A common convention is to add 001, 002 or _web, high-key etc before the extension. It’s a super straight forward and completely conventional way of showing when files have diverged and changes have been made.
It makes so much more sense is the first thing. Second they implemented it that way. Few standards are written so that you can’t misinterpret them if you want to.
Why insist I rename or move them and hence break the link between them? Sounds like a workaround to me. And bear in mind that the original files have not diverged. They are still the RAW and the JPEG that the camera produced.
haha, but you are saying you want to break the link right. That’s what all this is about. The need to break the link between the master and a child. Or more generally to allow two files with identical filenames to be completely disconnected in terms of metadata.
With filename.ext.xmp you have separated the files already they are unique. No link between them in terms of metadata. You have to handle them separately.
It’s not a master/child relationship. These are two files produced at the same time by the camera. Every camera I own names these files the same, but with different extensions. I shouldn’t have to manually rename or move one of them to process it independently of the other.
Anyway it seems nobody is going to convince anyone here, so I’m out.
1 Like
That’s one point where you need separate metadata: The face rectangles on a raw won’t match those on a jpg in general. More often than not they wont (lens correction, crop, rotation, …).
Could it be worded better? Yes.
Does the entire photo industry — apart from Corel Aftershot and a few Linux-centric apps — follow the file.xmp standard? Yes.
Have they done so for years now? Yes.
Do millions of users and countless existing programs rely on this practice? Yes.
Do industry standard processes immediately break when file.ext.xmp is used? Yes
“It’s tradition, that makes it okay”
Weird Al Yankovic - Weasel stomping day
There’s a Polish joke about eating manure due to sheer numbers of flies doing it and power in numbers guarantees it’s the best idea evar.
Fragile little shits aren’t they? Why does actually sane and working solution has to change? it’s a freaking one check more for that “indumbstry standard”. “do we have file.xmp? no? do we have file.ext.xmp? yes? cool” instead of “do we have file.xmp no??? oh noooooo…”
how about THEY do sane thing? huh? I mean - In normal world file.ext1 and file.ext2 are completely different files, so the “metadata container file” should respect file.ext1 as a valid name.
If couple open source devs are clever enough to support xmp with both ways of naming and commercial software can’t then it’s 
for commercial 
2 Likes
That could be that the spec is poorly written here and ambiguous. What is the name of a document? Somewhere in the spec it is defined as a URI!
So you propose to stick to the de facto industrial standard to provide interoperability and give some traction to FOSS. This applies mainly to DAM.
But there are some cases where the interoperability with industry is not interesting and the ext.xmp scheme is useful.
Imagine applying this mentality to the binary representations of images in industry standard images formats like JPEG and TIFF. See where that leads you. I can’t speak for anyone else, but thank goodness you are not responsible for maintaining libjpeg and libtiff.
Really? In the first post I gave the example of Google image search using XMP data to display photo ownership. I also gave the example of Flickr reading XMP data.
Alternatively, you don’t understand the standard, you don’t understand its rationale or the history behind it, you don’t have to support millions of users, and you don’t seem to care if ordinary users lose their metadata when they try to move their image data from one system to another.
2 Likes
The standard clearly has a severe flaw: file uniqueness is determined by the complete path. As soon as you exclude the extension, you encounter duplicates. So to maintain the standard you’re left with:
- choosing a new path when a new xmp is requested for a duplicate (whether that’s by a new filename or directory)
- embedding the data in some cases
- sharing a single xmp, which effectively becomes a mini database (horrible!)
- simply disallowing a duplicate in the same directory
Anyone got other ideas?
How is this actually solved in the “industry standard” world?