I think everyone is aware of the spec allowing edits to be stored. However this is a separate issue and much less critical as edits can’t be fully compatible between software.
The choice of using xmp for edits is of much, much less concern for users and more an issue of one less sidecar in the folder and what format the developers want to write their configs in. It has very little impact on users. If config is stored in xmp it’s crucial to follow the spec though to avoid breaking the exif/iptc part.
Is it though? Not even Adobe, the creator of the XMP standard, holds to its own standard for handling all types of metadata. Take a look at what Premiere Pro produces after analyzing video files:
This is still metadata according to Adobe’s own definition: “Metadata is any data that helps describe the content or characteristics of a file.” Apparently the company who designed and pushed for adoption of a standard is okay to store this type of metadata differently? But some people think it is really bad that not every (FOSS) software follows the XMP standard? Aren’t those double standards?
This seems the core of the argument, really. There are multiple levels of metadata. Metadata per file, metadata per group of files, even metadata for multiple groups of files, and so on. These different levels of metadata seem hard to reconcile if you restrict yourself to a single XMP file.
Along with the different organizational levels also come different types of metadata. On a per file basis you may want to store things like creation date, but perhaps also some color label or ranking (for example, if you have multiple renditions of the same image that you label differently), and also things like editing history. Then on a group basis you may want to store things like shooting location, descriptors of the content (‘family pictures’ etc.), things that would result in redundant information if stored on a per file basis. And one level higher you may want to store information about author.
So, how does the XMP standard allow for this kind of control? And how does it rhyme with the idea of using the filename.xmp convention?
In my mind the master child relationship is important and inluences how metadata propagates. For a reasonable workflow you tag the master file, and any sooc children, with all the relevant metadata in one go. Creating the master .xmp file that applies to all files with identical basenames.
All files produced from the master will then have the base metadata included. Those children will naturally have some properties that diverge be it colour space, resolution, changed content due to crop file format specific metadata, notes that help identify it etc. Depending on the changes and workflow a rename (suffix perhaps to maintain relationships) can be made. You can also embed additional metadata in the child file as long as the format allows it. When outputting the file again overwriting it, after tweaks say, you have to redo that extra tagging but that’s inevitable. Allowing tagging only at export would be an interesting feature.
Of course you can maintain any personal metadata system on top of this if you wish but this can’t be expected to propagate or be understood buy the world. xmp and the standardised tagging is there to for that data you want to work externally.
That restriction is only for files with identical basenames in the same folder that haven’t been individually tagged. Not much of a restriction imho.
^ I’m not sure this is was an intentional retorical repost or a mistake as I answered it in the post you replied to.
As a user you can to whatever you like with your tagging and metadata. Override with fine grained per file embedded metadata, run parallell system, have a database, a text file, all metadata in file names etc. This is all possible whilst having well behaved standards compliant software than can interface with the rest of the world.
I’m super confused about this, a joke that this thread is to heated risking to undermine free software? A conspiratorial anti-capitalist worldview? @johnny-bit is expressing similar “rebellious” anti corporate stuff but it’s pretty hard to understand. Perhaps because I doubt anyone else on this forum has as “hard”, long term and “extremist” views on those issues as I do. There are only a few positions below and none to the left of me on the political compass.
You’re trying an anti-corporate BS as a counter argument against “the standard”?
I’m saying it clearly that filename.metaext is inferior and even @Thanatomanic showed that Adobe itself can use filename.ext.metaext. You say it’s “not much of a restriction”… Sure it’s not “that big of a deal”, but clearly allowing filename.ext.metaext is more flexible and robust for ALL standards that relate to file connections.
So, to circle back to anti-corporate BS: I have nothing against corporations (in this discussion), I have nothing against actual standard. I have a problem with interpretation that filename.metaext is “THE STANDARD” and therefore filename.ext.metaext is bad.
Simple: You guys are drumming for filename.metaext to open source devs, have you drummed for filename.ext.metaext to commercial stuff? I think more flexible and robust interpretation of filename is generally better than blind reliance on less flexible and less robust first implementation.
From my angle there’s no significant difference between those to so that’s probably why I didn’t get the joke.
Oh @johnny-bit just read things again please. The text you quote contain no argument about standards what so ever. It referred to you meme with “corporate” appearing dumb.
As for the rest of your post it’s also all over the place.
I think the filename.xmp standart is better than filename.ext.xmp regardless or the standard that should be clear by my extremely numerous posts.
Since the well adopted standard uses filename.xmp “we” should to regardless of my feelings.
We’re not discussing any metadata sidecars besides xmp ones. There are lots of possibitilies for lots of use cases and metadata formats beyond xmp but those are irrelevant to this thread and can use whatever conventions they see fit.
Convincing the entire world of DAM, publishing software and commercial raw developers to use a, in my view worse, solution is a completely different thing to arguing the case that a couple of foss softwares whose developers I’m in contact with should adhere to the standard. It takes a special mind not to see that.
Sorry to interfere. A total ignorant about metadata standards…
After reading every post here, I still have a doubt: as pointed in the first post, metadata is really valuable when publishing images or giving information to the viewer. As a standard de facto, publishing online requires jpegs, and those files embed metadata inside them. Same for tiffs and pngs (AFAIK). So if a FOSS tool correctly saves metadata into the headers of those files, why would I ever need a file.xmp sidecar? Doesn’t Google and others read inside the images?
If so, why a raw development app must ever need to write anything about the raw file into a file.xmp file? All in all, there will be no interchange of developing information between different raw developers, so the only excuse for that file would be metadata. Anything else would have to be recreated/redeveloped in a different software. So where’s the need to interchange that? I mean the information about what you have done with the raw file.
If all the problem is metadata, wouldn’t it be enough having a button in every free raw developer to «export» (save) just the metadata in a file.xmp sidecar? Just in case you need to change to a different raw developer for good? And if you are not going to change app, then leave to the developers create the sidecars they wish/need? Why is that a problem? I just need to upload a single file (e.g. a jpeg) to Flickr, not the sidecar, as the jpeg has all the needed information. Or not?
Because the raw file is the master. Typically multiple files will be exported from this file. At a minimum you’ll have a srgb jpeg file for web use and a wider gamut jpeg or tiff for print and other media. By tagging the master with the base metadata all child files will automatically contain that info. So all things like creator, keywords, as well as most other iptc fields will flow from that file.
If you only tag output files you have to do that every time you export a new one which can be an awful lot of times. This is error prone as well as time consuming. If your output format has dubious metadata support or the recipient demands it you may send the xmp along with the image to ensure all metadata gets shared/uploaded.
Whether a raw development app should have a metadata editor is up to the scope of the software. To work well it does need to read and propagate metadata correctly following the xmp standard. “technical” tags might well have to be written by the raw developer to xmp for it to work but I care less about the technical metadata so I don’t know about this. Its fully conceivable to do all the metadata editing in a separate specialised software but then agan the raw developer has to read an propagate it.
Absolutely, this would work. But it’s better not to have a second file.ext.xmp laying about next to it confusing matters and software.
You think that filename.xmp is better, i (and evidently couple other devs) think that filename.ext.xmp is better.
Still - there would be absolutely no harm for “the standard” to also adopt checking for filename.ext.xmp. Literally. That’s maybe 3 lines more to check for it’s existence…
It takes a special mind IMHO to not see that this is a bit… “Ohhhh big commerical has a std… and FOSS devs are stubborn that the std is a bit limiting… So rather than bothering big commercial that FOSS have solution to limitation imma bother foss devs to criple their solution”. That’s how I see the argument.
Wonderful thing about foss seems to be that one can talk with the devs, argue, file a feature requests/bug reports etc… With commercial software you pay and don’t get that level of sway.
Another wonderful thing about foss is: PRs welcome. So if you don’t like something you can actually fix it yourself!
Ok. I agree that there must be a standard about placing certain information under certain tags.
I agree that after tagging the raw file, any exported image will include those same tags.
Don’t follow this: if I export an image with my preferred raw editor, I expect that any tagging I have already included in that raw will be automatically added to the exported image. I don’t have to do anything. Or do I?
No matter the way the raw developer stores its raw metadata, I figure it will be correctly included into the exported image.
If you mean that if I add new tags, then I would have to re-export all previous exported images, …, well, then read next quote.
If I follow you, in the file.xmp scenario, I don’ have to re-export the (e.g.) jpeg file. And if the recipient demands it, with the updated file.xmp everything is fine…
Well, I read some time ago about iptc vs exif vs xmp, and how are they supported, but I can’t seem to find it right now, so let’s assume this old post explains a bit how convoluted the situation is (and I would love that it was not that way, but…).
So, if what is in that post is true (that is, each program defaults to certain metadata storage), there will be a bunch of programs (including, shockingly, Adobe PhotoShop) that won’t read certain tags in the updated xmp file, if and only if those tags are already included in the jpeg. So to put it clearly: I exported a jpeg including certain tag in its header, then I updated that tag in file.xmp, and finally I sent both. The program may only read the tag from the jpeg header because it takes precedence…
I don’t know, but I guess the standardization problem goes way farther than just including a middle extension or not. E.g.: to be sure a program (any program) reads correctly the metadata, it should be stored in all three storages (iptc, exif and xmp). And that presents a whole bunch of other problems, I think.
As I already said, no matter what the program uses to store its metadata (even in a xmp file including processing parameters), if you exported a file, then sent it somewhere, and after that you had to update the raw metadata, which is asked by somebody, just click that button and you will have your desired file.xmp. Then it has to be seen if the recipient already sees the updated metadata or not (it will depend on the program).
The xmp file is about the metadata being compatible with lots of software, systems and organisations. If you only ever expect to use one piece of software for all your development and dam needs, for all eternity, then how and where the data is stored is irrelevant until you share it. It could be an vendor encrypted database and it wouldn’t matter.*
The purpose of the xmp is that you can tag in a dam, develop in a specialised tool and handle your files with scripts. Pass the files to someone else, change your setup and software without losing the metadata.
That might well happen. If you embed in jpeg change the .xmp, send of the jpeg without any update/sync. The jpeg likely won’t have the metadata. That all depends on the software and set up. Unless you send the xmp or sync the files it may differ.
Yes that’s a whole other issue. Which tags to use. But if the standard is followed there a much greater chance of successfully moving tags between namespaces. Exiftool handles that well so a more comprehensive dam should be able to implement it nicely to the extend the tags overlap.
As mentioned xmp is complicated but successful non the less. There are choices and options and workflows but it’s hugely helpful if the software follows the standard in writing tags and filenames. Once that is in place you stand a chance at using or developing tools to solve the other issues.
This conversation started about interchanging metadata and then spiraled into who’s right about XMP files (@patdavid, can we have a pissing contest emoji?). Everybody had a use case to justify why they felt they were correct. And each of them is right.
So, maybe we need to focus back on the original idea of sharing data between applications. Perhaps the software(s) can just export an XMP file containing the desired information that can be shared along with the image?
A standard is created, sometime in the past, to address a need. Then governments come along and enact privacy laws. Now my standard compliant (or not) information is in violation of privacy laws if I share it. So, I need to filter what I share. I can see the case for “private” metadata, i.e. names, places, details, etc., versus “public” metadata, i.e. no names, generic places, etc.
Yes, but then you end up with two xmp files one following the standard naming and one following the foss naming which makes managing the files complicated.
That’s really the whole issue. If darktable for instance would change their extension from .ext.xmp to .ext.dtb and export a correct .xmp file for standard metadata only the problem would be solved. Since the .ext.xmp files don’t follow the xmp standard they aren’t helped by being xmp files at all and would be better off as something else. Users wouldn’t think they have metadata compatibility sorted until they export .xmp files.
