Questions about the histogram

[Steve Pricks]

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?
- Will they stay after the space invasion project?
- Why are there Non-Linear and Perceptual - is Perceptual not a special case of Non-Linear?

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?

Thank you for your answers.

Steve

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

[Elle Stone]

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:    [hidden email]
> 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:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Steve Pricks]

Hello,

first of all thank you, Elle, for your - as usual - detailed answer, especially with your health restrictions!

Being an amateur photographer myself I know about the purpose of the histogram for photographers and use it all the time as one step among others. I cannot tell much about the needs of the other mentioned user groups, such as artists creating art for web and print.

However, I have not seen buttons like these in any other image editing software, neither commercial nor free/libre (not even in RT with its technology filled GUI). I wished the developers themselves could tell about their intentions. At least I found in commit e09e563 from 07/21/2018:
"
- change all "linear" properties to "trc", in all config objects like
  for levels and curves, in the histogram, in the widgets. This results
  in some GUI that now has three choices instead of two.
  TODO: we might want to reduce that back to two later.
"
Ah so, it's in an unfinished state.
To get some input from other relevant software I did some checks:
Lightroom 8.3.1: Article [1] describes how Lightroom handles this in its Develop module: it works with a profile of ProPhotoRGB gamut and whitepoint. Internally it computes with a linear TRC, but the histogram in the Develop module uses a gamma ~2.21 sRGB TRC (they named it MelissaRGB profile). This sounds similar to GIMPs behaviour, but with a greater color space. (I don't want to revive the old discussions here). I ran a test by converting images to ProPhotoRGB and clicking the "perceptual" button which shows the histogram using the sRGB TRC. It's visually almost equal to LR's histogram in the Develop module and Library module.
Photoshop CC: Histogram view and histogram in Camera Raw Filter look close to the perceptual view.
Darktable 2.6.0: No match at all. It shows almost nothing where the other histograms have massive peaks.
Darktable 2.7.0+1612~g9e212dc9d-dirty: Shows nothing at all.
Krita 4.2.5: Looks like the perceptual view.
RawTherapee 5.6.1: Looks like the perceptual view.
DxO Optics 11: Looks like the perceptual view.
As it seems, the perceptual view is common. Elles lines read as perceptual uniformity has benefits or is required - why?

I think one crucial step to finish the work while avoiding further confusion about mysterious buttons is to do some user research among the aforementioned user groups and then do decide whether and how these buttons should stay in the GUI. Perhaps different histogram views as outlined in [2] could be a solution.

Sad, that the promising space invasion project has stalled. I hope it will not end like the OpenCL efforts.

I checked out Elle's CCE versions of babl, GEGL and GIMP for reference.
To build GEGL with the current ffmpeg library three commits have to be cherry-picked from stock GEGL's master branch:
Commit 28185ee7 by Franz Brausse, 2018-05-06 13:38,
Commit 02f90ebb by Franz Brausse, 2018-05-06 13:40,
ommit d1a6f855 by Øyvind Kolås, 2018-05-06 15:09.

I hope my lines help somebody to get forward in this field.

Best
Steve


[1] R. Griffith, The Truth about Lightroom Colour Management, http://www.colourspace.xyz/the-truth-about-lightroom-colour-management/, retrieved on 08/11/2019.
[2] A. Prokoudine, Work in progress on histogram redesign, https://gui.gimp.org/index.php?title=Work_in_progress_on_histogram_redesign#Adobe_Photoshop,
retrieved on 08/11/2019.

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

[Elle Stone]

On 08/11/2019 04:34 PM, Elle Stone wrote:
> On 07/30/2019 09:07 AM, Elle Stone wrote:
>
>> On approximately 08/11/2019, Steve Pricks wrote:
> (text below copied from Nabble)
>> However, I have not seen buttons like these in any other image editing
>> software, neither commercial nor free/libre (not even in RT with its
>> technology filled GUI).

An actually helpful evaluation of and suggestions for improving the
histogram buttons does require a good understanding of how GIMP works
"under the hood".

* Many operations (eg Normal/Addition?Subtract/Multiply/Divide blend
modes (and a few other blend modes), Gaussian and other blurs,
down-scaling, Exposure, radiometrically meaningful Levels adjustments
including white balancing, Channel mixing, conversions to Luminance
black and white - the list goes on and on) *require* being done on
linear RGB to avoid "gamma" artifacts and produce radiometrically
correct results.

* Many other operations are *designed* to work on perceptually uniform
RGB, for which purpose GIMP uses the sRGB TRC instead of the more
appropriate (imho) Lab "L" TRC. These operations include Luma
conversions to black and white, plus various layer blend modes such as
Soft Light/Hard Light/Screen/Burn/etc, plus no doubt a plethora of
legacy operations and plug-ins.

Either way, and unlike various other editing programs, GIMP does the
appropriate transform between linear and perceptual encoding "under the
hood" to produce correct results, with "correct" defined for each
operation. This is one reason (not the only reason) for the two buttons
(linear and perceptual) in GIMP-2.10.

I'm assuming based on preliminary testing - and hopefully Pippin will
correct me if I'm wrong - that the third button in GIMP-2.99 is to
accomodate use cases such as opening a ProPhotoRGB image encoded using
gamma=1.8 TRC, and wanting to produce results that match PhotoShop when
the "linear" option is disabled in the PS Color Management settings. As
an aside, please note: "linear" option in PS CM settings doesn't affect
all 16-bit editing operations, and 32f editing in PS is handled somewhat
differently than 16-bit integer editing. See this article and try the
tests using PhotoShop at various bit depths:
https://ninedegreesbelow.com/photography/test-for-linear-processing.html

That's all I can write right now. Hope it helps. I'll try to continue
responding to your post tomorrow or hopefully later today.

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

[Elle Stone]

On 08/12/2019 10:07 AM, Elle Stone wrote:
>>> On approximately 08/11/2019, Steve Pricks wrote:
>> (text below copied from Nabble)
>>> However, I have not seen buttons like these in any other image
>>> editing software, neither commercial nor free/libre (not even in RT
>>> with its technology filled GUI).

> On 08/11/2019 04:34 PM, Elle Stone wrote:
> I'll try to continue responding to your post tomorrow or hopefully
later today.

Continuing on where I left off,

>> To get some input from other relevant software I did some checks:
>> Lightroom 8.3.1: Article [1] describes how Lightroom handles this in
>> its Develop module: it works with a profile of ProPhotoRGB gamut and
>> whitepoint. Internally it computes with a linear TRC, but the
>> histogram in the Develop module uses a gamma ~2.21 sRGB TRC (they
>> named it MelissaRGB profile). This sounds similar to GIMPs behaviour,
>> but with a greater color space. (I don't want to revive the old
>> discussions here). I ran a test by converting images to ProPhotoRGB
>> and clicking the "perceptual" button which shows the histogram using
>> the sRGB TRC. It's visually almost equal to LR's histogram in the
>> Develop module and Library module.

Lightroom is somewhat similar to GIMP, in that some (all?) Lightroom
operations are done "under the hood" in linear RGB. But apparently
Lightroom "lies" to you about the TRC encoding, and never let's you see
the linearly encoded histogram, I'm guessing because their intended
audience is used to using perceptual histograms. I think Lightroom is
pretty funny given that for years and years PhotoShop users in various
forums (eg Luminous Landscape) ridiculed anyone editing in linear RGB
color spaces.

But seeing the actual linear histograms is sometimes helpful and
necessary, for example if you want a physically meaningful
"ev/stop-based" presentation at the information captured by your digital
camera. Take a look at software like the old Rawnalyze
(http://dave-anderson-photo.com/blog/2010/08/23/gabor-rawnalyze-author-rip/ 
- closed source Windows software, runs under WINE - an example
screenshot is in Section A of this article:
https://ninedegreesbelow.com/bug-reports/ufraw-highlights.html).

Also, if you have access to Mac, or don't mind reading through the
documentation, take a look at RPP's histograms
(https://www.raw-photo-processor.com/RPP/Overview.html,
https://www.rawdigger.com/usermanual)

Also consider dealing with HDR images. I don't mean tone-mapped images,
I mean actual linearly encoded HDR images, which today's camera raw
files many times actually already are HDR images after an appropriate
middle gray point is set.

GIMP's floating point processing already can be used for HDR images, and
histograms for such images make no sense at all if presented (or
manipulated) using perceptually uniform RGB.

>> Photoshop CC: Histogram view and histogram in Camera Raw Filter look
>> close to the perceptual view.
>> Darktable 2.6.0: No match at all. It shows almost nothing where the
>> other histograms have massive peaks.
>> Darktable 2.7.0+1612~g9e212dc9d-dirty: Shows nothing at all.
>> Krita 4.2.5: Looks like the perceptual view.
>> RawTherapee 5.6.1: Looks like the perceptual view.
>> DxO Optics 11: Looks like the perceptual view.
>> As it seems, the perceptual view is common. Elles lines read as
>> perceptual uniformity has benefits or is required - why?

For Krita and PhotoShop, and also my "CCE" version of GIMP, after
opening an image in any RGB color space, the histogram always and only
reflects the color space's actual TRC.

So for these softwares, if the embedded ICC profile has a linear TRC
(gamma=1.0), then you get a linear histogram. And if the ICC profile has
the sRGB TRC, you get the sRGB-encoded histogram (almost perceptually
uniform). And if the ICC profile has the gamma=1.8 TRC, well, you get
the point.

As an exercise to understanding how GIMP histogram buttons work:

Open an image in the regular sRGB color space in my CCE version of GIMP
or in Krita or PhotoShop. Look at the histogram - it will match GIMP's
perceptual histogram. Then convert the image to one of the linear gamma
versions of sRGB included in my github ICC profile collection (I know
you already have the link to these profiles), and watch the histogram
change to match GIMP's linear histogram.

>> I think one crucial step to finish the work while avoiding further
>> confusion about mysterious buttons is to do some user research among
>> the aforementioned user groups and then do decide whether and how
>> these buttons should stay in the GUI. Perhaps different histogram
>> views as outlined in [2] could be a solution.

The aforementioned user groups aren't using GIMP, and so what works for
the aforementioned user groups is only tangentially relevant to what
will work for GIMP users.

GIMP histograms need improvement in two very different areas:

1. Ability to zoom in on a portion of the histogram to more precisely
view and set points for manipulating, especially important for shadow
tones. For a possible direction on solving this problem see these links
which show histogram interfaces with the option to zoom in:

https://pixinsight.com/doc/legacy/LE/16_histograms/histograms_window/histograms_window.html

https://pixinsight.com/doc/legacy/LE/17_curves/curves_window/curves_window.html 
- Alexandre, as an aside and if you are reading this, it looks like the
old PI did allow Curves manipulation of LCh hue and Chroma - look under
"real time preview" at the bottom of the page.

The above links are documentation for a version of PixInsight that's no
longer available. But the current version of PI runs on Windows and
Linux and can be downloaded in trial mode - I think you need to request
a key - if anyone wants to take a closer look at the Histogram (really
Levels) and Curves interfaces.


2. How to deal with RGB channel values that exceed 1.0f when working
with HDR images. For which the appropriate places to look for existing
implementations of the histogram would be softwares that already allow
to work with HDR images, such as HDR Luminance. Sliding windows seems to
be the usual way to deal with this sort of data. But maybe a logorithmic
scale could also be used. Or perhaps "slide the data" using stop-based
exposure adjustments to bring various portions of the data into view.

Also take a close look at how RawDigger handles histograms:
https://www.rawdigger.com/usermanual/histograms

> On 08/12/2019 06:18 PM, Elle Stone wrote:
>> I used PhotoShop extensively in the past, and I quite much prefer using
>> GIMP, having switched entirely over from PhotoShop to GIMP five or six
>> years ago, long before that horrible CC version was released.

Sorry, that wasn't written very clearly. The last version of PS I used
before switching to GIMP was released long before CC came out. But CC
itself came out quite a few years ago.

Best regards,
Elle

--
https://ninedegreesbelow.com
Color management and free/libre photography
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list