I notice that GLSL examples apply tone mapping to RGB values directly, which seems to me would be incorrect. However, I'm having trouble figuring out which color space to do the conversion in. Luminance is already in such examples computed as a weighted sum from RGB using matrix values I see used for Y in XYZ color space. Once the luminance is mapped, (I use Y = Y * (Y / (maxY * maxY) + 1.0) / (Y + 1.0); ) I've seen examples where they simply multiply it into the original RGB values. How can that be right? I did try to extract X and Z as well and then convert the XYZ after tonemapping Y back to RGB, but I'm not getting a sensible result...

Hi, I am quite ignorant on this subject, but AFAIK the pbrt raytracer uses XYZ for the color calculations, and it provides tone mapping so I suppose that it is the right (or a reasonably good) way to do it. From the site you can download the source.
Hope this helps

Hi Prune,

I'm experimenting with tomemapping the past few days as well, and as you said, i've also seen a few of demos where they just multiply the HDR RGB value with the adapted luminance. I suppose there is an explanation behind this, but i haven't actually searched for it. Instead, i did what seemed more logical to me. I tried RGB to XYZ, adapt Y and back to RGB as you said. It seems that in XYZ space you can't modify luminance (Y) and get the same color back (either darker or brighter).

What i found out is that you can convert XYZ to Yxy, alter Y and convert back to XYZ (and from there to RGB) and the color will stay (almost?) the same with a different brightness. From this:

Quote:
It is often convenient to discuss "pure" colour in the absence of brightness. The CIE defines a normalization process to compute "little" x and y chromaticity coordinates:
...

Probably by doing all the math on paper (RGB->XYZ->Yxy, alter Y, Yxy->XYZ->RGB) you will find the explanation behind the direct multiplication of RGB values with the adapted luminance.

Hope that helps.

HellRaiZer

EDIT : Forget about Yxy. You can try it and see that it works, but there is actually an explanation behind what most demos do. If you do the math you will find out that the whole thing boils down to :

ldr_RGB = hdr_RGB * (adapted_luminance / hdr_luminance);

I hope i haven't done any mistakes. This will make your shaders a lot simpler :)

Wrong, right, there is none.

Tone mapping is taking a high dynamic range picture (one that has data from very small values to very high values) and compress it to a very small range (0..255 integers). That compression will lose some info whatever route you take. The control you have is where you'll lose this info. Some people will prefer to lose brightness info to saturation info. Some prefer to preserve hue, other will want a maximum contrast. Other will prefer to preserve "saliency" at the expense of truth.

There is no right and wrong answer.

Preserving hue, although it avoids the 'washing out' effect, can often lead to very unnatural images.

I usually prefer a weighted mix of a standard RGB space tonemap and a hue preserving tonemap.

Any shader code you care to share, or a general algorithm you use to do this tonemapping?

Quote:Original post by LeGreg
Wrong, right, there is none.

I disagree. The way it should be done is one that makes the least visual difference in the human visual system from an equivalent image displayed on an HDR screen. The same way audio and video codecs are studied in blind testing with human subjects needs to be applied here to find an approximately optimal mapping operator.

Quote:Original post by stephanh
Suprisingly the the answer might be different when choosing the "best" TMO with/without reference image.

That's a failure of the specific study mentioned, not the concept that blind testing of perception is the correct approach.