Preserve metadata in XMP sidecars for RAW images: Allows the application to process and export your RAW images while using metadata previously stored in an XMP-format file alongside the input image (e.g., metadata created by a program such as Adobe Bridge).
I have this Preferences option selected. I make editing changes in PL to my RAW file, including a star rating of two. Later, I change the star rating to three in IMatch (DAM). This creates an XMP sidecar file.
Back in PL, I export the image to a DNG file. The star rating in the resultant file is two. Why isn’t it three? If more editing is done, exporting the file again results in the same two stars.
So if the XMP data is not used when explicitly requested (via Preferences), what is this option for?
Well, it preserves the data until you modify it inside the PL (in your case you put 2 stars and it gets the priority). In your case if you disable the PL rating on this image you will see your 3 stars rating from XMP and in this case the processed images will have 3 stars as well.
You can also check it by simple putting this image+xmp in the new folder and browse it in PL -> in this case you should also see 3*.
Svetlana, I too use external tools to efficiently rate my photos (FastRawViewer in my case). On occasion when working on the RAW in PhotoLab, it makes sense to change the rating. Those changed ratings don’t show up in the XMP.
Or perhaps I go back to FastRawViewer and re-rate some of the images. Changes also don’t show up.
I agree with Brian: PhotoLab should be much more interactive with the .XMP files. To the point of even storing its own XMP standard metadata (ratings, keywords, GPS?) in an XMP for better interaction with external programs. Storing metadata in its own files just makes a mess.
So based on the replies here, I’m guessing that this Preferences option gives the user the choice of whether to process their files using the ratings (and other metadata) stored in the DxO dop proprietary file or that which is stored in the XMP standard file. Is this correct?
If so, then I agree that DxO is going down the wrong path. I see no value whatsoever in this as a feature. Certain core metadata such as ratings are fundamental attributes that are ubiquitous and should never be application specific. Furthermore, how would one know what metadata types are recognized and thus applied by PL and what is not? (Good luck keeping it in your head over PL versions.)
Anyway, aside from the problems I’m having getting it to work, would someone please confirm if I’m correct on how this Preferences option is supposed to work. I would be grateful.
Thank you for the feedback on this preference option. To be clear on this option, i’d like to explain what does it mean this option “Preserve metadata in XMP sidecars for RAW images” in Processing session.
XMP sidecar contents not only Rating or Author/Copyright information, but there are a lot of other information in xmp sidecars as well. So,
If you enable this option, all information in xmp sidecar will be preserved in your output image.
If you disable this option, only a few basic information of xmp sidecar will be exported to output image.
Moreover, how we understand RATING behavior when working with image files associated with XMP sidecar ?
It’s independant with "“Preserve metadata in XMP sidecars for RAW images” option, so any this option enabled or disabled, rating of output image will be imported from rating of input image in PL. (for example, if rating of input image in PL is 2 stars, 2 stars can be imported from XMP sidecar or from Exif or directly set in PL, output image will also have 2 stars)
What is priority for rating? PL > XMP > Exif.
*if Exif rating = 2 stars, XMP rating = 3 stars --> final rating = 3 stars in PL (stars with yellow color and explanation tooltip will be displayed when you mouse over on) --> output image rating = 3 stars
*if Exif rating = 2 stars, XMP rating = 3 stars, then we rate 4 stars in PL --> final rating = 4 stars in PL --> output image rating = 4 stars
This is the way PL working for rating, in the first state, we respect XMP rating until you change it in PL.
About XMP writing, this is a future feature, we have already this one in the backlog and will let you know when we get back on keyword implementation.
Can’t agree more. Especially when you use an external DAM - Photo supreme in my case - it is very important to carry over rating changes done in PL to XMP. Otherwise your external DAM will not recognize these ratings correctly.
Yes, you are talking about XMP writing (rating is part of xmp sidecar), we should thinking to covert all (or max) cases possible. Something like:
What happens when we have virtual copies? and rating is not identical for each virtual copy. In XMP sidecar, we can store data for only one image. (therefore in the previous EA, we set the Master image notion, this can help workflow to overwrite XMP sidecar.
We should add preference options and let user decide for automatically overwrite XMP sidecar or not
We will keep your feedback and fine tune it when we implement this xmp writing feature
Those star ratings are primarily for rating incoming images. Using selection ratings to rate virtual copies should be discouraged. Virtual copies should employ some other kind of rating or comment system (colour labels?). If I were the UX designer, I’d lock the ratings on virtual copies to the rating of the master file to avoid the issue
This an unnecessary and confusing preference. If a photographer has chosen to use XMP and DOP sidecars the XMP rating should always be overwritten.
Consistent behaviour is often more useful to the end user than flexible behaviour. Steve Jobs stressed that it’s the developer’s job where possible to make intelligent choices for the end user. Decisions carefully made save users time.
The deeper issue here is the conflict within DxO to make PhotoLab some kind of monolith program like Lightroom which demands that every other program be subordinate to it and runs off of a huge database or to carry on with a RAW developer which interacts well with other software and stores its data within the file system (.dop and .xmp files). Iridient Developer is an example of clearly the latter. C1 is an example of the former. PhotoLab doesn’t know which one it wants to be and has been walking the fence for the last couple of years.
For most existing users (we’ve all paid a pretty penny for the privilege), playing well with others and compatibility with other software and storing settings separately from a database are extremely important. The Lightroom users (most of whom would never drop €200 in a single purchase for any software, particularly if it doesn’t have the name Adobe on it) targeted by DxO marketing would probably prefer the monolith.
The question is does DxO throw its existing users to the wolves in the pursuit of potential users in the hopes of attracting users who 1. would not pay that kind of money for software 2. are mostly Adobe die-hard junkies 3. the last people to leave Adobe software behind. Never forget the existing Photographer’s Package includes a full copy of Photoshop. Phase One just had a go at pulling users out of Adobe, with an extended half price sale to bring in Sony and Fuji users. I’m curious to know if they made a dent in in the Lightroom userbase or not with that big promotion. Unless there are plans to radically change pricing and positioning, siding with the existing paying users would be both ethically better and commercially wiser.
DxO PhotoLab’s situation with its userbase reminds one of the husband of ten years abandoning his exquisitely beautiful and scintillating wife to chase after a common or even vulgar young nanny. Of course this illogical situation happens almost every day. I.e.: Jude Law and Sienna Miller or d’antan Hugh Grant and Elizabeth Hurley.
PS. The above is written with a smile, not a frown. To amuse, not to offend.
I disagree. A virtual copy in my workflow can be a totally different picture (different crop, perhaps B/W, …). Often I export even two versions of the the same source, but they may have different ratings from each other and from the other versions that I don’t export.
I would like to have the possibility for PL to Read only XMP files because PL is not gonna be my DAM anytime soon and I do not want any software to mess with the XMP, especially as long as you are debating those topics. I do NOT want to be an XMP feature beta tester Thank you.
Marc, If you don’t make changes to XMP properties (ratings, keywords) in PhotoLab, there’s no reason for PhotoLab to write to XMP. If you are making changes to XMP properties, I’m afraid you and everyone else like me who do not use PhotoLab as a DAM do want those changes written. Otherwise we don’t have any kind of sync with our existing applications.
Your point that DxO should proceed with considerable care here not to damage existing data (zeroing XMP files for instance) is well taken.