I agree that permanently this doesn’t make sense, it is only a temporary solution as I want to see how PL4 works before uninstalling PL3. But I have understood that on the same PC I can use different settings in PL3 and PL4 to avoid problems, which is good enough.
Has this been improved in PL4? When I had only PL3 on both computers I had unwanted virtual copies all the time. I would be surprised if this was better now with PL4 on both PCs. Looking at other posts in this topic I am not the only one who experienced this.
My experiences of this with PL3 were explained by DxO as normal and due to the need to preserve incompatible data. Fortunately, I’ve been revisiting a lot of older photos (some previously edited with PL2 and PL3) and have yet to see unwanted virtual copies appear. One reason might be that I renamed these folders or copied their contents into new folders before loading them into PL4. (Takes the database out of the situation.) But there seems to be less incompatibility, too. Images look little changed in PL4 from how I last edited them in an older release.
A problem that I think needs to be considered is that the master copy can’t be deleted in order to make a virtual copy the new master. While virtual copies aren’t a problem as far as disk space is concerned, they do need to be easier to manage.
I have the same issue, virtual copies being generated everywhere. Often 3 or 4 copies even. This is a nightmare. Could DxO at least implement a feature to remove identical copies? I spend hours cleaning up my workflow.
P.S.: All my pictures are stored on my NAS, nothing special otherwise
Whilst not a solution, as such, Sigurd - - a quick(er) way to clean-up unwanted Virtuals is to first sort byVirtual Copy Number, which groups them all together, for selection and deletion.
First besure the database is ok and not corrupted of the one who needs to provide the new dop files.
Delete te dops and recreate them by opening the dxoplversion who you need and select images fot export dopfile.
That’s not a solution as this would also remove the real virtual copies. I don’t want to redo the different variations. Also, once removed, close app, open app again, virtual copies are back most of the time. It is really annoying.
VCs are created as a “fail safe” approach by PL when it detects (what it believes to be) duplicate instances of correction details for the same image; such as a copy of corrections held in the database versus corrections held in a sidecar/.dop file which do not have the same unique-ID as those in the database.
I’m guessing your problem is somehow caused by the fact that your images (and, presumably, their related sidecar/.dop files) are stored on a NAS. To confirm this, try moving a sample set to a fixed-storage location and see if the problem persists. If so then you’ll have something specific to report to DxO support.
The only work around is to delete the database on every start of DxO (via script). That takes away some features, but mitigates the constant fear to get the collection messed up by those copies.
I’m not sure of the exact problem that causes the generation of unwanted virtual copies, but I’ve been using Photolab since version one was first released and have never had that problem.
Yes, that’s true - - but , there will be a good reason for “unwanted virtuals” appearing in the first instance … PL doesn’t do this “just for fun”.
The only good reason I can think of - is lack of good UI design. Like ignoring the UI animation setting under Windows (making a slow application appear even slower under load).
One thing is needed, to fix it: A setting which to prefer - Sidecar / Database / Ask User
If I had encountered the problem during my testing phase back in the days (DxO 1 or maybe 2) I would have never purchased the software.
The issue is so severe for me (one wrong copy and a complete folder is messed up and needs to be recoverded from the backup), that it is a real stress factor while using the software.
This “feature” causes so much aggravation and wasted effort when it occurs, that whatever the logic behind the current behaviour of PL, DxO really needs to change the software to either address the “bug”. Or, if its genuinely not a bug, then they need to add UI features that allow the users some level of control over what happens when this scenario is encountered.
From PL’s perspective, it’s a “fail safe” strategy - in that, if PL detects any potential for ambiguity (2 or more versions of corrections for the same source-image) then it presents all versions as separate versions (rather than arbitrarily choosing one of them as the “right one”).
There will be a reason for PL adopting this strategy when it encounters it.
Lars; Have you carried out the test I have previously suggested ?
PS. I am trying to be helpful.
That’s a fair point - You could raise that as a request/suggestion.
Pity, I was hoping that this would lead to a better understanding of the circumstances that trigger the creation of these extra copies, because although I understand the principle behind the concept of creating virtual copies just in case data was going to be lost, my own real world experiences don’t make sense in that context.
Is there a member of the DxO staff out there who could spare the time to fill in some of the details as to the root causes of this PhotoLab behaviour?
A few specific details relating to the explicit conditions that are required to cause this to happen are quite likely to be enough for anybody experiencing this problem to understand it enough to avoid the issue.
At the moment nobody seems to fully understand the circumstances that trigger this behaviour which is a source of frustration for those who regularly encounter this behaviour when “seemingly they should not”.
I’m also curious to the why. Special since I don’t have that problem and am synchronizing between 2 pc and a nas.
I didn’t find the word ‘project’ in this thread. It seems that projects deals with virtual copies slightly different. So are projects being used in combination with this unwanted behaviour?
Hi @George,
interested with projects, I found Workflow management with projects(scrolling down …)
“A photo that is assigned to several projects … If you want to apply different settings or corrections to the same image that belongs to several projects, you should make as many virtual copies of the photo as you need.”
What I understand, the projects contain sort of pointers/links to the originals.
To check, I ‘copied’ a VC (1) already existing in the source folder to a new project and made there another ‘VC’ (2), which I changed to blue color.
Going back to the source folder, it showed the Master (M), the first VC (1) and an additional blue VC (2) from the project.
Erasing the blue VC (2) in the project didn’t touch the source folder with (M), VC (1) and blue VC (2).
In the project I made a new (orange) VC, which now got #(3).
Erasing this orange VC (3) in the source folder removed it simultaneously from the project.
The relevant information seems to be stored with the source folder – if as dop-file, in the database or both, I don’t know.
I don’t know about projects. I never used them. I think you’re right a project is a collection of pointers/links to a diskfile/edit list.
Dop files can be seen as an array of edit lists. Every new virtual copy adds an edit list to that dop file. Deleting a virtual copy is deleting an array item, deleting the image is deleting the dop file, so including the dop file/array of edit lists.
If you want to play with this, check the file size of the dop files when adding virtual copies.
But as Alun said lets hope somebody from the staff with specific knowledge is answering.
With a nas involved I start wondering about the effects of time sync between the nas and the machine running PL, and whether or not PL uses the time stamps on the dop files themselves in any way. I am guessing that they don’t though as there are timestamps in the dop file… but who knows…
most of the time. It is really annoying.