Hi,
anyone also do not want to use the database and has heavy problems with using star ratings?
All star ratings (saved to dop files) I made with PL 5.x are not displayed anymore. Star ratings from older versions do work. The star ratings are still there in the dop files, but PL does not interpret them while other modifications like activating deep prime are still available.
I made lots of trial runs and found that there are some big issues, can you reproduce the following?
Prerequisite:
Version: PL 5.1
Preferences: “Always synchronize” unchecked; “Save/Load settings in sidecar file” both checked
delete PL Database file
Steps todo:
open PL
browse a RAW image
give it a rating
close PL (a dop file will be written)
delete the PL Database file
open PL
the rating will not be displayed anymore (information is still there in dop file and option “always read from dop” checked in prefs)
select the RAW image
go to File → Sidecars → Import
A message says the import was successful, !!! BUT what actually happened is that the star rating in the dop file is now overwritten with 0
Yes I tried. Result is, when I import the dop file manually, PL5 creates a virtual copy with the star rating displayed correctly. But thats obviously not a solution.
The rating is regarded as metadata and, normally, for a RAW file, will only be read/written from/to an XMP file accompanying the RAW file, not the DOP file, even though it is indeed stored there. The only part of your test scenario I don’t get is the last bit where you import the DOP - I don’t get the writing of 0, the rating stays as set (5) but still doesn’t show in PL.
I believe the problem stems from the number of possible places the rating can be stored…
some cameras (e.g. Nikon) can set the rating in-camera. This is written into the NEF file.
most RAW workflows write the rating to an XMP file, even if the rating exists in the RAW file
PL writes the rating to a DOP files as well as anything else it might find in the previous two places
PL also writes the rating to the database, as well as all the previous three places
So now we have up to four “truths”, but which one should PL read and modify?
My personal feeling is that, when reading for the first time, the rating should be read “conditionally” starting with the RAW file, then the XMP file.
I have some NEF files that contain a rating that was set in the camera and, no matter what I do in PL, that rating in the NEF never changes.
So my conclusion is that the DOP file is never read for the rating, even though it is read for image edits.
Further proof:
NEF contains rating of 5
XMP file contains rating of 3 after editing in PL
close PL
delete database
delete DOP file
open PL
rating for image shows 3
Once again, the DOP file is ignored, so I end up asking why is it used at all for the rating?
But the question remains - if a RAW file already contains a rating, why isn’t that updated at the same time as the XMP file is exported? My guess is it is to do with the “sanctity” of a RAW file, extended to cover, not only image data but, metadata as well.
There are some DAM solutions out there that do allow writing of metadata to RAW files - should PL not honour that in its manipulation of metadata?
Thank you very much for your inputs and sorry for my late response!
It seems like PL5 does not care about rating settings in dop files. If there is no database or XMP File available PL5 does not care about rating settings in dop file.
BUT this problem only exists with PL5 generated dop files. It works fine with PL4 dop files.
Since last Saturday I’m also facing this kind of problems.
I had to replace the database with a backup of it because of a massive crash of PL.
Now the dop files contain the rating but become overwritten wir rating = 0. This whole concept of dop files never convinced me and now to turns out it’s a deterioration.
Of course I can copy all 6500 dop files to another place, just in case that app keeps on overwriting existing ratings. But this whole “unpredictable video game outcome” really takes the fun away and turns it into insecurity. Not to mention how to bring back the old ratings.
@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?).
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.
