Same here, same here, so I never lost an image! But it is more that you have to restore them from trash and restore them into the darktable library. Which is a bit fiddly…
(Before switching to darktable I used capture one, which has a internal trash, so deleting a image moved it the internal trash and removing them from the internal trash moved them to the system thrash)
Feel free to open a feature request on github, that might be a good idea for someone wanting to get involved in dt dev. It’s nothing really big, doesn’t involve any tricky part of the code …
When I saw the subject line of this thread, this is what I expected it would be asking for, and man would I like it! Just last night, I fat-fingered the wrong duplicate of an image in dt, one that was required to be identical to a print.
I have created a feature request for this on GitHub. I included @Masterpiga mention to freeze an image. I think that might be two different features but maybe it can be implemented in one go, or his feature idea builds on this feature.
I also added that it would be awesome if darktable also can take the ‘protect image’ information from the meta data that Nikon / Canon camera’s have (both are featuring a ‘prevent deletion’ feature in their camera’s) but this is no must of course.
+1 for support for both locking from deletion and locking from editing. Not sure if those need to be two different features or not but I’d appreciate them both!
Select all images, press F1 to red-tag them, then filter by red-tagged images. Now just go through your culling process as usual. If you find an image you really want to keep, press F1 again to untag it and it will not be displayed at all in your culling process, so you can’t accidentally delete it in the culling.
Not exactly what you wanted but it’s not a bad solution either and it’s quick.
I use something similar But one way or the other, I am sometimes just too quick in selecting the wrong filter or I think that I have select the right one and I press the wrong button.
But thanks for sharing your workaround!
Currently I’m experimenting with a workflow of importing the images bit by bit, ‘bird by bird’ so to speak, so the culling happens only happens at the end collection. All already accepted images are marked with the green colour tag, and they are filtered from my view. This also reduces the sometimes overwhelming view of a couple of 1000s images…
A feature I’d like that overlaps somewhat with the above is the ability to output an XMP with the same file name as the output jpeg/tiff/whatever.
So whenever DT outputs, and assuming you are using XMPs, as well as updating the standard XMP it will output a second XMP as a partner to the jpeg. This means you don’t lose your edit if you start changing things a week later, or remove the raw from the collection. DT doesn’t write to or delete specially named XMPs.
This would need to be switched on per user.
You can store the edit history in the metadata of the jpeg. Tags etc can also be written to the exported jpeg (and most other export formats?). So what does the extra side car give you?
Keep in mind that DT does not automatically import the exported images, so should not touch those files (or their sidecars), until/unless they are imported into DT.
Why is it weird? Why you don’t believe in it? The content of the xmp is stored in the metadata of the exported file. This is the ideal scenario since you can recreate that same export without managing two files.
Nvm, we’re getting off-topic wrt. the original proposal. If you want to develop the idea of a sidecar with each export, perhaps open a new thread?
Implementing it would probably be a lot more complicated than an move/delete lock on a file (basically a flag, to be checked when the user wants to move files around).
I don’t see the overlap with my feature idea / request. My request has nothing to do with export. If you don’t want to accidentally use your edits, or track your history, you could check them into a git repository (maybe that would a cool feature if darktable supported that)
Another option is to embed the xmp file darktable creates in your jpg. This is possible with exiftool:
I agree about guaranteed reproducibility, and it’s secure in terms of protecting against accidental editing or deleting the wrong thumbnail. But people receiving my output (apart perhaps people here on pixls) are not interested in process steps and the extra data is clutter, even if not exactly big in most cases. I exclude exif too, people don’t need to see what gear I have even down to serial numbers!
I think DT and Rawtherapee, plus forks, are the only pieces of software that embed the history.
I still don’t get what you are trying to explain here and what feature you would like to see? And how it related to the locking / freezing images discussed earlier. Could you open please a new thread, explain the problem you have and how you would like to see it fixed? It is for developers very confusing if two feature ideas are fixed in between.
