I have a client that requires a small selection (5-10 pictures, typically) of images as quickly as possible after an event for use on their social media channels. This is totaly fine, I can do this on the laptop in the car before drivnig home.
I’ve been selecting the raw files for editing and placing them in a folder called ‘Quick edit selection’. A copy of these raw files also goes into the ‘Selection for main edit’ folder.
I’d like the edit I do in the car to be carried across to the edit for the main edit. So far I’ve tried copying the .dop and .xml files from the quick edit to the main edit folder, but the edit does not reapply itself in the main folder. I had (wrongly) assumed that by copying these data files over then the edit would be picked up for the iamge in the alternate folder.
Could someone please explein to me what am I doing wrong?
@CHPhoto check the option that was mentioned by @Pathal but caution is then needed with respect to what you have done and what you then do!
Basically you need … but actually I (and others) need to know are you running DxPL(Win) or DxPL(Mac)?
I am running on DxPL(Win) so what I write here may or may not correspond to what you need to do!
I believe (from your post) that you are going to do your initial edits in ‘Quick edit selection’ (A) and then want these edits to be transferred to the same images in the (larger) ‘Selection for main edit’(B).
The problem comes if you have “discovered” the images in B before you try copying .DOP and .xmp files from A to B. If the answer is yes you will most likely get Virtual Copies created in B when you (re-)open B in DxPL!?
I just tested that by accident and although the discovery of B images in DxPL had not resulted in the creation of a DOP, the entries were in the database with the assigned preset and the DOPs identity clashed with the database entry identity and I got VCs, as I expected.
Drag and drop from A to B doesn’t work because the images are already in B and DxPL does not provide an option to overwrite it simply rejects the attempt.
The only way out of a mess like this one is to do something that I hate intensely which is deleting the [M] entries from B (which will also delete the [1] entries at the same time) wherever they have occurred and then use drag and drop to copy from A to B!
The best way is to avoid the problem is not to navigate to B before you have completed the edits in A and then copy the .dop and .xmp before any such discovery takes place.
PS:- For safety
Create a new directory C
Select the images you are going to delete and drag and drop copy to C
Delete those selected items from B
Copy the items from A to B and hope for an exact match!
Select the images in C and ‘Remove’ when you are sure that everything is as it should B sorry should be.
Delete the temporary directory using another utility.
Many thanks for all this info @BHAYT , very useful read.
I’ll have more time to experiment with your suggestion next week.
To quickly answer your question. I use a Mac Mini desktop and a Windows 11 laptop. Images are stored on a Samsung external SSD, and it is plugged into both computers.
I have the same issue when trying to view edits if I move the SSD from the Mac to the Windows machine, or vice versa so I hope the info you provided may help me work more productively when moving images between folders and machines.
@CHPhoto I have done quite a lot of work testing moving data around, including co-hosting the database on the same drive as the images but I believe that particular idea is only possible with Windows because I believe (and you can confirm) that you cannot move the database from its default location on a Mac?
But I have moved directories with DOPs successfully between two systems, with a database on each system, without getting “Unwanted Virtual Copies” and I have also moved directories between systems and got Virtual Copies!?
The later items in the “Unwanted Virtual copies” post from Unwanted virtual copies - #86 by BHAYT onwards identifies how the problem occurs, namely when DxPL identifies a clash between a database entry Uuid and a DOP Uuid.
This “suggests” to DxPL that they are not referring to the same edit so the database entry becomes the [M]aster copy (edit) and the DOP entry becomes the VC[1] entry and a new larger DOP containing the data for [M] and [1] is created!
I actually managed to take edited images (image + DOP) to another system and it was absorbed into that system with the same Uuid, and then carrying that back to the first system was perfectly O.K…
A similar problem occurred in my “mistaken” test, the reason that it was a mistake was that I was deliberately going to test the scenario but actually did it by accident. When B is discovered by DxPL the database entries are created for all the images in the directory. If a new DOP is then copied into the directory it is always going to clash with an existing database entry!
There is no real “fix” for this situation, other than avoiding it altogether and I believe that on the Mac some elements of my suggested “recovery” strategy are not actually possible on a Mac because there is not an identical set (to the Win version) of directory options available!?
So you may have two situations to contend with
the A to B situation on the laptop and
then the switching from processing on the laptop to processing on the Mac mini desktop system
That represents a challenge or rather multiple challenges, made even more challenging because you are using two systems with different features available!?
This is the database structure that holds images called ‘Items’ and the snapshot is after I have discovered A (4 images) and applied a preset and then discovered B (6 images, 4 of which are the “same” images as those in A).
But if that DOP is copied from A to B for this image then there will be a clash between the database Uuid for the “same” image in B (shown in green) with the Uuid from the DOP copied from A to B.
The result will be that the edits in B will become the [M]aster and the edits from A (carried in the DOP) will become [1] (a Virtual Copy) and a new DOP will be created about twice the size to hold the data from the [M]aster and FC[1].
This explanation is intended to help but if you need additional information please ask. The actual problem is easily encountered but difficult to rectify and needs some additional features put into both versions of DxPL, along with creating full compatibility between the two releases (if possible) but …
EDIT:-
There is an alternative recovery strategy
Copy the DOPs outside DxPL from A to B and if VCs are created then
for each VC do the following:-
‘Copy correction settings’ from VC[1] and
‘Paste all correction settings’ to the [M]aster
‘Copy metadata’ from VC[1] and
‘Paste metadata’ to [M]
Effectively the [M]aster has become the same as the VC[1], i.e. the same as the image in A
You are now free to delete VC[1]
This must be repeated for all the DOPs in A that are copied to B (arguably this will not be necessary if you are able to delay discovering B until after copying to A and editing in DxPL and then copying the DOPs prior to any discovery of B by DxPL).
I’d not copy files to a quick edit folder but use a logical differentiator instead.Several possibilities exist:
use a colour label
use a star rating
use virtual copies
All of the above transmit through sidecars and all you’d have to do is to have DPL read the sidecars, once that you external drive has been plugged into the second computer. For better control, I’d set DPL to not automatically read and write or sync settings and metadata.
@platypus given the “agony” I have documented above that is a good call but I would add
use the ‘Tag’ (if that is also available on the Mac, but that is only stored in the DOP which might conflict with your recommendation of not automatically reading and writing or sync settings)
I am concerned about your recommendation to not automatically create DOPs in particular when you are copying data between systems, the same applies to metadata but there we have the issue of what DxO chose to do with
where the setting of the ‘Synchronize metadata …’ ‘Preference’ changes the “first discovery” rules as to whether DxPL takes the metadata from the sidecar file (which it will if set as I have shown, but it will automatically update metadata every time it is changed in DxPL or a change is detected by DxPL).
If the field is left empty then on “first discovery” DxPL will take the metadata from the DOP and no automatic synchronisation will occur.
I choose to run with the automatic creation of DOPs and vary the 'Synchronize …" settings.
If your advice of manual control of both is selected then the user can always resort to
and
to manually force a read or write but …
EDIT:-
@Musashi adding an “Import - Overwrite” command to this menu, coupled with @platypus recommendation to stop automatic ‘Reading’ of DOPs could help overcome the “agonies” that can accompany DOPs!
My recommendation is intended to assign control to the user and to prevent DPL overwriting perfectly valid sidecars by whatever crud might be in the database on the other computer. Not automatically doing these syncs means, that one has to do manually, through the respective menu items, the necessary imports or exports.
Workflow
open DPL on the laptop and point it to the folder with the new images
select from the new images the ones, that should be sent presto to the customer, and mark them with a colour label, edit to taste if needed
manually export sidecars
plug external drive into second computer and point it to the folder with the new images
@platypus I understood your post very well it was well explained and I agreed with your suggestion with respect to the use of ‘Rating’, ‘labels’ etc. to avoid the local issue of “Unwanted VCs” and it is a good strategy.
I would personally use the ‘Tag’, providing DxO are not going to deprecate it any time soon, simply to leave the other elements free for their “normal” use, but that depends on the users workflow.
My problem was with the idea of turning off the automatic export of edits (via the DOP) in particular.
The problem with your statement is that the power of any manual control is predicated on the user being able to know that there is “crud” present.
The only way of getting edits to a second computer is to first “externalise” them on the first computer, manually or automatically, because without those DOPs the data is going nowhere.
So whether DxPL writes the DOPs automatically or the user chooses to do that manually is immaterial with respect to the writing of edits.
Hence, if what is in the database is needed externally, for transfer to another computer or simply for storage away from the database, then whatever is in the database has to be found outside, i.e. where is the additional control?
The only case where the user might want to exert control over DOP input is if they suspect there is a Uuid mismatch but
How is the user going to determine that (you and I can do that using Beyond Compare, but only realistically for testing purposes)?
What is the user going to do about that situation even if they know there is a potential issue?
With respect to output I would agree that it is possible that a user might want a DOP left intact even when it caused an “Unwanted VC” situation (rather than having the DOP overwritten by the bigger DOP containing the original edits from the database + the edits from the DOP itself).
But realistically what can then be done to resolve the issue?
I have designs for PYTHON scripts to copy DOP Uuids, to swap the [Master] and VC[1] data in the DOP and have tested the processes manually. I have not extended those “designs” to the database because I haven’t even begun to use SQLite PYTHON Libraries.
But the real issue is that you don’t know that something is going to go wrong until it does and no amount of manual controls can prevent it, unless DxO or the forum issues a warning and we all …!?
With respect to importing DOPs on a second machine there is arguably little that the user can actually do if the edits are required to be added to that computer, manually or automatically.
I am afraid that I believe that DOP control through manual intervention does little to prevent the problems we are discussing here, whereas your alternative strategy does help avoid the Local VC issue.
Keyword metadata is potentially another issue and manual control will prevent DxPL “adjusting” the format of keyword metadata created externally.
But if DxPL is actually the sole or main source of that metadata then what is in that database has to come out to preserve it and with the new features I am happy to have DxPL in charge of my keywords (rather than pay “big bucks” for more software, albeit I have IMatch as well).
The procedure you show will work regardless of the automatic or manual DOP import and/or export mechanism. If there was a DxPL warning of a Uuid clash plus the ability to override the current action then that might be a different issue, but the warning and request for user intervention would work equally well in the manual or automatic situation.
The work that I undertook looked at the round trip experience, from laptop to desktop and then back to the laptop, with edits of one sort or another added at different points on the journey.
It showed that if the DOP was imported into the Desktop DxPL database without a change of Uuid then it will return to the laptop (with its original Uuid intact) and be accepted there without problem. This seemed to be possible in all situations that I tested with respect to “first discovery” situation on the Desktop system providing the Uuid had not been “seen”/used before on the desktop system, i.e. the Uuid is not somewhere in its database.
Thanks, these options had crossed my mind as a solution and I think it will be what I do in the future to avoid this issue as much as possible.
Coming from using my current workflow process (separate folders and copying sidecar files from one folder to another, etc) with Exposure X6, which also uses sidecar files where this process works seemlessly (and across Mac <-> Win) I had rather naively expected a similar experience with Photolab.
As far as I understand, Exposure X6 does not have a database in the background, it relies purely on the sidecar files for edit info.
The problem is not caused by the database itself, but by the fact that we can copy and move files without that DB tracking such changes or detecting them later. Imagine having a folder “New” that you use again and again. All files will end up being catalogued as contents of “New”, even though they have been moved away. Same for a folder “For client” or any other folder (structure) that is used again and again. Most things should work, but search will deliver loads of false positives: files that are remembered in the DB, but are in fact long gone.
BTW, you can delete DPL’s databases at any given moment, unless you want or need search, editing history or projects. Trashing the DB before any new import could be the “solution” of your workflow issues, but if you go that way, I’d propose to set DPL for automatic r/w of sidecars again.
What happens if you move the files within Photolab? Will there be a option to overwrite the current pictures? (you can switch between copying and moving by holding down the shift key during drag&drop if I am remembering correctly).
PS:- all my test files are in an old Beta directory for PL5 and this was actually done with PL6.4.0 not PL6.3.1. You can (only) copy or move to a directory that is within scope (i.e. view) that does not contain the same named images already.
I have never been able to get the view to scroll to find the target directory while dragging or Shift dragging at the same time (that might just be me so if anyone knows how that can be done I would like to know). Plus DxPL(Win) does not automatically open directories when I hover over them, the target must be in view for the process to work at all i.e. virtually every other piece of Photo and file management software I use does way, way, way … better than DxPL in this respect!
