Re: [Gimp-user] Histogramm -- values

On 11/25/2013 02:10 PM, Wolfgang Hugemann wrote:
Elle Stone and Nicolas Robidoux, can you please also have a
look on this topic? Thank you in advance.

Wow, this was a very elaborate answer ...

The original question was whether Gimp uses the term "Value" correctly, at least that was the part of the question I tried to answer.

The answer is "Yes" at least for the Histogram, Levels, and Curves dialogs. I looked at the actual Levels code, Curves emulates Levels, and the Histogram accurately reflects adjustments made using Levels and Curves. So logically they must all use the same algorithm, which is Value, which is the maximum of R, G, and B.

Being assured that the term 'Value' is used correctly doesn't say much unless you understand what "Value" in Gimp really means. If I erred on the side of too much information (almost certainly yes!), my apologies!

Fred Weinhaus also answered me and he is pointing to some transfer
functions that ImageMagick uses, see

Quoting from the Imagemagick page:
   Rec709Luma        0.212656R' + 0.715158G' + 0.072186B'
   Rec709Luminance   0.212656R + 0.715158G + 0.072186B
   Brightness        max(R', G', B')

The Imagemagick page says that Primed (eg R') values are non-linear sRGB. Unprimed are linear, presumably linear sRGB although the immediate text doesn't make this clear. Imagemagick "Brightness" is the same as Gimp "Value".

Rec709Luma and Rec709Luminance both give the appropriate values for calculating what to send to an D65 sRGB-compatible monitor screen, in a NON-color-managed application. Gimp is color-managed.

The right values for calculating sRGB Luma and Luminance for a color-managed application like Gimp are 0.2225*red + 0.7169*green + 0.0606*blue (to 4 decimal places). If you want real Luminance ("Y" of XYZ), then you need to use the linear sRGB RGB values, not the regular sRGB RGB values. See for details.

He also gives some helpful illustrations what effects different transfer
functions have on the image:

Fred's scripts fall into the category of "instant pretty" algorithms (click a button or run a script and the image might be prettier). "How to manipulate the RGB values to make the image instantly prettier" is a very different topic than the question of what Gimp's "Value" actually means. As an aside, Fred's scripts license isn't floss-compatible.

I understand what Elle says in regard to histogram clipping, i.e. max(R,
G, B) being very helpful for finding the white point -- while min (R, G,
B) in regard to the black point is missing.

Perhaps one should give the user just a few more options what to display
in the histogram and how to transfer R, G, B into a single 'value'. I
would be very lucky with 'Rec709Luma' as defined by ImageMagick. I
understand that GIMP internally uses the sRGB colour space at the moment

"Single measure" histograms are very useful, and which measure to use is an important question. But Imagemagick's "Rec709Luma" isn't particularly useful (IMHO), having a mathematically convoluted and physically meaningless relationship to the image's actual Luminance ("Y" from XYZ) values.

A standalone feature for GIMP would be the possibility to display a
cumulated histogram,

which would for instance demonstrate the effect of
equalisation better than an ordinary histogram. This should be easy to
implement, I guess, and would be a simple check box for the user.

BTW: Besides equalisation, one could also try to meet other cumulative
histogram distribution, like a Gaussian bell curve, see

Fred's non-floss "REDIST" algorithm script is an "instant pretty" way to manipulate the image's RGB values to produce an image with a predetermined histogram shape. The resulting image histogram will be different because the image's actual RGB values have changed by the algorithm.

Two different questions are easy to mix up:

One question is how to helpfully display the image histogram, based on the image's current RGB values. This involves things like what type of histogram ("ordinary" seems more generally useful; "cumulative" would have a specialized use) and what measure(s) (eg Value, Luminance, Min, Max, R, G, B, etc) should be displayed.

A second question is how to instantly prettify an image by applying algorithms that are designed to alter the image's distribution of RGB values, which of course means the image's histogram will change, regardless of which type of histogram you use. If I understand him correctly, Wolfgang says the cumulative histogram might make choosing an algorithm easier.

On 19.11.2013 at 5:14 AM Wolfgang Hugemann wrote:

> I'm for using the words value, tonal value, brightness, lightness etc.
> consistently to avoid further confusion.

Gimp uses the term "Lightness" as in Hue/Saturation/Lightness. Here's an excerpt from the code:

  max = gimp_rgb_max (rgb);
  min = gimp_rgb_min (rgb);
  hsl->l = (max + min) / 2.0;

That's exactly the definition of Lightness from HSL. I'm going to bet that the Gimp interface always uses the right terminology for whatever HSX model is being used. So it's not terminological inconsistency but rather different HSX models for different purposes.

Gimp uses "Brightness" as in "Colors/Brightness-Contrast", which based on a glance at the code is just a call to Levels. Brightness and Value mean the same thing, not just in Gimp but as far as I can tell, in general, when referring to HSB and HSV. If Gimp used the terminology "Value-Contrast" that might confuse people who use to other image editors, as "Brightness-Contrast" seems to be used universally. So again, the Gimp terminology is accurate. As an aside, there is nothing you can do with Brightness-Contrast that you can't do with more control using Levels.

In "Colors/Desaturate", looking at the code, Lightness and Average are used correctly. Luminosity isn't "gamma"-corrected in Gimp 2.8 (so the term is technically incorrect), but it is "gamma"-corrected in Gimp 2.9, so when the next release of Gimp comes along the terminology will be 100% accurate.

I am very far from being an expert in using Gimp. Where is "tonal value" used in the user interface?

> Another approach would be to have a look on what these things are
> called in Photoshop

Photoshop seems have its own version of HSX:


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]