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.
