RV OCIO not matching Nuke

RV
1

I’m using RV with an OCIO config and am trying to do a colorspace conversion from ACES2065-1 to ‘Output - Rec.709’. The OCIOColorSpace conversion in Nuke, using the same OCIO config file, appears to be working correctly. In RV the same colorspace conversion isn’t matching … the gamma appears correct, but not the gamut. The following code in my custom RV Package results in the chroma not matching the same “ACES - ACES2065-1” → “Output - Rec.709” in Nuke:

RV Package snippet:
look_pipe_nodes = [“OCIO”]
commands.setStringProperty("%s.pipeline.nodes" % lookPipeNode, look_pipe_nodes, True)
ociolook_nodes = extra_commands.nodesInGroupOfType(lookPipeNode, “OCIO”)
ociolook_nodes.sort()
ocio_ap0_to_rec709_node = ociolook_nodes[0]
commands.setStringProperty("%s.ocio.function" % ocio_ap0_to_rec709_node, [“color”])
commands.setStringProperty("%s.ocio.inColorSpace" % ocio_ap0_to_rec709_node, [“ACES - ACES2065-1”])
commands.setStringProperty("%s.ocio_color.outColorSpace" % ocio_ap0_to_rec709_node, [“Output - Rec.709”])
commands.setIntProperty("%s.ocio.active" % ocio_ap0_to_rec709_node, [1], True)

The result in RV is more cyan than Nuke.

I can get closer using an OCIO Look in RV and changing the ‘process space’ to be ‘Output - Rec.709’ in RV … but this results in the RV image being actually slightly less cyan than Nuke compared to the pure OCIO colorspace transform situation above.

RV Package snippet:
ociolook_nodes = extra_commands.nodesInGroupOfType(lookPipeNode, “OCIOLook”)
ociolook_nodes.sort()
ocio_ap0_to_rec709_node = ociolook_nodes[0]
commands.setStringProperty("%s.ocio_look.look" % ocio_ap0_to_rec709_node, [“ACES2065-1_to_rec709_ps-rec709”])
commands.setIntProperty("%s.ocio.active" % ocio_ap0_to_rec709_node, [1], True)

OCIO config snippet:

  • !
    name: ACES2065-1_to_rec709_ps-rec709
    process_space: Output - Rec.709
    transform: ! {src: default, dst: Output - Rec.709}

However, the OCIOColorSpace transform AND the OCIOLookTransform are identical within Nuke, but in RV they don’t match.

Clearly I’m missing something, or are RV and Nuke interpreting the same OCIO config differently, which seems … crazy?

3 Likes
2

Anyone? Maybe just a holiday hello? Any insights from the Autodesk/ShotGrid/RV team on why RV would interpret an OCIO config differently than Nuke?

3

SG help seems to be MIA these days.

I know that RV references the GPU implementation of OCIO, not the CPU which is what Nuke uses. And the two are not exact matches. The reference manual says there are known discrepancies:

Haven’t tried it, but there might be a way to change the RV OCIO config to use the CPU?

4

I was about to post about this. I am noticing a very big difference between Nuke and RV. On some shows the difference seems to be very big on others less so but still there and more than I would expect is this really the norm?. It definitely affecting the blue channel more, as skies appear way more saturated and I would say blacks are slightly lifted. Nuke matches to the supplied references and i now is correct.

5

I had a long back and forth with the RV engineers via Autodesk support and this is below is the outcome.

In short, as @g.bailey referenced, RV uses GPU and Nuke uses CPU. Out of the box the OCIO processing is not a great match between RV and Nuke in all situations. You can close this gap in RV 2022.0.1 or later by setting the variable RV_OCIO_3D_LUT_SIZE to 65

Example:
export RV_OCIO_3D_LUT_SIZE=65

TL;DR
In the footage I was testing this definitely got it closer. A/B I could still see a small difference, like in the skies as @Simon_Arnold may have experienced, but side-by-side on the same monitor it was hard to see a difference with the naked eye. Your mileage may vary.

I followed up with the Engineers to see if a value higher than 65 would get it closer (it didn’t in my tests, I have no idea what that value represents) and the Engineers confirmed 65 is the best they can do to close the gap unless Nuke were to use GPU processing for OCIO.

With this information, though the Engineers didn’t mention it, I also found that setting .ocio.lut3DSize on any OCIO RV node will achieve the same thing.

Example:
commands.setIntProperty("%s.ocio.lut3DSize" % the_ocio_node[0], [65])

So if you are stuck on RV prior to 2022.0.1, need more granular control on a per-node basis, or setting the RV_OCIO_3D_LUT_SIZE variable isn’t appropriate for your setup you could use this approach.

Thanks to Rafael Dart in support for sticking with it for over four months while the Engineers looked into the issue, and for RV Engineers that ultimately implemented a variable to more easily get RV GPU to match Nuke CPU. Would be great if this where now clearly stated in the RV documentation.

1 Like
6

Thanks very much. So i add that to the RV ocio_setup config then I guess

7

Ok we put this in and yes its a big improvement but still quite a bit out on Skies. Will have to wait until we can use OCIO v2 and see if the GPU updates in that get them closer.

1 Like