Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenDRT v0.2.4 #19

Open
antonmeleshkevich opened this issue Jun 27, 2023 · 2 comments
Open

OpenDRT v0.2.4 #19

antonmeleshkevich opened this issue Jun 27, 2023 · 2 comments

Comments

@antonmeleshkevich
Copy link

antonmeleshkevich commented Jun 27, 2023

Hi, Jed!
The latest OpenDRT v0.2.4 looks very smooth! And I like how the sliders are intuitive and precise at the same time in terms of the sliders' values that are displayed in UI.

I've noticed OpenDRT doesn't have surround compensation. Maybe it could be added as a gamma slider, that affects tonemapped luminance only, but not colors? Not sure if this is a good idea in terms of perceived saturation, but at least it shouldn't add hue skews that per-channel gamma adjustment adds.

Also I always find it easer to grade under sort of my custom DRT that has your Gamut Compress applied right after display gamut encoding. It allows me to unstick saturated colors from 0. This will make every colorist happier, to see on waveform analyzer how the saturated colors are not crushed, but nicely compressed.

I use one of the older versions, that has shadow roll-off slider, because the latest one that is shipped with Resolve bypasses some dark pixels (I believe this is made for invertibility).

If you don't mind me sharing my thoughts, that's how I see it:

Limit sliders are pre-set based on the selected display primaries.
Threshold slider (or all 3 sliders) is exposed to UI.
Don't preserve the darkest shadows (pre-set shadow roll-off maybe?). I hope for DRT invertibility this won't be a problem (but not completely sure).

And if the (luminance only) surround compensation can possibly somehow create negative values, then, I think, surround compensation should be made over tone-mapped, but linear image, and before gamut encoding. This way gamut compress could deal with the negative values that could possibly be produced by luminance only surround compensation. This would also affect the default values for Limit sliders I guess.

UPDATE.
Ok, now I feel stupid :)
Based on what I've read, from v. 0.2.3 OpenDRT has gamut compression after display gamut encoding. Maybe I just need to play with the values to get what I want.

@jedypod
Copy link
Owner

jedypod commented Jun 27, 2023

Hey @antonmeleshkevich !

Thanks for the thoughts, and for poking around at this mess of undocumented experiments. Yes there is a "gamut compression" type of operation happening towards the end in the latest two versions of opendrt. I'm not totally sure it will do what you want though. Let me dig up a couple of screenshots to demonstrate.

screenshot_2023-06-26_17-55-15
screenshot_2023-06-26_17-55-06
screenshot_2023-06-26_17-54-00
screenshot_2023-06-26_17-53-47
screenshot_2023-06-26_17-52-45
screenshot_2023-06-26_17-52-31

The rewritten opendrt v0.2.x does not use an lms colorspace to render, it uses the display gamut. To compress colors down into the display-referred gamut cube we do the following:

  • compress towards peak achromatic by "luminance" (brighter values get compressed more)
  • scale down vector/ reduce intensity by chrominance*luminance (reduces overshoots in bright saturated colors common in older opendrt)
  • finally "gamut compress" - this reduces discontinuities in gradients on bright saturated colors as seen in the screenshots above
  • finally finally, we clip, which is in itself also a type of gamut compression that is always happening. This gets us the last little way and of course skews hue towards primaries (below gamut cube midpoint) and towards secondaries (above cube midpoint). if we've done our job right the clip shouldn't introduce any super noticeable discontinuities in gradients.

So yeah this "gamut compress" is pretty conservative. if you want something less saturated in midtones and shadows you could do this with operations upstream, or maybe setting the dechroma to 1.0 instead of the (current) default 0.5. I was playing around with some film-like looks yesterday and ended up pushing the dechroma higher.

For the surround compensation, it is one of the features I am planning to add back once i get into a bit less of an experimental phase. It would be pretty trivial to add a "surround compensation" control which is an unconstrained gamma adjustment post-tonescale, but I was hoping to scrape out some time and re-do the little perceptual experiment which I did at home on my tv matching image appearance with different surround luminances, which is where those values in the old opendrt came from. I was also going to try to compare this approach to an approach using an exposure adjustment in linear pre-display transform to see if that might be an interesting alternative. That's a lot of if ands and buts.

Anyway thanks for poking around at it and for the feedback, always valuable! I'll try to scrape together some better documentation once I get my head out of the weeds over here too.

@antonmeleshkevich
Copy link
Author

Thank you for the detailed reply @jedypod !
The current post-everything gamut compression definitely helps a lot. It still clips colors at some point though.

Regarding the surround compensation:
I also sometimes do it using linear exposure, but only as a per project adjustment, not something I bake into a show LUT for example. I'm bit worried about the peak luminance change.

I apologize for the mess, I accidentally closed and then re-opened the "issue"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants