I am trying to make my company to adopt ACES, we have already made the switch on some extend but there is still blurred area that I didn’t get.
We are producing full CG film, occasionally integrated with live footage. We are rendering and comping in ACEScg. In various documents found here it says our delivery should be in ACES2065-1 color space.
My question would be quite simple. Why ? What is the benefits to store deliveries ACES2065-1 rather ACEScg ? ( We are using EXRs as a container )
As far as I understand it, it’s just to keep a standard.
If many years from now you need to view that files again, you just need to know that it’s ACES.
Not “which” ACES.
Although I really wonder if that will be the case if RRT and ODTs are changing with versions.
We are using ACEScg when rendering,because it is the default setting and not find a way how to rendering out as ACES2065-1 in Arnold , but using ACES2065-1 when write out exr from Nuke to Resolve
@Baiking: Generally, you should avoid rendering with ACES2065-1 because it is far from optimal for computer graphics rendering, some RGB colourspaces are performing better than others and ACEScg (AP-1) is greater than ACES2065-1 (AP-0) here. Some reading:
On 1) ACES-compliant EXR does have to do with AP0 primaries, but also includes metadata.
On 2) Rendering in ACEScg uses color primaries that are closer to actual devices - a little bigger than Rec2020, but AP0 is the target for File Outputs (and archive and interchange). When working completely within your own facility without sharing of files, ACEScg is sometime used for convenience but using the format in the name of the file to distinguish it from the ACES standard (putting ACEScg in EXR with the primaries specified - a device or AP1 - means it is not an ACES file. The ACES flag in a header should not be set.
The colorspace drop-down in the write node still needs to be set to ACES - ACES2065-1 (and the rest of the OCIO pipeline correctly set up) or the image data being written must be converted to ACES2065-1 in some other way. Checking the ACES compliant box will not change the image data to ACES2065-1, it will simply flag it as being that, even if in fact it is not.
Thank you for the amazing contributions to the Aces community!
In an effort to share knowledge and looking for personal reassurance myself, I have the following questions and wanted to make sure all my statements are valid as of October 1st, 2023.
#1 PRE-COMPs: When exporting an exr precomp from Nuke for later use in Nuke, should I export it as Aces_CG or should I consider the file as “exchange or archival”, and export it in Colorspace:Aces_2065_1 and EXR Options: wirte ACES complaint EXR?
#2 When rendering in Arnold, I choose Aces_CG as my rendering color space. When importing the render in Nuke, I import it as Aces_CG. Is there any in between step required?
The concept of exchanging files in Aces_2065_1 does not apply here?
#2B All the process described until now has involved one person (me) carrying the shot from start to finish on one computer.
What if I render the CG part, and someone else on a NAS will work on it on a different machine? Should the CG always be rendered in Aces_CG? Should the Aces_CG render be precomped in Nuke to Aces_2065_1 and then shared on a NAS?
Do the same considerations for a NAS apply for data exchange between Studios?
As for interchange with Editorial and DI, we all agree that Clean/Back plates are to be requested in Aces_2065 16bit EXR and returned/forwarded to DI as equal.
For rendering, Aces_CG is our choice of colorspace.
Your wisdom really has a great impact and facilitates our community.
I appreciate and thank you,
Diego
#1 for internal precomp, I would personnally stick to ACEScg. #2 The concept of “exchanging file” does not apply between Arnold and Nuke. I would say same thing with a NAS ?
I think the terms “exchanging files” implies to another studio. Internally at my previous studio, ACES 2065-1 was never used nor manipulated by the artists. It was strictly for external delivery. We thought it was easier if we sticked to ACEScg internally.
I think @ChrisBrejon has said it all. Basically using ACEScg EXRs is not the “official ACES way” but is very commonly used, particularly for internal exchange.
But as has been said before in this thread, if you do it:
Ensure, by file naming and good communication, that everybody knows the files are ACEScg
Do NOT set the “ACES compliant” flag in the EXRs – they are not properly ACES compliant
If there is any possibility that the files may be used by somebody who doesn’t know they are ACEScg, don’t use it. Use ACES2065-1 EXRs.
Check turnover specs, and if anybody is expecting ACES2065-1 EXRs (for eg DI) make sure that is what you give them.
Hi every one, I have been working with Aces for a while now and normally we work everything in Aces CG and final exports in ACES 2065-1 for delivery, as you guys mention.
The thing is, I started working with another studio and they are using footage exported in Aces 2065-1 to comp. So every Comper is using this footage as it comes. My main question is… pre-render this footage in ACES-CG inside nuke is must, right?.
What they are doing now is interpret footage in nuke as ACES-2065-1 and work with it, if a pre-render is needed they use ACES 2065-1 too.
Another thing that they are doing is mixing footage exported in different versions of ACES.
3D is exported with version 1.0.3, And compositing department is working with 1.1 version, maybe in the near future they will use ACES 1.3.
Everything is a mess right?
If the footage is encoded as ACES2065-1, this is what you should pick from in the Read node colorspace.
From a colour rendering standpoint, nothing has changed in the 1.x releases except for the HDR Output transforms. Because you deliver ACES2065-1, it should not matter anyway.
Good practice is to use colorspace tags in the filenames, e.g. aces or acescg. Then everyone knows how they have to set their read nodes in nuke.
Sadly even with the new OCIOv2 configs the default name tags are still not as clean and clear as they could be and they are often too long.
Great, so mixing version will no be a problem in the future . I did a difference test between versions before asked this question and they match perfectly, But I was a little bit unsure about what type of changes were made, and if something will be different when comping.
So work with footage in ACES 2065-1 will not be a problem when doing compositing as long as we interpret it correctly right?. This is because nuke working space is in ACES CG and make all internal conversions to work with any imported material.
. I did a difference test between versions before asked this question and they match perfectly, But I was a little bit unsure about what type of changes were made, and if something will be different when comping.