@RKyburz and @Joanna I made comments in a similar but not identical Topic PL5 Tag Field not read from .dop file - #23 by Crispy and @sgospodarenko made a comment about a forthcoming FAQ to better understand the processes
and
- Well the algorithm of the prioritization of the files containing this data has been changed with the introduction on xmp support (it also depends if it’s a master image or VC). Everything will be explained in details in FAQ very soon.
Regards,
Svetlana G.
[/quote]
I had originally intended to stop testing for a bit and concentrate on other things but decided to have one last try at this (more fool me!!). I cannot yet repeat @Joanna’s findings but believe I have seen something similar (I have done so many tests I believe I have seen a photo of a UFO somewhere amongst the tests!!??) .
I have run some tests which are a little worrying (to be posted) but decided to use some test photos in a new directory structure and use PL4 to set up certain scenarios and then import that database into PL5 and continue testing (all tests up till now have been made using PL4 and then accessing the DOPs and photos using by PL5; they have not included an imported/upgraded database).
However @sgospodarenko this testing “fell at the first hurdle” when I opened the photos in PL4.3.6.32 and as the snapshot shows the photos have Ratings (Ranking) externally assigned. I have seen this before during testing but this is an entirely new directory and FRV, PM, ExifPro and Exif Pilot all show no ‘Rating’ present in the photos!?
While it is possible that I am looking at the wrong directory in PL4 could it also be that the photo entries have “bled” from elsewhere in the PL4 database (the photos have been used many, many … times?)
From here perhaps
I will abandon testing with this set of photos and pick some that have never been used in any tests before and continue trying to test what I set out to test.
UPDATE 1:-
@sgospodarenko I apologise for suggesting a database “bleed through” I re-initialized the PL4 database and the issue still persists. I also enlisted Imatch and it also shows no ‘Ratings’ set; so where is PL4 getting the data from!? Comparing the different photos (Beyond Compare) the only field that I could see that might relate to the problem was ‘Rating Percentage’ which showed 1, 25 and 50 (for photos that have a Rank of 1, 2 & 3) while the actual ‘Rating’ in all cases showed as 0!!
Opening the directory in PL5 shows no ‘Ratings’ at all (in the absence of any PL4 DOPs), which is in-line with the other programs. My tests have indicated that PL5 will import the DOP values for ‘Rating’ (‘Rank’) in preference to those for ‘Rating’ in any photo, if the DOP exists. This is inline with the fact that JPGs are considered “immutable” in PL4 and so the photo will not be changed, any Tag, Rank and keyword changes will only be stored in PL4db and the DOP.
Hence for a photo with a PL4 DOP the (PL4) DOP appears to be taken as the only source of ‘Rating’ data whereas I would contend it should be taken as the “prime” source and any “competing” photo data must be analysed rather than just dismissed.
By analysed I mean that the algorithm needs to be “clever” enough to determine if there have been changes made by other software e.g. LR, PM Imatch etc. that post dates the PL4 database (hence my planned tests) or post dates the DOP which I have already tested and it seems to be that the DOP will always be preferred BUT I have not experimented with date/timestamps except that all my Photo changes should (but may not) supersede the DOP data!!
The issue of “immutability” was always treated by DxO as almost something “sacred” but it means that interworking with other software was a potential nightmare and further complicates the transition from PL4 to PL5!
UPDATE 2:-
Getting PL5 to ‘Metadata’/‘Write to Image’ made the ‘Rating percentage’ vanish and PL4 picked up the Photos without any ‘Rank’. However, because I had not made any changes to the metadata in PL5 the ‘sync’ option did not make any “routine” writes to the photo and the manual write was required.