Snapshots should always be applied from a source image to a target

[lefth]

This prevents snapshots from being applied in an unloaded image, which causes loss of image history if undo is not applied.

This tends to happen and go unnoticed when working with duplicates. This fixes #22018.

[TurboGit]

Indeed, the issue is fixed but I'm wondering if we just want to disable restoring a snapshot to another image. The restore has been designed to go back to an old edit for the same image.

To be discussed, but applying a snapshot to another image seems awkward to me.

[lefth]

@TurboGit It would be awkward if done by accident, but on purpose (and with Duplicate Manager) it's a straightforward way of persisting snapshots to disk, or to get snapshots into a state where they can be viewed in lighttable.

Here's an example workflow: I've been reading that the proper way to give a warm glow to a scene is not to let some warmth seep in through color calibration, but to calibrate the scene to entirely neutral and add warmth through cbrgb. Without getting into the arguments on either side, I'd like to test it.

• white balance it neutrally
• save a snapshot with a descriptive name
• apply a tint
• save a snapshot with a descriptive name
• ask if I can do better; create a duplicate
• load the snapshot with neutral illuminant
• apply a creative color calibration

You can do all this without applying changes onto duplicates, but (with multiple versions) it would take longer and introduce confusion about which image I need to load to restore a snapshot. Plus I try not to alter my history stack after I have an image I like, so the workflow would involve cloning with the clone being an original and using the first image to load snapshots then create other duplicates.

I also temporarily apply snapshots just to see module parameters, though this goes against my rule of not casually altering history. (If the parameters are complex, I might even load a snapshot, save a module as temporary preset, undo, then apply the preset.) In short, snapshots are a general tool.

Should we restrict applying snapshots to non-duplicates? I can think of one use case: a snapshot is like a named history stack. I could apply my "artistic color calibration" or "warmed with cbrgb" snapshots to another image in the same set to see how they work.

[wpferguson]

After reading the use case, my head is spinning

IMO this would be much cleaner and clearer using duplicates, copying and pasting history stacks and if necessary using styles.

---

From a support standpoint if something goes wrong with the snapshot workflow, I'm not sure we could troubleshoot it and identify the issue. With the dupilcate/history stack workflow we can.

[lefth]

@wpferguson When I look at the history stack, I can't see what each step accomplished when I'm working in a multi-purpose module like cbrgb. It's useful for going back in time, but not for finding when I achieved neutral color grade, for example. (Since multiple changes can be combined as one step, the version I'm looking for may not exist in the history stack.) And there are sometimes too many steps to find anything.

I agree with you about snapshots being risky and impossible to support. Still, the simple workflow I would like to do is: pick a snapshot I want to work on (e.g., neutral color grade), make a duplicate, then load that snapshot and start to edit.

(I have several ideas about how the history stack could be improved, but the required changes might be too large for too small a benefit, though it would be worth discussing with other users on PIXLS.)

[wpferguson]

I have several ideas about how the history stack could be improved, but the required changes might be too large for too small a benefit, though it would be worth discussing with other users on PIXLS

Open it as an RFC issue. The sheer volume of issues and PRs here have increased dramatically. Adding PIXLS threads with all of their opinions and noise to the dev workload will not be helpful.

I've pretty much given up on PIXLS because I don't have time to wade through all the crap. I read new posts, and reply when I'm tagged, but that's about it.

---

@lefth could you accomplish the same things with styles? I'm not talking about ease of use, just will styles do it?

[lefth]

@wpferguson Do you mean using a style instead of a snapshot to temporarily save a look? I don't think that would work because I'd still want to have the snapshot to do the comparison. And the style would definitely get out of sync with the snapshot.

If every snapshot contained a temporary style, it would work, but that seems redundant.

[wpferguson]

If every snapshot contained a temporary style, it would work, but that seems redundant

We have tools/experience to work with styles. I'm trying to find a supportable way to do what you want. You've found a way to use a feature in a way that was not intended and it's useful for you and possibly someone else. So now is the time to look at what you're doing, what tools/processes/hooks that we have available and try and figure out a way to implement that work flow that we can support (and explain... my head is still spinning from your earlier explanation 😄 )

Also maybe we identify why other solutions wont work such as multiple steps for a module in the history stack don't give you a clue as to what the difference is

EDIT: @lefth I'll try and work through your example to get a better understanding

[wpferguson]

So, is this what you are going for?

Each time you want a fresh start you just duplicate the neutral image. You can also duplicate one of the "processed" images and try different variations.

[lefth]

@wpferguson I take it snapshots were expected to be used only for the duration of a comparison, not for the duration of an edit?

Regarding your example, yes, that's the use case. I've also used this sort of method to compare sharpening techniques (effectiveness, noise, artifacts). But to clarify, I use snapshots in the early part of the workflow, but later I promote some snapshots to duplicates if I want to edit them. (At least, that's what I tried to do. There may have been an earlier version of this workflow that fully worked.)

Some benefits of snapshots compared to duplicates:

• They have a great UI for comparison.
• An inferior edit can be abandoned (load the better snapshot in one click).
• I like that snapshots are temporary. Despite the risk of relying on session snapshots, I don't want seven versions of a photo in my library. I like being forced to choose before the session is over.
• Creating a snapshot is cheap. There's no commitment. Creating a duplicate is slow, and requires cleanup later.
• When you load a snapshot, you instantly see the module states and parameters. I use this to see how the snapshot differs from the image I'm comparing it to. (What are those DorS parameters? Did I deactivate some contrast-related module?) I recognize someone could lose their image edit history this way and write an angry bug report.

So I see duplicates as a complement to snapshots, not an alternative.