When I star rate an image outside PhotoLab before I open the image’s directory in PhotoLab the star ratings show in PhotoLab. If I then change the star rating or add a star rating of another image in the directory, these changes do not show outside of PhotoLab.
I had expected the star ratings would be the same with programs reading the star rating via xmp file. Perhaps I’m not doing something correctly.
I use IMatch as a DAM have not had this issue with it and other programs.
Same problem when you use Photo Supreme as DAM. Must be something with DXO not properly handling XMP data.
1 Like
Again a reason to implement more DAM functionality in PL. Correctly reading/writing XMP is a substential part of it, independently of whether the XMP producer/consumer is an external application or PL itself.
4 Likes
Hello guys,
PhotoLab reads the star rating data from XMP files and displays the rating (stars are yellow in the Filmstrip in this case). But if you change the rating inside the app it won’t rewrite the XMP data unless it’s processed.
Regards,
Svetlana G.
1 Like
So please change this if possible. Seems to be the same problem as the wrong image orientaton when you export JPEGs in portrait mode out of PL. PL changes EXIF image orientation without writing the corresponding information to XMP. Please make PL fully XMP compliant. Everyone with an external DAM is running into problems otherwise.
1 Like
+1 what roeslewf said, to me that would be a app requirement to write changes back to XMP.
Mike
Hi Svetlana,
To me this behavior appears to be a bug though I also believe the current behavior is DxO’s intention. I believe XMP data should be on a 2 way street. Accepted from other applications and available for other applications to read.
So I think DxO specific information should be in the DOP files and XMP should be read from and written to XMP files.
Cheers
It would be best to drop DOP and use XMP only. XMP allows storing company specific tags in addition to common tags, like:
<xmp:Rating>0</xmp:Rating>
Lightroom specific tags:
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>Events|2016|Urlaub_Spanien</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
Acdsee specific tags:
<acdsee:keywords>
<rdf:Bag>
<rdf:li>Events|2016|Urlaub_Spanien</rdf:li>
</rdf:Bag>
</acdsee:keywords>
Possible DxO specific tags:
<dxo:corrections> ... </dxo:corrections>
<dxo:hierarchicalKeywords> ... </dxo:hierarchicalKeywords>
...
One sidecar is more than enough.
Hi Asser,
My thinking is that an XMP file with multiple programs writing to it, one program may corrupt another programs tags. I know it shouldn’t happen but…
I’ve come to accept sidecars, presently I have dop, on1, and nx-d sidecars. IMatch handles them all nicely, moves them with the raw files and I generally don’t see the sidecars except when I look in the file explorer.
Cheers
1 Like
If a program writes back a rating, it also can destroy the file content. So if there would be a bug, it would have to be resolved. Everything else should be covered by your backup solution.
Hello,
Anyway it’s not a bug for now as it was not designed like that. In PL the star rating is stored in XMP/EXIF when saving the image (for the test you can select any image, put several stars and export it to LR for example as a processed image -> when opened in LR output will have the same rating you put in PL).
Regards,
Svetlana G.
I like architectures, so here is the summary for the current design:
What is missing is an edge back from bottom RAW to XMP. Shall I make a voteable feature request for this or is this covered by the DAM feature request?
Nice table! 
I think it’s better to create a separate request.
Thank you
Regards,
Svetlana G.
Hi Asser,
Nice table. it’s nice to have a picture of the issue.
Besides the 2 way arrow between Photolab raw and DAM xmp. I would have another user box going into DAM raw. I do realize this is implied in your table but I think it might make the impact greater.
If I’ve got any votes left (I think I’ve got 1) I’ll give this a vote.
Cheers
Please keep in mind that not everybody uses XMP sidecars at all for metadata.
I write the information (description, keywords, location data etc) directly into the RAW files!
Besides this, a RAW file might develop to different RGB files (by virtual copies) having different ratings.
IOW a RAW file doesn’t need to have the same rating as the derived RGB file.
Therefore the current behaviour of Photolab is not bad for everybody.
Oliver
Yes, but this should work somehow, because it also works in other tools. I have tried it. Maybe for the RGB files the XMP is embedded, so that the sidecar is used only for raws, and the embedded XMP for the RGB. The different XMPs can carry different ratings.
Hi,
In my view this is a design flaw. The standard way to store meta data is in xmp files but DxO stores it redundantly in the DOP file. This is even more of a problem than it looks because generally in software design storing the same information in 2 places leads to synchronization problems that are hard to fix and lead to unexpected behavior. That’s what we have here: information (star rating) is not synchronized when the user expects it to be and worse they must keep track of the yellow vs. green stars. That makes no sense because the star rating should be the same in every product and having it otherwise is unintuitive, inconsistent with the behavior of other products, and confusing.
Short of getting rid of the star rating in the DOP file completely, I suggest ensuring that any star changes entered in DPL be stored back into the XMP and JPG files so everyone in every product sees the same star rating.
Mike
6 Likes