GIMP 2.9 now has an LCH Hue-Chroma tool plus LCH Color Sliders

People keeping up with the development branch of GIMP have probably noticed that GIMP 2.9 now has an LCH Hue-Chroma tool, plus LCH Color Sliders in the “Change Foreground/Background” and “Colors” dialogs.

If you’ve already seen the new LCH Color Sliders, then chances are good that you might be shaking your head and asking “What were the devs thinking when they added this stuff to GIMP’s color picking tools? And what’s with all the magenta covering up the colors in the sliders and panels?”

GIMP’s LCH color tools are amazing, in fact they’ve completely changed the way I edit and paint (the LCH tools have been in my patched “gimp-cce” version of GIMP for a long time). So I’m hoping to use this thread to help answer questions GIMP users might have about these new tools, such as:

  • What is LCH?
  • What are some differences between using LCH and HSV to pick colors and make color palettes?
  • How do you interpret the LCH color sliders and corresponding color panels?
  • What artistic problems can LCH solve, that aren’t so easy to solve using HSV, and vice versa?
  • How can the LCH color tools be made more intuitive and user-friendly?

My normal inclination when explaining “color stuff” is to write tutorials. But this approach can easily deluge people with information they don’t need, without ever getting around to what they actually want to talk about. So I’m going to change tactics and instead try to help answer specific questions from people who are experimenting with GIMP’s new LCH tools. In the event that no-one asks any questions, at least I won’t have spent the time it would have taken to type a tutorial! :slight_smile:

5 Likes

hi @Elle, if I want to experiment with LCH and have GIMP do most of the adjusting of a photo, what practical approach would you suggest re. raw conversion. I use RT. I’m thinking I shouldn’t do too much adjusting in RT otherwise there is little for GIMP LCH to do. But on the other hand, the most resolution I believe you can get out of RT is a 16bit tiff. So if you then do significant shifts in GIMP, perhaps quality will suffer. If I do the adjustments in RT, I think it’s all done via 32bit floating point up to the point of output.

Perhaps you have a fair idea about the GIMP roadmap? Do you have any idea when re-vamped processing will appear in the Curves and Levels tools please?

(My GIMP is 2.9.5 with commit ending …f766)

Hi @RawConvert ,

As far as editing in GIMP starting with a 16-bit file, if you promote the precision to 32f upon import, then quality won’t suffer even with significant shifts. Well, at least this has been my experience, and I sometimes subject image files to a whole lot of editing.

You’ve pinpointed two approaches to editing: do as much as possible in the raw processor, or start with scene-referred output (minimal processing in the raw processor) and do the “make pretty” processing in GIMP. The latter is the approach that I use, but that doesn’t mean it’s the right approach for you. It partly depends on what kind of edits you want to use LCH for (about which I’d be very interested to hear what you are doing and how it works out). Anyway, try both approaches and see which one you like.

An important consideration regarding the adequacy of 16-bit integer output is the question of whether your output profile (in which the interpolated file is saved to disk) has a large enough color gamut to include all the colors that were captured by your camera, as interpreted by your camera input profile. It’s an unpleasant fact that the colors in interpolated camera raw files can easily exceed the sRGB color space, and in fact can exceed the color gamut of very large RGB working spaces such as Rec.2020. This is especially true of images that contain saturated bright yellows and yellow green (eg bright yellow flowers), and dark saturated violet blues (eg neon signs). Saving to disk using 32f precision (as eg darktable allows) means colors are not clipped by the act of saving them to disk and opening them with GIMP. But when exporting to disk at 16-bit integer, any out of gamut colors that are still in the file will be clipped upon export.

So an important question is what output color space do you plan to use with RT? Default GIMP requires images that are in the regular sRGB color space. But if the image contains a lot of saturated colors, you can export from RT in a larger color space that hopefully holds all the image colors (but again, bright yellows and dark violet blues can be problematic even for very large output color spaces). Then open the image with GIMP, change the precision to 32f, and then convert to GIMP’s built-in sRGB color space - at 32f colors won’t be clipped by the conversion. That’s the good news. The bad news is you’ll need to learn how to deal with any resulting out of gamut colors to bring them into gamut. Otherwise when you export the finished image to disk as a jpeg or png or integer-precision tiff, you might be surprised and dismayed by color shifts from clipped colors.

I don’t know the GIMP roadmap other than what’s on the GIMP website. What revamped processing are you referring to for the Curves and Levels tools? Do you mean defaulting to linear processing instead of processing RGB data that’s encoded using the sRGB TRC? In any event, I don’t know the timetable. When was your version of GIMP compiled? The LCH Hue-Chroma tool was added only a short time ago, and the LCH color sliders were added just a few days ago. So this is really new and worth updating to get.

Thanks @Elle for this. I will need to experiment and digest what you’ve said, I still have some way to go getting my brain around colour, spaces & manipulations! I have Gimp 2.9.5 at present but I see there is a 2.9.6. I get Gimp via a PPA so will wait for 2.9.6 to come through.

Re. curves and levels, yes, it was the linear processing.

One piece of detail though where you say “convert to GIMP’s built-in sRGB color space - at 32f colors won’t be clipped by the conversion”. I was thinking that if you have an extreme colour on input, then it won’t fit into sRGB because this is a small-ish space, and that’s regardless of what format the numbers are stored in. I.e using 32bit fl.pt. means the arithmetic is more accurate, but doesn’t change the basic value a pixel has, so when converted to sRGB will become out of gamut. I expect there’s a flaw in this, but what is it?!

Floating point values do not only provide higher accuracy, but also allow for unbounded processing, I.e. values below 0 or above 1.

Therefore, out-of-gamut colors are representended by out-of-bound values (unless the conversion is explicitly clipped to [0…1]

Correct me if I am wrong: many tools in the default GIMP are hard-coded to sRGB, so while it would be ideal to be in 32f and a generous color space it is impossible at this time. The gift of 32f is that even though there is the initial clipping we are able to maintain a least some accuracy within the limitations we are given. For this reason, I tend to use pure G’MIC because sorting through this stuff makes my head explode. :blush:

1 Like

In addition to being done at floating point precision (and exporting to a file format that supports floating point precision), also the destination ICC profile color space has to support an unbounded conversion without clipping either the negative channel values or the channel values that are > 1.0 floating point.

Fortunately GIMP’s build-in sRGB color space does support such unbounded conversions.

My github V4 ICC RGB working space profiles (GitHub - ellelstone/elles_icc_profiles: Elle Stone's Well-Behaved ICC Profiles and Code) with parametric sRGB/LAB/Rec709 and gamma=1.0 companding curves support such unbounded conversions. So do any other RGB ICC working space profiles with these same TRCs.

However, if the destination color space is a profile with a higher gamma TRC (gamma=1.8, gamma=2.2, etc) negative values are clipped upon conversion.

And if the destination color space is a profile with a point curve TRC (V2 profiles with the sRGB/LAB/Rec709 companding curves, and also some V4 profiles made with point TRCs) then both negative and positive values are clipped upon conversion. FWIW, RawTherapee used to - I think still does - ship some ICC profiles with point curves, that would otherwise support unbounded floating point precision. But as RT doesn’t yet output at floating point precision, this isn’t really a problem, yet.

Most people (including me) would like to not have to worry about such details. But when working at 32f precision, it can sometimes be very useful to have such information available.

This is true. Many operations in default GIMP are hard-coded to sRGB. In fact essentially all default GIMP operations are hard-coded to sRGB because much background processing assumes the image has the sRGB TRC.

What I meant to say, tried to say, is that upon opening an image in GIMP that’s in a larger gamut color space, first promote the precision to 32f and then convert to GIMP’s built-in sRGB color space. And then you can edit in the sRGB color space without having clipped any values. This is not an ideal situation because of two reasons:

  1. It’s not easy to learn the nuances of dealing with any resulting out of gamut channel values. But it’s worth doing so because of the things it allows you to do, that you can’t do otherwise. See this article for some examples: Edit tonality and color separately using high bit depth GIMP - the article is somewhat out of date because default GIMP now does have full LCH support.

  2. Many - but not all - editing operations produce different results in different RGB working spaces:

The good news is that GIMP’s LAB/LCH operations are color space independent - once you’ve done an unbounded conversion from sRGB to LAB/LCH, the resulting LAB/LCH channel values are exactly the same as what you’d have gotten if you had converted to LAB/LCH from some other, larger color space.

Many other editing operations also are color space independent, for example scaling an image larger or smaller, gaussian blur, etc. But taking advantage of editing operations that are color space independent requires knowing which operations fall into which category.

Well, 32f also allows to do true HDR processing, which is a field that a lot of people are interested in moving into and many already have moved into.

G’MIC also is hard-coded to sRGB. Take a look at the code, sRGB parameters are all over the place. There’s no provision for extracting the image’s actual ICC profile and using the parameters of the image profile for conversions to XYZ/LAB/LCH. Not to mention the various operations that use sRGB Y values for Luma/Luminance.

The good thing is that the stdlib code is open for perusal, though I cannot speak for the native commands. Generally, I avoid commands that need sRGB to function, or attempt :persevere: to write custom code to compensate. I also rely on a raw processor like PhotoFlow to prep the image for G’MIC processing. Maybe I am getting it all wrong… Thanks for your expertise, @Elle. Color management will always confound me :blush:. @David_Tschumperle, any thoughts on the matter?

What is LCH?
I assume that this is LCHab since LAB is supported and discussed extensively. However, I have always had a nagging question about the role of LUV and LCHuv, practically speaking – just a curiosity really because CIELUV does exist. I.e., should we care about it?

Some links that might help stimulate this conversation:

  • CIELAB color space - Wikipedia

  • CIELUV - Wikipedia
    “It is extensively used for applications such as computer graphics which deal with colored lights. Although additive mixtures of different colored lights will fall on a line in CIELUV’s uniform chromaticity diagram (dubbed the CIE 1976 UCS), such additive mixtures will not, contrary to popular belief, fall along a line in the CIELUV color space unless the mixtures are constant in lightness.”

  • Colorimetry - Systems CIELAB and CIELUV
    “The CIE recommends using the CIELUV color space for the characterization of color displays [and] using the CIELAB color space for the characterization of colored surfaces and dyes.”

  • http://www.imagemagick.org/Usage/color_mods/
    “Note that for very dark colors the ‘LCHuv’ can generate color values with discontinuities. This however should not happen for real images, only images generated directly in the cylindrical space.”

In GIMP, LCH is LCH(ab). There is no code for LCH(uv). To be more explicit, in GIMP LAB and LCH are both 1976 LAB/LCH, with the D50 reference white as per the ICC specs (http://color.org/specification/ICC1v43_2010-12.pdf, Annex D). Otherwise the reference white for ICC profiles would be different from the reference white for LAB/LCH.

@afre - you are the second person to ask me about CIELUV, the other person asked just two days ago - something in the air?

Anyway, I don’t know anything CIELUV or about using CIELUV. This color space hasn’t been used in any of the software that I’ve ever used for editing, and I’ve never thought twice about it, other than I think I looked at the equations once.

I’m not sure whether CIELUV is attracting much attention these days. The people who deal with HDR video and such are very busy trying to figure out optimal ways to deal with HDR images and with the up and coming Rec2020 displays, and I don’t think CIELUV is something that’s being discussed in this context, but if you are curious, here are some links to some interesting materials on these topics:

https://pdfs.semanticscholar.org/1c83/520be9486ebdcdfa597108e983bca16f3f2f.pdf

http://rit-mcsl.org/fairchild/PDFs/PRES19.pdf

Above two links are by Mark Fairchild, and the second link is a slide presentation with lots of pictures. These are about trying to extend LAB to HDR imaging.

https://www.dolby.com/us/en/technologies/dolby-vision/measuring-perceptual-color-volume.pdf

Above two links are oriented to Rec2020 displays.

LAB/LCH is not the final word on “true perceptual uniformity”. JAB/JCH improves on LAB/LCH, though “how” or “why” is beyond my limited knowledge base. Unlike LAB/LCH, JAB/JCH deals not just with “just noticeable differences” but also with color appearances, which means JAB/JCH tries to accomodate observations such as the fact that a bright saturated color looks brighter than the same color after doing a luminance conversion to black and white, and the fact that putting two colors next to each other alters each color’s appearance, compared to viewing each color alone.

But even JAB/JCH isn’t perfect - for example apparently neither LAB/LCH and JAB/JCH are as good as one would like when dealing with blue hues going from dark to light, though JAB/JCH apparently is better than LAB/LCH. I say “apparently” because I’m just summarizing the gist of observations made by people who know a whole lot more than I do - I don’t want to give anyone the idea that I’m an expert in these fields, because most definitely I am not!

Color scientists are actively working on figuring out newer models that might work better at capturing how we perceive colors. - this is an area of very active research, most of which goes right over my head.

That is okay. Was wondering if you came across it due to your interest in color management. Oddly, I only ever used LCHuv upon discovering LCH years ago. I don’t remember why. Anyway, I would have loved to talk about other spaces such as JAB/JCH, etc., but then we would be off topic again. :blush:

How did you use LCHuv? I’ve never seen LCHuv tools in any image editor that I’ve used. I’m guessing you were using a command line tool?

Well, it wouldn’t be that far off-topic. One major inspiration for my interest in LCH is the handprint.com website, which has a wealth of color information, much of which is given in terms of JAB/JCH. I’ve been using this information when choosing colors for painting.

LCH is “more or less close to JCH”, but JCH color sliders would be a nice thing to have. I’m trying to increase my understanding of JAB/JCH. The math is rather more complicated than is the case for LAB/LCH.

If anyone consults the handprint.com website for color information (well worth doing), please be aware that his LAB/LCH and JAB/JCH values are all relative to D65, not D50.

A bit of information and two LCH color wheels:

XYZ is based on color matching experiments and reflects the linear behavior of light.

LAB is intended to be a perceptually uniform mathematical transform of XYZ, such that equal distances between pairs of LAB coordinates cohere with our perception of “equally far apart colors”.

LCH is a straight-foward polar transform of LAB. This means that an LCH color wheel is also a LAB color wheel. Given the a and b coordinates of any LAB color located on the LAB/LCH color wheel:

  • LCH “Chroma” is the square root of the sum of the squares of a and b (this is just the mathematical formula for calculating the distance of a point on a 2D cartesian graph to the intersection of the two axes).

  • LCH “Hue” is the angle between the positive “a” axis (Hue=0/360) and a line drawn from the color’s (a,b) coordinates to the intersection of the a and b axes (where a=b=0).

The third axis of both the LAB and LCH color spaces is “L” for “Lightness”. The “Lightness” axis is perpendicular to the ab/Hue-Chroma plane. So you would need a 3D “LCH color sphere” to show all three axes at once.

The handprint.com website has a nice downloadable LAB color wheel that shows the LCH Hue angles and Chroma values for commonly used watercolor pigments. Directly posting images from the handprint.com website would violate the handprint.com copyright, but here’s the link if you want to download the color wheel for personal use: handprint : CIELAB ab plane.

Here is a blank LCH color wheel licensed as CC-BY-SA in case anyone wants to try their hand at using the new GIMP LCH color readouts to locate sRGB colors on an LCH color wheel:

It’s interesting to see where the sRGB red, green, and blue primaries fall on the LCH color wheel. For example sRGB bluest blue (0.0f, 0.0f, 1.0f) has an HSV Hue of 240, but an LCH Hue of 301, which is decidedly on the magenta side of LCH violet-blue.

Actual sky-blue colors - measured as wavelengths and converted to LAB/LCH - are centered at roughly LCH Hue 250-255, but vary quite a bit between LCH cyan-blue and LCH violet-blue, depending on a host of factors that affect the color of a blue sky. So a naive interpretation of HSV Hue 240, might lead one to assume that sRGB’s bluest blue really is “blue sky blue”, but this would be incorrect.

@afre - you’ve mentioned difficulties with dealing with colors. I have the same problem when painting and when modifying colors in photographs, which is a major reason why I started making use of LCH color information. I figure that if my blue sky is in the range of believable sky blue colors, and my green leaves are within the range of normal healthy green plant colors, and so on, that’s a good thing!

Good idea. I keep notes on all sort of things: why not do the same for colors?

Same here. What got me interested in image science was partly the result of trying to keep colors and tones sane out of camera and during post-processing; in my case, it was mostly due to people’s faces being in mixed and poor lighting situations without useful grey references.

I put up a web page with some notes on LCH compared to HSV:

http://ninedegreesbelow.com/photography/lch-vs-hsv-for-picking-colors.html

I’d like to put together one or two tutorials on using LCH to pick colors, that hopefully could be tutorials for gimp.org and/or pixls.us, and would incorporate comments, input, images, and such from this thread.

As you all know, I tend to be too technical and too detail-oriented :slight_smile: . So any input/help in writing actually useable tutorial(s) is greatly appreciated.

So far the tutorial notes somewhat cover these topics:

  1. Picking colors.
  2. GIMP’s new LCH color sliders (no details on how to use).
  3. A tour of GIMP’s sRGB-based HSV color wheel.
  4. The primary, secondary, and tertiary sRGB colors on the LCH color wheel.
  5. Making hue-based color palettes from a color wheel, with links to some excellent resources.
  6. Comparing LCH and HSV color palettes - next topic to be covered, no pictures or text yet.

In preparation for comparing LCH and HSV color palettes, I’ve made (but not yet posted) a bunch of monochrome color palettes. It’s been interesting to see when the HSV and LCH color palettes look similar and when they look very different, and also to encounter the “gamut limitations” the very small sRGB color gamut places on making LCH-based palettes.

Here are the three images from what I’ve put together so far (the tutorial notes have text explaining the images):


GIMP’s HSV, RGB, and LCH color sliders.


Left: GIMP’s sRGB HSV color wheel; Right: HSV Hue ring with color dots smarking every 30 “HSV Hue degrees”.


The sRGB HSV Hue ring wrapped around the LCH Color circle, showing the locations of the sRGB HSV primary, secondary, and tertiary colors on the HSV Hue ring, and also on the LCH Color circle.

1 Like

12 posts were split to a new topic: Elle’s Writing and Articles

Quoting from this thread ( Elle's Writing and Articles)

I did incorporate @afre’s suggestions into the second of the two LCH tutorials I’m working on, and I think this tutorial is mostly finished, pending questions, suggestions, errors spotted, etc:

This is the table of contents and some images, on the assumption that images speak louder than words:

A. Introduction: Choosing complementary colors, color harmonies, and colors for painting warmer highlights and cooler shadows: Why LCH is so much better than HSV

B. LCH (approximate) hues for highlights and shadows

C. Painting highlights and shadows on a sphere using an off-complementary color harmony


D. Coloring a black and white photograph to emulate early morning lighting and some notes on the trouble with yellow and blue



E. A triadic color harmony


F. Conclusion: Who needs LCH? and notes, and how to use GIMP’s LCH color sliders to pick the brightest, highest chroma color for a given LCH hue

I’m pretty sure that no one will ever learn very much about LCH or other topics covered in tutorials on my website, just by reading the tutorials. My tutorials are about the practical and applied aspects of color management, color mixing and such. These are things that imho don’t start to make any sense until you are actively experimenting and incorporating your observations into your workflow. The tutorials are intended merely as guides to starting the process of experimenting.

I’ve learned a lot from writing tutorials, from the process of creating images and learning new stuff in an attempt to explain something that often turns out to not be as obvious as I thought it was. I think sharing explorations is whole the point of the pixls.us forums, and I’ve learned a lot following the threads on this forum. We learn from each other. My LCH tutorials are an attempt to share what I’ve learned, and I’m looking forward to seeing and learning from what other GIMP users and pixls.us forum members will do with the new LCH color tools.

1 Like

The articles are coming together nicely. Thanks for your contribution, esp. with the wrist pains.

As an aside, I have to deal with and manage a lot of pain myself. It can be difficult to cope at times especially when people don’t understand or care about what you are going through. Indeed, I have had people question why I don’t do certain activities or whether the pain is really there.

Additional remarks:

  1. Maybe I missed it but I don’t see your explanation on the LCH polar coordinates in your articles or website. It would be great to have a short boxout or article to house this explanation. In the past, I have referred to this one: Introduction to the CIE LCH & Lab Colour Spaces, the images being incredibly clarifying whenever my mind stops working :blush:.

  2. “Images speak louder than words”. Definitely, but I struggled with this one for some reason. Maybe it is the wording, the fact that it is crowding in the figure, or how it interacts with the surrounding body text — I don’t quite know. In any case, section C2 could be a little friendlier.

  3. I am sure that this will come later but currently I don’t think that the sister articles refer/link to each other. Also, instead of being 6 and 7 on the article links page, maybe make it 6a and 6b or something to that effect.

Again, thanks for the tremendous work!

Would it perhaps be more informative to instead of having solid magenta washing over everything outside of the colour space of the image to have a blended version of the nearest color in the colour space of the image and the magenta color? For example using some dithering pattern or so…