We are using ACES for a while, the color delivery between compositing and DI is reliable. For some reasons, we haven’t implement ACES color management in our whole VFX pipeline yet. So in compositing step, we have to deal with lots of sRGB/709 footage, and need to keep them looks identical as previous steps, such as MP or lighting, etc.
Here is some problems I met:
When we import footage which have linear gamma with sRGB gamut, which IDT I should use?
This snapshot shows the comparison between a sRGB(gamma=2.2"approximately" & sRGB gamut) file and a “linear sRGB” (gamma=1 & sRGB gamut) file in the nuke-default color management, when “linear sRGB” imported as linear, and sRGB imported as sRGB, it looks identical.
This snapshot shows comparison between a sRGB(gamma=2.2"approximately" & sRGB gamut) file and a “linear sRGB” (gamma=1 & sRGB gamut) file in the ACES 1.03 color management.
The code value of this sRGB colorchart photo (de-“camera curve”) is very close to the X-Rite target code value, so I think the right side of the comparison is reliable.
As the waveform monitor shows, the colorspace transformation from “Utility Linear-sRGB” to “ACES CG” to “sRGB(ACES)” ( the darker one) seems not right.
I found that when ACES shows the log footage on LDR monitor, it always has more contrast and more saturation than traditional color management.
Here is ACES color management from IDT LogC to ODT Rec709 in NUKE (it has the exactly result as it in DaVinci with ACES1.03)
The ACES transformation has beautiful highlight roll-off when handling HDR footage shows on LDR monitor, and preserve the linear code value at the same time. But I’m not sure if the Rec709(or sRGB) look is “correct” , or as the same look on the monitor on-set.
I personally use “Utility - sRGB - texture” as an IDT for a sRGB file. (gamma=2.2"approximately" & sRGB gamut) I know some people use “Output - sRGB” as an IDT but I have never been personally a big fan of this method.
Unfortunately I am not very familiar with resolve and log footage. But from what I can see, I would not expect to have the same result between a 3D LUT from Resolve and an ACES LUT. The ODT from ACES includes 4 LUTs in total (if I am not mistaken) including a filmic look (s-curve shape). This may be why it looks a bit more contrast and saturated.
I am happy to hear from ACES experts if that makes sense,
Hi Brejon, thanks for sharing!
We really care about the consistency of image appearance in shot reviewing and
delivering.
Using “Output - sRGB” as an IDT for a sRGB image, the image and waveform monitor looks identical with other software which using traditional color pipeline.
When I use IDT “Utility - sRGB - Texture”, the image looks much darker, seems like lower the offset, and then add a S-curve based on “Output - sRGB”.
Could you tell me why you prefer “Utility - sRGB - Texture” as an IDT for a sRGB file?
The main problem in your workflow is that your whole CG phase (before compositing) uses a non-ACES workflow, so you are forced in introducing an Input Transform at a very later stage in the process.
You may never expect to “see” footage converted into ACES pipeline the same as footage you look at through a non-ACES pipeline. This is simply so because what converts imaging in Rec.709 on your monitors comes from different algorithms.
Only if you use ACES thoughout you can expect to reliably and consistently see footage the same across all products.
I know many CG/lighting software is not yet ACES-compliant, but some are indeed (3ds Max, Maya, etc.), so better think off for next project.
Hi Walter, thank you for your suggestions.
One of the reason that I had to match the linear sRGB is our HDRI captured on set by DSLR is in sRGB gamut and "de-tone curve"ed and then merged in scene-referred linear.
Still about the the sRGB tone mapping of ACES. This footage shot by RED Raven.
In nuke default color management. Here I choose the “P3” colorspace or gamut in debayer setting, just because there has the same gamut in colorspace node. I transferred the colorspace into sRGB in order to pickup the code value to check with x-rite colorchecker’s target value. The result is similar to the x-rite target sRGB code value.
I know the sRGB ODT has a good tone-curve, but in our case we need a “traditional sRGB reference”. I use OCIOcolorspace to do a gamut conversion, and then use a colorspace node to do a traditional linear-sRGB curve conversion, In this way I can get a close result to nuke default, beside a little difference in saturation.
But don’t know how to do a correct conversion before applying ACES sRGB ODT.
Do you have any advice in our case?
Hi Ivan.
I’m not sure I can follow your workflow from the description or from the pictures.
There’s nothing wrong with DSLR footage captured in sRGB gamut (apart from possible lack of color-depth, especially if it’s 8bpp). You just need to process it directly in ACES from the beginning, through an ACES Input Transform that is to be used consistenly by all software processing the footage.
If, instead, footage is converted in a non-well specified “scene-referred linear” space (non-ACES managed), to be later processed again via ACES color-management (by means of an ACES Input Transform) you’re not to expect anything to be color-matched.
Besides, looking at your pictures --and whatever your color pipleine is (ACES or non-ACES)-- there’s some alert: I can see you set the Nuke’s Read node in two completely different image states / colorimetry:
DCIP3 in one case (which is an output-referred colorspace – for displays), then in
REDWideGamutRGB in the other (which is a scene-referred colorspace – for cameras)
Then something is processed in sRGB… there’s something deeply wrong with it.
Especially given your multi-camera setting, you should convert every footage in ACES2065-1 via their respective Input Transforms (from LogC, RED WideGamut, or sRGB), then set Nuke working space in ACEScg.
The viewport and Write nodes should use the correct ACES Output Transform(s) for your monitors or deliverables.
As regards your ACES-related questions: in my opinion, you are still out of focus here. What I have the impression you are about to achieve is having a few passage through ACES, but working in a fundamentally non-ACES color-managed pipeline. There is simply no easy way to match things in this case; and certainly that won’t be an ACES workflow.
I uploaded the wrong pic before, the 3rd image. I’ve modified my reply.
Maybe there is some misunderstanding caused by my state, or my crappy english.
I have a basic concept about ACES workflow.
The pics I showed is not any step in our workflow, It’s just my test, and want to express my question about sRGB footage handling in an ACES workflow.
As I said before, I choose DCIP3 in r3d debayer setting just because there is the same option in the node “Colorspace”'s gamut “in”. I know is not a right choice in the workflow. In this test, I just try to keep the consistency of colorspace conversion in nuke-default color management.
In the 2nd pic, for the same reason, I choose the redwidegamet because my input raw file debayerd as linear-redwidegamet.
I want to show the difference viewing processing between nuke-default and the ACES RRT+ODT makes me missing a reference when handling sRGB footage in a ACES pipeline. And the reference here for me are two things:
the target sRGB codevalue of X-rite colorchecker
the consistency of image looks in sRGB viewing environment with pre-ACES pipeline steps.
Especially, the the tone mapping in the processing of scene-refered colorspace to a display-referred colorspace makes me unsure about the conversion.
I’m not trying produce a shot, and this is not our workflow. We do set the Nuke working space in ACEScg.
About the DSLR footage, our HDRI images merged by 3 photos which shot over and under 3 stops around normal exposure. we de-"tone curve"ed (camera curve) the 12or14 bit raw file by dcraw, and merged them into one HDRI image, saved as a 16bit HDR file. This file is a linear and sRGB-gamut image.
These images are the on-set lighting reference for lighting and compositing.
You mean we should convert the colorspace of the DSLR footage into ACES int the first step. And this is just my concern, I don’t know how to judge if I did a right sRGB-ACES 2065-1 conversion.
Different image apearance as before, and difference sRGB code value in sRGB viewing state.
Hope I expressed my question a little bit clearer in this reply…
Regards,
