"color-accurate" tonemapping

Hi together. Since a longer time, I prefer luminance-based workflow for raw development. So I changed over to luminance tonecurves (and tonemapping etc.)
I’m investigating on the issue with desaturated images in case of strong contrast increases. Here an example:

Up left you see my proposal. Big image is linear raw - right bottom is luminance blend mode in gimp.

Is there anyone of you color-experts out there - willing to check the idea / technical concept I pursue? I “wrote” a gegl-plugin as PoC please have a look here: https://github.com/immanuelsch/gegl-HDR-ColorMapper

Cheers, Immanuel

2 Likes

@PhotoPhysicsGuy @jandren
this thread shows, that for this topic color “accurate-tonemapping” you might be the experts :slight_smile:
https://discuss.pixls.us/t/new-sigmoid-scene-to-display-mapping/22635/32

Oh! Hi Immanuel.
Thanks for the Laurels! I would not consider myself an expert, more like a noob with an Interest or something.

So I did not do a deep dive on what your method actually does yet, I just skimmed over it. I already have some questions though.

  1. how would you describe the intention of your tone mapping. It’s not just about mapping high dynamic-range scenes to low dynamic range displays is it (reducing contrast to put it loosely)? sometimes you want to increase contrast?

  2. What’s the key thing you want to achieve with this? Or differently: How are different DRTs (display rendering transforms) not achieving what you want?

  3. For your algo, you introduce concepts of an analog medium (color particles, density) to then derive qualities. What are those qualities (pleasing, accurate, sth. else)? What would be the difference for you in “pleasing” and “color-accurate”?

Looking forward to what’s to come!
Cheers,
Rob

I too am having difficulty in following the use of “color-accurate” in connection with tone-mapping.

Because the definition of a color normally includes brightness or lightness or Y, tone-mapping other than 1:1 renders it inaccurate, does it not?

Found much more about the OP’s proof-of-concept here:

https://github.com/immanuelsch/gegl-HDR-ColorMapper

That’s what I was referring too when coming up with my questions.

The Motivation part describes something, but I just want to know more befor giving a more detailed step into stuff.

In the link that I found, OP says:

My experience is the opposite.

Moreover, I just “stretched” the histogram of some flower petals and the HSV saturation increased - again in opposition to the link’s stated theory …

You are right. I should be more precise. My point is about:

finding the “correct” chroma after remapping the images luminance from source to target. Independent from how target was created. In my case I create target from source using tonecurves on luminance, sigmoid on luminance c2g, mantiuk or contrast equalizers from dt … everything luminance-based :slight_smile:

And now: how to shorten that in a chat title :slight_smile:

With regard to desaturation on contrast increase: Exposure - RawPedia says the following referring to luminance tone curves:

Luminance

Each component of the pixel is boosted by the same factor so color and saturation is kept stable, that is the result is very true to the original color. However contrast-increasing curves can still lead to a slightly desaturated look for the same reason as described for the Saturation and Value Blending curve mode. If you want to manually counter-act the desaturation, using the Lab* Chromaticity slider is a more neutral way of compensating for it than using the RGB-based saturation slider.

That’s what I try to express and what my poc wants to address.

I don’t care for the length of the title. :blush:

what shall happen to out-of-display-gamut values assuming they are in-camera-gamut? What working colorspace are you using? How do you transform from Camera-gamut to working colorspace? What method for gamut mapper?

So you do not want to maintain a certain range as at least somewhat 1:1 going from “scene” to “display” and only blown-out and crushed parts need adjusting? Is everything up for grabs?

Cheers! :slight_smile:

Thank you. To help my understanding further, what definition of “chroma” are you using? And is your image’s Luminance Y or Y ?

In HSV/HSB space, a multiplier applied to a set of RGB channel values changes the value of that pixels’ chroma C and I’m not convinced that trying to keep that chroma the same ("correct’?) is a Good Thing …

https://en.wikipedia.org/wiki/HSL_and_HSV

the right title would maybe be: “chroma-correct” luminance blending / scaling :slight_smile:
nobody will read this … too nerdy :slight_smile:

I’m still in-gamut (small saturation, usual lightnesses) - so gamut handling should be done by color-management later - as soon as the image is on dislpay.

And … I’m color-space independent. Gimp shouts this “native” chroma scaling. I explained it here, when I brought up this bug report. saturation change causes color shift (with default settings) (#171) · Issues · GNOME / gegl · GitLab
Simply by blending the original image with its desaturated equivalent. Imagine it as a kind of weighting between saturated and desaturated image.

I’m referring to Luminance Y not Y’ - and of course - chroma constant is not the right thing. it is what LCh lightness blending does. Luminance blending is saturation-constant. But this is also not sufficient - see above-mentioned rawpedia article.

But here an XCF-file that shows my saturation-concept:
Native Saturation.xcf (915.8 KB)

just change the exposure of the white layer to change chroma/saturation. This is my simple saturation-approach … and what I understand as chroma :slight_smile:

Enjoy Saturation :muscle:

Thanks - will play.

So base layer ‘Hintergrund’ is made with Gradient > Full Saturation Spectrum CCW ?

And “Full Saturation” appears to be constant C if I extract C from LCH.

background created by:

  • decomposition into LCH
  • Hue: gradient 0…100
  • L: gradient 25% … 75%
  • Chroma constant 50% (Y’) respectively 18% (Y)

and desaturation is just Y (Luminance-mode)

Thank you. So not the spectrum gradient that comes ready-made with the GIMP.

In the .xcf layers I am beginning to struggle with understanding because I am less familiar with blending modes other that Difference.

Yes - No spectrum gradient. A self-made one. :slight_smile:
With the blending modes - it’s just math.

  1. create background layer
  2. duplicate it
  3. subtract desaturated image from original image (so difference between image and gray-scale image results in color-only part of Image)
  4. scale color information by multiplying it with layer
  5. adding the scaled color back to the gray-scale image (results in color scaled image aka saturation change)

That’s it…

I did the above with a real image:

Instead of white I used light gray … the result:

But now I’ve forgotten the advantage of the above procedure as opposed to say adjusting the saturation directly in an editor or to reducing the “exposure” of a saturation layer in an HSV or in an HSL de-composition.

sorry …

I was just answering your question:

so in short: to ensure chromatic consistency during luminance re-mapping my method uses this blending mechanism - thats by the way a native method from GIMP … so nothing exciting from that point of view.

The point is: to overcome the obviously well-known desaturation-effect that occurs on luminance - remapping I suggest to compensate for it by systematically adopting the chromaticity on top of the luminance scaling.

Don’t hesitate. In case you are using Linux: my repo includes binary *.so files. You need both:

both files do reside in $HOME/.local/share/gegl-0.4/plugins

Thank you for the example.

By not defining “chroma” it’s beginning to appear that the goal is that of your “chromatic consistency” as in mapping CIE colors xyY1 to xyY2 the values of x,y - i.e. their chromaticities - do not change.

1 Like

I compiled gegl plugin for Windows 10 64bit and Gimp-2.10.38

HDR ColorMapper
exposure_map.zip (34,5 KB)

Image Density
image-density.zip (35,8 KB)

image gradient
image-gradient-rel.zip (35,3 KB)

Location to put binaries (.dll) they do not go in the normal plugins folder.
Gimp regular:
C:\Users(USERNAME)\AppData\Local\gegl-0.4\plug-ins

Gimp portable:
d:\Gimp-2.10.38\lib\gegl-0.4\plug-ins

In Gimp menu:
In menu

@immanuelsch
If you want, you can add these files to GitHub

1 Like

Sorry to ask so many questions, but I am still in the dark about how exactly you want your method to work with respect to being “accurate”.

in which one?
this is important because doing the same operation in different gamuts will change the output for your final display version.

and

would both again mean that depending on how and where you do your operation the result will be different.

All of this is fine as a creative way of doing things, but this brings me back to the question of: what do you mean by “color-accurate”?

It looks like the density adjustment is doing what other density adjustments do, reducing “brilliance”. But when you are resaturating, I doubt that you keep xy-chromaticities as they were. (Luminance adjustments should do just that, adjust xyY1 to xyY2, keeping xy untouched)

If you do want to adjust xy values away from the achromatic axis, you should be able to have an answer about the way that should happen. There can be many different answers to that question, creative and “color-accurate”. That is why I asked what you think “color-accurate” means.

Cheers

1 Like