Re: [Gimp-developer] Questions about the histogram

On 07/27/2019 12:23 AM, Steve Pricks wrote:
> 
> Hello,
> 
> I am working with the histogram code and have some questions.
> 
> 1. In the upper right of the histogram dialog are three buttons: Linear, Non-Linear, Perceptual.
> - Which purpose do they serve for artists, graphics scientists and developers?

Histograms are useful for displaying the distribution of tones in an 
image. Speaking as a photographer, some photographers use them a lot. 
Other photographers don't use them at all. The internet has a lot of 
articles on using histograms.

In GIMP-2.10 there are only two buttons: linear and perceptual. 
GIMP-2.99 has all three buttons.

GIMP-2.10, depending on the specific operation, encodes RGB data either 
linearly or "perceptually uniformly". Except that the "perceptually 
uniform" encoding isn't the Lab "L" TRC as one might expect. Rather it's 
the sRGB TRC. The sRGB TRC is only approximately perceptually uniform.

GIMP-2.99 adds a third way to encode RGB data, that being the TRC of the 
RGB color space the image happens to be in.

So for example, if you were working with a ProPhotoRGB image with a 
gamma=1.8 TRC, all three buttons would show you the histogram of the 
image encoded using ProPhotoRGB primaries. But the linear histogram 
button shows you the histogram of the channels encoded linearly. The 
"non-linear" button shows the histogram of the channels encoded using 
gamma=1.8. And the "perceptual" button shows you the histogram of the 
channels encoded using the sRGB TRC. None of the buttons show you the 
actually perceptually uniformly encoded channel values

If you open an image in an RGB matrix working color space that happens 
to have the Lab "L" TRC (such profiles are available from my github 
account: https://github.com/ellelstone/elles_icc_profiles ), 
"non-linear" shows you the histogram for the actually perceptually 
uniform Lab "L" TRC, and "perceptual" shows you the histogram for the 
"close to but not really perceptually uniform" sRGB TRC. Bleh.


> - Will they stay after the space invasion project?

Yes. They are actually part of the space invasion.

> - Why are there Non-Linear and Perceptual - is Perceptual not a special case of Non-Linear?

Yes, it's a special case of non-linear.

One nice thing about working with RGB encoded "actually perceptually 
uniformly/Lab L TRC" is that the midpoint really is Lab L=50. So Curves 
can easily target the midpoint, and "soft light/hard light/etc" blend 
modes that use 0.5 in their calculations actually swing the colors 
darker and lighter right at middle gray.

Unfortunately because "Perceptually uniform" in GIMP really means "the 
sRGB not quite perceptually uniform TRC", the "midpoint" really isn't 
the midpoint, R=G=B=0.5 isn't Lab L=50. The midpoint (middle gray) for 
the sRGB TRC is R=G=B=0.467 - this might not sound like much of a 
difference, but in practice it does make a difference.

I've modified my own "working" copies of GIMP (actually babl and GIMP 
both need to be modified) to use the Lab "L" TRC as the perceptually 
uniform TRC. I keep meaning to file a bug report requesting that this 
change be made to the official code for GIMP-2.99, but haven't gotten 
around to it.

Here's a couple of pictures illustrating the difference between "sRGB 
TRC" and "actually perceptually uniform TRC":

https://ninedegreesbelow.com/photography/lab/gimp29/xicclu-lstar-lab-l-srgb-trc.png

https://ninedegreesbelow.com/photography/lab/gimp29/correct-vs-gimp29-decompose-drag-drop.jpg

> 
> 2. The histogram's RGB luminance weights are calculated from GIMP's builtin sRGB profile, see gimprgb.h, lines 193-195.
> Will the space invasion project change this?

In theory, yes, when someone gets around to finish modifying the code to 
complete the space invasion.

In practice, there's an awful lot of code to modify to complete the 
space invasion, and nobody seems to be making this a priority. Which 
perhaps isn't surprising as there are so many coding tasks that need 
attention, and not very many developers working on these tasks, and 
people naturally gravitate to coding tasks that they find most 
interesting/easier/higher priority for whatever reason.

I tried to take on the task of finishing the space invasion and managed 
to mofify a couple of additional operations to work using "AnyRGB". But 
the coding required is above my coding level. After spending a lot of 
time trying to find "the next bit of code" that I could actually figure 
out how to modify, I finally gave up and I simply won't try any more.

The space invasion mostly seems to be stalled at the moment. If you want 
an overview of the current state of the space invasion, check GNOME 
gitlab open and closed bug reports authored by "@ellestone".

Back in 2016 I compiled and uploaded to gitlab my "GIMP-CCE" version of 
babl/GEGL/GIMP, that uses the image's actual color space matrix to 
calculate all operations that use Y/XYZ/Lab/LCh/etc. I used a global 
variable to do this, which variable was available to all operations that 
needed it.

In my CCE version of GIMP, all operations that *don't* involve a 
conversion to XYZ just operate on RGB channel values "blissfully 
unaware" of the image's actual color space. Which imho is exactly what 
*should* happen because, for example, "Multiply" and "Levels" don't need 
to know what color space the image is in. But conversions to Luminance 
and to LCh do need to know what color space the image is in.

By comparison, in default GIMP-2.99 post-space-invasion, all operations 
that don't *specifically* request to use the image's actual RGB color 
space matrix, assume the sRGB color space matrix instead. So just about 
all operations, whether they actually uses Y/XYZ/Lab/LCh/etc or not, 
need to be tested and possibly recoded before the space invasion is 
complete. Personally I think this is a somewhat odd coding decision, 
because it means the number of "cases" to check for correct operation 
post-space-invasion is astronomical. And any slip of the coding can 
reintroduce errors.


>> 2. The histogram's RGB luminance weights are calculated from GIMP's builtin sRGB profile, see gimprgb.h, lines 193-195.
>> Will the space invasion project change this?

This question needs to be answered twice. I'm not sure whether the 
GIMP-2.99 histogram RGB luminance display actually gives wrong results 
or not. I'd have to check and see. Because it's entirely possible that 
the histogram is calculated by first converting the image from its 
actual RGB matrix to the sRGB matrix, before displaying the Luminance 
histogram. If this is what's currently being done, then this is a case 
of "using sRGB as the PCS" about which you can find much verbiage 
spilled on this list a few years ago if you search Nabble archives of 
GIMP mailing lists.

So ironically, *if* the babl/GEGL/GIMP code really is using "sRGB as 
PCS" for any given operation that requires a conversion to XYZ, then the 
very operations that one would expect to fail (operations that involve 
conversions from RGB to XYZ) pre-space-invasion actually might be giving 
correct results. You'd have to look at the actual code for each specific 
operation to see whether it's thrown in a conversion to sRGB before 
making the conversion to XYZ.

> Thank you for your answers.

As some of the people on this list know, I have an ongoing problem with 
my wrists and hands that makes sustained typing difficult. Having typed 
out answers to Steve's questions, it will require an icepack and several 
hours of rest before I can type again with any degree of comfort. But I 
thought it was important to actually answer Steve's questions because 
they are very important questions.

Hopefully what I've written sheds some light on the current state of the 
space invasion. Hopefully someone will come along "sooner rather than 
later" with better coding abilities than I have, and make the space 
invasion a priority.

Once someone decides to work on finishing the space invasion, it will 
take a *lot* of testing to make sure everything is working properly with 
each new space invasion code change.

Anyone who wants to help with testing the space invasion, it's a good 
idea to go ahead and compile my "GIMP-CCE" to use as a reference for "Is 
operation X working properly post-space-invason". If anyone is actually 
interested in helping with testing the space invasion, let me know and 
I'll upload to my github account a small code change required to allow 
"CCE" to read current GIMP XCF files. And I'll be happy to explain the 
details of actually using CCE to cross-check post-space-invasion editing 
results.

Best regards,
Elle Stone
-- 
https://ninedegreesbelow.com
Color management and free/libre photography

> 
> Steve
> 
> _______________________________________________
> gimp-developer-list mailing list
> List address:    [email protected]
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
> 


_______________________________________________
gimp-developer-list mailing list
List address:    [email protected]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list