Kludge: How to Make a Master of a VC (on Mac)

CAUTION: This is the result of an early test. Do your own testing and backups before using this method to remove a master without moving it to the trash.

Occasionally, we want to make a Master from a VC image, but DPL can’t currently do this, unless you throw the image file to the trash and “resurrect” it with proper settings.

Intro: DPL on Mac writes ONE sidecar (per image file) that contains all the info necessary for the master and all VC images belonging to said image file.

Caveat: The order of items relating to master and VC images is not consistent! To circumvent that issue, I chose to give masters and VCs distinct colour labels, e.g. red for the master and other colours to the VCs.

Method: In order to remove a master without actually trashing the respective image file, I deleted the items relating to the master image (carrying the RED label).

Notes:

  1. I exported and imported sidecars manually for better control, but automatic I/E should work too - I have not tested it though
  2. I deleted the database before importing the edited sidecars. This is necessary for the method to work.
  3. Carefully check, which items must be deleted. In my case, it was the one labeled “red”
  4. Yellow arrows: points out the colour labels, red frame contains the items of the master that will be deleted. The new master was the image with the “green” label/colour tag.

Why not just reset the ‘main’ and copy to it all settings from VC?
Prior to that, you can create new VC, if you want to retain the ‘main’ as a VC.

1 Like

…indeed, why not…and you’ll have to repeat for metadata too…and maybe check what comes along, really…

I have just tested and the way of @Wlodek works.

That’s the process I use too …

  • Copy all settings from the VC (Ctrl+Shift+C on Win)
  • Paste all settings to the Master (Ctrl+Shift+V on Win)
  • Delete the VC

What’s the catch you’re referring to, Mr P … Is not “metadata” copied too ?

Have not tested this case. Feel free to report your findings here.

Essentially, I’d like DxO to re-introduce the old pattern: Delete whatever and reassign the master. Current practice, be it the copy-paste or sidecar editing, is more complicated than necessary.

Before I could store all the information in the Presets, I had created a keyboard shortcut to recover model file information:
F7 (Ctrl/Shift/C + Alt/Shift/C) - Copy the setings and metadata of an image
F8 (Ctrl/Shift/V + Alt/Shift/V) - Paste setings and metadata to another image
And suddenly it works to copy them from a VC to a master

After intensive editing, it often happens that the next day you see things differently. You start with a new VC, just to be safe. This may continue, and at the end one would like simply to delete unused edits (which most often would include the master) and keep only the copy actually used. PL should let me do that and reassign the master automatically. It would make life slightly easier. But maybe the change would introduce new bugs, so better not risk :wink:

Was it like that in previous versions? Did someone want a change?

The first implementations did not delete the image file when a master was deleted. This was difficult to understand and the feature was changed due to corresponding votes/ requests.

While the distinction of master and copies is easier to grasp, it’s unnecessary from a technical point of view. Both master and copy are just different ways to prepare an output. Mixing the delete file with remove recipe was an awkward decision imo…

Thanks for historical background.
It would be better, if users voted on a precise pseudo-code, add scenarios important for them but pehaps not needed by others, etc. However, that will never happen, so DxO will proceed pragmatically, i.e. implement the minimum of what users asked for and do not try to invent anything else, which maybe made more sense.