LAB Lightness to black and white using GIMP 2.8

Introduction

This article explains mathematically correct and incorrect ways to use GIMP 2.8 to convert to black and white using GIMP's "decompose to LAB".

Somewhere on the internet there might be an article or tutorial that shows how to make a mathematically correct conversion from the LAB "L" channel to black and white. But the ones I've read — whether written for PhotoShop or GIMP — are based on mathematical and "color management" mistakes. This doesn't mean the resulting black and white image might not be useful or pleasing. It does mean that GIMP and PhotoShop users are being misled (however unintentionally) about the actual nature of the LAB Lightness channel.

Figure 1 below shows a color photograph of variously colored glass objects. The scene was set up to capture some nicely saturated red, green, and blue color gradients:

Now let's see what you actually get when following various tutorials on the internet for converting to black and white using the LAB "L" channel. If you want to follow along and verify results shown below (highly recommended — you'll learn a lot more by doing than by just reading), here's a downloadable 16-bit png version of the color photograph in Figure 1, licenced as CC-BY-SA 3.0 unported.

The commonly recommended "decompose, drag, and drop" produces incorrect results

Comparing Figures 2 and 3, it's obvious that the commonly recommended procedure for using GIMP 2.8 to convert to black and white using the LAB Lightness channel doesn't actually produce an RGB rendition of the LAB Lightness channel. There are several mathematical mistakes that result from following the "decompose, drag, and drop" procedure, but the major mistake is that a correct conversion to LAB requires linearized RGB values:

The mathematically correct procedure requires linearized RGB

Choking a mathematically correct LAB Lightness conversion to black and white out of GIMP 2.8 is possible, but it's made difficult by a combination of factors:

1. Converting to LAB requires working with linearized RGB. For GIMP 2.8, this means converting from GIMP's built-in sRGB profile to a suitable linear gamma version of the sRGB profile, and not every GIMP user has such a profile handily available.
2. Even after converting to a linear gamma sRGB profile, results won't be exactly right because GIMP 2.8 is hard-coded to convert from sRGB to LAB using slightly incorrect values for the sRGB profile's red, green, and blue primaries (this was legacy code and has been corrected in GIMP 2.9).
3. Because GIMP 2.8 only works with 8-bit integer data, converting to a linear gamma sRGB profile means you have a 100% chance of posterizing the shadow areas of your image.

Here's how to get "reasonably close to mathematically correct" LAB "L" conversion to black and white using GIMP 2.8:

1. Convert the color image to a suitable linear gamma sRGB profile ("Image/Mode/Convert to Color Profile").
2. Do "Colors/Components/Decompose" and choose Color model "LAB", making sure "Decompose to layers" is checked and "Foreground as registration color" is not checked.

   The decomposed "L" channel in the image to the right looks pretty close Figure 2 above. But if you follow this procedure and do a side-by-side comparison, you'll see that the shadows in the decomposed LAB "L" channel look a little darker and the highlights look a little brighter (unless you picked an "RGB profile" for "Edit/Preferences/Color Management/RGB profile", in which case what the "L" channel looks like depends on what profile you picked).

   The reason for the visual discrepancy is complicated, but in brief: In order to display the image, GIMP 2.8 has to assign an ICC profile to the image. So for purposes of displaying the "decomposed to LAB" grayscale image, it seems to (I haven't looked at the actual code) treat the image as if it were an RGB image instead of a grayscale image. And it assigns the GIMP built-in sRGB profile, which doesn't have quite the right TRC to properly display the image

   Or if, in Preferences, you chose a non-sRGB profile for the RGB working space, it displays the image "as if" it were an RGB image to which your chosen RGB working space had been assigned. So what you actually see depends on your monitor profile and your chosen RGB working space (which really should be left at "none").

   The technically correct ICC profile to assign to GIMP's "decomposed to LAB" layer stack would be a grayscale profile with the LAB L TRC, but GIMP 2.8 doesn't color-manage grayscale images.

   As an aside and in case you are wondering, the result of dragging the LAB "L" layer from the LAB layer stack to the RGB layer stack is completely independent of your "Preferences/Color Management" choices.

3. Don't drag the "L" channel over to the linear gamma color image! Instead, using the color picker dialog, select the color R=G=B=128, and use "Bucket Fill" to fill the entire A and B channels with gray. Make sure you choose "Fill whole selection" under the Bucket Fill Tool Options, because you want to fill the entire A and B channels with solid gray (you don't need to make an actual selection, but if you do, select the entire A and B layers before using the Bucket Fill).
4. Recompose the LAB layer stack to RGB ("Colors/Components/Recompose").

   And now you have a mathematically correct LAB "L" to conversion to black and white, except for posterized shadows and data loss from doing all these color space conversions on 8-bit (and especially 8-bit linear gamma) data, plus any small errors resulting from GIMP 2.8's slightly incorrect sRGB XYZ primaries. But you aren't done yet!

5. Convert the recomposed RGB image from the linear gamma color space that you converted it to in Step 1 above, back to GIMP's built-in sRGB color space. This is an absolutely crucial step for several reasons:
   1. If you plan to export the image to disk as a jpeg, the jpeg compression process produces horrible artifacts in linear gamma images (try it for yourself, jpeg output from a linear gamma sRGB image can produce some pretty spectacularly unpleasant results).
   2. Images displayed on the internet should never be left in a linear gamma color space because most people's browsers aren't color-managed, and so these people will see the wrong tonality.
   3. Images sent out to be printed usually should be converted to the regular sRGB color space (depending on the print shop), and if you send out a linear gamma sRGB image instead, you'll get back a print with the wrong tonality.

See the solid dark band in the glass in the lower right corner (the blue glass in the original color image)? This conversion is mathematically correct, or as correct as possible when using GIMP 2.8. But compared to Figure 2 above (which was done using high bit depth GIMP 2.9), this conversion suffers from data loss (posterization) in the shadows, caused by multiple color space conversions done on 8-bit integer RGB data.

When using GIMP 2.8, the mathematically correct procedure produces severe shadow posterization

OK, a more or less mathematically correct conversion to black and white using the LAB "L" channel can be done using GIMP 2.8. But assuming you start with a regular sRGB image, the process requires:

1. Converting the original color image to a linear gamma version of the sRGB color space.
2. Decomposing to LAB and filling the A and B channels with the right shade of gray.
3. Recomposing to RGB.
4. Converting from the linear gamma sRGB color space back to the regular GIMP built-in sRGB color space.
5. And if the original image isn't already an sRGB image, first you have to convert from whatever color space the image is in, to GIMP's built-in sRGB color space.

That's a lot of color space conversions (decomposing to LAB and recomposing from LAB count as color space conversions). With GIMP 2.8, perforce you are doing all these conversions on 8-bit integer data. This is a really bad idea. Every single one of these 8-bit integer color space conversions involves the potential for data loss, or rather the certainty of data loss — the real question is "how much and how visible":

The left side of the above screenshot shows a close-up crop from the image before and after converting to linear gamma sRGB (top and middle rows), and after finishing the mathematically correct procedure for converting to black and white using LAB Lightness (bottom row).

The right side shows the same crop, except a Levels adjustment was done to better show the posterized regions and also to give an idea of the problems that arise when trying to edit an image that has been damaged by severe data loss from 8-bit color space conversions.

• Top row: The original sRGB image doesn't show any evidence of posterization. All tonal transitions are smooth.
• Middle row: When making a mathematically correct conversion to black and white using the LAB "L" channel, Step 1 is converting the image to a linear gamma version of the sRGB color space. The image already shows obvious data loss — the shadows are posterized. Posterization happens "channel by channel" — notice the mottled purple splotches on the inside of the blue glass.
• Bottom row: By Step 5, the image has been converted to linear gamma sRGB, decomposed to LAB, recomposed to RGB, and converted back to the regular sRGB color space, resulting in extreme shadow posterization.

So if you want to use GIMP to make a mathematically correct conversion from LAB Lightness to black and white, that doesn't have severely posterized colors from the accumulated data loss resulting from multiple color space conversion using 8-bit integer data, use GIMP 2.9 (the development version) or else wait for GIMP 2.10 to be released.

Summary and conclusion: "Mathematically incorrect" is not an aesthetic judgement, but it would be nice if tutorials also showed correct results

When using GIMP 2.8, the usual "decompose, drag, and drop" method of converting from LAB Lightness to black and white produces wildly mathematically incorrect results, mostly because a mathematically correct conversion to LAB requires that the image RGB data be linearized.

In GIMP 2.8, making a mathematically correct conversion to LAB requires multiple 8-bit integer color space conversions, which results in accumulated data loss and posterized shadows.

"Mathematically incorrect" is a statement about the underlying math. It's not an aesthetic judgement about the result. If your workflow requires making a conversion from LAB Lightness to black and white:

• The only way to avoid severe shadow posterization when making a mathematically correct conversion from LAB Lightness to black and white is to operate on high bit depth RGB data, preferably 32-bit floating point RGB data.
• When working with 8-bit integer RGB data, mathematically incorrect results will probably serve your editing purposes better than mathematically correct results that are severely posterized from the required multiple color space conversions.
• Sometimes mathematically incorrect results are exactly what you want. Nonetheless, it would be nice if tutorials didn't mislead users about the actual nature of the LAB Lightness channel.

See LAB Lightness to black and white using GIMP 2.9 and PhotoShop for mathematically correct and incorrect conversions from LAB Lightness to RGB black and white using GIMP 2.9 and PhotoShop:

• Getting a mathematically correct conversion from GIMP 2.9 is surprisingly easy, but it doesn't involve decomposing to LAB.
• The usual PhotoShop tutorial on using LAB Lightness to convert to RGB black and white produces mathematically incorrect results for a somewhat surprising reason: what you actually get depends on your Color Settings for the Gray Working Space.