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.
( Marc (macOS Ventura on MBP16" Intel))
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.
Since I wrote the note below, I have done bit more exploring.
I find that when you export a sidecar to a Nikon raw image, the exported file name is “filename.NEF.dop”. Although this file looks very much like an xmp file, Exiftool indicates that it is not a xmp file but a txt file.
I have tried every combination of settings I can find but I cannot find any way to transfer color settings, star settings, or any other metadata between dop files and xmp files. this means that I can find no way to use Photo Mechanic to set metadata and then import it to PL3 or vice versa. I may be missing something, but I just cannot find a way.
Metadata that is embedded in a jpg file by Photo Mechanic 6 Plus does not show up in any way in PL3.
This is all very confusing. I hope the developers might be able to shed some light on this. However, I find it disconcerting that it is so difficult to use other programs that all interchange metadata by xmp files that do not play well with PL3.
I too have been very confused by this discussion. However, after digging around a bit, here is what I suspect is happening.
All of the external programs/apps mentioned above read and write the metadata for raw files to sidecar, usually with an extension xmp. The format of this file is an industry standard ( Since early 2012, the XMP specification part one, which defines the XMP data model and core namespaces, is an open, international ISO standard (16684-1).) This is how Photoshop, Lightroom, etc. handle metadata. I use Photo Mechanic 6 for my DAM and have the preferences set so that the metadata for raw files are stored in such a sidecar. It is possible, but not a good idea, to embed the metadata in the file. If you do this, it is my understanding that PL3 will not process the file. Metadata for non-raw files (e.g., jpg, tif) is always embedded in the image.
If the preferences are set, PL3 creates a sidecar with the extension .dop. This file turns out to also be an xmp-formated file. You can verify this by using Phil Harvey’s command line tool Exiftool.
(the simple command to display the xmp data in a file is ‘exiftool filename.ext’. This file is thus a second, separate, and DxO proprietary xmp file. (I note the both files are, in fact, txt files, so you can read them in any text editor.)
What is happening in the discussion started by Brian is that when he goes to IMatch and changes the number of stars, the information is stored in the industry-standard xmp file described in (1) above, while PL is reading their xmp file described in (2). Hence, PL does not see the change. And, vice-versa, when he changes the stars in PL, IMatch cannot see the change.
The consequences of this disparity are significant. For those who use a cataloging program external to PL (e.g., Neofinder, Photo Mechanic 6 Plus, …), to the best of my knowledge they index only the xmp files described in (1). I have not looked in detail at how the metadata that one enters in PL is handled, but some of these data are set up to transfer to Lightroom, but certainly not all. Also, if you need to store IPTC data, as far as I can tell, the is not done in a dop file, but is fully supported by the programs that write xmp files. Caveate–I may misunderstand some of these details and certainly may stand to be corrected.
For my personal workflow, I turn off the creation of the dop sidecar and rely on saving all of my parametric edits in the PL database. I do all of my classification and cataloging in Photo Mechanic 6 Plus (still in beta test as of this writing, but available to all customers). I can then find the images I want quickly and easily. Many readers of this forum do the same thing using other DAM systems as well. Once sorted and selected, I create an empty project in PL3. Then, in Photo Mechanic, if you right click on one of the selected images, you get a choice to ‘Edit Photos With …’. I have set up DxOPhotoLab3 as one of my choices (you get a pull-down, so you can add as many choices as you wish). One click, and all of the images show up in the project perfectly. As noted elsewhere in this forum, you may be able to drag and drop the selected images in your DAM onto an empty Project in PL3, but I have not tried this.
Since I back up my work nightly from my working drive to two separate external drives (a primary and a secondary backup), I also want to backup all of the parametric data in the PL database. Thus, I also copy this database (as noted elsewhere in the forum, there are a variable number of database files–anywhere from 3 to 5 have been documented) to a folder on all three of my hard drives. (My working drive only has images and their derivatives–all of my programs, apps, word processing, etc. are yet on a separate hard drive.)
Hope some of this helps in understanding what appears to be happening with PL and metadata.
I can’t remember what this thread was all about, but after a trial and some reading about Photo Mechanic I can say, that you can configure it to save data to the XMP sidecars in a way, that Photolab will be able to read it.
You can only use the star rating and the keywords only.
Unfortunately (at the moment) it is a one way street: settings in Photo Mechanic will show up in Photolab after you saved them.
You will not see the color labels as Photolab doesn’t support them.
Unfortunately if you change a star rating in Photolab or add a keyword it will only be saved to the database (or the star rating also to the .dop sidecar) so normally you shouldn’t do it. It will hopefully change to something more useful in the future.
If you export the edited photo, the exported file will have this information too.
The pick/reject (green/red) colors in Photolab are only useful inside Photolab.
In my experience the .dop sidecars are more useful and easier to backup.
These are not XMP files. You probably confuse XMP (a specific namespace inside XML) with XML (a markup language format). The .dop seems more like a JSON, but is rather something else. The categorisation as a text file from Exiftool is correct.
It might only be in the Photo Mechanic Plus Beta, but they were also talking about handling the .dop sidecars for renaming/moving.
You will not really be able to move information from a .dop file to a .xmp file unless you write some special program for it. But if you only change data outside Photolab and use above mentioned settings, you will be able to see them inside Photolab.
I definitely see changes made to star ratings and keywords in Mylio and IMatch inside Photolab.