Bug in the "Remove" of virtual copies

DxO PhotoLab
41

@saint-112 Nick I am profoundly glad you sent us down a rabbit hole because of what I discovered in the process!

So one last point worth noting I believe, a lot of my time since the release of DxPL 5 has involved the problems with “unwanted” Virtual copies in one form or another. Typically created when a user enters images on one machine, takes them to another to continue processing with a better screen and faster graphics card and then returns them to the first machine.

If done carefully, as I proved recently, then all will be O.K. but many times that has resulted in the creation of a VC where VC[1] holds the latest updates and [M] needs replacing but while it is easy to locate (filter) and delete VCs, trying that with the [M]aster is going to result in the loss of all data!!

Fixing the images one by one using the procedure is time consuming when an entire directory is involved.

The alternative is another procedure I documented which involves changing the name of the original directory to e.g, -OLD and introducing the returning image complete with DOPs as and then deleting -OLD when the user is happy with the swap!

So I devised a little test to confirm my worst “fears”, i.e. that none of the grief that has been caused by the [M]aster was actually necessary!

  1. Four JPGS set up and discovered in DxO 11
  2. Set the ‘Rating’ (‘Rank’ in DxO 11) and close DxO 11.
  3. Open and modify the Uuid of the 4 DOPs (to deliberately create unwanted Virtual Copies)
  4. Re-open DxO 11 and we have

image
image1703×315 170 KB

  1. There is no command to filter on [1] or [2] available in DxO 11 so select all the [1] one at a time to give

image
image1677×482 116 KB

  1. ‘Remove’ and we have

image
image860×289 79.1 KB

So I and others have wasted huge amounts of time handling queries about “unwanted Virtual copies” and proposing solutions all because some “clever” person(s) at DxO “destroyed” a perfectly good design and replaced it with the biggest pile of … on the planet!

Actually that is probably a “slight” exaggeration but the change in design has caused an inordinate amount of grief for no real purpose.

The whole design for the handling of Virtual Copies that centres around the way the [M]aster is handled is a BUG, a wholly unnecessary bug (albeit there might have been a sound reason behind it that I haven’t fathomed because I don’t have access to the code).

The [M]aster has made us all “slaves” to a distinctly wrong design @DxO_Support-Team @Musashi please release us from this as soon as possible (but do discuss it with us before you do and check and share with us any hidden reason why it should stay - an opportunity to establish co-operative communication rather than the rather one-sided … we have today)!

@platypus I would suggest that it is a bug but one that might not be easy to fix and one that I don’t think occurs in Win 10 but I would need to run the tests again just to be sure!

PPS:- In one of the discussions the issue of the complications of real Virtual Copies versus “unwanted” Virtual copies was raised, e.g.

  1. On the first system (a laptop), VCs might be added to the image before transit to the desktop system.

  2. The images and DOPs will be imported into the desktop system for further processing where even more edits may be added, i.e. more Virtual copies or single copies acquire edits before returning to the laptop.

  3. Iff (if and only if) any of the Uuids are not identical to the original system (if they ever existed on that system in the first place) then “unwanted” VCs are going to exist alongside intended VCs and the very best of luck handling that one. The safest approach might be the rename/replace/delete approach but that automatically means that ‘Projects’ on the originating system can have links “broken”!?

This issue only exists when the DOPs are taken into System B and allocated new Uuids. When that happens there is no hope of just carrying them back to the original system without “unwanted” VCs.

1 Like
42

Much easier to just have an option to assign a new Master from one of the VCs.

2 Likes
43

How come this didn’t happen in Optics Pro? If you created VCs you could remove either of them including the “1” without touching the others. There was no master and everything was simple. The “1” copy was my master.

It doesn’t because my issue is that when I want to delete a VC it happens randomly that it’s the file that is sent to the trash. As a rule of thumb, since I started with Optics Pro I kept the “1” image untouched as a reference either to see how the shot looks like out of the box or to create new, virgin VCs. I never needed to remove the Master.

So now that you both explained to me the constraints introduced by this Master/VC configuration could you tell me what its benefits are. Several people complained also about it but nobody said what it’s good for. I looked in the manual and saw the how-to but nothing about the why.
Nick

44

@KeithRJ The answer is yes and no.

Yes it is easier for us and no the coding effort a greater and needs to be accompanied by UI changes and we know how DxO love those, new documentation, new localisations etc., although the coding effort to re-assign is not that great at all, it should be almost trivial to allow for the deletion of the [M], essential a reversion to the old way of working!

EDIT:-
Sorry the statement is not entirely true, if the ‘Remove’ reverted to the old way of working the [M]aster could be removed with no UI change but that would deprecate the current feature!

I go on and on and … at DxO not to change things without preservation of the previous feature so there would be a UI change to leave ‘Remove’ as is and provide a ‘Remove from database’ but that could also accommodate a removal of all copies from the database and a complete re-discovery of the original data which has even more merit but would be a new feature!!

My own preference is to provide a UI to avoid the unwanted VCs at the time they are introduced to the database and to provide free movement of the VCs for those using such a feature creatively while managing and editing their data, but I don’t manage the budget, am not looking for for the next “killer” feature etc!

@saint-112 only because someone at DxO thought it was a good idea, the database does not look much changed but the coding obviously is!

Nick I have explained workarounds which I developed simply because people were experiencing problems and I took the design as being essential, unusual for the sceptic in me!?

I can see no sensible rationale for the design and I eagerly awaiting the DxO explanation @DxO_Support-Team but not holding my breath while waiting.

Regards

Bryan

46

That would certainly be an improvement over the the current need for copy/paste, but it doesn’t address the fact that being able to maintain multiple independent edits of an image (ie. virtual copies) and distinguishing one of them (ie. Master) are completely separate things that don’t need to be intertwined.

If I decide to that I want two versions of an image, one in colour and one in black and white, then there’s no natural Master. You might even say there are two masters in this case, but for PL there can be only one. I don’t think Master is anything more than PL’s representation of the underlying image data, but that’s an implementation detail that doesn’t need to be forced on the user.

If some like the Master as a way to distinguish one version then you can do that and more by being able to name them (reorder would also be nice) as you like. Except that that’s only possible on Mac. Sigh.

This just seems to be more muddled thinking by DxO.

47

If you don’t have a master system there is no master. The original VC just had numbers, if in Windows there could be renamed problem solved.

48

I understand your point about the current behaviour being different to how it was with OpticsPro - but, that was a DxO design decision … and this is a user forum.

No - there’s nothing random about how it currently works;

  • If you delete the 'M’aster version - then all related versions are deleted too (after you confirm that that’s what you want to do).
  • If you select a specific Virtual Copy - then ONLY the selected VC(s) are deleted.

John M

2 Likes
49

… and maybe move it to the ‘front’

1 Like
50

I am sorry to say that you completely missed my point.
• What my issue is not:
I can adapt to changes in settings (provided it improves the soft) so, since I already had implemented the master concept, the new configuration didn’t change my workflow at all.
• What my issue is:
When I remove a VC it randomly results in the trashing of the file especially with photos that were initially edited with DOP.
Maybe I should repeat to make the record straight:

  1. When I remove a VC (not a master)
  2. Randomly
  3. The file is sent to the bin.

You say

I am not a yes-man:

  • The fact that it’s DxO decision doesn’t make it necessarily sound and sensible to me. Given other users’ experiences it’s flawed.
  • It’s obviously useless. The only difference with the prior arrangement is that by removing the master you remove the file. Big deal. When I wanted to get rid of a photo in DOP I used to select all VCs, remove them and voilà. I kept the habit with DPL. I doubt you could measure the extra time it takes to select several images compared to selecting only one.
  • I am still waiting to hear the real advantages of this feature.

Bottom line: it’s not an important issue. I can live VCs I can’t delete. It’s just rather annoying to be unable to manage such a menial task because of a bureaucratic decision that has, to this point, no rationale.
NIck

51

…the change came with DPL3 because it was requested by many users of this forum.

Maybe someone should add a feature request in behalf of the reversal?

52

I don’t understand. With DOP, my first move with a new set of pics was to select them all and create VCs. I kept the “1” unchanged and made editions to the other one(s). I didn’t change this practice to this day. When I want a fresh VC to try new editions I created from the “1”. Very simple and efficient. The new feature is to me useless.
Nick

53

At the moment, I cannot see the problem. Your original copy is now marked as master instead of one and any virtual copies are numbered one, two and so on. If for argument’s sake you like virtual copy number three. You can make a virtual copy of number three and that will add a new copy to the end of the list. Deleting any of the virtual copies will not delete the master but if you delete the master, it will delete all the virtual copies.

As for me. I prefer the new way of doing it. It is much simpler and logical. This way. For me the master is an untouched copy.

2 Likes
54

@saint-112 I am writing a longer response to some of the issues but what I would say is whether it is possible to use [1] & [2] together with the [M]aster (@Prem effectively beat me to it), simply because getting any sort of change out of DxO is likely to be … (but that won’t stop me trying and defending the reasons for trying)!

That doesn’t change the original issues of DxPL(MAC) taking old DOPs and playing games with the data on discovering the DOPs.

The overheads of using the [M]aster & at least 2 VCs are slightly bigger DOPs (3 x 1 instead of 2 x 1 entry size) and additional database entries until all the editing is done and the culling begins!

So your workflow would become:

  1. Navigate to a new directory
  2. Select all images and create a VC, i.e. VC[1] so nothing really changed there then!
  3. Sort by Virtual Copy number, [M] is classed as [0] by DxPL in that process, it seems!?
  4. Allocate a ‘5 - No correction’ preset to all M to provide a true original or change your starting preset in preferences or …
  5. Apply an appropriate starting point to all [1]'s (if required) (step 3 & 4 could be reversed)
  6. Remove the sort criteria
  7. Use your original strategy with VCs [1] and [2] with no danger of losing the image until you explicitly delete [M], i.e. when an [M] stands alone then it is a candidate for deleting!

Please note that my “title” should be @BHAYT not some truncated version of that!?

55

Could you post an image and its DOP file that you know exhibits this problem?

I would suggest you copy the contents of a folder into a test folder and proceed as you would delete VCs on the test folder.

Then send the originals of one that fails.

56

Apart from the problems that look like they exist the current VC system is a night mare if you use it on a large number if images having to copy and paste each one back to the master (after remembering to close down soft proofing)then deleting the non masters. So very much easier before just deleting the unwanted imiges leaving just the one/master. Yes we were told this was requested but no one appeared top know by who and there are requests long ignored with large numbers requesting them.

57

Cast your vote here:

1 Like
58

So, Keith’s suggestion might be worthwhile to be raised as a feature request …

(Rather than unlikely expectation that DxO might reverse the current behaviour)

John M

Edit: Just noticed that Wolfgang raised this before I did - in which case I endorse it.

59

If you consider spending some time writing a post it would be useful to read carefully what the issue actually is to make sure your response will be relevant.
Nick

60

I did a couple of tests and it didn’t happen. I’ll send you what you ask when it happens again.
Nick

61

@Prem I take some exception to what you write, but only because it is less than completely accurate!

The [M]aster is only untouched if the user so chooses, whatever the [M]aster was intended to represent it is still capable of being edited . Being the [M]aster doe not endow the copy with any different “powers” other than controlling the complete deletion of the image, all edits, its own and those for any associated VCs, AND the image on disk.

Personally I didn’t use VCs at all, I was effectively using the only “copy”, i.e. the [M]aster but not so designated when there are no Virtual Copies.

It is certainly possible to always create a VC and only edit that copy and to treat the [M]aster as “inviolate”, i.e. don’t touch it and it effectively holds no data of “importance” except the “key” to preserving the image data on disk or not!

But that is “simply” a matter of choice and I outlined that in my post that I “published” just after your post!

The reason for this topic is because @saint-112 “tangled” with the revised DxPL handling of Virtual Copies and, potentially a bug in DxPL6 when handling DOPs from the DxO OpticsPro era.

I admit that I originally thought it was a “hoax” and tried to reply as politely as I could while doubting @saint-112’2 “sanity” and/or my own. @Platypus helped to set the record straight by describing that DxO changed the product, after consulting with the users, and while you may prefer the [M]aster and VC processing rules they are “arbitrary” and have, at times, caused more trouble than they are worth.

  1. The “only” positive that I can see was mentioned in a post above, namely the ease with which the image and all the edits can be eradicated with a single ‘Remove’ of the [M]aster!

But that was always possible by selecting all the Virtual Copies and deleting them in a single operation. The last one of which would then control and perpetuate the deletion of the image itself.

So nothing gained there then, but what was “lost” in the change. I went back to OpticsPro 9 and tested and installed DxPL 2 and tested and these are my “findings”!

  1. The “old” way was in use at least from DxO 9 through DxPL 2 i.e. 5 releases (DxO 9, 10, 11, DxPL 1, 2) and the change has been in use for releases DxPL 3 to DxPL 6, i.e. 4 releases.

  2. The freedom offered by the original code allowed any VC to be deleted, including the first, and effectively allowed what was to become the [M]aster to be deleted and replaced, albeit only by the next VC in line!

  3. One of the main issues that arose during DxPL 4 and DxPL 5 forum posts was the “Unwanted Virtual Copy” issue, not an inevitable issue as my recent tests and posts have indicated’ but experienced by many and a nightmare to correct. But it is “simply” a consequence of the coding surrounding the [M]aster architecture!

With DxO 9 onwards (possibly earlier) it was possible to delete any VC, as I described above, so in the event of 'Unwanted VCs" there would be two VCs whenever a Uuid mismatch occurred between the database and a DOP.

But a simple sort on ‘Virtual Copy number’ would allow all [1] VCs to be identified. This is an example from DxO 9 of two images containing 1 VC and one image consisting of only the original master

image
image1108×201 77.2 KB

Sorting on ‘Virtual Copy number’ yields the following

image
image993×195 73.6 KB

Lone masters are sorted to the front, followed by VC[1], followed by VC[2] if there were no VCs before a directory was rediscovered then removing the VC[1] entries would leave the potentially newer edits as the only edit.

This is certainly not a fool proof process but with some care it is a lot better than the newer [M]aster architecture.

As for the workflow you propose @Prem then @saint-112 had worked out his version with the previous scheme without the rigid [M]aster architecture.

In truth, I can just about live with either but what I really detest is the confusion and “danger” created by mixing image file management with edit management!

This “danger” exists with both version when either the deletion of the last VC or the [M]aster results in the deletion of the original image, the two functions should never have been joined in the first place, there should always have been two separate operations

  1. One operation to remove the edits, all edits if desired and

  2. Another separate operation to delete the Image, which would have also have removed all edits, the ‘Remove’ operation as it currently is in the product and has been through both models of VC operation, using a ‘Del’ command pre DxPL 3 and a ‘Shift Del’ command thereafter!

Splitting it this way should prevent any unexpected deletion of the image “all” you would lose is the edit that took hours to perfect and neglected to turn into a preset or assign to another image or …

1 Like