@John7 I am sorry about my “brutal” post to @platypus but he is simply re-hashing stuff that I have done before without referencing that work DxO Photolab 5 Image Rotation Lost in Backups - #3 by platypus.
I apologise for not responding to your original post earlier but I find it difficult to read a post and “fully see it for what it is” when I am already working on something else so I saw it but didn’t fully take in what it was about at the time!
My response to @platypus was that he had seen this before some of this before and repeated tests I had done back in February as if he was discovering this for the first time, without referencing my earlier posts. The rest of @platypus’s post is very much his own work and nothing I have attempted in any of my posts.
Now back to your concern that DxO have engineered a bug! They would argue that they have put metadata where is belongs, namely, into the image metadata (embedded for JPG, TIFF, DNG and sidecar for RAW)!
In fact prior to the February post there had been numerous arguments about why the PL5 DOP contained superfluous metadata at all which “violated” the “rules” of data separation and data “duplication”.
The original reason that the data resided in the DOP was because of the “so called” immutability constraints that DxO were following at the time. I believe that Capture 1 maintains such constraints and that all metadata changes for all image types are held in xmp sidecar files, only being “merged” back with the image when it is exported (or at least that is what appears to happen).
DxO decided to use their own sidecar, the DOP, and you have been using that feature as a useful tool, as indeed had some others. When DxO finally decided to handle metadata more like other programs they continued to store the now expanded metadata in the DOP but for the [M]aster copy that is never used as the source of the metadata, the source is now the image (JPG, TIFF, DNG & RAW) and the xmp sidecar file (RAW) which then completely undermines you carefully crafted strategy.
Others detected the problem because they conserved only the DOP in PL5 as they had previously in PL4 and discovered ‘Rating’ turned to 0 when PL5 read the PL5 DOP or rather didn’t read the DOP but read the metadata which had not actually been written or preserved (e.g. saving the xmp sidecar) . For any metadata changes made in PL5 to be preserved they must be written back to the metadata with AS(ON) in the ‘Preferences’ or ‘Write to image’ with AS(OFF).
@joanna as it should be, the [M]aster data is coming from the image metadata and the Virtual Copies from the DOP.
Only with AS(ON) or ‘Write to image’ I believe.
Thank you for adding that bit which confirms my statement and the little chart that @Musashi provided some time ago which is now in a FAQ on the website I believe!
We are now on the same page but unfortunately it leaves some users bereft of a “feature” they have been using to their advantage.
Fortunately all the data is present in the DOP if DxO decided to change their minds and start re-using the DOP for the [M]aster but I would suggest that needs to be carefully engineered, preferably as a special option so that @John7 and others can use it to their advantage while others who have become used to the way PL5 currently works can continue to use the PL5 way of working without discovering any unwanted side-effects @sgospodarenko @alex.
I consider the implementation of the metadata changes made in PL5.2.0 to be a “knee-jerk” reaction to a genuine issue in an attempt to assuage the ire of some users, which didn’t fix the cause of that ire and actually had a retrograde impact on keyword management. It effectively de-implemented the current way of working and didn’t provide a facility to allow those who were using the product to choose which course of action they wanted to follow!
I don’t think I have ever seen such wanton, inexcusable “vandalism” in years!