@JoJu @Joanna etc. Sorry another big post!!
@saint-112 As has been stated by a number of users in this post the Virtual Copy (VC) is just that it is “Virtual” and exists only in the PhotoLab “space”. It has no physical presence until a export from any given image or image copy, [M]aster or VC, is created!
So let me explain what I believe happens and why I find some of the situations you describe difficult to understand. Please remember that these tests were conducted on a Windows 10 machine using PL6.0.1 and various database copies were “injured”, even “destroyed”, doing these tests, not to mention the impact on my “sanity”!
The final test scenario consists of 1 image in a test directory and the same image in a directory of photos I took yesterday, while visiting Leonardslee Gardens with my wife, hoping to see some late Autumn (Fall) colour.
This one image has 4 VCs “in tow” in both directories and they look like this in the final database snapshots but only the IPTC data was present in earlier tests!
Where ‘Rating’ has been set by VC number (0 for [M]aster), ‘Colour Label’ set by order and the DeepPrime and DeepPrime XD used to identify two basic edits for ease of checking the thumbnails. In addition the IPTC contact field has been used to hold “Master”, "VC(1), "VC(2), “VC(3)” and “VC(4)” for even further identification (the “only” identification in earlier tests)!!
The details are actually held in the database as separate database records (table entries) but all the edits and metadata from each copy ([M]aster and 4 VCs]) are retained in a single DOP sidecar file, i.e. 5 database entries but one DOP containing 5 lots of edit data and metadata.
The database entries of interest are
- ‘Sources’ which holds a reference to the [M]aster only
- ‘Items’ which has an entry for each and every incarnation of an image, [M]aster and any associated VCs and
- ‘IPTC’.
For the “lone wolf” directory we have:-
I apologise for the size of some of these snapshots, the original tests were more orderly but I managed to “corrupt” the database and PL6 reverted to the default location and …
Some columns have been “hidden” to ensure that the critical fields are visible!
‘Sources’:-
With one entry per original image, essentially the [M]aster image.
‘Items’:-
Please note that all these highlighted entries have a single ‘SourceId’ (the pointer to the original ‘Source’ entry) and I believe that the order of entries in the table is significant! The first entry for the same image being the [M]aster, the next VC[1] etc… when a VC is deleted in PL6 then its corresponding ‘Items’ entry will be deleted and the numbering of VCs will change to maintain the order (or they should!)!
IPTC:-
The “highjacked” IPTC field used for additional identification in this case. Where ‘ItemId’ points to the associated entry in ‘Items’!
Why can’t we delete the [M]aster entry in DxPL:-
In truth I cannot answer that @Musashi & @DxO_Support-Team, the first entry in ‘Items’ is little or no different from the other VC entries unless there are SQL rules that maintain a relationship back to ‘Sources’!? This ability has been has been requested on many occasions’ in relation to the “Unwanted Virtual Copy” situation but …
While there is no particular reason that DxO could not change the code (and possibly have to make changes to the database definition) to allow you to delete the [M]aster and preserve the Virtual Copies that capability does not (currently) exist and with my naïve view it is a very simple coding exercise to delete any entry and leave the ‘Sources’ entry until the last ‘Items’ entry is deleted!
The storage of the [M]aster and VC data is as simple and complicated as that! I have gone to some lengths to identify the various copies because there does not appear to be any such identification in the database!
Using the commands on offer to make any copy “identical”:-
I can make the [M]aster look like one of the other VCs using ‘Copy correction settings’ and ‘Paste correction settings’ and ‘Copy metadata’ and ‘Paste metadata’ from e.g. [2] to [M].
Indeed I can use the same capabilities between any and all copies at any time, arguably one way of “parking” edits without creating presets and then I am free to delete [2] if I so wish but I am never free to delete[M] without losing all the copies AND the DOP!!
Effectively the deletion of the [M]aster deletes the entry in ‘Sources’ and would leave all other VC entries in ‘Items’ pointing at a “missing” entry in ‘Sources’!
Although Mac users can use the ‘Advanced History’ to “park” edits that can be retrieved on a subsequent run of DxPL(MAC) that preservation of the history is not available on DxPL(Win) so using VCs is one way of preserving edits at different stages of the development of an image, a horizontal “stack” rather than a vertical “stack”, but lacking the granularity of the ‘Advanced History’!
I have never seen a listing other than [M] [1] [2] [3] etc. or have I
Miss numbering of Virtual Copies:-
Please note that this was before my more “extreme” identification methods!
As part of the testing of this and another issue I created 4 Virtual Copies but my attempt to delete one of them was impossible because the ‘Remove’ command was “greyed out”. The difference with the[M]aster test image was that I had passed it from FastStone Image Viewer and it was a member of an ‘External Selection’ (possibly only a Win10 feature!?) as were the VCs and the ‘Removing’ any item appears to be prohibited!?
So I first executed a ‘Load original image folder’ which restored the ‘Remove’ command. Adding this image (& copies) to a project still left the ‘Remove’ command active when the project was selected (at this point I was working with the original image in the original directory)!
So I deleted VC[1] and got the following!
Creating “huge” numbers of "Unwanted Virtual Copies:-
The circumstances of this issue are purely of my own making but I am unclear as to exactly why is happens; yes I do understand Uuids clashing cause VC creation.
After deleting all VCs, with the directory still “in scope”, i.e. in view in PL6 and with only the [M]aster image remaining, I copied the DOP from a safe location back into the directory and wound up with the following
I have had triple the number of VCs created in previous tests but have never understood why @DxO_Support-Team. Given that I have deleted all the VCs before “recreating” the DOP I am unclear as to where the Uuid clash occurs!
I then progressively deleted VC[1] and wound up with
and a locked PL6!
I have repeated the test a number of times since and cannot repeat the miss numbering but the 12 VCs happens every time!
Snapshots are important:-
What I have tried to explain above is that I can move the edit “persona” between copies but that doesn’t change their order in the scheme of things (or so I believe)!
@saint-112 If you can recreate the problem then please snapshot the screen so that we can all see it for ourselves!