To compare images before/after is great, however I don’t get why I’ve to generate the first snapshot myself.
Just saying, if I edit an image, I expect Darktable to generate the very first snapshot automatically for me. If I don’t edit images, there’s no need to create auto snapshots.
Maybe somebody made a script or I’m missing some setting, but I didn’t find any.
Since the rendering with the defaults is not some ‘ground truth’, just a default rendering, I don’t find such a comparison useful for the initial adjustments (only later, when fine-tuning). You can always just click step 0 in the history to go back to that one (despite the default modules coming after it in the history, darktable will include them in the image you see).
I disagree.
Not all my images need complex modifications, because I develop selected images only:
depending on my shot I’ve my own style presets, then follows fine tuning. Since I’m using DT in a systematic way, some features would be handy to be automatic.
An automatic snapshot after applied style presets of new imports is nothing to worry about - and it doesn’t influence the final picture.
Snapshots persist across images so you would have to code for that or clear your snapshot…for each new image…
Maybe it is scriptable, and is simpler to do that way than by adding it to the core. @wpferguson will probably know if that’s the case. If not, please create a feature request on Github and see if any of the developers is interested (or, of course, you can volunteer to build it yourself).
thank you guys for telling me straight.
Me guess, a snapshot is a jpg copy of our image, ofc it would take additional CPU power to generate these previews as automatic snapshot - (even just if trigged by edited images) and eat memory to keep this data persistently.
I think with nowadays hardware (which latest versions of DT requires to run) is powerful enough to generate these snapshots (with a min. 8gb VRAM, min 30gb ram, openCL, etc).
From my side, it wouldn’t matter if auto snapshots would be core as a checkbox preference or a script, of course.
Nothing is automatic without the right code lines. Sometimes even minor code is challenging. I only know bash, CSS and applescript. With Lua or other languages I wouldn’t know.
If you know some scripting languages, Lua should not be a challenge. The question is more if darktable’s Lua API exposes the required controls.
Not being a programmer its really hard for me to guage the level of work for something that seems even trivial to add… The current snapshot feature takes a snapshot from an image and that is persistent so if you move to a new image you would be essentially comparing 2 different images and not the earlier version of the same image so there would have to be clean-up of that and at the same time a way to keep things working that way when you want the function as is and then also the way you want it to function… I suspect given the complications within the DT pipeline and all the versions used to maintain backward compatibility etc etc that it might not be trivial…
I think your feature is a request to add one that some software has where you see the image as loaded vs the current state and its usually a toolbar icon toggle …
To add this function, rather than trying to massage the snapshot feature and incorporate all the overhead and processing, I think maybe this could be done if and I say if, you could store in the history stack a copy of the initial load and maybe even a second one that was the last loaded state.
This might be no more efficient but if you could do it then with one key stroke or icon you could toggle between the original loaded image from that history stack “snapshot” of the very first time it was opened and the current preview. With a keystroke modifier you could in an editing session also compare the current state of the preview to the state of the image loaded at the start of that session/edit. All this of course can be done by using the history stack manually and/or using duplicates but if there was a way to store those two states in the history stack ie the initial load state of the image the first time ever that it was loaded and then the history state on open for the most current session then these could be used as reference points to go back to via some key press or keystroke for review…
It would probably be a nightmare to add this given the complexity of things but really I don’t know enough to say.
Having said that I think in ART and I could be wrong that the snapshots are saved between sessions, ie added to those sidecars and can be called up in subsequent editing sessions and so you could in effect create one or both of the history stack versions I mentioned above as “auto snapshots” to be used for comparison against the current image preview during an edit if this sort of thing can be added in DT the way it is in ART…
I don’t think there’s an overhead: the image has to be processed anyway when it if first opened in the darkroom. Creating snapshots is instantaneous.
The question for @johans3 is: would you like to create such a snapshot every time you open an image, or only the very first time you open it.
Also, snapshot are persistent (so you can compare snapshots of different versions (duplicates) of an image, or between different images in a sequence). If a snapshot is created automatically when you open the image, the number of snapshots in the snapshot history (in the module) will grow. Would you imagine a script that first always removes snapshots from the previous image, so a new one can be made just for the current one?
Ya it’s more the tracking cleaning up of snapshots that might be required that’s why I proposed keeping it separate so that the persistent nature of snapshots didn’t need any change and somehow you just leverage the history stack… But beyond that I don’t really know what the easiest way to do it would be…
I was wondering if you could just leverage the duplicate option of original but repurpose it not to create a duplicate but just a preview that could be toggled with the current displayed preview…There is also the hover code where by if you had a duplicate that was original and you hover on the duplicate icon it swaps with the preview … So basically I wonder if that could be packaged or recoded to a compare function that you could toggle from the main preview
Seems like the requested feature is already there in form of a lua script:
https://docs.darktable.org/lua/stable/lua.scripts.manual/scripts/contrib/auto_snapshot/
I didn’t say it before, but I’d like to use the snapshot feature in DT much more, to check changes between my applied style and final tweakings.
Yes, DT’s snapshots are persistent and switching to the next image doesn’t clear up the previous snapshot. This behaviour is somehow strange, as I’d expect snapshots to be separate “backups”, individual for each image. Snapshots should be valid for images with the same name/id/hash.
Not really a critique, but I don’t understand why snapshots behave this way. In my opinion, it would be more “suitable” if DT could generate snapshots in a separate folder like mipmaps / thumbnails for the lighttable .
I don’t expect that DT creates auto snapshots for each and every photo. Auto snapshots should trigger on modified photos only, eg, after applying a whole style or after a single, manual change in darkroom.
And more important, this automatism should trigger just once per image, if there isn’t any snapshots available in the snapshot history.
I find it useful for comparing two similar shots or even different processimgs
What @paperdigits said (and I did, too). Mipmaps / thumbails are static (have a fixed size and are only regenerated if you change the image), but snapshots, for quite a while, have been more than mere bitmaps: you can zoom in/out and move around, which is pretty useful for detail-related comparisons (denoising, sharpening, checking for halos and the like).
Understood, I think if snapshot backups have a decent or the same size as its original, zooming shouldn’t be an issue.
For me, comparing similar images is something I prefer to do on the lighttable or after export in another digital asset management app like Digikam.
To compare similar images in darkroom sounds OK to some extend, but feels stretched - imo.
Maybe because of the way snapshots were implemented, snapshots got another use than just to compare the history of the same image.
I mean, I do more targeted shootings with some duplicates, but get rid of dups in favour to the best shots - a priori .
If I can say, DT’s Darkrooms main focus is to develop images. The lighttable instead, offers features to compare images.
Well, I think, comparisons are intuitively and more suitable on the lighttable as overlapping previews? But then we would talk about something completely new.
If you prefer to work a different ways that is all good. But some of us have developed workflows based on how it works now would be upset if our workflows were not preserved, and that’d likely mean a decent amount of development work.
well, I wrote a lot of points and feel not heard by this brief answers.
Agreed, people have their workflow , me too.
Darktable is improving all times and I’ve modified my workflow multiple times because of merged modules, new modules or a new pipeline that’s the evolution of software.
I’d love to hear some constructive critics too.
No. Snapshots are not “backups”. They are calculated from the source image and its stack; they are not saved to disk, and are calculated at the size required by the current zoom level. You can zoom in to 400% if you like, for pixel peeping, without this taking up disk space.
The power of snapshots for comparisons is the draggable split view. That’s not something you can do on the lighttable. You can compare the state of one development of the image with another the effect of another step (which you really cannot do on the lighttable, as you only see each duplicate once – this is exactly what you wanted to do in the first place, why this thread was started), or with another duplicate of the same image, or with another image.
Your request for an auto snapshot feature seems reasonable. As for if this should be part of the snapshot module itself or something separate I would leave to the developers who understand the difficulty, but the reality is that it can be achieved by a simple click in the snapshot module by you at the start of the process and this may be the most efficient way. Hopefully the lua script for auto snapshots works for you and resolves your issue.
As for the current behaviour of snapshots to remain between in images, I find this a very useful feature. One scenario I have used it for is to do a snapshot of the out of camera JPG. I then start editing the raw file and I can check that my edit is superior or if not what is it about the jpg that I want to replicate. 99.999% of the time I can beat the JPG, but once in a blue moon the camera does something that just works so well on the individual image and the JPG wins. I also used this same snapshot feature to create my own style in DT that comes close to the JPG for a starting point in my editing process. I do see the JPG as the holy grail of what the photo should look like, but this has proven a nice starting point for many of my travel images.
Terry, glad to see with your comment another example on this matter!
If I understand correctly, you take landscape pictures like me, but as raw and jpg. I tried diff recording combinations too, but to simplify life I’ve settled with raw as my preferred recording method .
As I see it, by landscape motifs there’s no need to take multiple shots from the exact same view, and to shoot animals in motion is yet another topic.
I also like to take multiple photos from the same place and diff angles if special, but these pictures don’t overlap and therefore, can’t be compared each other.
Usually I don’t take my laptop on the road to check my shots on the fly, so to have a use for immediate raw image comparisons.
Same, I made my dtstyles too, but less from detailed image comparisons, more from overall improvements depending on the mood, light and season of my shots. Dtstyles are for me only base modifications on which I tweak and add final corrections.
As much as I would like to understand and shake hands with you on this shared snapshot thing between similar (and not same) images and trying to appreciate it with best intentions, this concept doesn’t unfold for me and how it should fit into my raw development workflow.
I appreciate however, your nice comment and the time explaining in detail how you use and suggest to use snapshots.