darktable-org / darktable

darktable is an open source photography workflow application and raw developer
https://www.darktable.org
GNU General Public License v3.0
9.77k stars 1.14k forks source link

Some thoughts on improving the Tone Equalizer UI #17287

Open wilecoyote2015 opened 3 months ago

wilecoyote2015 commented 3 months ago

Hi all! I'd like to exchange / contribute some opinions on the usability of the Tone Equalizer module. I use the module quite often and noticed some issues regarding the Interface and UX that have grown quite annoying for me over time. As functionality and concept of the tone equalizer is awesome, I'd love it to feature streamlined and easy UX. In the following, I describe the issues and ideas for improvement.

Merging masking and advanced tabs

This is basically https://github.com/aurelienpierreeng/ansel/issues/134 When working with photos, I have to fine-tune / adjust the mask for almost every image. The process is quite laborious:

  1. switch to the maskng tab
  2. turn on mask display because the mask posprocessing range display does not provide something like a histogram.
  3. fiddle with the exposure and contrast compensation
  4. switch back to the advanced tab and try if it works well. if not, repeat...

Merging the advanced and masking tabs would provide two benefits:

  1. Adjustment requires less steps
  2. THe histogram in the advanced tab can be used to assess the mask's distribution and directly enables seeing the effects of mask adjustment with regard to the equalizer controls you tune it for.

Replacing mask exposure and contrast compensation by min / max points and maybe add some gamma-like parameter

Basically, exposure and contrast do some linear tranformation of the mask values, right? But as a user, I am most interested in spreading the mask's values from black to white without over- or underexposing. So I'll basically do some kind of histogram equalization. This is difficult using exposure and contrast because both sliders work interdependently with regard to the resulting min and max values.

So, why not introduce white and black relative exposure sliders like in the filmic rgb module? This would be consistend UI with filmic and it enables the user to control the mask's range easily by setting the min and max luminance values. In addition, something like a gamma parameter or a gray value like in rgb levels would allow further adjustment of the mask's value distribution. This would also be consistent with rgb levels UI and intuitive.

Advanced tab: dragging one node should only affect one node

As A user, I want to have control over my adjustments. I want to make fine andjustments in a controlled manner. Hence, I want to change one node and do not want to drag neigboring nodes along. Currently, based on the curve smoothing parameter, neighboring nodes are dragged when dragging one node. Personally, this drives me mad.

See, for example, many parametric equalizer UIs: There, the nodes can be dragged independently. The effect on the equalizer transmission curve is visualized. Here, the nodes are not necessarily on the line due to the spline interpolation, but this is understandable for the user, as they see that the curve is smoothed and dragging the nodes affects.

For some reason, exactly this behavior can be achieved using the simple tab. But then, visual feedback and control using the histogram view is lost. What is the intention of this UX design? I guess there is some benefit of having the magnetic / smoothed interaction with nodes in the advanced tab, but unfortunately, I don't see it. There are not that many nodes and adjusting each one independently in the advanced tab would quick and efficient for achieving the desired result as quickly and with as much control as possible. What do you think? Does the current smoothed behavior provide real benefits for you?

Use some spline interpolation with finite support

This may be a controverse point. As far as I understand the documentation, the curve interpolation is some gaussian and hence has infinite support. In words, if the last node is moved, this will also affect the curve around the first node. According to the documentation, this is by design, following the assumption that the provided smooth modification of gradients is the most important design goal for interpolation.

But is this assumption valid? Personally, I want to do smooth, but local changes in the gradiation. The global smoothing leads to artigacts like oscillations on strong adjustments, regardless of the choice of the corve smoothing parameter. Wouldn't finite-support interpolation like quadratic or cubic B-Splines provide more precise control while still being reasonably smooth?

[EDIT] Update Preview in realtime when dragging nodes in advanced tab

In the simple tab, dragging the sliders updates the preview in realtime. In the advanced tab, the preview is only recomputed after mouse release and not while dragging. This makes adjustment more cumbersome than necessary in my opinion and it is also inconsistent UX regarding simple and advanced tab.

[EDIT] Option to increase equalization range beyond +-2EV

In some Situations, the fixed range of +- 2 EV is quite limiting. An option to increase the range would be very useful.

What do you think about those points? I'd love to hear some opinions, as I am not sure whether other users / devs share some of my struggles with the Tone EQ UI.

da-phil commented 3 months ago

I remember a vivid discussion about exactly this feature, either in the github issues or in the forum at pixls.us.

da-phil commented 3 months ago

Found it here: https://discuss.pixls.us/t/should-the-mask-adjustments-in-tone-equalizer-be-improved/41374 There are also concrete UI suggestions later in the thread. Maybe continue the discussion there?

wpferguson commented 3 months ago

But as a user, I am most interested in spreading the mask's values from black to white without over- or underexposing.

As a user I sometimes want to only affect the lightest or darkest part of of the image so I move and adjust the mask to that section.

Have you watched Boris's videos on tone equalizer? He has some use cases that broadened my horizons with respect to what tone equalizer is capable of.

I don't want to lose features (flexibility and capability) in the interests of making tone equalizer easier to use, especially when ease of use is often in the eyes of the beholder and their workflow.

For my part I find tone equalizer quick and easy to use. Mostly I use presets and the masking isn't an issue unless I didn't do a good job in camera or got a really challenging scene. For the cases where I want to spread the mask over the entire range I have a lua script that uses the auto pickers to accomplish it. It's good for 90+% of the images I use it on, so every once in awhile I have to do it by hand.

jenshannoschwalm commented 3 months ago

Not going into detail - again, this has been explained multiple times here and on pixls - the nodes and the maths behind the simple and advanced UI are identical, they use an identical spline curve.

Also, it does matter how the nodes are positioned and the spline function is calculated as the pixel calculating math depends on it. So it's not about implementing a UI mockup.

BTW this is also noteworthy for the nodes in the color equalizer ...

So any change in the UI must be done with above considered.

marc-fouquet commented 2 months ago

Regarding exposure compensation / contrast compensation

I have not been using Darktable for that long, but my experience is this:

How about an option to set those two magic wands to "autopilot", so they automatically trigger whenever mask exposure and contrast need to be updated?

In my opinion, merging the advanced and masking tabs would clutter the UI quite a bit. The masking tab contains a lot of complicated options that can overwhelm users who basically just want simple sliders for changing the exposure of shadows/highlights while preserving local contrast (like they exist in most other RAW development software). If the tone equalizer UI is changed, the goal should be to simplify things for new users and reduce friction for existing users.

Is it frequently the case that the magic wands do not work properly, so it is necessary to manually tweak exposure compensation / contrast compensation?

Regarding the mask

Another thought (on a slight detour): There are other masks in darktable that have the (in my opinion) undesirable property of changing the selected pixels when an upstream module changes the image. Examples are parameteric masks and the shadow/midtone/highlight-masks in color balance RGB. Wouldn't it be better to calculate a stable version of the image once (early in the pipeline) and always use this representation for all masking?

Final thought about the UI

Finally I wonder if anyone really uses the "Simple" tab in the tone equalizer. Contrast- and Color-Equalizer don't have a similar tab. The Tone Equalizer module could be streamlined by removing it.

marc-fouquet commented 2 months ago

I looked a bit at the source code and I wonder if this contrast boost and exposure boost is necessary at all.

As far as I understand it, the current process is this:

Step 1: Either get user input for contrast boost and exposure boost or use the automatic estimator. But since the estimator does not know, what will happen in step 3, this involves guesswork. Step 2: Convert the image to Black & White. At this point the contrast boost and exposure boost is applied. Step 3: Blur the B&W representation of the image, which changes exposure and contrast in an unpredictable way.

These are all 32 bit float calculations that should have enough precision to do it the other way round:

Step 1: Convert the image to B&W without applying anything special. Step 2: Blur the B&W representation. Step 3: Scale the resulting mask to the desired dynamic range.

This would involve no guesswork, so the result should be perfect every time. Or am I missing something here?

jenshannoschwalm commented 2 months ago

If you know what you want you would have to go into coding and see how that works out. Currently i don't think there is a big desire from any dev to get into discussing ideas and details that don't seem to fit into implementation without any code to test/review. So feel free to start developing dt and contribute your work to the project :-)

Donatzsky commented 2 months ago

This would involve no guesswork, so the result should be perfect every time. Or am I missing something here?

I haven't considered it very thoroughly, but I suspect that you are indeed missing something. The first question to answer would be if your simplified approach gives the same result. At first glance, it seems to me that it wouldn't. And if the results are not the same, would it be an improvement.

github-actions[bot] commented 2 weeks ago

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.