Make "master" deletable again / treat all copies the same

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.

Fully agree it was stupid change and would be better to admit it and change back.

2 Likes

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.

Mark

2 Likes

Regardless of what might (have) be(en) intended, the current approach simply does not make any sense.

Even if we later might be able to name the virtual copies, it must still be our own choice which of them to keep - and which to delete.

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.

Mark .

1 Like

Would you mind to explain the usefulness of such a relation in a new thread? I’m interested in the benefit I might have overlooked.

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.

Mark

Hi Tilmann,

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”.

Hope that helps …

John M

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.

George

1 Like

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.

And why is it not now ? … One can always delete any VC one chooses to - - No ?

John M

Only partially.

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…

No. VC 0 aka Master can’t be deleted. That’s the topic of this thread.

Strictly speaking, that’s true … but, there’s an extremely quick&simple workaround …
See the 2nd point above.

John

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.

a workaround is not a reason not to fix the problem itself.

Are you in favor of “Master” copies being able to be deleted, against it or neutral?

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.

Mark

1 Like

Coming from Lightroom, I first found that DxO’s masterless vc solution was odd and welcomed the change to the current way of working.

Instead of making the master deletable, I’d prefer to be able to affix the ‘master’ tag to any vc.

After all, vcs are just different recipes applied to the one and only original file. A master displayed on screen is a virtual copy too…

3 Likes

I like the idea of being able to assign a vc to be the master. If you have a number of vcs you may forget which one was the one you wanted to keep!