It’s been clear that that’s your argument for a long time but it’s also now clear that you have no interest in the xmp functionality nor understanding of it’s main use case. You are making the case for darktable to not support xmp sidecars.
You are arguing that a feature is a bug because you don’t understand the feature. The people doing the standard got this right because they think about interoperability and sharing of metadata something you have expressedly pointed out you have no interest in.
As damonlynch points out a certain level of intent and ambition with the organisation of your files have to be assumed to create anything useful. The organisation of files is a feature of the standard that enables meaning it’s part of the relationships of metadata. You can but your images scattered across all folders of /usr and still have a decent experience using darktable. Doesn’t make it a good idea if you ever deal with other people.
Bad wording and so misunderstanding by people implementing it. Exemple:
I have a file XYZ.pdf containing a text document here Wuthering Heights
What is the main document name. I should say either the title or perhaps the URN:ISBN identifier or something else but what? Surely not the file base name as a file is not a document but the location to access it and completely defined by an URL.
Perhaps the writer wanted to write “the same name as the main file”. Then until now a file name includes the extension.
This phrase is all nonsense.
So for that subject please don’t refer to XMP standard but to de facto industrial standard and we can close that debate.
Argument from authority, absurd assertions, and talking past each other.
Is darktable going to change? Probably not. Devs made it clear that darktable had a reason for working the way it did when you first raised this five years ago. Nothing has changed.
Let me be clear here: XMP files are fine. what is not is that reduction to 1st implementation that clearly lacks flexibility and calling it “THE STANDARD”. apps like darktable correctly look for filename.ext.xmp and filename.ext. filename.ext.xmp is better because it’s clearer than filename.xmp in case of ambiguity. And solving possible ambiguity by yelling “you’re naming your files wrong” or “your usecase is bad” is doubling down instead of simply adding check for filename.ext.xmp.
I think @gaaned92 nailed it: “same name as main document, but with .xmp extension” is nonsense because when dealing with files we have filenames and filename is simply unique identifier in filefolder that might or might not have extension and long gone are the times where 8+3 was all the characters one had to name a file (and couldn’t even name file “.” (that’s a joke, but i can name file that))
So to sum up again: we believe “THE STANDARD” had got it wrong and all it needs is a simple fix, you believe that “THE STANDARD” is ok but we got it wrong. There’s no middle ground and no need for it.
Irrespective of what you and I think is best, the sad reality is that darktable users are going to silently lose the metadata they’ve entered by hand when they move their photos to another system, unless they are aware enough to take mitigating steps.
How many have already lost their data? Who knows. Have the darktable devs thought about this? I hope so, and I hope they will take steps to solve the issue.
Unless the sidecar files are deleted, the data is not lost. It’s merely not found. Also, it’s easier to remove the intervening source file extension with scripting than to add it in…
In any case, the right thing to do would be conservative in what you produce, and liberal in what you accept.
The only useful interoperability for xmp is user-entered metadata. To me it seems I should follow the sidecar naming standard, but only put user-entered metadata there. There is still a potential issue with name collisions between cameras with different extensions but Filmulator has countermeasures for that.
When reading I’ll accept both the nonstandard and more logical xmp naming from darktable, and the standard but non-collision-resistant ISO way.
For processing parameters, there’s no reason to use that naming standard, or even xmp at all. There is no benefit in the slightest to interoperability there, because it’s already a reverse-engineering task.
Exiv2 and Exiftool have made a great work to decipher this jungle.
It is not about liking or not. Just a fact: 3737 different tags.
Do you think that deserves really the name of standard ?
There are specific tools to manage that, digikam, …
I don’t believe that every image tool needs to deal with that complexity / redundancy.
Talking about darktable, I would focus on manipulating / controlling properly the metadata associated to exported / published images (and here the number of useful tags is far more limited).
Interoperability with other commercial raw development tools is far more questionable, at least as a general principle.
More than 99% of the pro photography world uses commercial software that these days implements the XMP spec for metadata storage. They’re comfortable using it. It largely works. Systems are interoperable, leading to cool things like the Google image search feature I mentioned above. It’s not perfect. Sometimes the software has implementation bugs, and some of the data is silently lost or corrupted. But overall this group of people are in a much better space then even 5 years ago. XMP is doing its job. Legacy systems are still around but are less of an issue. The XMP spec itself has to deal with legacy data, which looks ugly when you actually read the data, but that’s life. The spec would never have been adopted if it didn’t!
Less than 1% of the photography world uses contemporary software that does not implement the XMP spec. The spec is not implemented because the devs think it is stupid, the users think its stupid or don’t understand it, or more benignly because the dev didn’t have time to implement it yet. These users are guaranteed to face problems transferring their own data to systems developed and controlled by the 99%. Will the devs be there for them at that time? Hard to say.
A perfectly reasonable choice. Thank you. You can store your image development data in whatever format you like given you have no need to make it interoperable with anyone else’s program.
It’s worse because the XMP standard needs to have lots of rules dealing with what to do when there is conflict between the various sources of metadata.
That XMP has succeeded despite this crazy legacy is I think a sign of its success, not its failure. As I said initially, things are much worse in the video world, where metadata is vendor driven and introduces vendor lock-in.
Plus I have to say huge respect to people like Phil Harvey. Few people are capable of the exceptional work he and a very select few others like him do.
Yes I agree here. The xmp file name is obviously a spicey topic, but getting tags correct on places like the internet is way more important than everyone’s personal raw collection.
The main issue seems to me to be that those keen on .ext.xmp aren’t really concerned with semantic metadata but only with saving edits and history?
I can see the issues with using xmp as a sort of universal config file for photo editors. But thats imho not it’s core role. I understand it as the image part of the huge xml metadata effort that aims to tag content and relationships. Sacrificing the metadata part for the config file part seems very backwards and misses the point completely.
.
” (that’s a joke, but i can name file that))