Since a while, the first virtual copy is called “master” and can’t be deleted anymore for unknown reasons.
In earlier versions of Photolab, each version was of the same value. There was no “master”. And of course, any virtual copy, including the first one, could be deleted.
The current behavior is a setback, an unnecessary limitation.
I use virtual copies to investigate different approaches, compare them and select the best. The other variants are then useless (“bad”) and shall be deleted.
Why should the first incarnation be treated differently from the other “copies”?
Therefore I ask DxO to restore the ability to delete any copy, including the first one (now called “master”). This could be achieved also by being able to switch the “master” property among the virtual copies anytime.
To be honest, I would prefer to handle this as a bug but maybe this issue gets more attention as a feature request.
Oliver
P.S.: This has been already mentioned 2020-02 in Set virtual copy as master - #2 by mwsilvers but not as a feature request. Other posters considered the current behavior as a regression.
I think this may have been intended as part of a larger redesign effort of virtual copies. Unfortunately, nothing has happened since then. We’re still waiting for the ability to uniquely rename each virtual copy and to identify the hierarchy of virtual copies. Until that time comes I would prefer to go back to where we were before before the current scheme.
My point was that if at some point they may develop a useful parent/child hierarchy for virtual copies based on the original image. In that case deleting the original parent (master) may not not be reasonable to do. Remember in a true hierarchy we should be able to see the path for copies of the original but also copies of the copies, and further copies of those copies.
You can make multiple virtual copies of an edited or non edited original image. You can also make multiple virtual edited or non edited copies of a copy of an original image, as well as a copies of those copies. Some people, myself included, do this to develop multiple “what if” scenarios when editing an image. It is useful to know which parent copies spawned which child copies. Just numbering them sequentially as they are created does not give you that information.
I recall the discussions when this change was first made (back in an early version of PL) - and there were pros & cons, of course.
On the positive side, the new “M(aster)” identification was helpful in the case where an image had been exported and then, subsequently, new VCs were made and also exported. In this case;
– the first export was named: “ImageName.jpg” … with no VCs.
– the subsequent exports were named: “ImageName_1.jpg”, “ImageName_2.jpg”, etc … with considerable confusion due to (original “ImageName.jpg” and subsequent “ImageName_1.jpg”) being the same image.
– The change eradicated this problem - now with the (explicit and implied) “M” version consistently having no suffix.
The only real negative, as you’ve found, is that the “M(aster)” version cannot be deleted (without deleting all related VCs) … … There’s an easy work-around, tho;
– simply copy all corrections (Ctrl+Shift+C) from the VC that you wish to make your new “M(aster)” and paste them (Ctrl+Shift+V) over the “M(aster)” version … then delete the now obsolete VC(s).
– Yes, it’s a mild annoyance - but it’s not a “show-stopper”.
What makes a master the master?
As far as I figured out a vc is only a copy of the edit list of the image I want to create a vc from. There’s no relation between them. When I reset a vc I get the unedited original image.
Even then, it must be the users choice to decide which VCs to keep and which to delete. Even if, in case of an eventually hierarchical “structure” (in future), that means that some childs may be left orphaned. The naming conventions as they are now are OK - and absolutely no argument against this demand.
I agree to Oliver that the main purpose of VCs is to find out which corrections provide the best result. And after that decision is made, the other VCs can/should be deleted to not cause any confusion afterwards.
As long as the copies are named automatically, name shifts also happen now if I delete any virtual copy not being the last one (e.g. the second copy of three). Then, the names of the exported images don’t match the copy numbers since the exported images are not renamed.
And no, I don’t propose that VC renaming should rename existing exported images automatically. That would have to be thoroughly thought through first. No quick fixes, please!
To be clear: I can accept that the virtual copy 0 is now called “Master” and it’s export doesn’t get a suffix. But I still see no reason to combine this change with “master can’t be deleted”.
To be consistent, DxO would have to forbid the deletion of any “not last” copy. Should I rather not have said that? I hope the irony detectors of all readers are adjusted properly…
Thank you @obetz! This morning I thought the same and you said it. I agree absolutely with you. A friend always makes virtual copies because she thinks the “master” files are the originals and they shouldn’t be touched. I found the old version better and would like to have it back.
I do it both ways. Sometimes I make a virtual copy of an unedited original. And sometimes I make virtual copies of an edited original. The edited original becomes the baseline for experimentation with different additional changes In one or more virtual copies of it.
Like many here I was not happy with the introduction of a master file that could not be deleted without deleting all its related VCs. At the time, If I recall correctly, it was claimed it was done as a result of multiple user requests.
In my opinion, the only good reason to have an undeletable master copy is if it’s a requirement of some general planned overhaul of virtual copy functionality.
However, since they implemented this change (in PL 2 or PL 3?), we haven’t seen any additional updates to virtual copy functionality that would seem to have made this necessary.