Unwanted virtual copies

DxO PhotoLab
, , ,
86

Divide & Conquer Versus Divide & Complicate:-

The following resulted from a desire to reduce the render (export) time for photos which with my current processor (i7 4790K) and graphics card (GTX 1050) falls into the 132+ seconds to process the D850 images column in the Google spreadsheet.

With graphics card prices currently over-inflated an alternative, in my case, would be to use both my machines (both 4790K, one with a 1050Ti 4GB and the other a 1050 2GB) and split the load between them!!!

However, I already have some directories stuck with errors (another forum post needed) caused by mixing PL4 and PL5 processing and the worse that could happen would be unwanted virtual copies which have been written about at some length in Unwanted virtual copies (i.e. this post).

EDIT:- I need to retest this in the light of what I have discovered since I did the original test!?

20 RAW files were copied to a directory the first 10 of which were accessed by PL5.0.1 on one machine and the other 10 by PL5.0.0 on the other, across the LAN. To be honest that test appeared to work well and I did not have any issues with virtual copies etc…

But it all went very wrong when I tried to use the ‘Tag’ to differentiate one group from the other and Virtual Copies started popping up!

End EDIT

The problems that I have experienced working between PL4 and PL5 have alerted me to some of the dangers and I wrote the following in a response to @uncoy in Database hell between PL4 and PL5 - #30 by uncoy.

I was also under the wrong impression that the database did not hold an up-to-date copy of the editing data and that the DOP was the sole custodian but that was a very wrong assumption. Effectively the database is the prime custodian and PL goes to some lengths to protect the database entry, creating a ‘Virtual Copy’ whenever it is in doubt!

So what have I “discovered” so far

  1. Changing the Uuid at the end of the DOP does not cause an instant VC.

  2. Changing the Uuid located just after the ‘ShouldProcess…’ field causes an immediate VC. It is also probable that the file date timestamps are changed by the software I used to change the DOP and that alerted PL to the occurrence of a potential change.

  3. Changing the keywords in the DOP has no effect, PL5 currently appears to ignore the change and quickly changes the DOP back to the original value.

  4. Adding a keyword to the DOP and changing the Uuid (from 2 above) will result in a virtual copy with the new keyword.

  5. The ‘Name’ line in the DOP is not used as a checking mechanism, changing it will not have any impact and PL5 will change it back quickly (as part of a DOP update).

  6. I did cut and paste the editing from one photo DOP and pasted it into another DOP leaving the top and tail of the “old” DOP intact and managed to get PL5 to accept the new editing (with no VC) but using a preset is a lot easier!!

I would conjecture that a DOP will only be imported into the database if there is no entry in the database already otherwise it will come in as a ‘Virtual Copy’. What plans DxO have for the keywords in the DOP I am not sure but a command that allows for its import would be useful in the event that it is the only data available to a user.

I personally would like more controls to allow virtual copies to be “promoted” to the [M]aster status and the old master either to become a virtual Copy or be replaced entirely. However, such a facility is potentially complicated by keywords. It is possible to copy the metadata from one VC to another and similarly with all or some of the edits, e.g. from [1] to [M] then delete [1] when [M] is now effectively what [1] was! Deleting [M] currently deletes [1], [2] …

Others have complained in the past that PL effectively imports (ingests etc.) a directory as soon as it is selected by the user and that it would be useful to prevent/control that import process, i.e. have a preference that prohibits automatic import and provide a ‘directory read’ command . In fact once one PL database has imported a folder any DOP that is encountered that does not tally with the Uuid identified in 2 above will cause PL to “protect” the database entry and create a VC.

As I mentioned above I encountered this a number of times and in one (now abandoned) database I have a whole directory that has effectively been “red” flagged and which cannot be exported. Unfortunately the exact path to that particular disaster has gone from my memory. My solution was to save the database and start afresh but that will not be possible if I start using keywords etc. unless I make sure that all keyword data is updated to the ‘xmp’ sidecar files or the JPG etc. and/or make sure that I do not use PL5 to assign any keywords!

Currently only a few of my photos are keyworded but that is with ExifPro and though I can now force PL5 to accept such keywords PL5 won’t export any keywords back to the JPG (and until 2018 all my photos were JPGs!) that have been touched by ExifPro!! I would need to push the photos through some intermediary program since I have failed to get DxO to fix what is probably a one off issue!

I have not yet run a test to see if PL5 compares keywords in the DOP with those in a sidecar file or embedded in a JPG etc. but since it doesn’t compare them with the database I suspect not (at least currently) (but I will test that assumption soon).

The resolution to my “damaged” directory would require a PL feature that allowed a directory (including subdirectories) to be expunged from the database or a ‘directory (re)read’ command that would be executed even if there are database entries for the directory contents already!!