This is my first time post on this forum and new to ACEScg.
I am currently experiencing difficulty getting the Nuke viewer, and Write node renders to match? I’m working on a project rendered from Maya 2020/Arnold using ACEScg and P3-D65 ODT. I’m using OCIO config 1.2 in both Maya and Nuke and the color variation is noticeable. In a separate test I have imported a P3-D65 McBeth chart (EXR) into Nuke to make sure its not a render issue from Maya. The basic McBeth test still shows the same color/exposure variation which has now got me completely stumped. From what I’ve researched my settings listed below are correct?
Nuke Project Settings:
Working Space: scene_linear (ACES - ACEScg)
8-bit, 16bit and log files: default settings
Float files: scene_linear (ACES - ACEScg)
Read File Node Settings:
Color space: scene_linear (ACES - ACEScg)
Write node setting:
I hope someone has experienced this issue and can pinpoint a solution?
Hey there Darren, welcome.
I think it will be hard to help you without a bit more data :
- what file format do you use to transfer your renders to nuke
- where is the shift happening ? In the nuke viewer ? In the media written to disk from Nuke ?
- could you provide nda-safe screenshot of Maya/Nuke/export using the macbeth so we can maybe have a better idea at what the difference looks like ?
I am positive it is happening when writing to disk. But i’m more than happy to be corrected!
I exported multichannel exr’s from Maya. I have attached the requested images and hope this helps.
Thanks, what exact colorspace are you using on the write node ? Is it
Output - P3D65 ?
Also the format you are exporting in and the image viewer you are then using has its importance.
Here is an example of a nuke setup that should led you to a good export. You have 2 options. The option with the OCIO Display is the most “clear” one. (keep in mind its not linked to the colorspace set in the viewer, you have to manually change it as I did)
Also here is the same screenshot but with the P3D65 colorchecker imported as
scene_linear (=ACEScg) which is incorrect.
As you can notice it’s surprisingly similar to the difference you just have posted so there is something to look for in that direction.
Thanks for the screenshots I will def give that a try!! Yes I am using the P3D65 Output option for the write node. All exr’s files are using the ACEScg colorspace and not the Scene_linear (ACES-ACEScg) input in Nuke. Not sure if that would make a difference?
If you bring in an EXR with that has a baked in ODT it is no longer ACEScg, nuke will by default treat all exr files as being ACECsg in your config and leave them untouched. Your nuke viewer will always apply a transform its set at regardless and will assume its ACEScg and apply the ODT again in the viewer so essentially applying a double transform and not match to the original image you have in nuke before rendering.
If importing in an EXR with a baked in ODT you have to set the read node appropriately for that ODT to correctly apply the inverse transform to return it back to ACEScg then nuke will process it correctly. In this case you set the read node to the same transform you applied at render.
Example in my Config Linear is an alias for ACES-ACEScg and Rec709 is the ACES Rec709 ODT.
Example one rendering out with the ODT backed in
Example two exr imported back in with OCIO treating it as its default which is ACEScg
Example three correctly applying the inverse transform of the read node and it matches back to example 1.
scene_linear is a role defined in the ocio config to be ACEScg.
I don’t think we have asked yet, but where are you comparing the results of the written file and what is the written file? If you are exporting to Quicktime ProRes and viewing in a video player perhaps the file tags are incorrect but the data is correct. It would explain why in your picture examples it looks less saturated.
@MrLixm and @simon.arnold, I tried both your setups and settings as suggested and the issue still remains the same. However @simon.arnold I have noticed that my Nuke options for the read node colorspace, does not have the P3-D65 as a choice so an inverse of that ODT is not possible? All that exists is the output and utility options which list the P3-D65. I tried both those options but are wildly incorrect. Do I have to edit the OCIO file to make the P3-D65 an Input colorspace option?
I am writing .jpg’s.
So let met get this straight. Your writing out a jpg file from Maya and burning in the P3-D65 ODT in the viewport for the render? Then importing this jpg into nuke and comparing it to what exactly? Are you sure your baking in the correct transform in Maya you do have to ensure that P3-ODT is the correct display the viewport is set to bake in.
Please post you OCIO entries for the Display your using and the colorspace its using. ODT are in the the output family in OCIO.
To check all is correct you need to get the same macbeth chart as scene_linear exr, import into Maya applying your ODT and render out as a jpg. Then bring in same scene_linear exr into nuke and set the viewer to raw, apply an OCIO Display Node to this read node and set this to the P3-D65 ODT you can then write out a jpg from nuke setting the write node to use the P3-D65 ODT, import in the jpg from maya and the one you made in nuke, set the read nodes for both to be raw this will stop Nuke from doing any color management. Bring in the macbeth chart EXR that already had the P3-ODT baked in that you mentioned.
Now compare the output from the OCIO display node to the jpg’s and the exr with the ODT baked in they should all match (slight variations due to jpg compression might be visible). If your config is correct then they should match and you have rendered the same source using exactly the same ODT’s.
Just be warned Nuke always assumes your working in a scene_linear working space and how it applies its viewers, sets read node colorspaces are based on this. What scene linear it is is dependant on how your OCIO config is configured. Nuke will always try and color manage automatically for formats known to be not scene_linear, such as dpx, jpg, tga, tif or movies. What it uses to do this depends on what roles you have configured in the OCIO config. You can override this to be what you want.
Also the viewer in Nuke is applied to all images in your graph so you either have to invert the display on each file to linearise correctly or turn of the viewer and use OCIO display node on individual read nodes to apply it only to the source that needs it. Or your applying the ODT again to an image that already has an ODT baked in.
A jpg is an 8bit image with a unknown Display transform (usually sRGB) baked in and nuke will use what you have set for matte_paint in the config (OCIO v1) for the read node to apply a transform to what it believes needs to be applied to it to linearise the image to the working scene_linear colorspace. So you need to set it to the known display transform that was used if its an ACES defined ODT they are all reversible it will be under Output as thats where all the ODT’s are defined as a colorspace.
Apologies I can clearly see i’m confusing us all due to my lack of knowledge around Aces so here is my workflow for the actual project
- All renders from Maya are MultiChannel Exr’s with ACEScg set as the Rendering Space and and ODT of P3-D65 set as the View Transform. My understanding is nothing is being baked in? (See Maya Pic)
- See Nuke Project settings for ACEScg Color Management. (See Project pic)
- Once in Nuke, I’m reading the MultiChannel exr files as scene_linear (ACES - ACEScg) (See Read Node Pic).
- I’m then writing out of Nuke a single .jpg with the colorspace set to P3-D65 (See Write pic)
- I then open the .jpg in the standard windows pic viewer to check results. (Thanks Simon for your process of checking the output renders for Maya and Nuke and maybe this is where im going wrong?)
Other than Step 5, im certain my process is correct? Again im happy to be corrected!
.jpgs written out of Nuke don’t have .icc profiles embedded. Windows picture viewer may assume something by default, not sure. I would load the jpg back into Nuke to verify it like Simon suggested.
I’m happy to report that all your info in one way or another solved the issue. I’ve learned the windows picture viewer was in-fact the issue regardless of how I write files from Nuke.
Thanks all for your help!!
The way some viewing software uses icc profiles to colour manage can throw you off. Macs ColorSync for years would try and manage Quicktimes and always make them look different where other apps would ignore ColorSync.