RSS/Atom feed Twitter
Site is read-only, email is disabled

Histogramm -- values

This discussion is connected to the gimp-user-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

13 of 13 messages available
Toggle history

Please log in to manage your subscriptions.

Histogramm -- values Wolfgang Hugemann 12 Nov 09:39
  Histogramm -- values Øyvind Kolås 13 Nov 18:53
   Histogramm -- values scl 13 Nov 21:16
    Histogramm -- values Brendan Scott 13 Nov 23:53
    Histogramm -- values Wolfgang Hugemann 24 Nov 11:22
     Histogramm -- values scl 25 Nov 05:16
      Histogramm -- values Elle Stone 25 Nov 12:51
       Histogramm -- values Wolfgang Hugemann 25 Nov 19:10
        Histogramm -- values Elle Stone 27 Nov 18:36
         Histogramm -- values Wolfgang Hugemann 02 Dec 19:31
          Histogramm -- values Elle Stone 03 Dec 13:55
         Histogramm -- values Wolfgang Hugemann 03 Dec 10:06
       Histogramm -- values Ofnuts 27 Nov 12:21
Wolfgang Hugemann
2013-11-12 09:39:26 UTC (about 11 years ago)

Histogramm -- values

I have to make some histogram corrections to nighttime photographs where it is essential to keep the average brightness (luminance) constant. (The photos illustrate the human perception in nighttime traffic, as far as this is possible by means of photography.)

However, there seems to be no way to display the histogramm in terms of brightness in Gimp (?). The "value" seems to be just max(R,G,B). But luminance is generally caculated by
Y = 0.2126 R + 0.7152 G + 0.0722 B
see http://en.wikipedia.org/wiki/Luminance_%28relative%29.

Wouldn't it make sense to offer this option?

BTW: The histogram window always switches back to "value" when I start to modify the graduation curve. At the moment, I want to keep it at RGB, as this comes as close as (momentarily) possible to the above equation.

Wolfgang Hugemann

Øyvind Kolås
2013-11-13 18:53:52 UTC (about 11 years ago)

Histogramm -- values

On Tue, Nov 12, 2013 at 4:39 AM, Wolfgang Hugemann wrote:

...
However, there seems to be no way to display the histogramm in terms of brightness in Gimp (?). The "value" seems to be just max(R,G,B). But luminance is generally caculated by
Y = 0.2126 R + 0.7152 G + 0.0722 B
see http://en.wikipedia.org/wiki/Luminance_%28relative%29.

Wouldn't it make sense to offer this option?

In my opinion, the (still) widespread use of value = max(max(r,g),b) is a remnant of 8bit image processing centric performance short-cuts. We would be better off by using luminance in most or all the cases where this approach is currently used.

/pippin

scl
2013-11-13 21:16:56 UTC (about 11 years ago)

Histogramm -- values

On 13.11.2013 at 9:38 PM yvind Kols wrote:> On Tue, Nov 12, 2013 at 4:39 AM, Wolfgang Hugemann wrote:

...
However, there seems to be no way to display the histogramm in terms of brightness in Gimp (?). The "value" seems to be just max(R,G,B). But luminance is generally caculated by
Y = 0.2126 R + 0.7152 G + 0.0722 B
see http://en.wikipedia.org/wiki/Luminance_%28relative%29.

Wouldn't it make sense to offer this option?

In my opinion, the (still) widespread use of value = max(max(r,g),b) is a remnant of 8bit image processing centric performance short-cuts. We would be better off by using luminance in most or all the cases where this approach is currently used.

Hi,

we had a similar discussion about the inconsistent use of the word 'value' in IRC ca. 4 months ago. Currently this word appears at various places in GIMP:
- in the Levels Tool as a channel,
- in the Curves Tool as a channel,
- in the Colors Menu as item 'Invert value' - in the dockable Histogram dialog as a channel (but there's also a channel 'RGB'),
- in the dockable Pointer dialog as component of the HSV color model, - in the dockable Sample Points dialog as component of the HSV color model, - in the Color Picker tools info window as component of the HSV color model, - in the Change Color dialog as component of the HSV color model (V slider),
- as result layer in Color/Decompose/HSV, HSL, - as parameter in Filters/Distorts/Value propagate, - as parameter in Filters/Decor/Add border, - in various places all of the program in its original meaning (set/increase/decrease/minimize/etc. value) and - in various places of the help.

... and not all seem to have the same meaning as we found out that time. There also seems to be no consensus about the meaning of this word in the graphics industry, even when used as abbreviation for 'tonal value': some mean the brightness of a given pixel, others the perceptual brightness of each color (yellow->light, blue->dark).

I'm for using the words value, tonal value, brightness, lightness etc. consistently to avoid further confusion. What are the 'officially defined' or 'most commonly used' names and meanings in these contexts for you, the users?

Kind regards,

Sven

Brendan Scott
2013-11-13 23:53:14 UTC (about 11 years ago)

Histogramm -- values

On 11/14/2013 08:16 AM, scl wrote:

On 13.11.2013 at 9:38 PM �yvind Kol�s wrote:> On Tue, Nov 12, 2013 at 4:39 AM, Wolfgang Hugemann wrote:

...
However, there seems to be no way to display the histogramm in terms of brightness in Gimp (?). The "value" seems to be just max(R,G,B). But luminance is generally caculated by
Y = 0.2126 R + 0.7152 G + 0.0722 B
see http://en.wikipedia.org/wiki/Luminance_%28relative%29.

Wouldn't it make sense to offer this option?

In my opinion, the (still) widespread use of value = max(max(r,g),b) is a remnant of 8bit image processing centric performance short-cuts. We would be better off by using luminance in most or all the cases where this approach is currently used.

Hi,

we had a similar discussion about the inconsistent use of the word 'value' in IRC ca. 4 months ago. Currently this word appears at various places in GIMP:
- in the Levels Tool as a channel,
- in the Curves Tool as a channel,
- in the Colors Menu as item 'Invert value' - in the dockable Histogram dialog as a channel (but there's also a channel 'RGB'), - in the dockable Pointer dialog as component of the HSV color model, - in the dockable Sample Points dialog as component of the HSV color model, - in the Color Picker tools info window as component of the HSV color model, - in the Change Color dialog as component of the HSV color model (V slider), - as result layer in Color/Decompose/HSV, HSL, - as parameter in Filters/Distorts/Value propagate, - as parameter in Filters/Decor/Add border, - in various places all of the program in its original meaning (set/increase/decrease/minimize/etc. value) and - in various places of the help.

... and not all seem to have the same meaning as we found out that time. There also seems to be no consensus about the meaning of this word in the graphics industry, even when used as abbreviation for 'tonal value': some mean the brightness of a given pixel, others the perceptual brightness of each color (yellow->light, blue->dark).

I'm for using the words value, tonal value, brightness, lightness etc. consistently to avoid further confusion. What are the 'officially defined' or 'most commonly used' names and meanings in these contexts for you, the users?

For me, "value" means how white or black the pixel is. This assumes an implicit map to gray scale. I think that this meaning remains the same even if you choose different ways to map to gray. So, users should be made aware of, and be able to select a mapping/a default mapping.

Wolfgang Hugemann
2013-11-24 11:22:29 UTC (about 11 years ago)

Histogramm -- values

Am 13.11.2013 22:16, schrieb scl:

I'm for using the words value, tonal value, brightness, lightness etc. consistently to avoid further confusion. What are the 'officially defined' or 'most commonly used' names and meanings in these contexts for you, the users?

Do you think it is the right approach to ask the users? I would rather suggest asking someone who has a thorough understanding of colour spaces and alike. I could ask Fred Weinhaus (www.fmwconcepts.com/imagemagick) to give that a look, as he has a deep understanding of the matter.

Another approach would be to have a look on what these things are called in Photoshop, if you dare ;-). Normally, I would also suggest to have a look at ImageMagick's nomenclature, but this is also rather questionary in some regards ...

In regard to the HSV colour space, you probably have no other option than calling the V component "value", as this is its name, whether it makes sense or not.

In regard to the histogram of a colour image, I would regard the y-axis as the equivalent grey-value of the colour, i.e. its brightness, lightness or luminance, whatever you would like to call that.

I think the word unspecific "value" should be avoided as far as possible.

Wolfgang Hugemann

scl
2013-11-25 05:16:32 UTC (about 11 years ago)

Histogramm -- values

Hi,

thank you, Wolfgang, for your reply and sorry I couldn't answer earlier.

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. >> What are the 'officially defined' or 'most commonly used' names and >> meanings in these contexts for you, the users? >
> Do you think it is the right approach to ask the users? I would rather > suggest asking someone who has a thorough understanding of colour spaces > and alike. I could ask Fred Weinhaus (www.fmwconcepts.com/imagemagick) > to give that a look, as he has a deep understanding of the matter.

Asking someone with a thorough understanding of the topic is the rationale behind asking the users. The large amount of GIMP users and the assumption that there must be at least some among them with a thorough knowledge led me to my proposal. Yes, it's not perfect, but at least one step into the right direction. If you have an expert I'd be glad if you asked him and reported back. Another point that needs clarification is the use and meaning of the word 'Value' in the Layer and Painting modes.

Elle Stone and Nicolas Robidoux, can you please also have a look on this topic? Thank you in advance.

> Another approach would be to have a look on what these things are > called in Photoshop, if you dare ;-). I'm not feared of Photoshop ;-) Can we assume for sure that the wording there IS proper (using a wrong word just because PS uses it is no convincing reason for me)?
Unfortunately I only have the German version and switching languages in PS is not as easy as in GIMP. So if we want to do this somebody with an English version is needed.

> I think the word unspecific "value" should be avoided as far as possible. I agree with you.

Kind regards,

Sven

Elle Stone
2013-11-25 12:51:14 UTC (about 11 years ago)

Histogramm -- values

On 11/25/2013 12:16 AM, scl wrote:

Hi,

thank you, Wolfgang, for your reply and sorry I couldn't answer earlier.

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. >> What are the 'officially defined' or 'most commonly used' names and >> meanings in these contexts for you, the users? >
> Do you think it is the right approach to ask the users? I would rather > suggest asking someone who has a thorough understanding of colour spaces > and alike. I could ask Fred Weinhaus (www.fmwconcepts.com/imagemagick) > to give that a look, as he has a deep understanding of the matter.

Asking someone with a thorough understanding of the topic is the rationale behind asking the users. The large amount of GIMP users and the assumption that there must be at least some among them with a thorough knowledge led me to my proposal. Yes, it's not perfect, but at least one step into the right direction. If you have an expert I'd be glad if you asked him and reported back. Another point that needs clarification is the use and meaning of the word 'Value' in the Layer and Painting modes.

Elle Stone and Nicolas Robidoux, can you please also have a look on this topic? Thank you in advance.

This post is only about the word "Value" as used in Gimp's Histogram and Levels dialog. I don't know if the "Value" in the blending mode is the same as the Value in the histogram and Levels. Apologies in advance for a long post.

XYZ is a model of how humans actually perceive color. RGB refers to a convenient subset of all possible XYZ values. The simplest possible subset of all possible XYZ values is determined by picking red, green, and blue primaries in XYZ space, plus a black point and a white point, plus a tone response curve (TRC) to create a matrix RGB color space such as sRGB.

Above is covered in http://ninedegreesbelow.com/photography/xyz-rgb.html

So RGB is mathematically derived from XYZ. In turn the various HSL/HSV/HSI color space models are mathematically derived from RGB. So first you pick an RGB color space. Then you calculate HSL/HSV/HSI values. The question is "why"? Why not just use the RGB values directly?

According to Wikipedia (https://en.wikipedia.org/wiki/HSV_color_space#Motivation), the answer is because apparently RGB isn't intuitively obvious to us end-users of graphics programs, and also (here's the real reason) HSL/HSV calculations are computationally cheaper than RGB calculations, which made a difference back in the 1970s and 80s and 90s, but not so much today because computer hardware is exponentially faster than it used to be.

The question is Gimp's term "Value". The HSL/HSV/HSI models start with RGB and then define more or less adequate measures of:

*Hue (whether it's red, blue, green, or some in-between color)

*Saturation (whether it's very close to or far from the XYZ neutral axis connecting the RGB color space's white point and black point)

*Some measure of "Luminance". "Luminance" is a physical measure (based on real properties of actual light) of how bright something is (speaking loosely), or how much light reflects off of it in the direction of the viewer's eyeballs (speaking more precisely). Luminace happens to be equal to the "Y" of the equivalent XYZ value for the given RGB values in any specified RGB color space.

If your goal is to represent what people see out there in the world, rather than to make computationally cheaper calculations, none of the HSX models are any good. See the nice illustration in the "disadvantages" section of the Wikipedia article: https://en.wikipedia.org/wiki/HSV_color_space#Disadvantages, and then read the paragraph following the illustration.

To illustrate the problem with numbers, let's pick an RGB color space, sRGB. Then pick some colors and calculate Value, Lightness, and Intensity. Then divide each value by 255 to put them on a scale from 0 to 1 so we can compare them to the equivalent XYZ "Y" value. The L, I, and V equations are from the Wikipedia article:

Lightness L = The sum of the maximum ("M") and minimum ("m") RGB values for the RGB values for the color, divided by two = (M + m)/2

Intensity I = one third of the sum of R, G, and B = (R + G + B)/3.

Value V = the maximum of R, G, and B = M. This is what Gimp uses in the Histogram and Levels. I'm not sure what Curves does.

Below the word "value" (lower case) means "the numerical value" of the RGB coordinates of a color as specified in a particular RGB color space.

Let's pick the reddest possible red in the sRGB color space, at 8-bits, which is (255,0,0). The maximum RGB value of reddest sRGB red is 255. The minimum RGB value is 0.

The Lightness is (0+255)/2 =127.5. Divide by 255= 0.500000 The Value is 255. Divide by 255= 1.000000 The Intensity is (255+0+0)/3 = 85. Divide by 255= 0.333333

Now let's pick sRGB middle gray: (119,119,119). The maximum value of sRGB middle gray is 119. The minimum value is also 119.

Lightness=(119+119)/2 = 119. Divide by 255= 0.466667 The Value is 119. Divide by 255= 0.466667 The Intensity is (119+119+119)/3 = 119. Divide by 255= 0.466667

So how close are V, L, and I to the actual XYZ "Y" luminance?

xicclu -s255 argyll-sRGB.icm 255 0 0 [RGB] -> 0.436035 0.222443 0.013901 [XYZ] Y (Luminance) = 0.222443

119 119 119 [RGB] -> 0.233189 0.207916 0.428216 [XYZ] Y (Luminance) = 0.207916

So all of the HSX models do a bad job of estimating actual real world Luminance.

There's another problem with these HSX models: Change the color space and the HSL/HSV/HSI values stay the same, but of course the **meaning** of the RGB values from which HSL/HSV/HSI are calculated changes drastically. Here are the Luminance values for the ProPhotoRGB color space, using the same RGB values as above:

xicclu -s255 Rimm-elleV2-g180.icc 255 0 0 [RGB] Y = 0.288040
119 199 199 RGB] Y = 0.254242

So it sounds like I'm saying that Gimp's use of Value from HSV is a bad thing for Histograms and Levels. Actually, I'm not. The question is what is the point of a histogram, and what is the editing purpose of Levels?

The point of a histogram is to show the distribution of RGB values in the image, in the RGB color space that the image is in. When I edit an image, when I adjust Levels, I want to know when I'm clipping RGB values. I'm not so concerned about what the equivalent "Luminance/Y" value is. Adjusting the left and right sides of the Levels, the image's "white point" and "black point", is arguably the most important step in image editing, and where you start to clip pixels at the top and bottom of the histogram is a crucial piece of information.

If Gimp used Intensity or Lightness on the histogram and on the Levels dialog, that would be singularly useless information from an editing point of view.

But Gimp's "Value" gives the maximum of R, G, and B. So I know that I can adjust an image's white point using Gimp Levels upper right hand slider all the way to the right edge of the histogram and not clip any pixels.

I wish Gimp also had a Minimum histogram, too. At present we don't have a histogram that shows the minimum of R, G, and B. So sliding the left hand upper Levels slider to set the image black point just by looking at the Value (Maximum) histogram is misleading. Sometimes very misleading. It can result in a whole lot of clipped pixels, whereas switching to Curves would allow to compress rather than clip, if the user knew they were about to clip pixels.

If Gimp calculated the XYZ "Y" Luminance value, that would be useful as a blending mode, and also useful in a histogram as an overview of the image's distribution of light and dark, but not as useful for actually setting the image black and white point as the mathematically simpler "Minimum" (which we don't have at present) and "Maximum" (which we do have, only it's called "Value").

If I were designing the Levels and Histogram interfaces, I'd change the word "Value" to "Maximum RGB" and I'd add the equivalent "Minimum RGB" Histogram. And I'd offer the option to view the RGB channels in the Levels dialog just like you can in the Histogram, so you could move the sliders and see which channels are being clipped.

Having a Luminance histogram would also be nice to show the actual distribution of Luminance values. A Luminance histogram would be constant regardless of the color space the image was in.

Elle

Wolfgang Hugemann
2013-11-25 19:10:17 UTC (almost 11 years ago)

Histogramm -- values

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 ...

Fred Weinhaus also answered me and he is pointing to some transfer functions that ImageMagick uses, see http://www.imagemagick.org/script/command-line-options.php#intensity.

He also gives some helpful illustrations what effects different transfer functions have on the image:
http://www.fmwconcepts.com/imagemagick/color2gray/index.php

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 (?).

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 http://www.fmwconcepts.com/imagemagick/redist.

Wolfgang Hugemann

Ofnuts
2013-11-27 12:21:17 UTC (almost 11 years ago)

Histogramm -- values

On 11/25/2013 01:51 PM, Elle Stone wrote:

On 11/25/2013 12:16 AM, scl wrote:

Hi,

thank you, Wolfgang, for your reply and sorry I couldn't answer earlier.

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. >> What are the 'officially defined' or 'most commonly used' names and >> meanings in these contexts for you, the users? >
> Do you think it is the right approach to ask the users? I would rather
> suggest asking someone who has a thorough understanding of colour spaces
> and alike. I could ask Fred Weinhaus (www.fmwconcepts.com/imagemagick)
> to give that a look, as he has a deep understanding of the matter.

Asking someone with a thorough understanding of the topic is the rationale behind asking the users. The large amount of GIMP users and the assumption that there must be at least some among them with a thorough knowledge led me to my proposal. Yes, it's not perfect, but at least one step into the right direction. If you have an expert I'd be glad if you asked him and reported back. Another point that needs clarification is the use and meaning of the word 'Value' in the Layer and Painting modes.

Elle Stone and Nicolas Robidoux, can you please also have a look on this topic? Thank you in advance.

This post is only about the word "Value" as used in Gimp's Histogram and Levels dialog. I don't know if the "Value" in the blending mode is the same as the Value in the histogram and Levels. Apologies in advance for a long post.

XYZ is a model of how humans actually perceive color. RGB refers to a convenient subset of all possible XYZ values. The simplest possible subset of all possible XYZ values is determined by picking red, green, and blue primaries in XYZ space, plus a black point and a white point, plus a tone response curve (TRC) to create a matrix RGB color space such as sRGB.

Above is covered in http://ninedegreesbelow.com/photography/xyz-rgb.html

So RGB is mathematically derived from XYZ. In turn the various HSL/HSV/HSI color space models are mathematically derived from RGB. So first you pick an RGB color space. Then you calculate HSL/HSV/HSI values. The question is "why"? Why not just use the RGB values directly?

According to Wikipedia (https://en.wikipedia.org/wiki/HSV_color_space#Motivation), the answer is because apparently RGB isn't intuitively obvious to us end-users of graphics programs, and also (here's the real reason) HSL/HSV calculations are computationally cheaper than RGB calculations, which made a difference back in the 1970s and 80s and 90s, but not so much today because computer hardware is exponentially faster than it used to be.

The question is Gimp's term "Value". The HSL/HSV/HSI models start with RGB and then define more or less adequate measures of:

*Hue (whether it's red, blue, green, or some in-between color)

*Saturation (whether it's very close to or far from the XYZ neutral axis connecting the RGB color space's white point and black point)

*Some measure of "Luminance". "Luminance" is a physical measure (based on real properties of actual light) of how bright something is (speaking loosely), or how much light reflects off of it in the direction of the viewer's eyeballs (speaking more precisely). Luminace happens to be equal to the "Y" of the equivalent XYZ value for the given RGB values in any specified RGB color space.

If your goal is to represent what people see out there in the world, rather than to make computationally cheaper calculations, none of the HSX models are any good. See the nice illustration in the "disadvantages" section of the Wikipedia article: https://en.wikipedia.org/wiki/HSV_color_space#Disadvantages, and then read the paragraph following the illustration.

To illustrate the problem with numbers, let's pick an RGB color space, sRGB. Then pick some colors and calculate Value, Lightness, and Intensity. Then divide each value by 255 to put them on a scale from 0 to 1 so we can compare them to the equivalent XYZ "Y" value. The L, I, and V equations are from the Wikipedia article:

Lightness L = The sum of the maximum ("M") and minimum ("m") RGB values for the RGB values for the color, divided by two = (M + m)/2

Intensity I = one third of the sum of R, G, and B = (R + G + B)/3.

Value V = the maximum of R, G, and B = M. This is what Gimp uses in the Histogram and Levels. I'm not sure what Curves does.

Below the word "value" (lower case) means "the numerical value" of the RGB coordinates of a color as specified in a particular RGB color space.

Let's pick the reddest possible red in the sRGB color space, at 8-bits, which is (255,0,0). The maximum RGB value of reddest sRGB red is 255. The minimum RGB value is 0.

The Lightness is (0+255)/2 =127.5. Divide by 255= 0.500000 The Value is 255. Divide by 255= 1.000000 The Intensity is (255+0+0)/3 = 85. Divide by 255= 0.333333

Now let's pick sRGB middle gray: (119,119,119). The maximum value of sRGB middle gray is 119. The minimum value is also 119.

Lightness=(119+119)/2 = 119. Divide by 255= 0.466667 The Value is 119. Divide by 255= 0.466667 The Intensity is (119+119+119)/3 = 119. Divide by 255= 0.466667

So how close are V, L, and I to the actual XYZ "Y" luminance?

xicclu -s255 argyll-sRGB.icm 255 0 0 [RGB] -> 0.436035 0.222443 0.013901 [XYZ] Y (Luminance) = 0.222443

119 119 119 [RGB] -> 0.233189 0.207916 0.428216 [XYZ] Y (Luminance) = 0.207916

So all of the HSX models do a bad job of estimating actual real world Luminance.

There's another problem with these HSX models: Change the color space and the HSL/HSV/HSI values stay the same, but of course the **meaning** of the RGB values from which HSL/HSV/HSI are calculated changes drastically. Here are the Luminance values for the ProPhotoRGB color space, using the same RGB values as above:

xicclu -s255 Rimm-elleV2-g180.icc 255 0 0 [RGB] Y = 0.288040
119 199 199 RGB] Y = 0.254242

So it sounds like I'm saying that Gimp's use of Value from HSV is a bad thing for Histograms and Levels. Actually, I'm not. The question is what is the point of a histogram, and what is the editing purpose of Levels?

The point of a histogram is to show the distribution of RGB values in the image, in the RGB color space that the image is in. When I edit an image, when I adjust Levels, I want to know when I'm clipping RGB values. I'm not so concerned about what the equivalent "Luminance/Y" value is. Adjusting the left and right sides of the Levels, the image's "white point" and "black point", is arguably the most important step in image editing, and where you start to clip pixels at the top and bottom of the histogram is a crucial piece of information.

If Gimp used Intensity or Lightness on the histogram and on the Levels dialog, that would be singularly useless information from an editing point of view.

But Gimp's "Value" gives the maximum of R, G, and B. So I know that I can adjust an image's white point using Gimp Levels upper right hand slider all the way to the right edge of the histogram and not clip any pixels.

I wish Gimp also had a Minimum histogram, too. At present we don't have a histogram that shows the minimum of R, G, and B. So sliding the left hand upper Levels slider to set the image black point just by looking at the Value (Maximum) histogram is misleading. Sometimes very misleading. It can result in a whole lot of clipped pixels, whereas switching to Curves would allow to compress rather than clip, if the user knew they were about to clip pixels.

If Gimp calculated the XYZ "Y" Luminance value, that would be useful as a blending mode, and also useful in a histogram as an overview of the image's distribution of light and dark, but not as useful for actually setting the image black and white point as the mathematically simpler "Minimum" (which we don't have at present) and "Maximum" (which we do have, only it's called "Value").

If I were designing the Levels and Histogram interfaces, I'd change the word "Value" to "Maximum RGB" and I'd add the equivalent "Minimum RGB" Histogram. And I'd offer the option to view the RGB channels in the Levels dialog just like you can in the Histogram, so you could move the sliders and see which channels are being clipped.

Having a Luminance histogram would also be nice to show the actual distribution of Luminance values. A Luminance histogram would be constant regardless of the color space the image was in.

Elle

__

Fascinating... of course this kind of small details also lurks in Color/Desaturate, but where I miss them the most is in the layer blend modes. Color/Hue/Saturation/Value are very hard to work with...

Elle Stone
2013-11-27 18:36:18 UTC (almost 11 years ago)

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 http://www.imagemagick.org/script/command-line-options.php#intensity.

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
http://ninedegreesbelow.com/photography/srgb-luminance.html for details.

He also gives some helpful illustrations what effects different transfer functions have on the image:
http://www.fmwconcepts.com/imagemagick/color2gray/index.php

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,

https://en.wikipedia.org/wiki/Histogram#Cumulative_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 http://www.fmwconcepts.com/imagemagick/redist.

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: http://stackoverflow.com/questions/12121393/please-explain-this-color-blending-mode-formula-so-i-can-replicate-it-in-php-ima

Elle

Wolfgang Hugemann
2013-12-02 19:31:59 UTC (almost 11 years ago)

Histogramm -- values

OK, colour spaces are very confsing, but a very basic point is that the human spectral sensitivity has a pronounced peak in the green region, see http://en.wikipedia.org/wiki/Luminosity_function.

This is why any function deriving the perceived brightness or luminance from RGB, such as Rec709Luminance (0.212656 * R + 0.715158 * G + 0.072186 * B) weights the green far more than red and blue. This just reflects the spectral sensitivity of the human eye.

The perceived brightness of purely red image at, say, 100 bit will be far less than that of a purely green image at 100 bit. Correspondingly, the latter should result in a leighter equivalent grey than the former.

Gimp proceeds this way when converting a colour image to grey, as I have just tested:

100 R --> 21 G
100 G --> 72 G
100 B --> 7 G

This is very close to Rec709Luminance.

I just suggest that it should offer such a weighting in the histogramm for a colour image, i.e. the equivalent grey value at Gimp itself would calculate it.

Wolfgang Hugemann

Wolfgang Hugemann
2013-12-03 10:06:52 UTC (almost 11 years ago)

Histogramm -- values

OK, colour spaces are very confsing, but a very basic point is that the human spectral sensitivity has a pronounced peak in the green region, see http://en.wikipedia.org/wiki/Luminosity_function.

This is why any function deriving the perceived brightness or luminance from RGB, such as Rec709Luminance (0.212656 * R + 0.715158 * G + 0.072186 * B) weights the green far more than red and blue. This just reflects the spectral sensitivity of the human eye.

The perceived brightness of purely red image at, say, 100 bit will be far less than that of a purely green image at 100 bit. Correspondingly, the latter should result in a leighter equivalent grey than the former.

Gimp proceeds this way when converting a colour image to grey, as I have just tested:

100 R --> 21 G
100 G --> 72 G
100 B --> 7 G

This is very close to Rec709Luminance.

I just suggest that it should offer such a weighting in the histogramm for a colour image, i.e. the equivalent grey value at Gimp itself would calculate it.

Wolfgang Hugemann

Elle Stone
2013-12-03 13:55:39 UTC (almost 11 years ago)

Histogramm -- values

On 12/02/2013 02:31 PM, Wolfgang Hugemann wrote:

human spectral sensitivity has a pronounced peak in the green region, see http://en.wikipedia.org/wiki/Luminosity_function.

This is why any function deriving the perceived brightness or luminance from RGB, such as Rec709Luminance (0.212656 * R + 0.715158 * G + 0.072186 * B) weights the green far more than red and blue. This just reflects the spectral sensitivity of the human eye.

The perceived brightness of purely red image at, say, 100 bit will be far less than that of a purely green image at 100 bit. Correspondingly, the latter should result in a leighter equivalent grey than the former. Gimp proceeds this way when converting a colour image to grey, as I have just tested:

100 R --> 21 G
100 G --> 72 G
100 B --> 7 G

Gimp 2.8 uses the values from Poynton, which are the right values to use in a non-color-managed application when sending signals to a D65 Rec709 display device. The correct sRGB values for an ICC profile color-managed application are slightly different: R 22%, G 72%, and B 6%. See: http://ninedegreesbelow.com/photography/srgb-luminance.html

This is very close to Rec709Luminance.

Gimp 2.8 operates on the nonlinear sRGB RGB values, so it computes luma rather than luminance. See Poynton's ColorFAQ #9 and #11 (http://www.poynton.com/PDFs/ColorFAQ.pdf). Calculating true luminance requires that you first linearize the RGB values. Gimp 2.10 will use linear sRGB to calculate true luminance rather than luma.

I just suggest that it should offer such a weighting in the histogramm for a colour image, i.e. the equivalent grey value at Gimp itself would calculate it.

I concur 100%. I hope Gimp 2.10 includes exactly such a histogram, except personally I would prefer luminance (calculated using linear sRGB) rather than luma. Luminance is a mathematically expression of how we actually perceive relative light and dark, based on what you said above about how we perceive colors (very sensitive to green, less to red, even less to blue). Luma is mathematically easier to calculate than Luminance, but as far as I know that's its only virtue.

Elle