Frequently we hear that Lab* has defects which do not allow it to be a suitable support for image processing.
This is partially true, but only for the part that concerns the viewing (screen) of HDR images. In this case, and this case only, the image is processed at 8 bits, preventing good reproduction of HDR images.
In the same concept, I made a comparison (using the lacam16n branch of the current PR) of the various tools to treat DR all with “Local adjustments” whose working base is Lab.
Log encoding, ColorAppearance Cam16, Tone Equalizer, Dynamic Range & Exposure, Dehaze, Shadows/Highligts, Tone Response Curve (TRC), Exposure, Tone Mapping
Certainly we are on an artificial image, nevertheless this allows the user to identify the limits and difficulties of using these tools
As I understand, the downsides when doing adjustments in L* a* b* are compensated by a 200LUT Munsell correction.
Would swapping the underlying L* a* b* model to something with less hue-skews speed up calculations of adjustments then?
I understand that for representation of captured data the model works fine, even for 25eV dynamic range data.
Hello
You are right to ask this question, because many people have expressed doubts. I designed this system about 11 years ago. The 200 LUTs are very small and provide the necessary corrections whatever the hue, luminance and chroma values. The tests were carried out at the time, the correction is almost perfect (?), imperceptible (or hardly noticeable) on a TIF…
The main corrections are on Lab’s (well-known) drifts, particularly in blues/purples and reds/oranges, without forgetting all colors.
Here an old text, not entirely up to date: https://rawpedia.rawtherapee.com/Color_Management_addon#The_%22Munsell%22_correction
The time spent is negligible in the Preview, and around 100ms / 150ms - (on my computer) , for a TIF output on a Nikon Z9 file -45.6Mp (full image) - or less about 50ms / 100ms - which I consider to be largely acceptable. Of course you can deactivate it.
Working in RGB, or HSV brings otherwise significant drifts and complex saturation control… Here with these LUTs, it’s very simple.
For the Dynamic Range (DR), unless someone shows me otherwise, the Lab model “passes” 25Ev without problems, in the entire code (except the monitor control part, but that’s except for HDR monitors, always the case) . On the other hand, the DR actually passed depends on the tool used as I describe it.
So the improvements for Lab-like colorspaces from, for example, OKLab would not be too beneficial (or worth the time spent for implementing such a new Lab-like colorspace)?
As always, your work and contributions are much appreciated!
In the Rawpedia text, I mention “HDR-Lab”, you mention “OK-Lab”… These are 2 possible solutions.
From my point of view, this modification is only of interest for the “Export” part, either to the screen or a projector, or for TIF/JPG outputs. This also assumes that the output profiles (managed today by LCMS) support the ability to use these 2 variants of Lab, and of course generate the corresponding profiles (ICC…).
But for 99% of the code, maintaining the system as it is (in principle) ensures almost perfect operation. The colors are preserved, the system is “fast”, the DR passed and usable more than sufficient.