ARRI and RED DRTs in OCIO

I figured it out, the direction of Log curve is wrong

1 Like

@Derek how did you get the LMTs how are they made? Currently most of our VFX shows I have to use the same model as your Reveal workflow as most are hybrid ACES workflows anyway but would be interested to know how to get a supplied Display LUT into a DRT that can be used with the ACES Display. I am a novice be gentle with me.

The LMTs are from @priikone

1 Like

Thanks Derek very helpful

@Derek @ysysimon I replicated what you did on this thread and edited further based on what I understood, but I found out the result is slightly bland compared to the way of implementing LUT file directly. Please tell me what could I have possibly done wrong?
Discussions - Using ACES VFX

  - !<ColorSpace>
    name: TestLUT
    aliases: [test_lut]
    family: Input/ARRI
    equalitygroup: ""
    bitdepth: 32f
    isdata: false
    encoding: scene-linear
    from_scene_reference: !<GroupTransform>
      children:
        - !<MatrixTransform> {matrix: [0.695452, 0.140679, 0.163869, 0.000000, 0.044795, 0.859671, 0.095534, 0.000000, -0.005526, 0.004025, 1.001501, 0.000000, 0.000000, 0.000000, 0.000000, 1.000000]}
        - !<MatrixTransform> {matrix: [1.3317489220, -0.1910418312, -0.1407070910, 0.0000000000, -0.0010810260, 0.9928187215, 0.0082623045, 0.0000000000, 0.0006639882, 0.0007515137, 0.9985844981, 0.0000000000, 0.0000000000, 0.0000000000, 0.0000000000, 1.0000000000]}
        - !<LogCameraTransform> {log_side_slope: 0.0647954196341293, log_side_offset: -0.295908392682586, lin_side_slope: 2231.82630906769, lin_side_offset: 64, lin_side_break: -0.0180569961199113, direction: forward}
        - !<FileTransform> {src: ARRI_LogC4-to-Gamma24_Rec709-D65_v1-33.cube, interpolation: best}
        - !<RangeTransform> {min_in_value: 0., min_out_value: 0., max_in_value: 1., max_out_value: 1.}

This is the difference between two images.

Hi @Victor in the first image it looks like you are reading in your DPX as raw, and applying the ARRI Lut. One thing that is missing here is the color gamut conversion. That may account for the differences in the two images.

In the second image you have the same DPX going into a color space conversion from LogC4 into ACEScg. (This you can just do on a Read node setting the Input Display to LogC4 btw). Then you are viewing it with the Display Transform in the OCIO. There you have two matrix transforms. The second is the color gamut to AWG, Iā€™m unclear what the purpose of the first one is? Can you clarify?

Hi @Derek,
Thanks for the reply. The first line of matrix transform is actually to convert ACEScg to ACES2065-1. The reason I did that is due to the following matrix and log transform which are inverse conversions of ARRI LogC4 to ACES2065-1 (please correct me if I misunderstood). Could you please specify the missing color gamut conversion before applying the ARRI LUT?

FYI, this is where I got the image from.

Hi Victor,

Havenā€™t looked through the full setup yet but I believe on both ends youā€™ll want to set the interpolation to Tetrahedral.
Yours has Linear on the OCIOFileTransform and Best in the OCIO version.

Furthermore AFAIK all conversions in ACES OCIO should be to and from ACES 2065-1(reference). ACEScg is only the default working space, not the conversion space. So the first matrix isnā€™t needed. Like @Derek said, instead of Raw Data the read node should be set to input space ARRI LogC4 which the config would then convert to ACEScg but also back to reference once it converts to another space/display. To do your null test Iā€™d just duplicate the read and set the other to Raw to directly apply the LUT there.

Hope that helps.

Blockquote

Could you explain the difference between Tetrahedral and Linear? Iā€™d love to understand that better.

Precisely.

Hmm, Iā€™d think youā€™d want to have the Read node the same in both, no? That is, the Read node should be set to Input Transform: LogC4. Then in the first chain it should have 1) a color matrix from ACEScg to AWG 2) color space from ACEScg to LogC4 3) the LUT. This would parallel what is in the OCIO. The difference being that in OCIO, as you said, you want to be working in AP0, while in Nuke you are working in AP1.

Take a look at the Nuke script here:
Post #9

Thatā€™s also an option but I think Victor wanted to test the OCIO implementation against the direct application of the ARRI LUT on the source, hence my suggestion.

I donā€™t know much details about this topic but I know tetrahedral is what is being used generally for 3D LUTs in post workflows for the best interpolation quality, which especially for lower resolution LUTs like 33 or lower size matters. Iā€™m not familiar with the ā€œbestā€ method. But ā€œtrilinearā€ is cheaper/faster to calculate which maybe for some on-set hardware devices is what they use, but less accurate.

I also think Linear is intended for single dimension and trilinear for 3D LUTs but could be wrong.

1 Like

Hi @shebbe @Derek,
Thanks for helping. I finally figured it out and got it worked. As you said, thereā€™s no conversion needed from ACEScg to ACES2065-1. Yet, it looks somehow different in Nuke than other DCC softwares which looks matched when viewer LUT is set to the modified colorspace conversion (in my case is ā€œTestLUTā€).



Odd, would you mind sharing your config file?

Sure! Actually, I still found out thereā€™s a minor difference between the first and third images, similar to the result I did on previous post. I wonder whether there is something missing during color conversion or define the colorspace of the image wrongly?

testLUT.ocio.txt (55.8 KB)

It all looks fine to me. In Nuke NC v15.0 and in After Effects they perfectly null. But on the File Transform you have to match the interpolation method, which you set to best in your config.
A color space mismatch would probably yield in a much larger colorshift that would be immediately noticable.

Alright, I think thereā€™s something wrong with my nuke file for testing. When I open new comp file to test, it shows exactly the same result as you showed. Thank you for clarifying all those steps. :slight_smile: