# RV OCIO not matching Nuke **URL:** \ **Category:** RV\ **Tags:** rv\ **Created:** [November 21, 2021, 2:20am UTC](https://community.shotgridsoftware.com/t/rv-ocio-not-matching-nuke/14052 "2021-11-21T02:20:08Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![zachops](https://avatars.discourse-cdn.com/v4/letter/z/22d042/32.png) [@zachops](https://community.shotgridsoftware.com/u/zachops)\ **Post date:** [November 21, 2021, 2:20am UTC](https://community.shotgridsoftware.com/t/rv-ocio-not-matching-nuke/14052/1 "2021-11-21T02:20:08Z")
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? ---
**Author:** ![zachops](https://avatars.discourse-cdn.com/v4/letter/z/22d042/32.png) [@zachops](https://community.shotgridsoftware.com/u/zachops)\ **Post date:** [December 23, 2021, 10:47pm UTC](https://community.shotgridsoftware.com/t/rv-ocio-not-matching-nuke/14052/2 "2021-12-23T22:47:11Z")
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? ---
**Author:** ![g.bailey](https://avatars.discourse-cdn.com/v4/letter/g/13edae/32.png) [@g.bailey](https://community.shotgridsoftware.com/u/g.bailey)\ **Post date:** [December 24, 2021, 2:39pm UTC](https://community.shotgridsoftware.com/t/rv-ocio-not-matching-nuke/14052/3 "2021-12-24T14:39:56Z")
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: > **[Chapter 11 - OpenColorIO | ShotGrid | Autodesk Knowledge Network](https://knowledge.autodesk.com/support/shotgrid/learn-explore/caas/CloudHelp/cloudhelp/ENU/SG-RV/files/rv-manuals/rv-user-manual/SG-RV-rv-manuals-rv-user-manual-rv-user-manual-chapter-eleven-html-html.html)** > > Table of Contents 11 OpenColorIO 11.1 The ocio\_source\_setup Package Join the discussion at our RV forum . 11 OpenColorIO OpenColorIO (OCIO) is a software library which provides cross application color consistency. You can use OCIO in RV's display,... Haven’t tried it, but there might be a way to change the RV OCIO config to use the CPU? ---
**Author:** ![Simon\_Arnold](https://sea1.discourse-cdn.com/shotgunsoftware/user_avatar/community.shotgridsoftware.com/simon_arnold/32/3058_2.png) [@Simon\_Arnold](https://community.shotgridsoftware.com/u/Simon_Arnold)\ **Post date:** [May 10, 2022, 10:01am UTC](https://community.shotgridsoftware.com/t/rv-ocio-not-matching-nuke/14052/4 "2022-05-10T10:01:45Z")
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. ---
**Author:** ![zachops](https://avatars.discourse-cdn.com/v4/letter/z/22d042/32.png) [@zachops](https://community.shotgridsoftware.com/u/zachops)\ **Post date:** [May 10, 2022, 4:33pm UTC](https://community.shotgridsoftware.com/t/rv-ocio-not-matching-nuke/14052/5 "2022-05-10T16:33:20Z")
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. ---
**Author:** ![Simon\_Arnold](https://sea1.discourse-cdn.com/shotgunsoftware/user_avatar/community.shotgridsoftware.com/simon_arnold/32/3058_2.png) [@Simon\_Arnold](https://community.shotgridsoftware.com/u/Simon_Arnold)\ **Post date:** [May 10, 2022, 5:34pm UTC](https://community.shotgridsoftware.com/t/rv-ocio-not-matching-nuke/14052/6 "2022-05-10T17:34:59Z")
Thanks very much. So i add that to the RV ocio\_setup config then I guess ---
**Author:** ![Simon\_Arnold](https://sea1.discourse-cdn.com/shotgunsoftware/user_avatar/community.shotgridsoftware.com/simon_arnold/32/3058_2.png) [@Simon\_Arnold](https://community.shotgridsoftware.com/u/Simon_Arnold)\ **Post date:** [May 13, 2022, 8:56am UTC](https://community.shotgridsoftware.com/t/rv-ocio-not-matching-nuke/14052/7 "2022-05-13T08:56:05Z")
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.