[PhotoFlow] New feature in progress: tools editing mode


(Carmelo Dr Raw) #1

I am currently working on some usability improvements for the tools that require mouse interaction, like the crop tool.

Such tools in PhF have two “modes of operation”:

  • editing mode, in which the tool follows the mouse mouvements/clicks in the preview, and changes the result accordingly. In this case the preview might not match the final result - in the crop tool case, the preview shows the area which is to be removed with a darker color. There are usually also additional lines/areas drawn on the preview to guide the mouse interactions.
  • preview mode, in which the final output of a tool is always shown

Currently, tools enter in editing mode as soon as the corresponding layer is selected, and they switch to preview mode when selecting a different layer.
This means that there is no way to see the final output of an interactive tool as long as the corresponding layer is selected, which is quite annoying…

To improve the situation, I am introducing a new toggle button to switch ON/OFF the editing mode when a layer is selected. The toggling is also associated to a new CTRL+e keyboard shortcut for easier access.

Here are a couple of screenshots showing how the toggling works in the case of the crop tool.

Editing mode enabled (use button or CTRL+e for toggling):

Editing mode disabled (use button or CTRL+e for toggling):

The editing mode is enabled by default when a new layer is added, and is switched OFF automatically when a different layer is selected.

What do you think? Are you in favour of this new UI behaviour?


(Shreedhar Inamdar) #2

Idea is very good. Is it possible (from coding point of view) to have this behaviour automatically happening depending on the position of the cursor? For example, if one moves the cursor outside the preview window, editing mode is off and the moment we bring it in the preview window, the editing mode is on.
If this is possible then the workflow will be faster. If not, then what is suggested by you is fine.


(Carmelo Dr Raw) #3

What you suggest should be possible, though a bit harder to code. However, I am not in favour of this for performance reasons: whenever the editing mode is toggled, the entire preview has to be re-computed. If this re-computation is triggered by mouse mouvements, it might occur much more often than needed…


(Glenn Butcher) #4

You’re tugging at some of the reasons I designed rawproc the way I did. One of my thoughts was to have each tool in the chain store its latest transformation in the form of a result image, so adding a tool downstream only had to initially process its transform, and changes in mid-stream tools only had to instigate re-processing in downstream tools. This turns out to be challenging to implement, as it’s hard to trap all the add/select/delete sequences properly. Oh, and I do this at the expense of memory; rawproc is a real memory hog and I offer no apologies… :laughing:

Something I’m considering is to add what I call a “rate-adaptable” processing instigation. In this contrivance, I’d report the time it takes to do a tool’s initial processing, and if that time is lower than a settable threshold, the tool’s UI would switch from “process on mouse-up” to “process on mouse-move”. My motivation to do this is to be able to use smaller images to demonstrate the real-time effect of operations, particularly curves, in teaching image processing. For “real” image processing I wouldn’t particularly need it as i intimately understand the current processing impacts of UI operations (at the extreme, “don’t put in a denoise tool unless you REALLY mean it”).

I guess I don’t have much to offer specific to your current challenge, just perspective. As always, FWIW…


(Shreedhar Inamdar) #5

Yes. I thought that it would be demanding (from processing resources point of view) because I had noticed that in your first post, the histograms were changing depending on the crop mode! That means everything seems to be recalibrated. I will definitely welcome the addition of a new button and the keyboard shortcut. Cheers.


#6

What do you think? Are you in favour of this new UI behaviour?

Soundz good 2 me :fried_shrimp: :+1: :beer:


#7

@Carmelo_DrRaw It is a good fit to your existing interface.

– Unsure about the location of the edit icon. Users might not be able to find it or understand what it is for. Perhaps a big fat commit or confirm button would be better.

– Unsure about the CTRL+E toggle. My first instinct would be to hit Enter to commit and mouse click on the preview image to turn on editing mode.

Photoshop does that with its history. By default, it keeps all the intermediary steps and files but that eventually consumes all of your resources including hard drive space!