Bug 128377

I don't like very much effect of auto-level in digiKam but: this is the way other  FOSS tools are   doing it (eg. GIMP). I think bug report needs reformulation.

BTW why all FOSS image manipulation programs are using Luminance as main channel in histogram instead of Photoshop combined RGB?

Mik,

This is duing of the method used to compute histogram value. Look here :

http://websvn.kde.org/branches/extragear/kde3/graphics/digikam/libs/histogram/imagehistogram.cpp?revision=670778&view=markup

.. in void ImageHistogram::calcHistogramValues() method. This code come from gimp histogram algorithm. It compute the luminance of image.

If you have the code to compute the combined RGB, let's me here...

Gilles

Matthias,

Why, both histogram are a little bit different. Because the target histogram is computed using preview on screen which is smaller than original, not the full image as well. The reason is simple the : performance.

Histogram is a guide here...

The auto-levels always give the best result for me in 90% of case. Try to compare all others auto-color adjustment tools, and you will see what i mean.

Code come from the gimp...

Gilles Caulier

Closing 150647 (? - already forgot number) I noticed problem mentioned by Matthias in first paragraph. Differences in histograms can be dramatic. I will attach example. And I think they are overstated. I made experiments on several images and when doing resize histograms can be different but in digiKam this difference is very big.

Created attachment 23976 [details]
example of mismatched histograms

I understand upper histogram shows preview histogram and lower is histogram of
original.

Note that upper histogram indicates there is room to stretch into black. When
going with its hints user can create significant underexposure.

Returning to auto-level...

I was wrong with Photoshop. It does a-l similarly to digiKam but in less agressive method which IMO gives slightly better results. I uploaded 3 images:

http://www.witkacy.hg.pl/auto-level/Pa.jpg   -> original
http://www.witkacy.hg.pl/auto-level/Pd.jpg   -> a-l in digiKam
http://www.witkacy.hg.pl/auto-level/Pp.jpg   -> a-l in Photoshop *cough* 4.0

Check underexposed areas and they are smaller in PS. Also add auto levelling in levels dialog and you can see how aggressive it is clipping big amounts of channels.

For comparison

Manual correction only of luminosity channel:
http://www.witkacy.hg.pl/auto-level/Pl.jpg

The most subtle correction (that was it I was speaking about, my mistake), using levels tool of Photoshop in RGB "channel": 
http://www.witkacy.hg.pl/auto-level/Pr.jpg

My simulation of that effect in digiKam. This is done by manually detecting lowest level of color and setting this on all channels (apart from luminosity) and doing the same for high level, in case of this image it was 18-249 range. There were small differences with PS, Pr.jpg was done with 18-247:
http://www.witkacy.hg.pl/auto-level/Ps.jpg

So, after more all these tests my conclusion. Auto-level is good - this point is invalid. PS a-l is less aggressive but this may be acquired taste - although PS set standards in this field.

But what would be valuable addition to digiKam is possibility to act on combined channels. At the moment you can only view them in histogram but you have to operate on each one separately which is PITA. Another practical reason. Most new people in digiKam will have some background in Adobe tools, even if not directly at least indirectly because 99% of books about photo correction are describing PS tools. This wish will apply to AdjustLevels and AdjustCurves tools.

This is how auto-level works. PS gives less aggressive results but they are almost identical. I think adding some special cases of levelling: act only on luminosity, act on combined channels etc. may be task for scripting but most important thing is: digiKam works OK in that case.

Hello *, thanks for the respond.

About problem 1: This seems to be performance related. If using the preview image as histogram source is the only possible way (performace wise) I'm fine with it. But maybe it's possible to precompute one R, one G and one B histogram from the full image (don't know how long it takes, but should be fast) and use this as base for the GUI. Changing the sliders would then only stretch or compress the precomputed histogram data and would not require to re-create the histogram.

About problem 2:
Regarding the auto-function I would not look at other programs but at the users. I think what most of the users most often want is a feature to stretch the contrast of an image. This means:
* No visible change to the colour, only luminance (I know about the slight differences between RGV vs. LAB)  (an image of a green plant should remain green and should not become grey)
* No highlight or shadow clipping.

Therefore one single multiplication factor and one substraction factor should be computed for all three RGB channels:
 Substraction_factor = min(min(R), min(G), min(B))
 multiplication factor = 255/max(max(R - substraction_factor), max(R - substraction_factor), max(B - substraction_factor)) (for 8 bit per channel)
==> new_pixel_value = (old_pixel_value-substraction_factor)*multiplication_factor (same factors for all channels).

Best regards,
   Matthias

Hello,
I had a look at digikam 0.9.3 again.

Some more comments about problem 1:
* For usability you should name the two histograms (e.g. "original" and "new")
 In Digicam 0.9.3 users can only guess what they mean.
* The unnamed (please add a name to it) button seems to change the pixel values internally. So it's impossible to change the values to slightly less contrast once one has clicked onto the auto-button. That's bad. It would be better to only adjust the sliders (and the image correspondingly) so that users can see on the sliders what the auto-button does and can fine tune black- and white-point.
* The auto-function should not do something that is impossible to do manually in this dialog - e.g. change the colors. That's another reason that the auto-function should use the same values for all color channels.

Best regards,
  Matthias

> About problem 1: This seems to be performance related. If using the
> preview image as histogram source is the only possible way (performace
> wise) I'm fine with it. But maybe it's possible to precompute one R, one
> G and one B histogram from the full image (don't know how long it takes,
> but should be fast) and use this as base for the GUI. Changing the
> sliders would then only stretch or compress the precomputed histogram
> data and would not require to re-create the histogram.


Fine by me. Current situation is wrong. It may lead to some serious over
steering of corrected image. Don't understand me wrong - two histograms
is great idea and I use them very often but by reading bug report about
mismatched versions I looked deeper into results and was horrified.

> About problem 2:
> Regarding the auto-function I would not look at other programs but at
> the users. 


Definitely don't agree. Current behaviour is standard. Auto-level is
widely understood as "stretching of each RGB channel separately" and by
looking on Web it is known that this operation can change temperature of
image. If anything introduce new auto-tools: stretching of luminance,
"combined stretching" (treating of RGB as one), but don't change essence
of auto-level tool. The only acceptable correction is removal of
shadow/highlight clipping although this action is advised to make colors
more vivid. But IMO auto tools should be as less intrusive as possible.

> I think what most of the users most often want is a feature
> to stretch the contrast of an image. This means: * No visible change to
> the colour, only luminance (I know about the slight differences between
> RGV vs. LAB)  (an image of a green plant should remain green and should
> not become grey) * No highlight or shadow clipping.
>
> Therefore one single multiplication factor and one substraction factor
> should be computed for all three RGB channels: Substraction_factor =
> min(min(R), min(G), min(B))
>  multiplication factor = 255/max(max(R - substraction_factor), max(R -
> substraction_factor), max(B - substraction_factor)) (for 8 bit per
> channel) ==> new_pixel_value =
> (old_pixel_value-substraction_factor)*multiplication_factor (same
> factors for all channels).


Yes, but it should be introduced as new auto tool, not replacing current
auto-level action.

Let's me comment point #1 :

the original histogram is _always_ computed from _original_ image, never from preview. There is no performance problem here, because original histogram is always computed one time, at plugin startup...

The only histogram which is computed in live is about target image, and of course for performance reason. Computing full target image histogram is a non-sence : this require to render all color changes to original image and compute histogram as well. For large image, this will take a time and plugin will not be suitable duing time latencies (i'm sure, i have verified this point when i have developped DigikamImagePlugins in the past (:=)))

But, there is one point which can be improved here : all Color correction tools (CurvesAdjust, HistogramAdjust, WhiteBalance, ColorMixer, etc...) render target image on main digiKam thread not using a separated thread as all others image plugins (SharpnessEditor, Restoration, etc...). If we use multithreading here, render can be forked to another cpu and plugins can be more suitable in live, but this will not work better with mono-cpu computers.

Note : Unforget than Target Histogram computed from preview image is just a guide to help photographer.

Gilles Caulier

> Definitely don't agree. Current behaviour is standard. Auto-level is
> widely understood as "stretching of each RGB channel separately"

Fine, but at least this tiny "auto-button" should get a label so that users know what this button does.

> and by
> looking on Web it is known that this operation can change temperature of
> image. If anything introduce new auto-tools: stretching of luminance,
> "combined stretching" (treating of RGB as one),

This new function (defined as in comment #8) could be named "stretch contrast" or "auto contrast" (e.g. as in Picasa). Then it is also clear what it will do: Stretch the contrast in the same way as if the user adjusted the luminance slider manually.

> but don't change essence of auto-level tool.

OK, but does it really have a use case? Changing color temperature is probably better done in the white balance tool. Adjusting a too dark or too light photo can be done with a auto-stretch-contrast function but not with the current auto-function as this function often creates wrong colors. So what's the typical use case of the current auto-stretch-rgb-function?

> The only acceptable correction is removal of
> shadow/highlight clipping

From an photographers point of view that's not only acceptable but very important. It's not nice if you first try hard to avoid highlight clipping and then an auto-function deliberately creates highlight/shadow clipping.


> although this action is advised to make colors
> more vivid.

There are much better ways to make colors more vivid than highlight/shadow clipping. And making colors more vivid seems to fit better in the "hue/saturation/lightness" tool than in the basic "levels adjust" tool.

I think it's important that users understand what an automatic function does - otherwise nobody will use it. Therefore it would be much better if the auto (and the new auto-contrast) function would change the sliders, not the data of the source image (and the source-histogram). Then everybody could see clearly that the current auto-color function adjusts the sliders of the three colour channels while the (new) auto-contrast function only changes the slider of the luminance channel. And if someone likes some small degree of highlight clipping then he could just move the slider a little bit further.


Best regards,
  Matthias

Dear Gilles,

> the original histogram is _always_ computed from _original_ image, never from 
> preview. There is no performance problem here, because original histogram is 
> always computed one time, at plugin startup...

OK, no comments up to here.

> The only histogram which is computed in live is about target image,
> and of course for performance reason. Computing full target image 
> histogram is a non-sence: this require to render all color changes [...]

I think it should be possible to refresh the target histogram (based on the original! image) with more than 30fps. So you can have live display of the correct(!) target histogram.
How to do this?
1. calculate the original histogram (already done during plugin start-up as you wrote above)
2. copy the original histogram data (256 values * 3 color channels) into the target histogram data structure and display the "target"-histogram.
3. Every time the user changes a slider, recalculate the target histogram.
  To do this, there is no need to analyze the original or the preview image, just use the original histogram data (256 values * 3 color channels), apply the color transformation on it and display the histogram.

With this simple approach you can have a live histogram that changes while the user is moving the sliders around. AND it is correct and does not differ from the original histogram.

Hope this helps,
  Matthias

> Note : Unforget than Target Histogram computed from preview image is just a 
> guide to help photographer.

If the guide does not correctly show where the highlights and the shadows end, it is not a help to the photographer but the contrary.
 

To Matthias, comment #13 :

>I think it should be possible to refresh the target histogram (based on the >original! image) with more than 30fps. So you can have live display of the <correct(!) target histogram.
>How to do this?
>1. calculate the original histogram (already done during plugin start-up as you >wrote above)
>2. copy the original histogram data (256 values * 3 color channels) into the >target histogram data structure and display the "target"-histogram.
>3. Every time the user changes a slider, recalculate the target histogram.
>  To do this, there is no need to analyze the original or the preview image, >just use the original histogram data (256 values * 3 color channels), apply the >color transformation on it and display the histogram. 

(:=))) ==> it's already how is sone the current implementation...

Gilles Caulier

Am Dienstag 25 März 2008 schrieb Gilles Caulier:
[bugs.kde.org quoted mail]

Then I don't understand why the original and the target histogramms differ 
in shape (quite stongly). It seems (and you write) that you don't use the 
original histogram for the "live" histogram. That's an important difference 
to the above mentioned high level algorithm and quite a usability problem.

If you really think that you need two histograms (for me one histogram (as 
in Gimp, Picasa, Bibble) seems to be more cleanly designed), please make 
sure that both of them are accurate.

Best Regards,
  Matthias

Best regards,
  Matthias

> > Definitely don't agree. Current behaviour is standard. Auto-level is
> > widely understood as "stretching of each RGB channel separately"
>
> Fine, but at least this tiny "auto-button" should get a label so that
> users know what this button does.

If you think about gear button it has ToolTip and WhatsThis help. Worded
label wouldn't bring much. For full auto there is separate plugin.

> This new function (defined as in comment #8) could be named "stretch
> contrast" or "auto contrast" (e.g. as in Picasa). Then it is also clear
> what it will do: Stretch the contrast in the same way as if the user
> adjusted the luminance slider manually.


Auto contrast is the name. Just quick Google bring the name with good
description what is should do.

> > but don't change essence of auto-level tool.
>
> OK, but does it really have a use case? Changing color temperature is
> probably better done in the white balance tool. Adjusting a too dark or
> too light photo can be done with a auto-stretch-contrast function but
> not with the current auto-function as this function often creates wrong
> colors. So what's the typical use case of the current
> auto-stretch-rgb-function?


Remove haze from photographs, much simpler changing color temperature
than with white balance (and often with better effects). Yes, in many
cases it can be disastrous but in many it works. Interesting article
about another PS function:

http://www.creativepro.com/article/out-of-gamut-don-t-underestimate-photoshop-s-auto-color

Possibility to fine control behaviour of auto tools.
BTW - even if you don't find auto-levels very useful it is important to
change it into something other.

> > The only acceptable correction is removal of
> > shadow/highlight clipping
>
> From an photographers point of view that's not only acceptable but very
> important. It's not nice if you first try hard to avoid highlight
> clipping and then an auto-function deliberately creates highlight/shadow
> clipping.


Perfect would be possibility to control amount of clipping. Sometimes it
is needed to get better results, sometimes not (see article from link).

> > although this action is advised to make colors
> > more vivid.
>
> There are much better ways to make colors more vivid than
> highlight/shadow clipping. And making colors more vivid seems to fit
> better in the "hue/saturation/lightness" tool than in the basic "levels
> adjust" tool.
>
> I think it's important that users understand what an automatic function
> does - otherwise nobody will use it. Therefore it would be much better
> if the auto (and the new auto-contrast) function would change the
> sliders, not the data of the source image (and the source-histogram).
> Then everybody could see clearly that the current auto-color function
> adjusts the sliders of the three colour channels while the (new)
> auto-contrast function only changes the slider of the luminance channel.
> And if someone likes some small degree of highlight clipping then he
> could just move the slider a little bit further.


This works in Levels tools. Click Auto button and later use sliders to
correct effect. Maybe replace button with menu to choose type of Auto
correction?

Matthias,

This file still valid using digiKam 2.x serie ?

Gilles Caulier

*** Bug 412445 has been marked as a duplicate of this bug. ***

digiKam 7.0.0 stable release is now published:

https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/

We need a fresh feedback on this file using this version.

Best regards

Gilles Caulier