Not quite…but as far as I understand @MikeR , his request is to get an action log&undo instead of an edit log&undo. An action log&undo can act on every action the user takes, no matter if that action is considered to be an edit, select, flip, tag or journey to the moon.
Whatever the log&undo does, it will not suit all users. Featuring both modes with a preference setting for us to choose from could make more users happy and keep the decelopers busy.
m-photo
( Marc (macOS Sonoma on MBP16" Intel))
45
For sure the « undo » mechanism could be improved.
We are not talking anymore about a simple raw converter (the editing history of a single image) but a whole « PhotoLAB(oratory) » and the undos should be well thought.
They are. They change the output file. Some of them don’t change the pixels. But they change the output file.
DXO agrees because whenever these changes are made to an exported image, the green check mark turns orange, and the image is marked as “modified since export”.
Can we stop bothering about what an edit is or not? I get the feeling that this does not realy help to clarify the request.
As far as I understand your text, @MikeR , you’d like to get an undo that undoes any action you do in PhotoLab, including but not limited to edits, selects, tags, flips, rates etc. Right?
Basically yes with two notes:
Actions like moving the noise reduction loupe, or changing the image display zoom, toggling on and off gamut warnings…. Etc… these things are display only and they don’t affect the output. So they don’t go in the history. I know George disagrees, but in my mind, any action that changes an exported image to a “modified after export” image, changing its check mark from green to orange should be included.
Also the note about selecting is that when any other action is recorded the selection is also recorded… but selecting by itself isn’t a recordable action. I.e. if I select image ABC and make an edit those three edits are one “action” from the purposes of the undo history even though those three edits are each associated with their own image’s advanced history. But making the selection is not. If I select A, then I select ABC, then I select B, all without making any edits, then those selections don’t need to be remembered.
…this means that logging is conditional in the case of selects: Selects must be logged if (or as soon as) they are followed by something that is unconditionally logged. Unconditional logging is easier to program and understand…and unconditional logging of selects makes the log a true action log, and it does not hurt anyway imo.
Actually we are getting into the details, but I think this can be implemented very simply. All that really needs to be done is:
add the other change elements to the advanced history. Anything that changes exported to changed since export creates an item in the advanced history.
create a global integer index that increments each time any change is made.
for each entry in an image’s advanced history, attach the global index value to the change. If multiple images are selected, and a change is made, all of those advanced edits get the same index value.
That’s all it takes to capture the required information.
Then when you undo, you look through all the images and step back in each images history that matches the index value. And then you select those images and decrement the index.
When you undo again, you step back in each images history that matches the index value. And then you select those images and decrement the index.
There are a few other fine details to be worked out but that’s mainly how it works.
For people like George who only edit single images the only implication is if he presses undo after switching to a different image than his last edit, then the selection switches back to that last image and the most recent change is stepped back. Of course he can redo…. Or he can select the appropriate step in his image history instead.
Here is the difference between the Mac and Windows versions of Photolab 5 regarding how edits can be undone. The way Windows works is preferable (for myself at least) - the Mac implementation of Undo (when undoing an accidental edit to a selection of images, then unselecting them, then reselecting them to try and bulk Undo) has cost me a lot of time in the past.
I haven’t read all the posts in this thread so I’m not 100% familiar with what @MikeR is suggesting needs fixing, but this is my observation…
That’s incorrect; Undo (Ctrl+Z on Windows) will reverse the action for all selected images … In your case, you had probably de-selected all but one image.
I just ran a quick experiment in macOS Finder. I selected multiple files/folders and then hit Cmd+Z. This does not undo the selection - it undid the deletion of a file in another folder, which was the last action I performed before making the selection.
So, it seems that making and modifying a selection is not a standard undoable action in the basic file system, so I wouldn’t expect selection to be undoable in any app.
Windows.
Select A,B and C.
Set exposure at minimum. A,B and C are set to exposure -4.
Select B. Set exposure maximum. Only B is set to exposure +4
Select A,B and C. Ctrl-Z undoes the last edit in the selected files. A and C are set to exposure 0 and B is set to exposure -4.
In windows too. I never knew about this, using CTRL-Z in the file browser. The same as in PL. A selection is not to be considered as an edit and therefore not to be registered as an edit in any way.
Mac
Select A,B and C.
Set exposure at minimum. A,B and C are set to exposure -4.
Select B. Set exposure maximum. Only B is set to exposure +4
Select A,B and C. Ctrl-Z does nothing apart from bleep.
Whether I select one image or multiple, changing the selection away to another image and coming back to the original selection effectively purges the undo stack.