Hi,
here I encountered the problem, that at least the status of the Tag is not read from .dop files by any PL5 version, when the file was created or modifed by any version of PL5. Earlier version .dop files (PL4) are read correctly as far as I can tell.
Regards, Lars
Can no one reproduce the problem?
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:-
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â.
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)Dear Lars,
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.
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.