-
Notifications
You must be signed in to change notification settings - Fork 28
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
Comments
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. 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:
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. |
Thank you for the detailed reply @jedypod ! Regarding the surround compensation: I apologize for the mess, I accidentally closed and then re-opened the "issue" |
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.
The text was updated successfully, but these errors were encountered: