GNOME.org
 

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:    gimp-developer-list gnome org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]