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

Matthias Wieser mwieser at gmx.de
Tue Mar 25 20:13:51 GMT 2008


------- 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 mwieser gmx de  2008-03-25 21:13 -------
> 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



More information about the Digikam-devel mailing list