jedypod/open-display-transform

Open Display Transform is a collection of tools and experiments for rendering wide-gamut scene-linear data into an image for an SDR or HDR display device.

open-display-transform's Issues

How to install libDRT.h ?

Hi, I wolud like to try your Saturation .dclt but it seems it needs to have libDRT.h installed. Can you specify how to handle this issue how to acutely do it. Thanks :)

AP0 Gamut with OpenDRT

When primaries set to AP0, OpenDRT gamut compress does this strange black thing with blue colors.

NotoriousSix_Vibrance - random black pixels with 'chromaticity-linear' checkbox

I get these artifacts with all default settings of the DCTL. But when I turn off "chromaticity-linear" they go away.
And all the other look tools don't have this.

Looks like they are completely random. When I change anything prior the DCTL, they appear in random places. Does it look like a platform specific issue? I guess, you don't get this on your system.

And not to open a new issue for just one small thing, just add it here:
Is Linear Grade pivot default correct? Looks like it is far from 0.18 now.

OpenDRT v0.2.4

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.

Nayatani_HK.dctl with DR17/ATI/W10

Dear Jed,

Thank you in advance for your work/updates.

The first and the newer Nayatani_HK.dctl are not working in Windows 10 with Resolve 17.2.2 and ATI Radeon VII.

Propably it has a syntax in code that is not supported by ATI GPU.

Gamut Compress 0.7 had a similar issue, but you/Nick have solved it: jedypod/gamut-compress#4

Thank you.

Ted.

Inverse DRT issues

Hi! I get this when I try to inverse HDR DRTs. Looks like it turns high saturated colors into 0 in linear gamma.

And here is another thing, I've already asked about. But I'm not sure I understood your answer right.
Is this expected and correct behavior? It is Inverse 1886 and then back to 1886.
All the colors look different, even those that are low saturated.

P.S.
I've added OpenDRT into built-in Resolve ACES :)
They've made it possible now to add custom IDT and ODT based on DCTL.

Incorrect matrix?

Hi Jed!
I've noticed something like gamut clipping happening even with the same input and output gamut setting. Is this an expected behavior?

(the image is just a cube surface created using HSL/HSV)

Dolby presets not preserving red objects hue

It's most noticeable with 100 nit vs others. But with others it's also noticeable. The more nits - the more red jacket shifts to the orange. Not sure if this an issue or it behaves as it should.
And I apologize for the giant images :) It's probably because they are vertical.

Negative values are white pixels now with OpenDRT

Hi! In OpenDRT v0.0.90b2 I get this, if the image has negative values.

By the way, this is the red jacket I was talking about. Its hue is different with different "dolby" presets.

CAT for AP0 in libDRT.h

Hi Jed!
May I ask you what CAT have you used in libDRT.h for AP0 matrix?
#define matrix_ap0_to_xyz make_float3x3(make_float3(0.950362384319f, 0.000000000000f, 0.000093463248f), make_float3(0.343966454268f, 0.728166162968f, -0.072132542729f), make_float3(0.000000000000f, 0.000000000000, 1.089057803154f))

Seems like there is also something with the white point happening which I unfortunately can't replicate using https://www.colour-science.org:8010/apps/rgb_colourspace_transformation_matrix
It gives me the equal energy between AP0 and XYZ instead of preserving D65 white point but in ACES.

ZoneSaturation turns negative values into solid black

Hi!
I've noticed ZoneSaturation (even in its default state) turns pixels into solid black if at least one of a pixel channels have a negative value.

DCDM Inverse ODT

Hi! Here is the example of what I was talking about.
Even with rec709 limited gamut, XYZ image can't be completely used as an input for DCDM. And even if a hard clip the input image far from 0 and 1 values.

I've used Rec709 curve because if I use power law gamma or just Linear, the image that goes into Inverse ODT doesn't contain colors that cause this artifact.

And here is what happens if I replace Inverse ODT and ODT by each other:

OpenDRT OCIO Config

Creating a thread to track creation of a minimal but pragmatic OCIO Config using OpenDRT.

N6 Value and Vibrance not working in Resolve

Hi, Jedypod,

I installed the N6 Value and N6 Vibrance dctls into Resolve and when I move the sliders they do nothing at all. Am I missing a step? Thanks for your help!