This is what we are doing, its no different as I said the transform to ADX10 causes neg values before the view transform is even applied on the CG, there are no neg values before this transform. I have it all built into OCIO already. Nukes viewer applies the supplied display transform in the correct logspace and works fine on the footage its only when CG is introduced we have the issues. So it makes me think CHG are doing something wrong, or we have to work to a reduced gamut for ADX10 material which seems wrong. I just used the gamut compress node from Jed Smith and that brings them back in gamut and stops the negs, but not sure this is the best way to approach it.
So just to confirm: viewer set to Raw, you read in the CG as ACEScg. No negative values. You add an ocioColorSpace node in: ACEScg out:ADX 10 and get negative values on the washed out log image of the CG
Yes that is what we are doing and that is whats happening and is shown in the images I posted.
Wow thatâs unusual. I think applying the gamut compress to the cg before you comp it should not present any problems down the chain. Itâs just âpixel healingâ.
I know it seems really strange.
Weâve done a number of projects similar to what you describe, usually with scans that are actually scaled to be ~2.5D rather than the typical ~2D range, but the following should still apply.
Step one you will note that the ADX curve has limitations below 95CV, as such I extended the curve at the bottom end see ACES to ADX transform · Issue #113 · ampas/aces-dev · GitHub for some more details. Iâve also played around with other non-linear extrapolation.
The second factor is the conversion from ACEScg to the âfilmâ primary encoding space, Iâve tried moving the primaries about such that the gamuts have fewer excursions, either by direct intersection with the other and by blending between that and the AP1 primaries. I think I found that the largest chromaticity delta in was in the green primaries and that moving it didnât make a large visual difference, but did help with numerical results. (I canât find my notebook where I did the calculations at the moment)
Kevin
So its a limitation of the ADX curve? Not much I can do here then as this is out of my safe zone as I am not a colour science expert.
If it is not present in Resolve maybe it is a limitation of the LUTs in OCIO implementation? Perhaps as a workaround you could render out in ACES exrs and apply the conversion back to ADX in Resolve for the dpx output deliverable.
This was my thought too. Perhaps the values of the smoke reach outside the target gamut.
Not possible to automate using Resolve, which we need with the amount of shots we are working on. We are not delivering back DPX we deliver back Scene Linear AP0 exrs so the issue will raise its head in DI . The issue is unavoidable whilst viewing material with the correct display or delivering back QuickTimes for director review. Using the Gamut Compression seems to be working for now but may bounce back to DI to see if they have any ideas. I do think that CG will just need to reign in their gamut to ensure it doesnât get clipped like this.
Simon regarding the discrepancy between Resolve and Nuke, are you using an OCIOv1 or OCIOv2 config? OCIOv1 uses LUTs which are limited, but OCIOv2 uses analytical transforms.
Also it might be good to set the color picking role to sRGB/Rec709 linear to keep the colors of the CG within a more reasonable gamut.
Hi Derek, we are on V1 we cant switch to V2 for some time as we are not on the DCCâs required for it or all python 3 yet. I will try switching the colour role but I dont see the one you mention, Only Utility - Linear sRGB or Rec.709
Yes, thatâs the one.
1 Like