ACEScg in VFX for Non-ACES Shows in Nuke (OCIO) and Multiple Cameras

Discussions - Using ACES
, , , , , , ,
1

Hi Aces Community,

This is my first time posting so i hope i can explain correctly what i am trying to accomplish.

I have a non-aces project that is using multiple cameras (ie. Alexa, Red, GoPro, Stock, etc.) and the goal for this workflow is to read a ProRes, R3D or other camera sources inside of nuke and write out ACEScg EXRs.

In the case of Alexa ProRes, i am looking at the meta data and seeing Log-C and if i am understanding this correctly i would have to select ARRI - V3 Log-C (EI 800) as my IDT in the read node and create a write node with colorspace set to ACES - ACEScg.

In the case of R3D files, i am looking at the meta data and seeing Log3G10 - RedWideGamutRGB therefore in the read node i select RED - REDLog3G10 - RedWideGamutRGB as my IDT and in the write node set the colorspace again to ACES - ACEScg.

Is there any documentation out there for real life examples of similar workflows for other cameras such as GoPro, Black Magic, Canon, Sony, etc.

Once I have the ACEScg EXRs, apply the On Set Grade / CDL and Show LUT to match the offline reference provided by the client. Here is an example of some red footage in nuke:

Read Node (nuke viewer set to Rec.709 (ACES))
ACEScg > OCIOColorSpace Node (in ACEScg, out REDLog3G10 - REDWideGamutRGB) > OCIOCDLTransform Node in ACEScg workingspace > OCIOFileTransform (client provided show lut in ACEScg working space) > OCIOColorSpace (in Output - Rec. 709, out ACES CG)

The result unfortunately is close but doesn’t match, offline reference on top right and acescg exr with above color workflow on the bottom left of attached reference.

Screen Shot 2020-08-11 at 6.10.38 PM|570x500

Same workflow using an Alexa ProRes footage however is a much closer match to the offline reference.

With so many different inputs there are a lot of variables in play. With hundreds of shots being ingested in this way I need some sort of a precise way of determining what camera the footage is shot on to know what IDT to use to output ACEScg EXRs in order to automate this process.

I guess i’m just trying to get advice and feedback if this type of implementation is similar to what others are doing or do i have this all wrong.

Thanks in advance.

2

Hi Andranik! Welcome :slight_smile:

First things first - what you’re experiencing is completely normal!

As far as IDTs go - you are on the right track and what you have for the ALEXA and RED cameras sounds correct - some of this should happen automatically for you if you’re reading from .R3D raws in the read node in Nuke, but never hurts to just set exactly what you want. You’ll have to do it manually for the ProRes files.

As far as documentation for workflows, what you’ll find here on ACES Central is likely the closest. Sony and Canon have published ACES IDTs and are in the OCIO config. There’s also a few (experimental) gopro “idts” though they are not official. Blackmagic has ACES IDTs, but they are not published (as far as I know) - best advice I have there is to use Resolve to debayer & write BMD footage.

This is very close. It’s an interesting thought to try and invert out the Output - Rec.709 transform to ACEScg so that you can still use the viewer, but it’s not going to be exact - inversion of a 3D LUT is a complicated game and can’t ever really be expected to match reference - should only be used as a last resort. I can point you to some resources that explain a bit more about 3D LUTs and their limitations/uses in these workflows if you’d like - but your best bet is to try and avoid inverting them if possible :slight_smile:

You have a few options instead:

  • Choose “Raw (ACES)” from the viewer dropdown. This will essentially turn off the view transform, and enable you do do the entire chain in the node tree. So your workflow would be:

Set Nuke Viewer to RAW (ACES) > ACEScg > OCIOColorSpace (in ACEScg, out REDLog3G10 - REDWideGamutRGB) > OCIOCDLTransform Node in ACEScg workingspace > OCIOFileTransform (client provided show lut in ACEScg working space)

  • Create your own OCIO config with your client provided LUT, and select that view instead of the ACES output transform. If you go this route, there’s other things you’ll need to account for. Happy to help you get going if you’d like to try it out.

Just to confirm - is all the grading happening in a single grading colorspace (for the CDLs) or in each camera’s encoding? Will be important to track that.

Lastly - all of this is assuming you are using the ACES configs that ship with Nuke, and that your working space and float files roles are set to ACES - ACEScg in your Nuke project settings.

Hope this helps - let us know how you get on!

1 Like
3

Even though they are experimental, they are coming from GoPro, just to clarify that they are not some random values coming out of thin air.

Cheers,

Thomas

2 Likes
4

Thanks, Carol for all your Suggestions. I’m happy to say that I was able to successfully create an ACES config file using ACES 1.2 config as my starting point and introducing some shot/show environment variables that search the paths for a show LUT and cc file on the file server and is viewable through custom looks and a viewer transform through the Nuke Viewer. This was huge progress for me!

Your suggested alternative of writing out ACEScg exrs from Resolve is definetly an option that im exploring but the goal for me is to be able to pull in any camera source, whether is RED, ARRI, GoPro, BlackMagic, Canon, Sony, Etc and for nuke to set the correct IDT for that read node. Is this something that is even possible to do? Has anyone done this?

Red and Arri are easier since we have good metadata coming through that can help recognize the colorspace.

Metadata example in the case of a ProRes 444 coming from an Alexa Mini:

{quicktime/arri/camera/CameraModel “ARRI ALEXA Mini”}
{quicktime/arri/camera/ColorGammaSxS LOG-C}
If nuke sees the following information in the read node metadata then it automatically sets the colorspace within the read node to be Input - ARRI - V3 LogC (EI800) - Wide Gamut.

{r3d/color_space REDWideGamutRGB}
If nuke sees the following information in the read node metadata then it automatically sets the colorspace within the read node to be Input - RED - REDLog3G10 - REDWideGamutRGB

Looking at the metadata from a GoPro or BM sources there is nothing that I see in there that can be used to apply similar logic as above. The only key that can potentially be useful but unreliable is the {input/filename}.

{input/filename SHOW/ GOPRO /F002_RT/F002_GX020064_RT.mov}
{input/filename SHOW/ BM_POCKET /E037_ProRes/E037_01051412_C002.mov}

I can maybe grab the folder name 2 folders up from the source movie which is GOPRO and BM_POCKET but again if the provided footage is not in that specific structure then the logic will not work.

I may be totally overthinking this but i’ll let someone that is more knowledgable on the topic tell me.

Thanks again for all your help.

Andranik

5

I just checked a Blackmagic Film ProRes file from a Pocket 4K, and there is a lot of metadata there. Certainly I would think enough to identify the format of the footage.

com.blackmagic-design.camera.cameraType:
Blackmagic Pocket Cinema Camera 4K
com.blackmagic-design.camera.colorScience:
Blackmagic Pocket Cinema Camera 4K, Color Science Gen 4
com.apple.proapps.customgamma:
com.blackmagic-design.camera.filmlog

There are no official IDTs for Blackmagic cameras outside Resolve, but the primaries and whitepoints of the various colourspaces are shown on Resolve’s chromaticity scope. I have been experimenting with adding the Blackmagic colour spaces to my fork of Colour Science for Python, which you can see here, if its helpful. There is enough information there to build a custom ACES OCIO config which includes the Blackmagic colour spaces.

1 Like