Chroma Compression Explained

But in my equations above, it should not matter if k_{HDR} (or k_{SDR}, for that matter) is <1 or >1. It cancels out with only \frac{J_t}{J} scaling. If the tone curve takes display J above scene J for a particular value, then surely M should be increased – the cone of the spectral locus keeps getting wider as J increases. It would seem that doing additional processing to keep the M scale below 1 is a potential cause of the desaturation. Anything which changes the \frac{M}{J} ratio is literally changing saturation, because \frac{M}{J} is the definition of saturation in this model.

The M scaling going above one is not a saturation boost. It is a colourfulness boost. But surely that is appropriate to maintain saturation as J increases.

That is my argument as well, and was the conclusion I came to in that first post. However, I don’t believe the model will give us the match we want just by using the pure ratio. We want to be able to control it ourselves for the best match, and to avoid having to make the in-gamut compression peak dependent. In testing I have concluded that the pure ratio would give overly saturated image in HDR and would require the in-gamut compression to do something very different for each tonescale.

There is going to have to be a point in the transform where the appearance match is created, given the purpose designed mismatching tonescales. I’ve chosen to do that in the scaling step because I believe that’s the easiest place to do it. The only other place to do it would be the in-gamut compression step, but I believe it would be more difficult to do it with that, with the current technique.

We could make our lives a little bit easier if the middle gray wasn’t lifted quite as much between 100 and 1000 nits (as I’ve brought up a few times), or by reducing the 100 nits rendering saturation a smitch. Then the 1000+ higher nits can be dealt with the “hunt compensation” or “colorfulness boost”.

I hardly can follow you guys into that rabbid hole…

But:

Surely you want to (If anything) decrease chroma If you move luminance up to compensate for the Hunt effect. TBH I don’t think this is a major parameter for a match between SDR and HDR from my experience, so I guess you are chasing something else.

Then when you say “this gives an appearance match between SDR and HDR” how exactly do you judge this.
How long do you let yourself adapt to the new viewing condition, (see Contrast Gain Control)?

Then when you say you want to tweak on top what “the model” provides, why are you using the model in the first place then?

Also if you are not happy with the pre and post tonemap ratios to drive any other scale, maybe you shouldn’t .
Are you taking the original linear light ratios or some other form like PQ ratios?

3 Likes

It is the ratio of Hellwig J before and after tone mapping. We (as a first step) multiply M by that ratio to scale it down by the same amount the tonemap has scaled J by, in order to maintain saturation (which is defined in the model as M / J) through the tonemapping.

(this was originally suggested by @luke.hellwig as something that should be done if using his model)

So you taking the values before and after a linear light tonemapping function, then convert it to some JND based encoding (PQ ish I guess) and then take the ratios.
What do those ratio even mean?

1 Like

We’re not doing this, as far as I understand it. I would not get hung up on Hunt or anything like that when it comes to scaling the M (colorfulness). I consider doing that, and creating the appearance match, a purely technical step.

The first post of this thread tries to explain how the current compression works and behaves, including how the tonescale changing J over J (J_t/J) is currently used to do the scaling of M, but it also references older versions of the compression that have used entirely different method, not based on pre/post tonescaled ratios. There has been many many different versions, including using the derivative of the tonescale, but the current one works and is the simplest one, even with the extra tweaks needed to get the compression to a similar starting point for different displays (different tonescales) that can create a reasonable appearance match. It doesn’t matter much to me how the scaling of M is done, as long as it is simple enough and affords the necessary control I believe is needed to create the appearance match, and to get the behavior we currently have. I absolutely do not believe there is “one correct” curve to do it.

The discussion me and Nick are having is about trying to make a simpler version of what’s explained in the first post of this thread that would not need the extra colorfulness/saturation boost step. I’ve got that working quite well, but not necessarily any simpler… The scaling is the part that sets the overall base colorfulness level with each tonescale for the match.

If you have an alternative idea, tonescale based or not, that we could use, I would be very happy to hear about it.

Thanks for that link, I will keep that in mind. Personally I spend a long time comparing the images, especially in situation like this where I’m changing the appearance match. I favor doing A/B comparison with Rec.709 sim and Rec.2100, but I do side by side comparisons on same screen as well. My personal benchmark for the quality and performance of the appearance match is ARRI Reveal. Can’t be a bad match if we can get close to performance like that…

From earlier discussion:

How would you approach using M as the modulator and do it in a way that’s invertible? We are using M as the modulator and the current approach is invertible, but I am on the look out for any other way or technique that could be used to achieve it. There’s plenty of ways I can think of that aren’t invertible (we obviously don’t have the original M available in the inverse). Any tips and help would be highly appreciated.

I am confused:

In your original Post you write:

Now you write:

If this ist a “purley technical step”, what is your cost function? Surely there needs to be an objectiv metric.

A Look operation should not need any tweak for different viewing conditions. Otherwise the DRT is not functioning correctly.
If you are working on the appearance match of the DRT, you need to modify the model and not hand tinker with the parameter of the model.

The more I think about it J_t/J is probably a bad driver. Probably this is why your M modulation is so sensitive to shadows/greys. If you do some sort of log of the linear ratios you might get something that behaves better.

The look is created in the second step. That is the “base transform look”, and yes it does not need any tweaks to viewing conditions or anything else like that. Very much subjective step.

The first step is the scaling step which also creates the appearance match. That is what Nick and I were talking about. The first step is the technical step, or one could call it even a normalization step, and that then allows the second step to not need any tweaks, even though the output is for different displays.

I could not figure out how to do both in one step (at least not in invertible way, the very first version did that, but was very naive and not invertible)).

What do you mean by sensitive? Do you mean it compresses them clearly different amount or that it has to, or something else?

I believe the previous chroma compression version was actually doing something like that. It wasn’t the linear ratios of the tonescale itself, but another similar curve. It’s the one I linked in the first post. That thing is too complicated but I could probably come up something much simpler now, but still more complicated than the current approach. Simplicity was the reason why I switched…

Is this the right order?
Intuitively I would assume you do a “look” transform which then is translated to various viewing conditions. The same order would be present with any custom LMT prior to the DRT…

A division in log is very different that a division in linear light.

It is a valid question, but I can probably envision a more complicated solution for it. In the end they should end up in a very similar place. I have not tried to do this…

I also want to address this because I think it’s important:

This is a path I have chosen not go down. I wouldn’t know where to start. I’ve chosen to work with the CAM rather than develop an alternative CAM. I’ll leave that to someone else. I think both approaches are valid.

The J_t/J is not in linear. We’re doing it in the non-linear model space.

Exactly, have you tried doing the division in linear and maybe take the log of that…

Yes, the old curve essentially did that (it took log difference but same thing).

My understanding is that it is inherent in the design of the model that saturation is the ratio of M to J, so by doing that division in the model space, we are aiming to maintain saturation (at least in the way the model represents it).

And does it so?
If you make the whole image a stop brighter does this method maintain overall image appearance?

I just did an experiment, taking an SDR display-referred image, and adding gain in RGB and in Hellwig (our tweaked version) JMh (applying the same gain to J and M, and leaving h constant).

This is the result – Left is JMh. Right is RGB. Originals at the top for comparison.
(HDR display required to view this, as it is Rec.2100 PQ encoded)

It does appear that brightening an image in JMh adds colourfulness (and you can see chromaticity spread out on a CIExy scope) compared to doing it in RGB (where chromaticity remains constant). This is the opposite of what I would expect, if the model were compensating for the Hunt effect. @luke.hellwig, am I doing something wrong?

1 Like

I guess the logic is (wild guessing here):

Two stimuli with same M and h value but different J will be mapped to two different places when converted back to XYZ.
The stimulus with the higher J value is being “predicted” to elicit higher “saturation” sensation. (What ever that means)

Hence when you increase J the model adds “saturation/chroma”

This obviously is not what we want.

But again I am not familiar with this model so could be wrong.

The opposite happens actually. If saturation is roughly M / J and M is constant and only J is increased, then it will come out as less saturated. I haven’t seen Nick’s video yet, but he says he’s gaining both J and M (but J and M have different rate of change). If you increase the exposure in RGB and then go into JMh, the model will predict higher J and higher M.

Ok, it’s clicking into place for me. The model has additional background and condition dependencies in the exponent of the formula for J:
image c depends on the surround conditions (‘dark’, ‘dim’, ‘average’) and z depends on the background. These are lacking from the formula for M:
image
So the two quantities have slightly different nonlinearities relative to light, which messes with the chromaticity when you scale both. I see two potential solutions:

  1. Include the cz exponent in the formula for M:
    image
    I tested this out in MATLAB and found much less chromaticity drift. Still slight, but significantly reduced. I do not think this would have adverse effects on other parts of the model. We would also have to change the formula for gamma in the inverse model:
    image
  1. We could just force chromaticity to stay constant as we rescale J, instead of trying to back into that desired result with M.
6 Likes

I think that the limit parameter needs exactly the same scaling as the M channel. This way you may be able to improve the SDR/HDR matching. Without that, I got different transition points for the curve that protects purer colors.