Hue-Invariant Gamut Mapped Pseudo RRT

[Thomas_Mansencal]

Hi,

The Working Group would not be complete without squeezing-in some HSV based work.

So the transform used HSV and is thus Hue-Invariant, the RRT is used to compress the Value, Saturation is decreased reciprocally and Saturation is gamut mapped directly, so no OOG values.

Looking at Hues through the White to Black axis:

Some comparisons:

Base

2 Stops

3 Stops

Hues

I have not implemented any controls because it is a quick toy to explore the usefulness of the HSV model for that particular exercise. It is rather elegant:

Now the good thing is that it is trivial to build a hue mask to protect and isolate some particular hues and help them reach full saturation faster.

TCL for Nuke here: HSV - Pseudo RRT · GitHub

[zachlewis]

Not too shabby, Mr. Mansencal. That’s quite straightforward…

[Thomas_Mansencal]

Thanks @zachlewis!

The quick takeways and notes for me are that:

• It should be relatively straightforward to make the RRT hue invariant
• This is almost the HSV Control Based Study Model from @matthias.scharfenber and I, the main difference is the desaturation and value compression components.
• This experiment hints at the fact that the hue shifts we saw with the HSV Control Based Study Model were a consequence of the DRT and not the operator itself, thus, the VWG selected Gamut Mapping Operator is potentially introducing hue-shifts which we should check.
• As I gamut mapped directly inside it, the current DRT is applied in the final display space, do not have to be but it was here done as an optimisation step, but this highlights the fact that we will need gamut mapping in the display encoding block, hence those Output-Referred LMTs I mentioned.
• Because it is akin to the HSV Control Based Study Model, it is straightforward to add Hue Twists and maybe bring skin and fire in a pleasing spot as default, this will be my next test.

Cheers,

Thomas

[Thomas_Mansencal]

A bit of hue biasing, something that is certainly clear and, concern I raised a few times, is that Pyro Effects would have to be lookdev entirely.

Base

Some Hue Twists

@MrLixm : Given you have done the render, it might be worthwhile at some point for you to test modifying the look under either Jed’s or mine and see if you can get where you want/need!

Here is also a non-photometrically scaled hot candle flame colour (~1600K), on the left the value computed and on the right +2 stops exposure with vanilla DRT settings:

Cheers,

Thomas

[Troy_James_Sobotka (troy_s)]

@Thomas_Mansencal

• Because it is akin to the HSV Control Based Study Model, it is straightforward to add Hue Twists and maybe bring skin and fire in a pleasing spot as default, this will be my next test.

Skin skews ghoulish yellow with per channel already.

This seems like a bad idea applying chromaticity compression in the radiometric open domain. A proper gamut volume compression, as long as slope never hits zero, conserves the source chromaticity, and aesthetic manipulations can be applied much more cleanly in the radiometric closed domain.

@Thomas_Mansencal

the VWG selected Gamut Mapping Operator is potentially introducing hue-shifts which we should check.

This was pointed out a few times, no?

[nick (Nick Shaw)]

@Thomas_Mansencal

the VWG selected Gamut Mapping Operator is potentially introducing hue-shifts which we should check.

We should certainly investigate that. We always said that the scene-referred gamut compression algorithm would need to be re-evaluated when the Output Transform changed.

However I am hopeful that since many of the serious problematic values that the gamut compression is applied to deal with are so far out of gamut that their supposed hue is fairly meaningless anyway, there should be a relatively small range of chromaticities which are altered by the scene referred gamut compression but represent meaningful colours.

[Thomas_Mansencal]

@Troy_James_Sobotka

This was pointed out a few times, no?

Absolutely, and as @nick states it, the intent has always been to recheck, just pointing it out, again.

[MrLixm (Liam Collod)]

Here’s my result under Jed’s DRT with default settings. (If you look at the screen you can still see that i changed the highlight gamma slider.)

I started by trying to use the Blackbody controls but didn’t had enough control on the colors has I felt a massive shift toward red.
The screenshot are mainly me just using a good old ramp with random tweaks to see how it behave.

I’m far from being a fx lookdev expert so my shading might be heavily biased (thinking of how low my highlights values seems to be in Nuke).

(Click on the bottom image this is an album)

[22 new photos added to shared album] ACES DRT fx tests v01

https://photos.app.goo.gl/E17sfRMfv8oJR2249

Cheers.
Liam.

[Thomas_Mansencal]

@MrLixm

I started by trying to use the Blackbody controls but didn’t had enough control on the colors has I felt a massive shift toward red.

Thanks, seems quite painful to tweak to taste!

[ChrisBrejon (Christophe Brejon)]

Thanks guys ! I did a couple of sweeps to compare a bit several DRTs :

Using TCAM OCIO Config :

Using HSV Pseudo RRT :

Using Naive DRT :

I noted that in yours there was something weird going on on the blue ACEScg primary sweep.
Update : input in Nuke’s script is ACES2065-1. Not ACEScg !

So I checked as well on my blue biped :

Using HSV Pseudo RRT :

Using Naive DRT :

Update : input as ACES2065-1 fixes the stuff I mentioned.

Thanks,
Chris

[Thomas_Mansencal]

I would need to check as to why this happens, but there is gamut mapping occurring in the thingy atm, ACEScg primaries being OOG for sRGB I would not be entirely surprised to see that occurring. Oh and be sure to check the input space, I think it is AP0!

[ChrisBrejon (Christophe Brejon)]

I’m pretty sure having the right input will solve some of the stuff I mentioned ! Thanks Thomas !

Update : previous post updated with fixes of sweep and blue biped. Sweet !