Hey all, I just deleted an image, which had a clone variant, and they both disappeared (ooops!!). Is there any way to restore the images, or are they gone the way of the Dodo?
Thanks in advance.
mac or windows?
where it went… garbage? if you put it back in the folder it was, should be good to go (close and re-open PL).
Mac, and I checked the trash, but trash is empty.
I had emptied the trash earlier but, I wonder, did I do it AFTER removing them from the library…
Hmmm, I suspect I know the answer to that
In Windows deleted images can be restored from the Windows recycle bin. Something similar can be done on a Mac. I assume by clone variant you mean a virtual copy. With regard to any edits you made or any virtual copies you created, they will be gone forever, at least on a PC, unless you restore backups of the files including .dop and .xmp side car files and a copy of the database prior to your deletions. I know that Macs has something called a time machine. Perhaps that could help you. Don’t you back up your computer’s data on a regular basis
Mark
…maybe you’ve got it in a time machine backup?
On macOS, a locally stored photo will be moved to the trash while a photo stored on a network share will be deleted.
1 Like
If you are using Apple Time Machine, you can recover it. Do you know how to recover files from Time Machine. You could recover your entire computer if necessary. Time Machine is free. You just need an external drive. Apple computers only.
Is it possible to retore an accidentally deleted image along with it’s dop file in a Windows version of PL8?
I accidently deleted the master as well as the virtual copy.
The Ctrl-Z function, applied immediately from within PL8 did not work, so I “restored” the image from the Recycle bin outside of PL.
The image shows in the filmstrip but not in the main viewer. The global adjustments do not show up but the local adjustment “layers” can be seen as grayed out entries. The DOP file shows the global and local adjustments.
The same confusing issue remains after moving the image to a new folder and renaming it. PL creates a new dop with “(2)” appended.
I have not deleted the database yet.
Is there another way to get PL8 to re-recognize the photo and dop adjustments? What am I missing?
Thanks!
Strange. It works fine here. Restored images appear in film strip and selecting them show them in main viewer.
No manipulation other than restoring them from the recycle bin.
I’ve just checked this now to be sure it works with PL8. It does here.
PL8 Win11.
PS : I restored images when PL8 was open (I didn’t checked if this is needed and I don’t think so).
1 Like
I tried this with PL8 and got a slightly different result.
- I opened PL8 which was pointing at a directory containing a few test images I’d been working with. One of the images had a VC as well as the Master.
- In the filmstrip I selected the Master and VC and used the PL8 right-click Remove option, saying Yes at the warning question. This, as expected, removed the image Master and VC. (I’m assuming this is how @swmurray deleted the images from within PL8).
- With PL8 still running I opened the Windows 10 Recycle Bin, selected the RAW image and its DOP and Restored them.
- I immediately returned to PL8 and almost instantly the restored image reappeared in the filmstrip, and I was able to view it in the main image window.
- The one surprise, to me, was that the filmstrip only showed the image Master, with the VC no longer present. Given that the existence of a VC and its associated corrections are, I thought, contained in the DOP I’m puzzled why the restored DOP didn’t result in the Master and VC being visible.
- Still in PL8, I created a new VC for the same image and then again Removed the Master and VC.
- Once again, Restoring the RAW and DOP resulted in the image reappearing in the filmstrip - but again only the master, with no VC.
@SAFC01 – there might be two reasons:
- PL didn’t yet save the modified DOP file with the VC inside, so it deleted old DOP, still without the VC.
- Some microseconds race condition. Windows restored the raw file first, which immediately triggered PL to find the RAW but no corresponding DOP (not yet restored by Windows), so it restored the DOP from database, which probably did not contain VC yet. I don’t know the details of how Windows restore works to make this explanation valid, but if I restored DOP first and then the raw, the VC appeared, as expected.
Note that PL does not update DPO and the database synchronously with edits. For DOPs there was 20 sec lag in PL7, don’t know about PL8 and DB updates.
EDIT: Just tried restoring DOP (with VC inside) first and only then the raw. This time there was no VC. There must be still another timing issue, but I have neither time nor will to investigate it further – it would require using ProcMon, which is time consuming.
Ran an experiment with DPL7.10 on macOS Sonoma 14.7.1 on Intel 5k iMac 2019
Prep
- set DPL to auto-import sidecars but also to not auto-export
- emptied the trash (to make testing simpler)
- selected a folder of images and created a VC of each image
- treated all VCs with the default B&W preset (easy to see if applied)
Test 1
- Saved sidecars manually
- deleted all files with DPL
- moved all images and sidecars back to the original folder
→ all images and VCs re-emerged in DPL
Test 2
- deleted all files with DPL
- moved all sidecars back to the original folder
- moved all images back to the original folder
→ all images and VCs re-emerged in DPL
Test 3
- deleted all files with DPL
- moved all images back to the original folder
- moved all sidecars back to the original folder
→ all images re-emerged in DPL
→ NO VCs re-emerged in DPL - manually imported sidecars
→ ALL VCs re-emerged in DPL
Note that
- the automatic sidecar import setting did not make DPL import the sidecars when they were copied to the folder of images. Only upon manual import did the VCs come back.
- we have no control over how (timing-wise) files are restored. There is a risk of “losing” VCs due to timing and restore order. Manually importing .dop sidecars solved the issue in my tests.
Comments
- DPL on macOS seems to work as expected in the tests outlined above
- automatic import does not seem to work as expected
- I set DPL to NOT automatically read or write sidecars. This gives me full control…and as I use DPL mostly for optical- and noise correction as an extension to Lightroom, I don’t specially care about the .dop sidecars and I also delete the database every now and then.
- YMMV
2 Likes
@platypus and @Wlodek.
I’ve done another test, slightly different to yours but with strange, unexpected results that suggests:
a) the explanation you (@Wlodek) gave above while plausible may well not be correct
b) there’s yet another difference between Win and MAC versions
- Prior to launching PL8, I deleted the PL8 database, and the only DOP in the test folder, leaving just a single unprocessed RAW image in the folder.
- I launched PL8, created a VC and then altered the Working Colour Space of the VC to Classic (Legacy) for easy contrast with the Master (which my default RAW preset sets to DxO Wide Gamut).
- To be sure the DOP was up to date I used the File / Sidecar / Export menu item to force the writing of the DOP, choosing to overwrite the existing DOP (note I have the Preferences set to Save and Load DOPs automatically, which is why a DOP was already created).
- I copied the DOP to another folder for examination, and looking at it with Notepad could see the contents for both the Master and the VC (easily found by searching for “Wide” and “Classic”).
- In PL8 I selected the Master and VC images and used the right-click choice Remove to delete them.
- From the Recycle Bin I Cut and Paste the DOP to the same folder as the other saved DOP. Examining this DOP revealed two things:
- It was almost half the size of the original DOP
- Examining the contents I found there was only information for the Master - there was no entry information for the VC (and searching for “Classic” produced no result unlike with the original DOP)
So it appears to me that for some reason, at the point of Removing the image(s) in PL8 the DOP is first updated to remove the VC entry and then the DOP and RAW file deleted to the Recycle Bin.
I’ll repeat this test with PL7, and also try PL7 & 8 with multiple VCs to see what happens and post again.
That is unexpected as well as the missing entries for the VC.
Testing with my manual sidecar management gave no such effect.
Both the original DOP and its deleted copy are identical
Last login: Wed Nov 13 09:30:51 on console
501@iMac ~/Desktop $ shasum *.dop
a9b899eafb8668af9f310f27ed22514940236129 20231206_8606_R 2.CR3.dop
a9b899eafb8668af9f310f27ed22514940236129 20231206_8606_R.CR3.dop
501@iMac ~/Desktop $
Testing with auto I/E of sidecars…both .dop files were identical again.
Seems to be a Win thing…
I’ve just repeated the same test, but creating 5 VCs from the single image. The results are essentially the same as above. The DOP in the Recycle Bin (i.e. after Remove in PL8) is approximately 1/6 the size of the one for the Master & 5VCs, and again has no information for anything other than the Master image.
I’ll now repeat with PL7.
The results for PL7.10 (Master and 5VCs) are exactly as described above for PL8. As you (@platypus) say, it appears to be a Windows thing, but clearly the difference lies within PL as I can’t see any way the DOP could be being changed at the point of Remove other than from within the PL code.
So my conclusion, going back to @swmurray’s initial question is that:
- you can restore an image and its DOP that has been deleted in PL8, although it looks like you may need to force the re-Import of the DOP sidecar
- but if there were VCs as well as the Master than these VCs are gone forever.
@SAFC01 The most likely deletion sequence from the database is
- VCs first (you can’t risk having VC entries without the [M]aster
- Then delete the [M]aster
It appears that DxPL(Win) has decided to write the DOP between steps 1 and 2.
Download FolderMonitor, set it to watch the test directory, set logging on and then delete and analyse the results to see if a new DOP is created just before being deleted!
The simplest way to detect the break point and how many copies you have is to look for “ShouldProcess” (and count them), the Tag field, which sits just before the UUID (that can cause unwanted VCs).
This is the tail end of a “random” DOP which only contains a [M]aster.
The DOP write delay can be up to 20 seconds but I have seen slightly longer delays and for critical DOP writes DxPL can choose not to “batch” them up, I believe.
Thanks for the suggestion Bryan. I’m busy for the next few days but will give it a try next week and reply.
…about the same with DPL on macOS…but creating a VC is written to the .dop file almost immediately (within one second for 60 images)
Great analysis in this discussion - in my opinion, already more than sufficient for submitting a bug report to DxO Support. That VCs are being deleted before the image file and sidecar are sent to the recycle bin should be regarded as a design error, given the purpose of the recycle bin. While PhotoLab doesn’t provide a mechanism for restoring deleted files, it’s easy enough for us to do that in the OS. That said, I would not have the folder where those files resided open in PhotoLab at the time I restore the files from the recycle bin. I would either close PhotoLab or open a different folder while recovering the files, so that PL doesn’t read and process the image file before the sidecar is restored (data race). This has previously been demonstrated when copying or moving files while PL is running and monitoring one of the folders involved.
1 Like