[Digikam-devel] [Bug 128377] Adjust levels: histograms don't match, bad "auto level" function

[Mikolaj Machowski]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=128377         




------- Additional Comments From mikmach wp pl  2008-03-25 19:34 -------
> 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.