Notice that if you perform a Midtones correction of about 2.2 on Wikipedia's CIELAB L channel then the result roughly approximates GIMP's L channel decomposition. (Conversely, apply a Midtones correction of 0.45 to GIMP's L channel and compare results).

GIMP documentation says "The LAB color model is used by Photoshop" but from what I have seen this is not true unless there's some small detail about GIMP's decomp that we are overlooking.

For example, one effect I like to do from time to time is a luminosity inversion. In (an old version of) Adobe Photoshop I could simply switch the image from RGB to LAB color mode and invert the L channel. But I cannot do the same thing in GIMP using its LAB color space decomp because the yielded L channel is a magnitude too bright -- but! if I add the aforementioned midtones correction to my steps I do get results that are comparable to Adobe Photoshop.

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

From: stecnico0506@hotmail.com To: gimp-developer-list@gnome.org
Date: Sun, 18 Dec 2011 11:36:38 -0300 Subject: [Gimp-developer] Luminosity in LAB does not agree with Wikipedia or Matlab

Hi, In this article
http://en.wikipedia.org/wiki/HSL_and_HSV is displayed an image (http://en.wikipedia.org/wiki/File:Fire_breathing_2_Luc_Viatour.jpg) and its luminosity
(http://en.wikipedia.org/wiki/File:Fire-breather_CIELAB_L*.jpg). However, if I apply Colors-Components-Decompose-LAB in Gimp, the image L does not agree. The same happens with Matlab.

I'm not sure if this is an error in the program or a documentation problem. In the last case, for example, the LAB model of Gimp is not the CIELAB model, or the model is CIELAB but they use different white points.

Greetings, Adrián del Pino N.

From: strata_ranger@hotmail.com
To: gimp-developer-list@gnome.org
Date: Sun, 18 Dec 2011 10:59:32 -0800 Subject: Re: [Gimp-developer] Luminosity in LAB does not agree with Wikipedia or Matlab

Notice that if you perform a Midtones correction of about 2.2 on Wikipedia's CIELAB L channel then the result roughly approximates GIMP's L channel decomposition. (Conversely, apply a Midtones correction of 0.45 to GIMP's L channel and compare results).

Found a faster way to demonstrate it: Create a new image with a black-to-white linear gradient running from left to right across the image (i.e. even distribution of grey tones). Decomposing the image into LAB space does not yield an even distribution of values across the L channel, but something that more closely resembles a Midtones adjustment in the 2.2 to 2.5 range.

-- Stratadrake strata_ranger@hotmail.com
--------------------

What you have not quite said, Richard, is that this adjustment is the one that you would need in order to correct linear RGB to standard sRGB -- so the output of GIMP is not gamma corrected. IMO this is correct, since gamma-correcting would introduce inaccuracies and also reduce precision (which in this case is already limited to 1/256.). The wikipedia images are based on converting the L to rgb by treating the AB channels as if they were zeroed. This produces an image that *looks* accurate but is mathematically inaccurate.

Date: Mon, 19 Dec 2011 08:52:39 +1030 From: 00ai99@gmail.com
To: stecnico0506@hotmail.com
CC: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Luminosity in LAB does not agree with Wikipedia or Matlab

What you have not quite said, Richard, is that this adjustment is the one that you would need in order to correct linear RGB to standard sRGB -- so the output of GIMP is not gamma corrected. IMO this is correct, since gamma-correcting would introduce inaccuracies and also reduce precision (which in this case is already limited to 1/256.). The wikipedia images are based on converting the L to rgb by treating the AB channels as if they were zeroed. This produces an image that *looks* accurate but is mathematically inaccurate.

That is the part I was not sure about, but I erred on avoiding speculation and chose to just make observations as I came across them.

Out of curiosity I looked through the C source for the decompose plugin and noticed that the LAB decomp actually performs a cube root (and offset) of its input values during its calculations, which is why a linear input gradient produces a nonlinear result.

But as stated by the original poster this behavior is incompatible with the results produced by Adobe Photoshop or Matlab using their LAB color modes -- Wikipedia states that "uniform changes in L*a*b* components should correspond to uniform changes in perceived color" -- not the absolute color intensities, but its perception. IMO, if you take a greyscale gradient that looks linear and uniform in GIMP's native RGB space and decompose it to LAB, the L channel should still look linear.

Perhaps there can be an additional L*a*b* color option added to the plugin that incorporates the gamma correction into its processing? Performing it manually after the decomp does lose some quality in the color channels for obvious reasons, but if it could be included as part of the plugin's execution then it would not.

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

Richard Gitschlag wrote:

Out of curiosity I looked through the C source for the decompose plugin and noticed that the LAB decomp actually performs a cube root (and offset) of its input values during its calculations, which is why a linear input gradient produces a nonlinear result.

Perhaps there can be an additional L*a*b* color option added to the plugin that incorporates the gamma correction into its processing? Performing it manually after the decomp does lose some quality in the color channels for obvious reasons, but if it could be included as part of the plugin's execution then it would not.

How about just implementing the conversion correctly ? To convert from RGB to L*a*b*, one has to convert from RGB to XYZ, then XYZ to L*a*b*. A typical working RGB space (like sRGB, AdobeRGB etc.) has a gamma encoding. So RGB to XYZ removes the gamma encoding (since XYZ is linear light), and then L*a*b* uses a 1/3 power which models perceptual linearity. Of course to display an L*a*b* value you have to convert it to XYZ and then to the display's RGB space. [And yes there are many possible avenues for optimising the performance of such conversions.]

Graeme Gill.

Date: Tue, 20 Dec 2011 07:04:20 +1100 From: graeme2@argyllcms.com
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Luminosity in LAB does not agree with Wikipedia or Matlab

How about just implementing the conversion correctly ? To convert from RGB to L*a*b*, one has to convert from RGB to XYZ, then XYZ to L*a*b*. A typical working RGB space (like sRGB, AdobeRGB etc.) has a gamma encoding. So RGB to XYZ removes the gamma encoding (since XYZ is linear light), and then L*a*b* uses a 1/3 power which models perceptual linearity. Of course to display an L*a*b* value you have to convert it to XYZ and then to the display's RGB space. [And yes there are many possible avenues for optimising the performance of such conversions.]

Graeme Gill.

_______________________________________________

gimp-developer-list mailing list

gimp-developer-list@gnome.org

http://mail.gnome.org/mailman/listinfo/gimp-developer-list

If an image's raw RGB pixel values represent perceptual linearity (when viewed through your standard RGB monitor), and L*a*b* values also model perceptual linearity, it should logically follow that converting a linear greyscale gradient from one to the other should yield a linear gradient on the Y* value (like you get from performing an RGB -> YCC conversion), despite that the decomp must account for gamma encoding during the intermediate steps.

And this is not what you get when running a LAB decomp in GIMP.

So . . . yeah, I'm totally in agreement here.

-- Stratadrake strata_ranger@hotmail.com
--------------------

Richard Gitschlag wrote:

If an image's raw RGB pixel values represent perceptual linearity (when viewed through your standard RGB monitor),

Well, no they don't. They're whatever the device space makes them. Yes CRT displays native behaviour makes it roughly perceptual, which is why such display spaces are good to encode in, but the precise relationship to anything else is device dependent (hence ICC profiles).

and L*a*b* values also model perceptual linearity, it should logically follow that converting a linear greyscale gradient from one to the other should yield a linear gradient on the Y* value

I'm not sure what you mean by "Y*". Any conversion should yield the same color values (assuming you don't hit gamut limits), so there should be no change in appearance. If on the other hand you mean "re-interpret the same numbers in a different colorspace", then yes, what looks perceptually linear in a gamma encoded RGB space should look roughly perceptually linear in L* space. Normal CRT gamma curves and the L* curve are not a precise match though. If one or other are not true of GIMP, then it has a problem....

Graeme Gill.

Hm, it seems I had my thinking a bit mixed up when I was typing my last response, because when I typed "Y*" I actually meant to say "L*". (Color management terminology is something of a "New Math" for me, so I have to wing it.)

Other than that I agree: GIMP's current LAB decomposition does not work "correctly" because it does not account for gamma encoding in the soruce RGB values. It takes the input values as representations of linear intensity (not gamma-encoded perceptual intensity) and produces the corresponding LAB values for that -- mathematically correct in context, but it's missing an important step in the process.

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

Date: Tue, 20 Dec 2011 08:43:09 +1100 From: graeme2@argyllcms.com
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Luminosity in LAB does not agree with Wikipedia or Matlab

Richard Gitschlag wrote:

If an image's raw RGB pixel values represent perceptual linearity (when viewed through your standard RGB monitor),

Well, no they don't. They're whatever the device space makes them. Yes CRT displays native behaviour makes it roughly perceptual, which is why such display spaces are good to encode in, but the precise relationship to anything else is device dependent (hence ICC profiles).

and L*a*b* values also model perceptual linearity, it should logically follow that converting a linear greyscale gradient from one to the other should yield a linear gradient on the Y* value

I'm not sure what you mean by "Y*". Any conversion should yield the same color values (assuming you don't hit gamut limits), so there should be no change in appearance. If on the other hand you mean "re-interpret the same numbers in a different colorspace", then yes, what looks perceptually linear in a gamma encoded RGB space should look roughly perceptually linear in L* space. Normal CRT gamma curves and the L* curve are not a precise match though. If one or other are not true of GIMP, then it has a problem....

Graeme Gill.

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list