@Johnny & @Joanna & @platypus Sorry for my very late discovery of this item I have been working on the “problem” for a long period of time on Win10 (but after your original post) please refer to the following post (very long and I am sorry about that) PL5 Tag Field not read from .dop file - #66 by BHAYT and one of many posts on tests conducted by me, Joanna and Platypus.
Both Joanna and @platypus were involved in that testing on the Mac which also involved extensive testing of pre PL5 DOPs and their successful or unsuccessful import into PL5.
Summary:-
The migration of ‘Rating’ (DOP ‘Rank’) field residing in the DOP pre PL5 (due to the DxPL immutability constraints) to the ‘Rating’ being “restored” to the xmp metadata is essentially flawed, arguably mostly by lack of timely communication from DxO, including appropriate procedures for various scenarios (eventualities), coupled with over simplistic design in certain areas and bugs @sgospodarenko.
The outcome is that pre-PL5 DOPs were imported successfully on Win 10 PL5 but apparently not at all or not so smoothly on Mac.
With PL5 with or without a PL5 DOP (or possibly one that it is not recognised as a pre PL5 DOP but instead treated as a PL5 DOP) the ONLY source of ‘Rating’ data considered appropriate is the xmp ‘Rating’ filed (embedded or sidecar) and if that has never been set then ‘Rating’=0 is the only value that can be assigned and the DOP will have its WOM ‘Rating’ value set to 0 as well!
Please note I am not concerned about the rights and wrongs of metadata in DOPs versus in xmp versus in both etc. etc. The situation of the transition could have been better managed by appropriate consultation with and communication to the user base, including appropriate settings with respect to metadata sync versus manual read and write versus the changing role of the DOP versus … etc. Plus better coding, i.e. no handling only over simplistic scenarios and adding the odd (Tag handling) bug.
Pre-PL5 DOPs encountered for the first time in PL5:-
For me on Win10 pre-PL5 DOPs were imported correctly but also incorrectly!
The ‘Rating’ (designated ‘Rank’ in pre-PL5 DOPs) were imported successfully but any other ‘Rating’ data, in the xmp data (embedded in the JPG or RAW or in an xmp sidecar) is completely ignored, i.e. the pre-PL5 DOP is considered to the “be ALL and end ALL” with respect to ‘Rating’ metadata and PL5 ignores any other potential source of ‘Rating’ data; sources that will then become the only source of ‘Rating’ data for PL5, other than the database itself, the use of the DOP as a source of ‘Rating’ data is a deprecated feature.
In my long diatribe(this one is turning out longer than I had hoped) (in the post referenced above) I suggested that a better strategy would be to use metadata timestamps versus DOP timestamps to determine which ‘Rating’ data to use. This might work given that PL4 was good at recognising changes to metadata (most of the time - a personal grumble about ExifPro versus DxPL).
But PL4 would only ever update its ‘Rating’ value in the database and in the DOP (‘Rank’) if that directory was encountered while using PL4, so any externally allocated ‘Rating’ would lie undetected potentially for a very long time and there are no commands in PL4 or PL5 to undertake mass updates of the entire database (that might be a good thing, i.e. that there are no such commands but …)
The reason for the problem:-
DxO kindly supplied a table relating to the sources of data to be used by PL5 but these relate only to PL5 handling PL5 data (i.e. post migration) and the essence with ‘Rating’ is that they are written to the DOP as WOM items but are not used by PL5 (currently not at any time - even if the only source of that data).
The primary (ONLY) source of data for the ‘Ratings’ is the xmp data (embedded or sidecar) (except pre-PL5 DOPs which are not included in the chart?).
So where will PL5 get the ‘Rating’ data from:-
-
If there is a pre-PL5 DOP present it will take ‘Rating’ from the ‘Rank’ field in the DOP and ignore any other source of the ‘Rating’ which might post-date the creation/last update of the DOP. In my opinion one of the most short-sighted decisions I have seen in a long-time @sgospodarenko, it makes the assumption that if an external source is being used for ‘Rating’ then PL4 will be aware of such changes.
I also believe that there is a “flaw” even with this assumption because while testing for this post I set ‘Ratings’ in three images externally. These showed with the characteristic “yellow” colour in PL4 but I was able to set new ‘Ratings’ for the 2 JPGs (colour changed to white) in PL4 but was not able to set(change) the ‘Rating’ for the RAW (held in the xmp sidecar file, in this particular case)! -
If there is a photo with no DOP OR a photo with a PL5 DOP, PL5 takes ‘Rating’ ONLY from the xmp ‘Rating’ meta data, that field will “conceptually” always exist in both JPGs, RAWs etc. There has been some discussion that NEF images may be confusing PL5 because the camera sets ‘Rating’=0 but so does my Lumix and probably other cameras. In truth whether set to 0 or unassigned PL5 will set ‘Rating’=0 in the absence of any other value, arguably the only logical thing to do.
Hence, if the ‘Preference’ ‘Sync’ =‘OFF’ during migration from PL4 (or earlier) to PL5 the database will contain the DOP ‘Rank’ as will the new DOP but if the database is lost then so is the rating data! It “sinks” with the database because PL5 has “rightfully” restored the ‘Rating’ to its natural home (with the demise of the long held immutability constraints) namely, the xmp metadata wherever that resides (embedded or sidecar) but if that data has not been written because ‘Sync’=OFF and no manual export has been made (and there is no global export command because there is the ‘Sync’ option) then …
@Johnny and this applies for your test where the only ‘Rating’ data that PL5 was interested in was in the database or (unwritten) to the xmp ‘Rating’ field,
All of this should have been made clear in the long, long overdue FAQ of which the table reproduced above is part and that information should have been available with the release of the product.
So if you are going to use PL5 ‘Rating’ then please think seriously about whether you ignore the advice given by some about instantly damaging your “precious” (I mean that seriously not sarcastically) with ‘Sync’=ON or play safe with ‘Sync’=OFF and the choice largely depends on whether you are using external software to control the metadata, including the ‘Rating’ or PL5 or both and remembering to manually write back any metadata changes from PL5 etc. etc.
But using the ‘Metadata’ ‘Read’ and ‘Write’ features can never emulate the ‘Sync’ feature. Some products also provide a merge feature but on a directory or photo by photo basis. PL5 provides it as global feature, albeit one that can be turned on and off at any time and potentially many times during a “session”.
I have been asking for a manual sync feature since mid 2021, the current read and write will potentially overwrite the database or the photo metadata but not offer to combine (merge) or (even better but more complicated) merge and add from, i.e. add from photo and add from db.
Potential Issues:-
I believe I have found and documented a bug with respect to Tags which are PL5 only metadata and are being written to what appears to be a WOM field in the DOP, i.e. it is written but not read back!
The issue of migration from PL4 to PL5 using PL4 DOPs, i.e. where the database was “lost” during the migration for some users. If PL5 then treats PL4 (or earlier DOPs) as if they are PL5 DOPs (doesn’t appear to be the case in my Win10 testing) then NO ‘Rank’ data will be taken from the DOP.
Instead PL5 will look for an xmp ‘Rating’ and find either a value (1 - 5) or 0 or unassigned in a sidecar or the original photo (JPG or RAW with embedded metadata). In the absence of a real value already in that xmp data then ‘Rating’=0 will be assigned to the PL5 DB and the (now) WOM ‘Rating’ field in the DOP is inevitable and synchronised back to the xmp data if Sync=ON (arguably not a problem because if there had been a value it would have been used)!
The problem is that if PL5 goes looking for the xmp ‘Rating’ field and it will “always find one” and (in the absence of a ‘Rating’ = 1-5) it will assign ‘Rating’=0 and for those doing ‘Rating’ exclusively in DxPL they will not have been using the xmp ‘Ratings’ field at all, i.e. the DOP is their only source of ‘Rating’ data!
The use of PL4 DOPs works for Win10 but I am not sure what @joanna’s and @platypus’s conclusions were, it looked from some of the reports as if on the Mac pre-PL5 DOPs are actually being treated as if they are PL5 DOPs. I cannot verify this because I only have Win10 systems.