Unwanted Virtual copy generation

@Bencsi Endre read the rest of this post when you have time but in the meantime please to the following

  1. However you normally drag and drop the images to the Desktop for printing please drop to a new Directory e.g. “_Images for printing - 01” and then open that directory in PL8 and see what happens.

I believe you have been copying the same images to the Desktop and they have never been deleted by PL6 etc. and are still in the database and that is what is causing the VCs

The original Post begins here:-

@Bencsi Endre I thought I had a problem yesterday loading an OpticsPro 11 (OP11) image into PL8 but I tried it again today and it seems fine.

So I went back to the earliest release I have installed which is OP9 added two images to a new test directory, discovered the images in OP 9 and applied some fairly obvious edits and moved away from the test directory in OP9.

I discovered the directory in PL8 complete with the (OP9) edits and edited one in PL8 successfully.

I also have OP7 in a Trial mode so I repeated the test with that which also seemed to work O.K…

In both cases the tests today were on JPGs and

  1. The DOP was immediately converted to a PL8 DOP so no using that on an old release again. I have both the read and write DOP settings on and always have done.

  2. No VCs were created in the process which is what I would expect to happen.

All old DOPs should be loadable into PL8 and their edits shown as has been the case since … “forever”. and that still a seems to be the case for me at least.

I then added PL7 to my DOP test list and cleared the PL7 and PL8 databases, anything I want to keep is already backed up.

I then discovered each images in Pl7 then PL8 and compared to the original state of te directories on another machine and got the following
PL7:-

PL8:-

Both PL7 and PL8 change some of the DOPs (I made no edits in either release or exports in either release, either action will cause a new DOP to be created.)

DxPL has also caused changes to some of the JPGs which appear to be time changes i.e.

I will be reporting to DXO Support

  1. The situation where PL8 doesn’t create a DOP after discovering the PL6 change as discovered in my test above.

Endre I don’t like the idea of disabling the DOP write at all.

As has been stated by a number of users here they rely on the DOPs and not the database, i.e. they remove the database after an editing session and re-discover the edits via the DOP as and when (and if) they need to.

But I certainly don’t like the idea of relying solely on the database as the only source of the edit data.

It will indeed but if you still have the original in a folder and the change is made to an image on the desktop does that actually matter?

I just did that with PL8 and had no problem and no VC. Which version do you use to drag and drop the image, PL6 or PL8?

This shows two images dragged to the desktop and opened in PL8, the Acacia tree image was dragged and dropped by PL8 , the view of London from Southwark was dragged and dropped by PL6 and PL8 is treating both identically and no VC in sight.

Both DOPs are now PL8 DOPS.

It should work and it does work but not in your case. The images you are dragging to the desktop already exist in the database and that is what I believe is happening.

You have done this before on one release or another and you are doing it again, either overwriting the existing images in the drag and drop operation or (more likely) you have deleted them from the desktop in the past but they are still in the database!