Undo just goes back one step in the history of the image you’re currently viewing. This is not “undo” this is “step backward”.
Let me explain by way of a few examples why “step backward” in the currently selected image history is not “undo.”
Both of these happened to me in the last 15 minutes, by the way…
I have 250 images color tagged. (Thanks for color tags… I use them all the time.) Because of some mistake I made with the filter I was using. (I’ve complained about the filter elsewhere, but that’s a different story.) I mistakenly selected all 250 images and set the color tag to Red. Oops… Let me press Control-Z to undo that. Oh yeah, control-Z is step backward. That just undid the last adjustment on the image that I had selected after I deselected all 250 images. There is NO way to undo multiple color tag assignments in DXO. In other words “This command cannot be undone.” but there is no warning.
Here’s another one. Selected all images to set the white balance on the whole batch. I typically do this after checking the “as shot” for a number of images as I edit them, Then use the picker on a few spots… Then select all and manually set the white balance temp and tint. And then, because I had the next image already shown, I started to do the specific crop/straighten for that image. And I changed all the images in the set. Ok now try to undo that? As far as I can tell, I have to undo two step in each image, one image at a time. This is lunacy. Fortunately, I was only about 10 images in when this happened.
How about one undo that undoes multiple changes to multiple images if multiple images were selected when some step was carried out. This is what Undo should be… Not “step backward.”
Oh and please don’t tell me “you should back up your database.” (you know who you are. ) Don’t make excuses. Undo should work…
Oh. And color label changes aren’t even in the image history… This is also broken. It’s a change to the image that sets the “modified since last export” flag. (as it should since the color tag is in the exported metadata if all metadata is included.)
Color tag and metadata changes should create an entry in the history.
Apart from that, I agree that undo should be able to undo the last action within the scope (e.g. selected images) of when it was applied.
In order to handle your situation that includes (de-) selection, such steps should also be logged in the history, together with the respective scope. Sidenote: Lightroom started to include most user actions a few versions ago. I did not like it at first and still don’t like it occasionally. One size doesn’t fit all after all…
I think the undo function is undoing the edits, selecting is not an edit. If one wants undoing being able to be done on a selecting in the past then that includes that that selecting should be registered somewhere.
In both of your examples, Mike - the resulting undo-able actions came about because (without realising, or forgetting) you had multiple images selected when you applied the action.
So (without meaning to suggest that your proposal is not valid) , another way to address your request would be to have an “Are you sure?” safety-check in-place when an action is about to be applied to more than (say) 2 images … There’s been a long-standing request for exactly that.
The current state of logging was set up by DxO and some makes sense (to a bunch of users) and some does not (to a different bunch of users)… So what should we do or wish for?
Proposal
add user selectable levels (granularity) of logging and respective undoing (undoing backtracks the log, and if flipping and selecting an image is in the log, undo covers it)
@George, my point is to widen the scope of logging and allowing the user to narrow logging down again by setting respective preferences.
I care about giving users a reasonable choice and the only baseline for what is reasonable or not is the users need or intention, no matter if something is an edit or not.
Depending on selected granularity of logging and therefore undoing, the log can be an edit log or an action log as outlined by @Joanna in her post above…or anything in between.
There should be a separate “action stack” which becomes the undo stack.
So when I select “Undo”, PL knows which images were selected and what was done to them.
I’m not suggesting selection and deselection itself should be logged in this second stack. However the active selection when any command that changes images should be logged with the change in the “undo stack”. If I “undo”, then the selextion should change to the last selection where any edits were done and those edits should be undone.
I also agree with the “simplification” of the history and it should apply to the undo stack as well. By simplification I mean only the idea of multiple edits to the same adjustment. I.e. if I click the up arrow 5 times and then click the down arrow 2 times, then the history of those 7 clicks should result in a single entry of +3 for that control.
If I want to step back in history. I can use the history control…. If I want to “undo”, then PL should use the undo stack to know what selections were active.
And yes, of course image flipping and other adjustments mentioned should be included as well.
You don’t export a jpg, you export as jpg. Jpg is a diskfile containing a RGB image in a certain compression.
When loading a jpg it’s decompressed and stored in memory in a dedicated place. The transport starts from a certain position, let’s say x-left,y-top and is stored in memory starting at position x-left,y-top. The disk file, jpg, tiff raw, can have an orientation tag telling the program to start somewhere else. In that case it might start at x-bottom, y-top.
Saving an image can be done in the way you see the image on your monitor with the orientation tag specifying don’t change this and start at the default position. Or it can be saved in the original format with the orientation tag set to a certain value. In that case the program that reads it again is responsible for the right orientation.
No editing involved.
No. You’re missing the point. Whether flipping is done by a flag in the metadata or done by rewriting the raster image data is completely irrelevant.
In the simplest way, if I export one raw image to JPG without flipping and the same image with flipping, and I upload those two JPGs to Instagram, one is flipped and the other isn’t.
This is something that should be in the edit history. I can’t even understand why we are arguing about this!!??!?
Back to the topic at hand, thinking about this a little more, the undo stack I’m talking about is really a simple thing…. Each entry on the stack only needs to contain a list of images and perhaps the current filter state. When you “undo” PL simply goes back one step in the image history for each image in the undo image list, and then selects all of those images if they aren’t already selected. (Remembering the filter state is important because the images should actually be selectable so you can actually see what images you just undid the last operation on.)
Actually, I suspect not (easy to implement) - Largely due to the ongoing debate that would ensue regarding which actions should, versus shouldn’t, be able to be undone … as can be seen above !
@MikeR I am sorry if you feel you/everyone is being nagged about backing up the database but it is a useful thing to do, i.e. it provides options.
But in this case backing up the DOPs and keeping a reversible DOP history would be way more useful and a lot simpler to implement, i.e. trivial with respect to creating them but a potential nightmare for the user to navigate, i.e. a potential cornucopia of options but how do you present them so the user can determine the correct point in history and potentially expensive on storage.
But this doesn’t need to be a “forever” thing, i.e. there could be a user selectable limit on such an activity or the user could take a checkpoint (and select how many checkpoints should be mainntained or DxPL could decide that all group actions automatically invoke a checkpoint or …
So taking @John-M’s suggestion with respect to a warning
my “conjecture” about retaining/maintaining a DOP history, with “simple” issues about how you (the user) manages/navigates such a history we have
Windows users are still waiting for the retention of editing history across a DxPL(Win) restart but some might want to continue with the current lack of such a history (having the option to retain the edit history is long overdue)
I absolutely “hate” having to answer the export “unique” versus “Overwrite” question every single time DxPL detects the issue, I always want “unique” as the default for safety because I have other means for deleting the “duplicates”. So I want an option to select and retain “Unique” and never be asked the question again but other users might want…
@John-M would like DxPL to warn on activities involving multiple images, others may want the current “silence” to be maintained,
@platypus wants user selectable granularity of logging and associated reversibility of actions.
Users want customisable keyboard options.
If the notion of preserving DOPs was actually sensible users would want to be able to control when and where the DOP history was preserved and if it was ever used at all for them.
Basically we need more options to allow better control of our workflow, it does increase the issues of testing and troubleshooting an individual users “problems” but … this is 2023 after all!
I’m ok with having a debate about which adjustments that affect the output file by way of changing the image data or changing the metadata (including metadata that instructs how the image is to be displayed). But that’s really a separate discussion.
Currently the tool doesn’t have a proper undo function… and it should have one.
In my mind the only actions that shouldn’t be recorded as separate steps in an undo history are things like changing the display zoom for the screen display, panning the image on the screen, changing the DeepPRIME loupe location, changing which adjustment tab is showing, selecting another photo, etc… these are user interface things.
A list of 250 images added to the stack for each edit on all 250 pics. Anyway this is easy for a computer and don’t worry, not much memory. There are other ways to implement it as well, such as adding a step number behind the scenes to each history entry in memory that would only add 2 bytes of memory per image per history step. This can all be done with a few hundred kilobytes of RAM.
) Don’t make excuses. Undo should work…
