Creating "looks" for an ocio config

[Derek Flood]

I am having some trouble creating a "look" LUT for an ocio config (spi-anim). That is, the config file is working it just fine with the added look definition, but visually it does not look as intended. So the way I am creating the.cube LUT file appears to be incorrect. It is visually close, but noticeably different visually. I don't think it's a matter of being in log space instead of linear (which typically looks very different). The differences are more subtle, but noticeable. 

The workflow is simple: Make a ColorCorrect, attach a CMS test pattern, and write the LUT with the GenerateLUT node. The Nuke script is using the spi-anim OCIO config.

Is there something I should be doing differently to get this to work? I'm sure it is just some silly nube mistake, so I'm hoping someone here might be able to help me sort this out.

[Troy Sobotka]

On Mon, Jul 10, 2017, 3:17 PM Derek Flood, <dere...@gmail.com> wrote:

I don't think it's a matter of being in log space instead of linear (which typically looks very different). The differences are more subtle, but noticeable. 

Where are you placing the look when you have the "correct" look?

With respect,

TJS

[Derek Flood]

In Nuke I have a read node with a render (linear EXR). This is modified by a colorCorrect node, then all viewed with the spi-anim OCIO config (Film sRGB view transform). That is the desired "correct" look.

I then pipe a CMS test pattern into that colorCorrect and generate a .cube LUT file.

That .cube LUT is used in the OCIO as a "look." The idea would be to view the image in Maya (Vray) using the OCIO config with the look applied, and have it appear the same as the colorCorrect in Nuke.

[Troy Sobotka]

On Mon, Jul 10, 2017, 7:30 PM Derek Flood, <dere...@gmail.com> wrote:

In Nuke I have a read node with a render (linear EXR). This is modified by a colorCorrect node, then all viewed with the spi-anim OCIO config (Film sRGB view transform). That is the desired "correct" look.

I then pipe a CMS test pattern into that colorCorrect and generate a .cube LUT file.

That .cube LUT is used in the OCIO as a "look." The idea would be to view the image in Maya (Vray) using the OCIO config with the look applied, and have it appear the same as the colorCorrect in Nuke.

So in this case your scene referred linear data is fed through your colour correct, and then through the view. Is your 3D LUT being generated off of the combined colorcorrect + view?

With respect,

TJS

[Derek Flood]

No, the 3D LUT is generated from the colorCorrect only. The view transform is not baked into the .cube file. In the OCIO config I have the display defined as

- !<View> {name: Show Look, colorspace: vd16, look: +Show Look}

then the "look" is defined to read in the .cube LUT

looks:
- !<Look>
  name: Show Look
  process_space: vd16
  transform: !<FileTransform> {src: look.cube, interpolation: linear}

So, as I understand it, it will get the vd16 color space definition for the view transform, and then apply the 3D "look" LUT on top of that...of course I am obviously understanding something incorrectly since it is not working.

[Troy Sobotka]

On Mon, Jul 10, 2017, 9:41 PM Derek Flood, <dere...@gmail.com> wrote:

So, as I understand it, it will get the vd16 color space definition for the view transform, and then apply the 3D "look" LUT on top of that...of course I am obviously understanding something incorrectly since it is not working.

I believe the order of operations is the issue here. The process space will take the scene referred linear to the vd16 domain. However in your original chain, I believe your colour correct is laid upon the scene referred linear and then rolled through the view.

Not sure exactly how the Nuke colour correct node is working, but it would then be applying the adjustment across the entire scene referred range, not the nonlinear vd16 range as indicated in your process space[1].

To get a 1:1, try applying a color correct after a color space transform to vd16 in Nuke.

With respect,

TJS

[1] Even setting the process space to the scene referred linear would be problematic as the 3D LUT can only operate on a bounded range. If this were required, a shaper would be needed prior to the 3D LUT generation I believe.

[Derek Flood]

okay that makes sense with the order of operations. I'll test that tomorow to confirm.

If that is the case then perhaps I could apply a linear to vd16 OCIOcolorSpace node after the colorCorrect, and write that out as the 3D LUT, which would thus include the view transform in the look LUT. Then in the config I could use the Inf colorspace instead of the vd16 like I have currently.

"Even setting the process space to the scene referred linear would be problematic as the 3D LUT can only operate on a bounded range. If this were required, a shaper would be needed prior to the 3D LUT generation I believe."

Can you say more about this? What would the shaper LUT need to do exactly? Would this be done with a OCIOcolorSpace node, or perhaps a linear to log conversion?

[Derek Flood]

Okay, so an update: 

1) as Tony suggested I tried first converting in Nuke to vd16, then applying the CC, and writing that out as a 3DLUT. Oddly that did not work. The CC shifts the colors towards red, but keeps the highlights white. When I generated a 3D LUT with vd16+CC and applied that to linear color space in the config, I got pink highlights.

What did work is to generate the LUT the other way around: CC+vd16 LUT, applied to linear color space in the config. That matches Nuke in the opposite order: vd16+CC. 

Honestly, I'm a wee bit baffled as to why these opposite combos match. 

2) Ideally it would be good to do these CCs in log space since as you said a LUT only has 0-1 range. The filmic OCIO config works in log color space, and applies a look contrast curve to that for the display. The difficulty with spi-anim vd16.spi1d LUT is that it performs a lin2log conversion and then a log2sRGB conversion all in the same LUT. So if I did a CC in log space and then applied vd16 on that, it would be doing linear to log twice:

lin to log + CC + vd16 = lin to log + CC +  (lin to log + log to sRGB Film curve)

So the question would be: how can I remove the lin to log shaper from the spi-anim vd16 1d LUT?

[Derek Flood]

That's Troy not Tony. Mea culpa.

[Troy Sobotka]

On Tue, Jul 11, 2017, 3:33 PM Derek Flood, <dere...@gmail.com> wrote:

On Tuesday, July 11, 2017 at 3:33:03 PM UTC-7, Derek Flood wrote:

Okay, so an update: 

1) as Troy suggested I tried first converting in Nuke to vd16, then applying the CC, and writing that out as a 3DLUT. Oddly that did not work. The CC shifts the colors towards red, but keeps the highlights white. When I generated a 3D LUT with vd16+CC and applied that to linear color space in the config, I got pink highlights.

Applying after vd16 will work assuming process space is set to vd16 and the view is also set to vd16 when viewing.

If it doesn't, the process of generating 3D LUTs is likely the culprit. ociolutimage or using a CDL is another option.

TJS

[Derek Flood]

Thanks for the tips Troy, much appreciated!

I believe I have found a solution that allows for the "look" CC to be placed before the vd16 color space. Instead of defining a Look in the config, I made a custom color space. I made one that works with a CDLtransform file:

  - !<ColorSpace>
    name: vd16_CC
    family: vd
    equalitygroup:
    bitdepth: 16ui
    description: |
      vd16_CC : vd16 color space with a CDLtransform "look" applied before in linear space
    isdata: false
    allocation: uniform
    to_reference: !<GroupTransform>
      children:
        - !<FileTransform> {src: show_cdl.cc, direction: inverse}
        - !<FileTransform> {src: vd16.spi1d, interpolation: nearest}

and another that works with a .cube 3d LUT:

  - !<ColorSpace>
    name: vd16_LUT
    family: vd
    equalitygroup:
    bitdepth: 16ui
    description: |
      vd16_LUT : vd16 color space with a 3d lut "look" applied before in linear space
    isdata: false
    allocation: uniform
    from_reference: !<GroupTransform>
      children:
        - !<FileTransform> {src: show_lut.cube, interpolation: linear}
        - !<FileTransform> {src: vd16.spi1d, interpolation: nearest, direction: inverse}

I'll need to do further testing, but these seem to work as expected, matching the CC look I am seeing Nuke.