Of course. If someone writes the code, it will be added.

Note that there is already code in GIMP to do the RGB <-> LAB conversion. The
indexed color conversion routine works in CIE LAB internally.

Thank you for your comments. 

There are some parts of image manipulation programs that are so important to
professional photographers, and print shops, that they must be available, or the
program will not be considered for use. Two of these are the LAB mode, and the
CYMK mode. If image captures cannot be converted into either of these spaces, a
great deal of the utility of the other parts of GIMP will not be realized.

By adding these two modes, you will increase you user base, and by extension,
increase your developer base. 

I wish I was talented enough to understand coding, but I am not. I believe that
if you could find someone to address these issues, you will find a much greater
interest and acceptance of GIMP in the marketplace.

Are there still efforts to implement the LAB mode? It is so important for color correction.

Lawrence, Andi : see GEGL (www.gegl.org) The next development cycle (2.5..2.6) is planned for integrating GEGL. After that, implementing LAB mode is a strong possibility. Maybe someone will even manage to do it before 2.6. The likelihood of these things will be much more apparent when the 2.5 dev cycle has actually begun (ie. after 2.4 is released.)

Lawrence: Generally, the developers understand the benefits of a proposed feature, particularly such a fundamental one as this. However, understanding the benefits does not create the time or inclination to actually implement it. Typically, given that OSS development is a hobby to most developers, features are implemented by people who want them strongly enough. Some other types of feature (such as LAB mode) are side effects of implementing more major features (for instance, fully supporting arbitrary colorspaces through GEGL and BABL would introduce basic LAB support, as BABL includes LAB support by default.)

*** Bug 504512 has been marked as a duplicate of this bug. ***

GIMP 2.4.2 for Windows has Decompose to LAB -

in GIMP on the opened image - 
Colors --> Components --> Decompose (choose LAB) 
(and UNcheck Decompose to Layers) 

I've asked this over at the GIMP user forum - but thought I'd ask it here too -

Can someone please kindly explain why the "L" Lightness channel in LAB color mode is so different between the GIMP and Adobe PhotoShop? 

in GIMP on the opened image - 
Colors --> Components --> Decompose (choose LAB) 
(and UNcheck Decompose to Layers) 

I have images of a Macbeth chart - 

Original Color image - 

http://img.photobucket.com/albums/v71/UnknownVT/LED%20colors/Macbeth/MacbethScanN.jpg 

PhotoShop LAB Lightness - 

http://img.photobucket.com/albums/v71/UnknownVT/LED%20colors/Macbeth/deSat_LAB/labmacbethscanncm0T.jpg 

GIMP LAB Lightness - 

http://img.photobucket.com/albums/v71/UnknownVT/LED%20colors/Macbeth/deSat_LAB/MacbethScanN-L_GIMP_labT.jpg 

As can be see the difference is quite substantial. 

I'd be grateful for any comments or advice. 

Many thanks, 

Vincent

Because there isn't support for displaying L*a*b* images -- mapping L* to grey doesn't mean you'll get greyvalues that seem to match the colors, because L* is not linear. Also, the L*a*b* decompose code is probably somewhat wrong.
Anyway: GIMP maps each of the decomposed channels to a grayscale image. Photoshop, I suspect, maps each of the decomposed channels to an L*, a*, or b* image, which means that it understands how to map the L values to a displayable intensity that makes sense. In short, GIMP Decompose only aims to separate the channels, not display them 'realistically' (for now).

You would be better guided by comparing the results of colorpicking a specific area in each application. Actual difference is likely to be much smaller than your images suggest.

Thank you for the very quick reply and advice - much appreciated.

So if the GIMP decompose to LAB code is somewhat wrong -
should it be flagged as a bug?

Many thanks again,

--
Vincent

I don't know for certain. I know that the app/base/cpercep.[ch] files implement the conversion correctly, and that the decompose/recompose plugin does it a different way. To determine whether decompose/recompose plugin does it correctly would require someone to carefully compare the details of the two algorityhms to see if they are functionally equivalent.

Thank you again.

I have used decompose for HSL 
and the "L" Lightness channel in GIMP (2.4.2) matches other photo editors' "L" in HSL that I've tried.

Only in GIMP's decompose to LAB - "L" differs significantly from PhotoShop's "L" in LAB, and easily seen visually.

Thanks,

--
Vincent

That's what I'm saying -- Visual is the main difference. It's quite likely that the results are similar, and you are simply expecting them to *look* similar. I agree that GIMP should try to display L values accurately. However, support for this is waiting on GIMP using GEGL to back the display, and thereby supporting LAB images at all. Any hack to implement this in de/compose would distort the L-values, so the display would accurately portray L equation but the values would be wrong. the de/compose plugins can currently either be correct or look correct, but not both.

Honestly, much of the current operation of de/compose plugins will become irrelevant after GEGL integration. Since GEGL integration is happening.. now.. any effort on the de/compose plugins would probably become quickly obsolete.

I think I got it this time round.

Sorry to have been slow - 
I couldn't reconcile that correct values would display "incorrectly".

But if integration with GEGL would give us LAB color mode that displays correctly - there isn't much point pursuing this.

Thank you for the patient explanation.

--
Vincent

I have just started on learning color correction, read the book http://www.amazon.com/Photoshop-LAB-Color-Adventures-Colorspace/dp/0321356780, and tried to reproduce some of the effects there with gimp, with some success, though in gimp I loose the ability to preview as the final image doesn't come up until I do a recompose.

I am a programmer so I hope to be able to contribute in this area, I might take a stab at this if its not too complicated, I checked the decompose/recompose plugins and saw the equivalent algorithms, I think the idea here is to make the lab channels come up as channels instead of layers, correct?

For the reason why GIMP 2.8/2.6 produces wrong results when decomposing to LAB, see http://ninedegreesbelow.com/photography/lab-lightness-to-black-and-white-gimp28.html

For the reason why GIMP 2.9/2.10 produces slightly visualy wrong results when decomposing to LAB, and also for how to get correct results, see http://ninedegreesbelow.com/photography/lab-lightness-to-black-and-white-gimp29-photoshop.html

For the reason why PhotoShop also produces wrong results in the typical "convert to black and white using LAB" procedure, see "Mathematical mistakes behind the typical PhotoShop tutorial on using LAB Lightness to convert to black and white" (http://ninedegreesbelow.com/photography/lab-lightness-to-black-and-white-gimp29-photoshop.html#photoshop-tutorial-mathematical-mistakes).

As soon as GIMP 2.9/21.0's decompose to LAB will assign a grayscale profile with the LAB L companding curve to the result of decomposing to LAB (and LCH), GIMP 2.9/2.10 will produce correct results when decomposing to LAB (and LCH). *Numerically* the results are correct now, but assigning the built-in GIMP sRGBTRC grayscale profile *misinterprets* the decomposed-to-LAB grayscale values. And dragging from the decomposed-to-LAB grayscale layer stack to an RGB layer stack pushes the wrong interpretation over to the RGB layer stack. 

See these bug reports: https://bugzilla.gnome.org/show_bug.cgi?id=755376, https://bugzilla.gnome.org/show_bug.cgi?id=765178.

As a first step, could you patch up libgimpcolor/gimpcolorprofile
to contain functions that create the gray profiles needed for the
decomposed L, A, B channels? I have no clue where to even start
looking except asking you :)

(In reply to Michael Natterer from comment #16)
> As a first step, could you patch up libgimpcolor/gimpcolorprofile
> to contain functions that create the gray profiles needed for the
> decomposed L, A, B channels? I have no clue where to even start
> looking except asking you :)

Yes, I'll attach a patch for a function that makes a grayscale profile with the LAB L companding curve probably later today or else first thing tomorrow morning.

Created attachment 326294 [details] [review]
patch to make grayscale profile with the LAB companding curve TRC

(In reply to Michael Natterer from comment #16)
> As a first step, could you patch up libgimpcolor/gimpcolorprofile
> to contain functions that create the gray profiles needed for the
> decomposed L, A, B channels? 

I think this is right - I just followed the same pattern as the code for making the other two grayscale profiles. As a test I added code (since removed) to save the resulting profile to disk and then applied it to a decomposed-to-lab layer stack. It does produce correct results. 

I used the D50 white point because LAB for ICC profiles by definition has the ICC profile D50 illuminant white point. But if you prefer the D65 white point it really makes no difference except in a V2 workflow when doing an absolute colorimetric conversion from grayscale to, for example, a printer profile with a different white point than the grayscale profile.

Comment on attachment 326294 [details] [review]
patch to make grayscale profile with the LAB companding curve TRC

That looks perfect :) Let's make this your first commit with your
soon-to-exist git access.

Just two things to fix, simply fix them and push without more review:

- there is trailing whitespace in the patch, please get rid of it
- the new function needs to be added to libgimpcolor/gimpcolor.def,
  in alphabetical order

(In reply to Michael Natterer from comment #19)
> Comment on attachment 326294 [details] [review] [review]
> patch to make grayscale profile with the LAB companding curve TRC
> 
> That looks perfect :) Let's make this your first commit with your
> soon-to-exist git access.
> 
> Just two things to fix, simply fix them and push without more review:
> 
> - there is trailing whitespace in the patch, please get rid of it
> - the new function needs to be added to libgimpcolor/gimpcolor.def,
>   in alphabetical order

Umm, OK, will do.

(In reply to Michael Natterer from comment #19)
> Comment on attachment 326294 [details] [review] [review]
> patch to make grayscale profile with the LAB companding curve TRC
> 
> That looks perfect :) Let's make this your first commit with your
> soon-to-exist git access.
> 
> Just two things to fix, simply fix them and push without more review:
> 
> - there is trailing whitespace in the patch, please get rid of it
> - the new function needs to be added to libgimpcolor/gimpcolor.def,
>   in alphabetical order

I think I did the git push correctly. Please let me know if I did something wrong.

Thanks, almost perfect :) In the future, please use the bug's title for
the commit message's summary (first) line, like this:

  Bug 309485 - Add LAB color mode

  Make grayscale profile with LAB companding curve TRC

So we have a git log reference to bugzilla. And for referencing the
commit in bugzilla, after you pushed, paste the output of "git log -v",
like this:

commit db400d558a5f18a6d6905726f4376f38b88ecfcc
Author: Elle Stone <ellestone@ninedegreesbelow.com>
Date:   Wed Apr 20 17:01:17 2016 -0400

    Make grayscale profile with LAB companding curve TRC

 libgimpcolor/gimpcolor.def      |  1 +
 libgimpcolor/gimpcolorprofile.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 libgimpcolor/gimpcolorprofile.h |  1 +
 3 files changed, 68 insertions(+)

Then mark the attached patch as "committed" in bugzilla.

Although this bug report started as a request to have a "Mode" for LAB, way back in 2005, by now (2017) it's already possible to do many typical LAB edits in GIMP-2.9, even without a LAB Mode. 

It's not clear to me how an actual LAB Mode would be more beneficial than simply expanding the currently available LAB edits, such as adding L/A/B Curves and such (see Bug 43293), plus adding the ability to import and export image files in the LAB color space. This thread from the GIMP developer's mailing list outlines some possibilities: http://gimp.1065349.n5.nabble.com/Adding-LAB-support-to-GIMP-td52176.html

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/155.