Redshift in Cinema4D - OSL ACES Gamut Convertion maybe wrong?

Discussions - Using ACES VFX
1

Hello,

Ryan Daniels linked in his post (Valid C4D Redshift After Effects ACES workflow? - #12 by rdaniels29)
to the Redshift OSL Shader Github repo: GitHub - redshift3d/RedshiftOSLShaders

It’s really fantastic, because that makes ACES in Cinema4D / Redshift so much easier. But I have a assumption, that there is something wrong in the transforms.

I tried the ACESGamutConvert.osl in CINEMA4D and found by eye that the result is different for sRGB and REC709.
And I mean different in color. Not in gamma.

I am abolutely no programmer, but by taking a look into the code I see a different matrix for sRGB and REC709.

As far as I learned from Charles Poynton those two share the same primaries and therefore the matrices should be the same.

The texture fed to the OSL node should be already linear if I understand the shadernodes in Redshift correctly.

In the code is:
// sRGB
{ 0.6131, 0.0701, 0.0206, 0,
0.3395, 0.9164, 0.1096, 0,
0.0474, 0.0135, 0.8698, 0,
0, 0, 0, 1 },
// Rec. 709
{ 0.6131, 0.0701, 0.0206, 0,
0.3395, 0.9163, 0.1095, 0,
0.0473, 0.1345, 0.8698, 0,
0, 0, 0, 1 },

So is that just wrong or what do I do wrong with it :slight_smile:

Is there a “official” resource for such matrix values? For sRGB to AP1 for example?

Thanks for your help!

Peter

2

https://www.colour-science.org:8010/apps/rgb_colourspace_transformation_matrix

sRGB_AP1
sRGB_AP11518×1372 177 KB

Note: the orientation of the matrix is reversed here compared to what your shader needs.

3

Perfect! :smiley:
What an incredible cool tool. Thank you very much!

What would you recommend for " Chromatic Adaptation Transform"?
“XYZ Scaling” sounds the least terrifying :grin:

But I have no idea what the other are. And they change the numbers quite a bit.

Thanks again! Very helpful!

Peter

4

If i’m not mistaking ACES standard is Bradford. And the color-science python package use CAT-02 by default.

The sRGB values on the OSL node should exactly match the widget with the Bradford CAT.

But i’m also curious to know why there is a slight change (0.001) between sRGB and ITU-R BT.709 matrices as I always read that they share the same primaries.

5

They do use the same primaries but not the same matrices to/from XYZ: ITU-R BT.709 does not define any BUT IEC 61966-2-1:1999 defines them rounded at 4 places. When to use which is kind of contextual, and depends if the software you interchange with re-computes the NPM given primaries and whitepoint or use the computed matrices.

Cheers,

Thomas

1 Like
6

Thank you all very much! Again very helpful! :slight_smile:

And just for the records:
I checked the numbers in the original OSL-conversion at GitHub - redshift3d/RedshiftOSLShaders again with that tool. Now knowing that one should use the “Bradford” chromatic adaptation transform, they are correct.

Still strange that the REC709 visually looks so wrong. But I just use the sRGB then :grin:

Thanks!

Peter

7

That’s because the Rec.709 one has a typo, with one value a factor of 10 out because a zero has been omitted.
(The other variations are just rounding)

EDIT: I opened an issue for this on the RedShift GitHub.

8

I believe Saul corrected the typo.

1 Like
9

Yes, you’re right. We had a short email conversation and he corrected that and improved even more. :+1:t3: