-
Notifications
You must be signed in to change notification settings - Fork 35
tech_rgb tonemap
The status quo of display transforms today is the per-channel RGB Tonemap. All commonly accessible display transforms use this method:
- ACES Output Transform
- Filmic
- Arri Classic Rec709
- Red IPP2
RGB tonemapping does a pretty good job and creates decent image appearance, but it has some downsides which we will explore.
Make sure you read through the Definition of Terms, and Gamut Volume page before continuing, so that we have a basic vocabulary to communicate about these topics.
Note
Below I'll use the terms hue and chroma to refer to stimulus, not to the perceptual attribute.
RGB tonemapping works by directly applying a tonemapping curve to each of the three channels, independently. Let's explore what effect this has on hue.
As image makers we are probably all familiar with the effect on color that the "Gamma" operation has. If we gamma up, saturation is reduced. If we gamma down, saturation is increased. We are so used to this byproduct of changing contrast that it is innate in our expectations for what the operation does. But I find most people don't really understand completely why this is happening. Let's explore it a bit.
Rotating Hue Swatch
Nuke Script
Rotating Hue Swatch
Here is a simple example plot:
- Right: a swatch with hue rotating in 5 degree increments per frame.
- Left: a CIE 1931 xy chromaticity plot of the image on the right.
Note: The chromaticity plot only shows us the color of the samples without regard for the luminance of the sample. - The origin of the line is the whitepoint of the RGB colorspace, D65 in this case.
- The triangle is the gamut boundary of an RGB colorspace.
Gamma Up
If we take the hue swatch and gamma up to 4.0:
- Rotation speed further from the whitepoint is no longer even. The rotation "speeds up" as it crosses the primary hue angles (red, green, blue), and the rotation slows down as it crosses the secondary hue angles (cyan, magenta, yellow).
- As chroma increases, hue is bending towards the seconaries.
- Chroma is significantly compressed towards achromatic (it's hard to see in this plot).
- It's also hard to see here, but any chroma value at 100% in the RGB colorspace will get "stuck" to the boundary and will not be compressed by towards achromatic at all by this method. This is the cause of the "gamut clipping artifacts" in the ACES Output Transforms.
Gamma Down
The opposite is happening when we gamma down:
- Chroma is compressed away from the achromatic axis towards the gamut boundary, increasing apparent colorfullness.
- Hue is bent in the opposite direction: towards primary colors (red, green, blue).
To visualize what is happening with chroma (distance from achromatic axis), let's narrow our focus to a single RGB tristimulus value, and examine what happens when we do the same gamma adjustments. Here we'll use our 4-up plot again.
For this we'll use another plot, which I think will help us visualize what is happening in all dimensions.
Nuke Script
Nuke script used to generate this plot
Gamma Up
When we take a salmon color and gamma it up, this is what happens.
- RGB values are boosted towards 1, but at different rates.
- Chroma is pushed from its original position towards achromatic.
- Luminance is increased towards peak achromatic.
Gamma Down
When we gamma down, the opposite happens.
- RGB values are reduced towards 0, but at different rates.
- Chroma is pushed from its original position towards the gamut boundary.
- Luminance is decreased.
Let's try another color, this time brighter and a bit less saturated.
Gamma Up
Gamma Down
"These fancy plots are just a bunch of irrelevant garbage. A real display transform's tonemap is not a gamma adjustment!!"
-- Angry Reader
Yes this is true. A tonescale curve usually looks something more like this.
Above is the Arri LogC2Video curve, plotted in a semi-log graph, where Y-Axis is value (0-1), and X-Axis is stops, from 7 stops below 0.18 on the left to 8 stops above middle grey on the right.
We can see that there is a reduction in contrast in the upper range on the right, an increase in contrast in the lower range on the left, and a somewhat linear section in the middle.
"So this is that famous "S-Curve" I keep hearing about! S-Curves are better than gamma curves!"
--Angry Reader
Yes, just keep in mind that the X-axis is logarithmic! When viewed with a linear X-axis, the actual shape is revealed:
This shape is something closer to a hyperbola (More about this in the tonescale page).
So if we use some "S-Shaped" tonescale curve instead of a gamma, what happens?
Above is 24 samples of hue, at 50% chroma (again purely referring to RGB distances here, not the perceptual attributes). A scene-linear range of input values (0 to some big number) is compressed to a display-linear range of output values (0 to 1). This is only 50% chroma, but we can clearly see the chroma compression at the top end, and also the chroma expansion at the bottom end if you look closely.
At 100% chroma we can much more clearly see the distortions that are happening with hue, as we saw in the chromaticity plot earlier. But viewed in 3 dimensions we can see how the distortions change over a range of intensity values.
If we take another view from the top, and vary chroma from around 50% to around 100%, we can see how the chroma compression and hue distortions change over a varying range of chroma positions. Look how all hues anywhere near yellow are converging to pure (1, 1, 0)
. Affectionately termed "Rat-Piss Yellow" by those who can not unsee it. Once you start looking for it, it's crazy how often we see this everywhere.
Also look closely at the red sample. Note how it is not distorting at all? Peculiar!
If we do a very small hue rotation on the hue samples, so that the red sample is no longer exactly positioned at the red primary, but is pushed slightly slightly orange, look what happens.
Suddenly there is a huge distortion in red towards orange as it increases in intensity.
As the Angry Reader may have noticed by now, with a per-channel RGB Tonemapping display transform, many things are tied to the tonescale curve. How much hue distortions, how much chroma compression at the top end, the amount of chroma expansion in the bottom end, it's all tied directly to the curve itself. You can not adjust the curve separately from these byproducts of the rendering. This results in a lack of control. If we wanted to change the chroma compression, or the distortions in hue over luminance separately, have have to fight the innate byproducts of the tonescale. This is no way to live.
"Don't tell me how to live my life! I can do what I want!!"
--Angry Reader
Yes this is true. There are many valid approaches to the problem, and many beautiful images have been made with rgb tonemap based display transforms. But if there is a better way, perhaps we should innovate and explore.
One particularly problematic area of rgb tonemap display transforms is when you try to render an image for HDR. In HDR, less chroma compression occurs than in SDR. This is because of the way the tonescale curve and mapping is applied. For the per-channel rendering approach, this can result in big differences in color appearance between the two mediums. Here is a simple example.
Above is an "HDR in SDR" preview of an image from the Stuttgart Visual Media Lab HDR Test Footage.
What does that mean, "HDR in SDR"? The top image is the ACES 1.2 SDR rendering, multiplied down in display-linear, so that the peak brightness is 1/6. The bottom image is a 600nit HDR ACES rendering, scaled in display linear so that peak brightness is mapped to 1.0. So basically we are seeing an HDR rendering, presented within the luminance range of an SDR monitor.
This image does not show the exact appearance that you would see on an HDR monitor obviously, but it does show quite clearly the appearance differences between the two renderings. Look at the ghastly yellow jaundiced look of her skin in the SDR rendering, vs the more natural looking rendering on the bottom. This is the type of thing you see trying to use a per-channel display transform for HDR.
The other aspect that greatly affects the rendering appearance of rgb tonemap display transforms, is the gamut in which the tonemap is applied. The rendering gamut.
Applying the same curve in ACEScg vs Arri Wide Gamut has a dramatically different appearance, especially with more saturated colors. If you are curious to get a feel for this, there is a Nuke setup that I posted in this acescentral thread, which allows you to interactively change the rendering gamut, and view the results. It's pretty interesting.
Next...