RV ocio profile different to Nukes

RV
1

This is perhaps more of an OCIO question than RV, but given the heads here I thought I might post this here too (already posted on the Aces forums).

I thought I was getting on top of working with Aces, but I’ve hit a bit of a brick wall in terms of understanding. I’ve got a profile which works in RV but not in Nuke.

The source image is aces2065-1, so my readnode is set to aces2065-1 to convert it to acesCG on reading in.

ocio roles are :
roles:
color_picking: Output - sRGB
color_timing: ACES - ACEScc
compositing_linear: ACES - ACEScg
compositing_log: Input - Sony - Curve - S-Log3
data: Utility - Raw
default: ACES - ACEScg
matte_paint: Utility - sRGB - Texture
reference: Utility - Raw
rendering: ACES - ACEScg
scene_linear: ACES - ACEScg
texture_paint: ACES - ACEScc

So I’m assuming, that nuke is working ACEScg. This is confirmed by checking the ocio confi8g in nuke and under “working space” it’s set to ACES - ACEScg.

In Nuke, I have a shot profile that I’m using to apply a working space -> log, and then a cdl, and then a lut. This seems to be a fairly common setup these days.
This looks like this :

- !<ColorSpace>
    name: Shot
    family: Blah
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Blah Default Shot Display LUT for sRGB
    isdata: false
    allocation: uniform
    allocationvars: [0, 1]
    from_reference: !<GroupTransform>
      children:
        - !<ColorSpaceTransform> {src: ACES - ACEScg, dst: Input - Sony - Curve - S-Log3}
        - !<FileTransform> {src: "${CDL}", interpolation: linear, cccid: 0}
        - !<FileTransform> {src: "${LUT}", interpolation: linear}

Note that this is “from_reference”.

In RV, the only way I could get this to work is apply the profile as a OCIOFile node and in this case its much the same, except it’s “to_reference” :

  • !
    name: Shot (RV)
    family: Blah
    equalitygroup: “”
    bitdepth: 32f
    description: |
    Blah
    isdata: false
    allocation: uniform
    allocationvars: [0, 1]
    to_reference: !
    children:
    - ! {src: ACES - ACEScg, dst: Input - Sony - Curve - S-Log3}
    - ! {src: “{CDL}", interpolation: linear, cccid: 0} - !<FileTransform> {src: "{LUT}”, interpolation: linear}

To view/compare the results of these, I’m setting the viewerprocess in nuke to Raw and the display in RV to raw. In Nuke I’m adding a OCIODisplay node after the readnode and setting the input colorspace to ACEScg (as that’s the working space we are in in nuke), and the view transform to “Shot”. This should replicate how our viewerprocess would display when set to the “shot” profile.

What’s odd is that in Nuke, I’m not getting what I expected, the image looks like it’s not being processed in AcesCG space. I CAN get the correct result if I set the input colorspace to aces2065-1… but as we’re already processing the input image into acesCG this doesn’t make any sense to me, and although it works, I’m not happy that it seems like something is going wrong.

RV on the otherhand appears to be displaying the ocio profile correctly.

So what am I doing wrong?
One other question, why do I need to use “to_reference” for the RV profile and not “from_reference” as I’m using in Nuke ? Is there any way for me to use the same profile in both nuke and rv ?

Thanks in advance for your help!
p.

3 Likes
3

An update in case this might help others with the same issue. I received a reply from the Foundry regarding this issue :

After further investigation, we have discovered that the issue you are encountering has been previously logged as a bug within our developers database.
TP 347836 - Applying an OCIO config to the viewer process versus the OCIOColorSpace node gives a different result, when comparing the seperate RGB channels

I have added your comments and information to the above bug, and you will be updated automatically on the progress of this issue as the developers continue this investigation.

In regards to the cause of the issue, we suspect this occurs as the OCIODisplay node (which controls the Viewer’s OCIO output) has channel ‘swizzelling’ incorporated by default, whereas the the OCIOColorspace node does not.

When referring to ‘swizzelling’ this is terminology to explain that the node (in this case OCIODisplay) is separating the channels before applying to colour transform calculation, whereas most colour transforms in Nuke apply separating the channels after applying the colour transform operations. This slight variance in process specifically within the OCIODisplay node is what we suspect to be causing the issue.

Unfortunately, at this point in time, we do not have a workaround for this issue and the development team have been made aware of the importance of this issue.

I will now be closing this support request, although if you have any further questions related to this issue please feel free to get back in contact.

2 Likes