[Suggestion] Simplify Tone Equalizer

Yes, that would be enough. The main problem for me is not to know what’s outside the mask, but the fact that those points outside the mask end up generating a big spike on the edge that messes up the vertical scale of the histogram. Actually the UI is a bit misleading here because from it all points to the rigth are bunched on top of the right-most point of the mask, so one would expect this point to affect all of them (which of course if not how it works).

A “quick solution” (says somebody with zero knowledge of the code :wink:):

  • truncate the histogram at the edge of the mask, do not bunch out-of-range data on the first and last bin
  • (optionally) vertically scale the histogram according to only what’s inside the mask range
  • mark the existence of “many points outside range” by the orange bar

but thats not the darktable way - simply stuff at cost of control.
darktable is driven by those who wants the control they need and other tools doesn’t provide.
So simplifying stuff is ok, but not on cost of control. And the masking tab gives a whole bunch of control.
Crucially, the mask in the Tone Equalizer is an arbitrary element. There is no such thing as a general purpose mask.

I think I didn’t quite explain myself well.

And why would you have to touch the mask after generation with the current controls?

If my solution is viable, and the histogram is always perfectly spread out, these controls are superfuous, since their purpose is to spread the mask across 9EV nodes:

That’s only useful if you can decide to limit the mask. If I only have to correct part of the image (say the lighter parts) I do not care whether the shadows are all bunched up at the left side. I’m not going to touch them…

You are right, that’s what the white/black point sliders I was proposing would do. You could choose to exclude certain parts of the mask to work on highlights, shadows or midtones only:

Think of them as a way to zoom into the mask’s histogram, without changing its exposure or its contrast.

That, I doubt: there are a number of other controls in the masking tab, like what type of mask to generate, what estimator to use for pixel lightness, and some to steer mask generation.

Your proposal would replace/remove two out of 8 or 9 controls, some of which cannot be replaced by an automated procedure, like the luminance estimator you want to use. Same for most of the others: the setting to use is not purely technical but also depends on your interpretation of the image…

Once you remove the “unnecessary” sliders (this is all hypothetical), they could be moved to the other tabs no problem, and the masking tab could be removed.

but thats not the darktable way - simply stuff at cost of control.
darktable is driven by those who wants the control they need and other tools doesn’t provide.
So simplifying stuff is ok, but not on cost of control. And the masking tab gives a whole bunch of control.

I’m not advocating for removing any features. If my idea is doable, things would work the same, but once the mask is created to suit your needs, it would “just work”, without the need for compensating exposure or contrast, so less tabs and sliders. In fact, it would be easier to use, since you could watch the mask’s histogram while you adjust the controls.

What exactly do you think is the funtion of the exposure and contrast compensation sliders?
Your “black and white point sliders” would replace those two, and only those two. Just using another terminology…

But exactly this „mask is created and suit my need“ is done with the masking tab. No algo in the world can create a proper mask to match my need in a specific situation for an specific image…
Using a luma representation of the image as a mask is just one of several usecases…

1 Like

According to the manual they recenter and expand the mask’s histogram respectively (by changing its exposure and contrast). If we could zoom into said histogram, so that our 9 nodes affect the area we want to affect (or click on an eydropper, like in filmic), there would be no need for changing the mask’s exposure or contrast, and things would be pretty automatic. If you desire to zoom in further and work just on a portion of the histogram, you could do it with the black/white point sliders.

The advantage: exposure and contrast compensation seem to be difficult to control automatically so that the histogram spans the whole spread. My solution would in theory circumvent that problem, while retaining the ability to work on a specific range if you so desire.

The mask that suits your needs is done through the controls located in the masking tab at the moment. If some of those controls are superfluous (exposure, contrast, quantization), assuming my proposal is possible, they can be removed, and the remaining ones (the ones that actually create the mask you want) could be moved to the advanced tab, so you can monitor the changes on the actual histogram (and not the approximation we currently have on the masking tab).

This is supposed to be better in the upcoming 3.8, have you tried a master branch version?

No, I haven’t had the chance! What has changed?

The release notes say: * The automatic mask tuning has been improved in the tone equalizer module

1 Like

The main changes are discussed here, although the final implemention was delivered in a different PR:

1 Like

Two things that I would like to clarify to better use the Tone Eq would be one, the norm used. I have no idea other than cycling through them why I would use one over the other as a basis for constructing a mask…the current manual only offers this…

luminance estimator

Choose the method by which the luminance of a pixel will be estimated when mapping it to a mask intensity value (default RGB euclidean norm).

It might be nice to have just a few comments of what the overall impact of choosing one over the other might be as they produce widely different masks when you switch between them. If we have 5 or6 options we should be able to provide a concrete example or use case of why it exists and why you might think to use this over another…

Also, I think for a long time that while I understood that the mask histogram was not the same as the image histogram (early on I think many people equated the two) at the same time I was trying to get my mask spread across the full range as if it was and trying to adjust it to get some contrast in the mask that matched the brightness zones of the image so I could adjust these…but after revisiting the documentation it seems that this was not really a good mask. For example in an image where the foreground was dark and the sky was lighter if I wanted to simply lighten all of the foreground by the same amount and darken the sky a bit again I only need a mask that might actually look more like a gradient mask so that most of the dark pixels get the same adjustment ie are lightened the same and that the reverse is true for the sky and then it blends smoothly…in the past I would tweak the mask settings so that is almost looked like a monochrome version of the image thinking this was better for tonal adjustments but actually this is the thing the tone equalizer is trying to avoid… Perhaps I still don’t have it right but that is how I understand the documentation. I think the tone eq is amazing but I still think the mask is not well understood or controlled by many users… Any comments, corrections or explanations around this post are welcome for sure. I would love to use the Tone eq even better than I do now and I am sure many of you do. For context these comments are based on interpreting this section of the manual below…

It is important that the mask separates the image into regions of similar brightness, and that a suitable amount of blur is applied within those regions. This means that all of the pixels in each region will have their exposure adjusted similarly, without adversely affecting local contrast. Examine your image beforehand to identify which regions you wish to dodge and burn, and use the controls on the masking tab to ensure that those areas are reasonably separated in tone within the final mask. This will allow those regions to be adjusted independently.

2 Likes

Thank you. Looking forward to trying it out in the next release.

Reading through related issues on github, I found this one:

There @anon41087856 says the following:

[…] the contrast correction is meant to make the mask more manageable. So the contrast has to be set such that the filter behaves, it’s not for the filter to accommodate insane contrast settings. It’s a purely technical control that is only meant to push the filters in their sweet spot. If instead it makes them fail, then it’s ill-set. It’s not artistic, anyway it has no direct aesthetical effect on the picture at the end.

So from that I understand that

-The mask contrast is not artistic and has no effect on the final picture.
-It’s there to be able to make the mask more manageable.
-Push it too hard, and it will break the mask.

@anon41087856, what do you think? Does my idea from a few posts back make any sense?

There is no white and there is no black in a scene-referred pipeline. That kind of thinking applies only to a printing medium. In the pipeline, you have a range of light energies and no prior information on them, except how they look once they get projected onto your screen, which is unknown from the pixel algorithm. All we can do is to apply a gain (exposure compensation) and a fulcrumed gain (contrast compensation).

You got the sum-up right, but I don’t know what ideas you are referring to.

No. The radial-basis interpolation has 8 hard-set values for performance. Then, if we do that, copy-pasting presets becomes impossible. Finally, that requires running several pipelines computations (one for detection, one for actual processing), which is not allowed by the current pipeline design. That’s why any detection thing (spot WB, vertical/horizontal lines, etc.) needs a push on a button.


In any case, as a principle, I disregard anything that begins with “simplify”. What we are doing is not simple, the GUI should acknowledge that. Also, if it was simple, it would have been done already. I’m not known to be lazy and to pass on good opportunities to make things faster and easier, but sometimes you hit a good old technical wall that has no solution on paper. Like, in this case, predict how much contrast will be lost by applying a variance-thresholded edge-avoiding blur.

2 Likes

There is no white and there is no black in a scene-referred pipeline. That kind of thinking applies only to a printing medium. In the pipeline, you have a range of light energies and no prior information on them, except how they look once they get projected onto your screen, which is unknown from the pixel algorithm. All we can do is to apply a gain (exposure compensation) and a fulcrumed gain (contrast compensation).

Right, my bad. The names were poorly chosen, since we are in scene referred. I meant “white” as in the brightest value in the mask, and “black” as the lowest value in the mask. Since the guided filter reduces contrast, they are both probably going to be shown as shades of grey (unless the exposure is way out of what my screen can show and filmic is not activated, right?)

The question is: can we divide those 2.5EV equally into 9 nodes and have the module work properly?

No. The radial-basis interpolation has 8 hard-set values for performance. Then, if we do that, copy-pasting presets becomes impossible.

Bummer…If each of those hard-set nodes need to be 1EV apart instead of say 0.1EV or whatever the case may require, then my suggestion wouldn’t work.

What I don’t understand is why this would break copy-pasting presets. Leaving the hard set values aside for a moment, if you have 9 nodes spread out evenly throughout a histogram, as long as the brightest node matches the brightest level in the histogram, and the darkest node, the darkest, wouldn’t the effect translate perfectly between images? For example: if I increase the exposure of the third brightest node by 0.5EV, wouldn’t the effect be the same on the final image regardless of the dynamic range of the generated mask, assuming luminance estimator, preserve details, filter diffusion, smoothing diameter and edges refinement/feathering remain constant? What would change the final result would be if you alter any of those last five parameters, right?

Finally, that requires running several pipelines computations (one for detection, one for actual processing), which is not allowed by the current pipeline design. That’s why any detection thing (spot WB, vertical/horizontal lines, etc.) needs a push on a button.

I don’t mind pushing a button or moving a slider, or a couple of sliders. My issue with the exposure/contrast compensation, is that it is a bit of a guessing game. You press the button, and each time the result changes slightly, often not spreading your histogram very well across the nodes, so you have to go back and forth between tabs.

If exposure/contrast compensation are a bit fiddly to use, have the potential to screw up the guided filter at high values, and their goal is to spread the mask across the 9 nodes, wouldn’t it be easier (in an ideal scenario) to tell the module: these are the settings for the guided filter mask, dynamic range will be reduced accordingly, but this are the brightest and darkest levels in the mask, so please divide it evenly into 9 nodes.

In any case, as a principle, I disregard anything that begins with “simplify”. What we are doing is not simple, the GUI should acknowledge that. Also, if it was simple, it would have been done already. I’m not known to be lazy and to pass on good opportunities to make things faster and easier, but sometimes you hit a good old technical wall that has no solution on paper. Like, in this case, predict how much contrast will be lost by applying a variance-thresholded edge-avoiding blur.

I am sorry if I gave you the wrong impression. It’s hard to communicate the right tone through writing and english is not my first language. I chose this thread, since it had semi recent activity, and a lot of comments, but I didn’t pick the title. I know you are not doing simple stuff by any means, are lazy or don’t want to improve the tools you cleverly designed. My comments, opinions and mockups come from a place of admiration and respect for your work on darktable in the hopes that they might help any of you improve the tools we have. If this particular case can’t really be improved, I will still use the module. It’s not the end of the world, and what it allows us to do makes up for going back and forth between tabs and sliders.

Cheers!

Just my 2 cents since I also need to switch between the advanced and masking tab quite often with some pictures until the result is as I just need it.
What may help me in this situation would be some kind of direct interaction in the advanced view. I thought about the possibility to use the scroll-wheel plus accelerator here, like we have it in the mask definitions. e.g. scroll-wheel plus [shift] to shift the spectra left-right and scroll-wheel plus [ctrl] to stretch-compress the spectra. What do you think about this?

You can do that, at least with master (soon-to-be 3.8):

3 Likes

This is actually great! I didn’t realise you could map those sliders to shortcuts and use them from another tab. I set mine to:

Ctrl+Left = decrease exposure
Ctrl+Right = increase exposure
Ctrl+Up = increase contrast
Ctrl+Down = decrease contrast

So much easier to tweak the mask once you are able to look at its histogram!

I actually can’t believe how well this works once I got it set up this way. Looking at the histogram is key when adjusting the mask’s exposure and contrast. Would it then be crazy to have a true histogram in the masking tab (however short vertically) instead of a gray bar under the “mask post processing” label that displays a representation of the middle 80% of the histogram?

On another note, I don’t know if this has been changed in 3.8, but In 3.6 the sliders for the mask exposure/contrast compensation go from -4 to +4EV. It seems a little extreme for contrast, since after a few tests I haven’t needed to push it above .4EV. Perhaps to be safe in case someone wants to work only on a certain part of the image (highlights, midtones, shadows) it can have 1-2EV of room, but isn’t 4EV in either direction too much? Also, since contrast compensation is only used in the case of a guided filter, and the sliders always decrease the mask’s contrast, is there a need to let the contrast compensation slider go into negative values?

You can actually see it in the mask it just takes getting used to…if its black its off the left edge, if its extreme white its off the right edge and all tones in the region get the same ev adjustment…so if the areas you want to impact are shades of grey you are good…then its just how you blur, contrast, refine the edges of those grey regions…in that way the mask actually give you more information than the histogram as you don’t know where the bright and darker parts of the masking are from looking at the histogram…I guess you can match them up with the cursor indicator but the mask is better for an overall impression…

You are right, of course. A histogram is just a tool to help us make decisions, and if we want to target a specific area of the image, it won’t help us, since it won’t tell us if the blur is affecting the areas we need it to affect. However look at the following two screenshots with same settings of the same picture:

Screenshot_20211201_084308

Screenshot_20211201_084340

If you look at the grey bar in the masking tab, I’d think the histogram range is very narrow, and only spans three nodes at the most, as well as being all the way to the right side. In reality, the histogram is quite centered, and I’m able to affect the mask with at least 6 nodes before even touching the exposure/contrast compensation sliders. That’s what I’m talking about. Besides having the blur where and how we need it in the mask, I find it important to know how many nodes it spans, and the current grey bar doesn’t seem to be a very reliable tool, but perhaps I’m missing something.