Hello @Lars ,
Could you, please, provide us with this image+dop and tell us what exact tag is not read from .dop. Please, upload them via upload.dxo.com and let us know when ready.
Regards,
Svetlana G.
No issues here. Works fine.
I uploaded 2 Pairs of files. So far it does not seem to matter which type of file I use (MFT .rw2 or jpg) to trigger the problem.
With tag I#m refering to the green/red circle right of the image.
Did you delete the database to force loading of the information from a .dop?
Hello Lars,
I’ve received and analyzed your files. So if you mean “should process” status, it displays directly what is stored in the sidecar:
Regards,
Svetlana G.
Ok, so PL5 writes this information over here only into the database and not into the .dop files. As the files should indicate “green”. The .dop files gets updated but the information in question seems to allways been ignored when the file ist touched.
Lars (@Lars)
I don’t think that the following substantiates your statement!?
I ran a test yesterday setting the “tag” in PL4 and then reviewing immediately in PL5 and it worked perfectly (admittedly I had also changed the rating at the same time) with both versions running at the same time (I think??!!). Tried to repeat the test today on a newly created test group (that I thought was “unknown” to PL5 and PL4 and ran into the ‘Virtual Copy’ situation, however, the tag was present in copy [1].
Copying the metadata from copy [1] to copy [M] also transfers the ‘Tag’.
I then repeated the test on another test group that I had created at the same time (by accident) so I had a ‘-6’ directory preceded by an ‘_6’. The first test that created the virtual copies was on the -6 group.
So, with PL5 closed down I repeated the setting on both the rating (sorry) and the tag on PL4. Shut down PL4 and started PL5 and navigated to the directory and PL5 found the file and DOP for the first time and updated the master (no VC created). With both PL4 and PL5 open I repeated the test setting only the tag in PL4, there was a delay before PL5 finally reacted and created a virtual copy and marked copy[1] with the Tag just assigned in PL4, the [M] remained ‘untagged’.
At this point both DOP s are (still) 4.3.3.
I switched to the third photo in the sequence and set the Tag to ‘Reject’ (Red) in PL5 and a 5.0.1 DOP was created for that Photo with no change to the other two 4.3.3 DOPs.
Returning to Photo 2 I set copy [M] to ‘Rejected’ (Red) which caused the DOP to be changed to a 5.0.1 DOP that contained data for both [M] and [1].
In all cases the DOP file is created whenever the Tag is set or unset. When mixing PL4 and PL5 issues of database versus Uuid come into play and Virtual Copies can ensue.
After shutting down PL5, the first photo still had a 4.3.3 DOP file!
I decided to run one more test on a new test group of 20 photos and set the tags alternately Red, Green and then untagged (i.e. to Red then Red again to untag) and got one DOP for every photo before shutting down PL4 and starting PL5!
PL5 found all the DOPs and set the Tag colour appropriately on the display, no Virtual Copies created because this was the first encounter with the directory for PL5.
I then changed the order of the Tags to Untagged, Green and Red in PL5. The changes to the DOPs “rippled” through the files until they had all become 5.0.1 DOPs.
The ‘Rating’ (the * or ***** etc option) is stored at the front of the DOP and the ‘Edit Tag’ (‘Untagged’, ‘Reject’ and ‘Pick’) is stored as the ‘ShouldProcess’ option close to the end of the DOP and slightly more complicated when there are 'Virtual’Copies!!
The values of ‘ShouldProcess’ are 0=‘Picked’ (Green), 1=‘Rejected)’ (Red) and 2='Untagged" (grey or gray) (I believe!?)
PL5 loading PL4 DOPS:-
PL5 changing order:-
1 Like
Lars (@Lars)
I apologise that my post yesterday appears to dispute your report of problems will DOPs on your machine. I was simply stating that I was unable to reproduce your problem on my machine. The main feature of my investigation was that I was using the latest versions of PL4 and PL5 and creating DOP files purely for this investigation!
So I went back to photos I took last December when PL4 was reasonably new and modified a DOP from “grey” to “green” on my test machine, i.e. which contains copies of photos from my main machine. I launched PL5 with the amended photo and the Tag element still worked for me BUT in a Virtual Copy. The main difference there was that I was using MFT photos from my EM1 MkII instead of my RW2 files from my G9, sorry about my lack of loyalty (plus I was still using burst mode at that time so lots of duplicates in screen grab)!!
So to try to avoid Virtual Copies I removed the PL5 database and ran the test again and got a Virtual Copy for the second time. I then opened the whole folder and every photo had [M] and [1] Virtual Copies, with [M] showing the PL4 edits and [1] being an unedited copy!!! The “modified” DOP showed the “Green” status on Copy 1.
Why is PL5 creating Virtual Copies for PL4.0.2 DOP files?:-
@sgospodarenko I would like to request an explanation for why PL5 created Virtual copies for every file in a directory when it is the first thing to be processed after a database clear? Surely PL5 should simply take the DOP files and create new entries in the new database, unless it has a “memory” of the directory stored elsewhere!
I feel that I have had more encounters with Virtual Copies with PL5 than ever before but that could simply be that I am testing way more than ever before (I am currently recovering from a bad cold and have nothing better to do than “play” with PL5).
I repeated the test with PL5 on my main machine and exactly the same thing happened, backed up the database changed the database name and repeated the test, new database but same problem!!
PS. I was monitoring the catalog location while PL5 was coming up and saw the new database being created.
Why is PL5 creating Virtual Copies for PL4.0.2 DOP files?:-
EDIT:-
My apologies @sgospodarenko there was an “obvious” reason why only this directory was “afflicted”, it was “afflicted” when it was first processed late last year and wound up with a bunch of DOP files containing Virtual Copies for a reason I do not remember!
I did reduce the files to a single file and then reviewed the remaining DOP very closely when I could not clear the problem and found the obvious “error”. I will process the files again to remove the virtual copies so I do not make that particular error again.
Once again sorry about the “red herring”.
1 Like
Hello,
sorry for taking so long to post. I had been qite busy. And thanks for the time spend to try to reproduce my problems!
To sum thing up again:
-
Reading .dop/PL4 files works fine.
-
Reading .dop/PL5 files does not show the ProcessingStatus, even if “ProcessingStatus = 1” is set in the .dop file. This information is only read from the database if present.
With PL5 running thing get interesting:
-
Copping a picture with .dop/PL5 file within PL to a new folder, ignores the ProcessingStatus field and show it in the same status as in the source folder.
-
Copping a picture with .dop/PL5 file within the Windows Explorer to a new folder while PL5 is running and pointing to the target folder, creates a virtual copy of the picture. The for the original picture ProcessingStatus is ignored. but for the virtual copy ProcessingStatus is shown correctly.
There must be something messed up. And that is with reading the ProcessingStatus filed an that virtual copys are created when copping files.
Regards, Lars
ps: 1. Picture: Copy within PL5; 2. Picture - Copy with windows explorer
2021-07-22 T130343 (moto x4).jpg.dop (8,6 KB)
2021-07-23 T184842 (moto x4).jpg.dop (17,0 KB)
Dear Lars,
- It means that your image was never processed but not the tag status.
And for the tag status I see “ShouldProcess = 2,” which is equal to ‘undefined’ for the first image and Master of the second and ShouldProcess = 0, which means ‘green/pick’.
So this is exactly what we can see in your screenshot.
Regards,
Svetlana G.
Hi Swetlana,
Ok thanks for correcting me. It seeams ShouldProcess is changed by PL5 when opening a file not in the database.
I will upload the above .dop before and after PL5 touched them and not recognicing the files (empty database and cache).
2021-07-22 T130343 (moto x4).jpg.dop (8,6 KB)
2021-07-23 T184842 (moto x4).jpg.dop (8,6 KB)
“ShouldProcess" is changed from “0” to “2” when the file is touched and not present in the database (or cache).
2021-07-22 T130343 (moto x4).jpg.dop (8,6 KB)
2021-07-23 T184842 (moto x4).jpg.dop (8,6 KB)
Is there any additional information I can provide?
Thank you. Nothing for now. We’ll do the first investigation.
Regards,
Svetlana G.
With PL 4 and 5 on Mac, I find the following behaviour:
When I set PL 4 and 5 to NOT import and export settings automatically, the Pick/Reject lamps turn on and off as expected when I tell PL4 to export and PL5 to import settings (using the file menu).
When I set either PL to import and export settings automatically, the Pick/Reject lamps DO NOT change as expected, even if I tell PL5 to import settings (using the file menu).
This looks like PL4 is NOT updating the Pick/Reject entry in the sidecar, even if set to do so automatically.
1 Like
Hi all,
It seems that recently, when editing the number of stars of an image on a second computer, on an external drive, this rating is ignored on a second computer when reading the dop file. The other settings related to the image itself are properlly imported.
I believe this was not the case in PL4, but I cannot try that anymore. Is this a known limitation or a new issue ?
Chris
Can you check for behaviour similar to this:
Ok, there is definitly something strange.
I made a new folder with copy of two pictures: one with a PL4 dop file, one with a PL5 dop file. The number of star is directly seen for the PL4 dop file, but not from the PL5 dop file.
PL4 dop file initially contains:
Sidecar = { [...]
Software = "DxO PhotoLab 4.3.1", [...]
Rank = 3,
PL5 dop file initially contains:
Sidecar = { [...]
Software = "DxO PhotoLab 5.0.2", [...]
Rating = 1,
Once the folder is loaded within PL5, the content of the files are modified as:
PL4 dop file is transformed to:
Sidecar = { [...]
Software = "DxO PhotoLab 5.1", [...]
Rating = 3,
PL5 dop file is transformed to:
Sidecar = { [...]
Software = "DxO PhotoLab 5.1", [...]
Rating = 0,
Of course I tried to modify the PL5 dop changing “Rating = 1” to “Rank = 1”, but with no result.
dop file sync is activated in both direction.
XMP sync or not do not change the behavior.
With default settings, PhotoLab automatically exports .dop sidecar files, which means that PL5 will write a) its version number and b) Rating instead of Rank. Sidecars not being backwards compatible between major versions makes PL4 ignorant of anything PL5 did. Nevertheless, PL4 should rewrite the sidecar with the rank value it has in its database.
If you work with PL4 and PL5 in parallel, it might be an idea to disable automatic settings export in order to return control of when a sidecar is written to you.
Chris (@Crispy) I tried to replicate your scenario on a Win 10 system with PL5.1.0.4690 using RW2(Lumix G9 RAW) one photo with a PL4.3.1 DOP, one with a PL5.0.1 DOP and a further photo with a PL5.0 DOP. All DOPs were original from my files but had to be modified in an editor to set the ‘Rank’/‘Rating’ fields. i.e. as ‘Rank’=3, ‘Rating’=1 and ‘Rating’=5 respectively. I then navigated to the directory in PL5.1.0.4690 and the snapshot is shown below.
This shows the correct star rating for the 4.3.1 DOP but the thumbnails for the two PL5.?.?.? are showing no rating at all!?
This was not what I was expecting. Remaining in the PhotoLibrary and quitting PL5 did not adjust the DOPs in any way, they remained as they were.
Entering the ‘Customize’ screen, “touching” each photo and exiting PL5 also left the DOPs intact.
I am not a novice at “hacking” DOPs but I am tired at the moment (the “excitement” of Christmas obviously or late nights writing posts to this forum (+age)!!) so I might have made an error at some point.
In previous tests where people have lost the ‘Tag’ (‘Red’, ‘Green’ or ‘Grey’) between PL4 and PL5 I used the same type of DOP “adjustments” and included the ‘Rank’/‘Rating’ for good measure and my tests exposed none of the issues others had encountered.
In this case I have not replicated (yet) your scenario but the ‘Rating’ set in the PL5.0 & PL5.0.1 DOPs should have shown up in PL5.1.0 I believe @sgospodarenko.
Edit:
I stated that I had not recreated your scenario but effectively I have in that 5.1.0 is not showing any rating, any change that makes a DOP update for one of the PL5.? photos will set the ‘Rating’=0. So I forced an ‘Export’ on the first of the PL5.? DOPs and the results are shown in the snapshots below .
I believe we have a bug @sgospodarenko!
