Legacy ImageMagick Discussions Archive

I have had success adjusting photos in Lab colorspace. Brightness and contrast can be increased without color shifts. (An example of -sigmoidal-contrast altering colors, especially red flesh tones, is mentioned in Usage > Photos > Brightening Under-exposed Photos). Also, I may increase (or eliminate) color saturation. For the perfectionist, resizes, rotates, and distortions are often better in Lab, but I rarely bother.

The problem is clipping. Lab colorspace is much wider than sRGB, so converting back from Lab to sRGB may result in falling outside of the colorspace. This problem leads me to two questions.

1. All color profile conversions may suffer from clipping. Specifying the -intent (absolute, perceptual, relative, a good explanation here) can make this less perceptible. But -intent only works for -profile conversions, not -colorspace conversions. Is there another option for this? Or is there such a thing as a Lab .icc profile file? It is my understanding that Lab is commonly the connecting space for conversions, so going from Lab to sRGB with a given intent should definitely be possible somehow.

2. Any good ideas on how to detect when clipping has occurred? I would tone down my adjustment if it was clear I had gone too far. My process is:
a. convert photo from sRGB to Lab
b. make adjustments
c. convert back to sRGB.
The only thing I can think of is to:
d. convert the final result back to Lab, and compare this to the image between steps b & c. I would probably separate the channels, subtract the before and after Lab>sRGB>Lab conversion, and amplify the levels to better see visually what areas had been clipped.

1. There are no CIELab profiles because there is only one CIELab colorspace. There are many RGB, CMY and CMYK colorspaces (and hence profiles and their intentions) because there are many different screens and printers. See http://color.org/iccprofile.xalter

2a. In IM's implementation, between zero and quantum, if you haven't clipped in Lab, you won't clip when converting to RGB provided you use floating-point. The two gamuts overlap exactly, so Lab->RGB->Lab will show no differences. If you use integer IM, you get rounding errors that can be massive, even in 16-bit, so they look like clipping.

2b. Yes, converting from Lab to RGB and back, and comparing the two, will detect these rounding errors. My approach is to see if I have any zero or Quantum values in any of the RGB (or sRGB) channels, because the only errors I care about are the ones that look like clipping.

snibgo wrote:In IM's implementation, between zero and quantum, if you haven't clipped in Lab, you won't clip when converting to RGB provided you use floating-point. The two gamuts overlap exactly, so Lab->RGB->Lab will show no differences. If you use integer IM, you get rounding errors that can be massive, even in 16-bit, so they look like clipping.

When I go from sRGB to Lab, the L channel covers the entire range, but a & b fill under 80% of the range. I assumed this was because sRGB was a smaller colorspace than Lab and so fit easily within it. Maybe this is where I show the limit of my knowledge. Is this really due to massive rounding errors? Here I convert a full range of colors to Lab and look at the resulting range: Floating-point, like HDRI (described here and here)? I'm on Windows 7 and don't know how to build.

Ah, yes, you seem to be correct, and I was wrong. Thanks. We can get genuine clipping from Lab->RGB, and that's a neat way of showing it.

Yes, HDRI. I'm also on Windows 7, and don't roll my own. The standard compiled version isn't HDRI, but v7 is: http://www.imagemagick.org/download/alpha/

This raises the interesting question: what colorspaces have gamuts wider than sRGB? As measured by your Hald8 test, v6.8.5 on Windows:

Not wider: CMY, CMYK, Gray, HWB, LMS, Rec601Luma, Rec709Luma, RGB, Transparent, YIQ

Very slightly wider: HCL, HSB, HSL, LCH, LCHuv, OHTA, Rec601YCbCr, Rec709YCbCr, YCbCr, YPbPr

Wider: CIELab, Lab, LCHab, Log, Luv, XYZ, YCC, YUV

I think (but could be wrong) that CIELab and Lab are synonyms for each other.


And the converse question: what colorspaces are smaller than sRGB? As measured by ... ... and examining min and max values.

The answer: only LMS is smaller than RGB, and it is massively smaller; the RGB channels have values 0-39, 0-13, 0-13 for LMS values 0-65535.

snibgo wrote:There are no CIELab profiles because there is only one CIELab colorspace.

I understand that there is no need for a icc profile file for Lab, but I don't understand well enough to know if a Lab profile file is possible. The only reason I wanted one is so that I could do my colorspace conversion using -profile instead of -colorspace. -profile allows me to use -intent. Anytime you are moving between colorspaces with different gamuts, specifying -intent should be possible and would certainly be valuable. Why the -colorspace/-profile dichotomy in IM?

Some test results using: HALD:16 (all 2^24 8-bit colors), 16-bit processing, IM 6.8.3-0
From min and max, one can see that the sRGB colorspace is smaller than Lab. This compression of course will cause some rounding error in a round trip. Worse is that the standard deviation is smaller in Lab, meaning that much of sRGB is even more compressed in Lab. I see why snibgo suggested processing with floating-point HDRI.
For those looking for a simple answer, I'll call that 11-bits of accuracy. This is good enough for my need, if I limit myself to one round trip.

Profiles are designed as a mechanism for transforming between device-specific colorspaces (for cameras, scanners, screen, printers etc) and device-independent colorspaces (eg sRGB, Adobe RGB, CIELab and CIEXYZ) that are used for processing.

It would be nice if we had a mechanism for converting from CIELab to sRGB and specifying how we want to treat colours that are outside the sRGB gamut, just as profiles and intent handle outside-gamut sRGB->CMYK transformations.

Although profiles weren't designed for image processing, they can do the job. All you need is a profile that performs sRGB<->CIELab, but with the intents. You could roll your own, or perhaps someone already has.

Color profiles are very complex, too much so for me to create one. I'm not even smart enough to know if a Lab color profile can be created. I didn't have any luck searching for one. Profile conversions must currently go through a standard space such as Lab. I can't imagine that a profile defines the conversion for every possible pairing.

I reran my test with CIELab and got identical results. I agree that Lab and CIELab may be synonyms.

I noticed something unexpected for the a & b channels. I'm not surprised that the mean is off center, but I am that the median isn't 50%. I'll have to ponder on that.

I took the HALD:16 png I have been working with and colorspace converted it to Lab using GIMP. The results were very different from IM. Any guesses as to what explains this? I don't know how to tell.
(A) GIMP is limited to 8-bit - What I am seeing is much more than rounding error, but maybe this limit lead to (B).
(B) GIMP handles Lab differently - Are there different Lab colorspaces in use here? Are Lab and CIELab really supposed to be synonyms in IM?
(C) GIMP handles Lab incorrectly - My instinct is that L looks suspicious. a & b are also different but look more reasonable.
(D) IM handles Lab incorrectly


Does the -profile or +gamma setting impact the conversion to Lab? Why or why not?

I didn't know Gimp could convert to other colorspaces. How do you do that?

I suppose you are comparing your Lab files on the screen, which is a RGB device, so you must be converting them back to RGB for comparisons. How are you dong that?

IM's -colorspace equivalent in GIMP is under the menu Colors > Components > Decompose. It will use HSV, HSL, Lab, etc. to break the image into three layers. These layers can be adjusted and recomposed, but not much else. GIMP can't save a file in Lab (I believe IM can make a Lab tiff), but it can save a channel as grayscale.

I was comparing the mean, standard deviation, and histograms of IM and GIMP's Lab outputs. The L channel is visually different as grayscale. Negating L and returning to RGB gives visually different results too.

IM's LAB was corrected some time ago to fix issues by adding offsets so that it would work in non-HDRI mode. You might try compiling iM in HDRI and check LAB there where it will be probably more compatible with other implementations.

You can search the changelog and/or archives of this forum to see when and what changes were made.

As fmw suggests, CIELab is a floating-point system. Neutral values of the "a" and "b" channels are 0.0, but IM represents this as 50% of quantum. Gimp seems to do the same.

There is only one version of CIELab. I would have to look at IM's code to ensure that CIELab and Lab are synonyms. They seem to be.
This is 0.5%, which for an 8-bit file is an error in the least signficicant bit, so merely a rounding error. Conclusion: IM performs the round-trip sRGB->Lab->separate->combine->sRGB correctly.

BEWARE: IM versions from about 6.7.9 to before 6.8.5 won't do a "-separate -combine" without a "-set colorspace RGB".

For the separated files, values given by "%IMG685%identify -verbose hi-*.png" are:
Why don't the values in the "a" and "b" channels span the range of 0 to 255? Because, as we have established, the Lab gamut in IM is larger than the sRGB gamut.

Now look at Gimp v2.8.2.

In Gimp, Colors > Components > Decompose Lab. Export resulting layers to h-L.png, h-a.png, h-b.png. Each of these is monochrome. "Recompose" doesn't seem to work.

"%IMG685%identify -verbose h-*.png":
The values in all channels span 0 to 255. I conclude that Gimp's implementation of Lab (probably) covers the same gamut as sRGB. This would mean that manipulating Lab in Gimp, then converting back to sRGB, can't result in clipping. However, CIELab should have a greater gamut than sRGB. I conclude that Gimp's implementation may be helpful, but is technically wrong in the sense that it cannot represent some colours that are representable in CIELab.

snibgo wrote:In Gimp, Colors > Components > Decompose Lab. ... "Recompose" doesn't seem to work.

The result of GIMP's recompose goes to the window of the original decompose. If this window has been closed, it fails.

snibgo wrote:I conclude that Gimp's implementation of Lab...

I call for a recount. I believe your results from GIMP are correct for the L channel, but mistakenly repeated for a & b. I don't see them spanning the entire 0-255 range.

fmw42 wrote:IM's LAB was corrected some time ago to fix issues by adding offsets so that it would work in non-HDRI mode.

Usually L is scaled so 0..100 becomes 0..QuantumRange and a & b are offset so 0 becomes QuantumRange/2 (to fit signed values within unsigned stores). I want to say that a & b are usually left unscaled because -128..127 is nearly their full range anyway, but I'm less sure here. It would seem reasonable for HDRI to stay true to the math. But equally reasonable to stay consist (and compatible with existing tools and file formats).


I think GIMP is ignoring the sRGB profile and treating the RGB values as linear when converting to Lab. This would explain much of what I see, but not all.

Speaking of ignoring profiles, IM also seemingly ignores them when converting to Lab. So while I can do sRGB>Lab, I can't do AdobeRGB>Lab using IM.

If you want a LAB.icc profile, the Mac OSX ships with one (also one for XYZ.icc). I have no experience using it.

http://www.fmwconcepts.com/misc_tests/P ... rofile.icc