ACEScg for Animation feature and further questions

Discussions - Using ACES VFX
, , ,
1

Hi everyone,

I have been investigating ACES for the past month and it has been great. The topic is broad and very very interesting. I have been amazed by the amount of knowledge and the support provided by this community. I thought I would do a quick check point in this post and ask further questions.
Thanks all for your help!

I will focus here mainly on ACEScg and its utilization for full cg animation feature. :wink:

First thing that took me some time to figure out, (it may sound very obvious), but why is ACES interesting for full cg stuff?

image
image742×225 9.69 KB

When you look at this image from Autodesk, you’re like "okay, it makes sense if you have different inputs from Arri Alexa, Red and Canon. Aces will help VFX artists to work in the same color space. But for full cg? What’s the point? It is one of the argument that some of my colleagues used: ‘We don’t care about Aces, we are in linear.’

Well, actually we should care! Here’s the biggest point I have learned so far: ‘linear is gamut-dependent.’ Working in ACEScg (or Rec. 2020) will give better results for your render. Thanks Thomas Mansencal for your explanation. :wink: Rendering in “Linear - BT.709” won’t give you the same results than “Linear - ACEScg”! Interesting! It is apparently due to some basis vectors being more accurate in Rec.2020.

So I did this image to illustrate a full cg workflow:

image
image1483×449 123 KB

That’s what’s wonderful about ACES! You can load any texture you have and ACES will bring it into its own wide gamut world! Making your cg looks better! That’s called Wide Gamut Rendering if I’m correct.

You can actually load textures using the “Utility” modes from Aces:

image

‘Utility - sRGB - Texture’ if your texture comes from Photoshop for example.
‘Utility - Raw’ if your texture is linear.

If I am not mistaken, if you do NOT convert your textures to Acescg, there will be an extra cost in your render. (for the conversion)

That’s why it is recommended for the long term to convert your textures to ACEScg using for example a nuke script. Converting will make your life easier. Surfacing artists will then load their textures in one mode only: ‘ACEScg’, right?

This leads me to another question: how do you guys deal with Substance since it does not have any OCIO support (yet)? Can you paint in Substance in ACEScg? What about Photoshop?

Finally I have done this print screen of Maya Color Management with my own notes to see if I have understood the whole process. We are able to see the same thing in Maya and Nuke which is a good sign I guess.

image
image1446×694 71.4 KB

Now my question is: how do you integrate LMT in this process? If I understood correctly the LMT is your artistic look. But how do you generate it and add it to your config OCIO?

Final question, very theoretical this time is: lots of studios work in sRGB with a linear transfer function when ACEScg if intrinsically linear. Is that better and why? (to be in linear rather than using a transfer function)

Thanks all for your help!

Chris

2 Likes
2

So I have been doing some discoveries since I first posted this
 :wink:

Great article about colour space and terminology:

Great post about ACES and texture generation:

Apparently it is possible to paint in Substance in ACEScg using a 3d lut generated by an exr. I will have to investigate that.

I guess I am still left with my LMT question
 If anyone could shine some light on it, that would be much appreciated!

Thanks!

1 Like
3

Here is the link for Acescg in Substance if anyone is interested:

Many people have asked Allegorithmic about OCIO integration.
So hopefully it should arrive some day


All of this leaves me with another question. :wink:
I have done a cornell box test with some tests of IDT and ODT:

cornell_03_acescg_aces_srgb
cornell_03_acescg_aces_srgb1024×1024 510 KB

cornell_04_acescg_aces_dcip3
cornell_04_acescg_aces_dcip31024×1024 497 KB

I am actually asking myself if the white point will be an issue for us or not.

1- I know that ACES has a white point of D60.
2- We have calibrated our screens to D65 white point. (in DCI-P3)

Is this the reason why the DCI-P3 image looks warmer, compared to the sRGB?
Is it “better” to recalibrate our screens to a D60 whitepoint or to generate an
ACES OCIO config with a D65 white point?

I’ll be interested to know your views. :wink:

Many thanks for your help!

Chris

1 Like
4

Hi Christophe,
thanks a lot for your inputs and investigation.
About your last question I cannot help as we mainly work for tv and web so our pipe (and screens etc) is based on sRGB deliverables, but I will follow with interest to see how it develops.
Super interesting stuff the link about substance and in general the resources you are sharing here, THANKs!

Paolo

5

The reason the DCI-P3 images looks warmer is because you are using the wrong ODT for what you say you calibrate to. If you calibrate to D65 white point (within P3 primaries), then you should use the P3D65 ODT.
The P3-DCI ODT is mainly for digital cinema projectors and assumes that your display calibration white (equal RGB code values) is the greenish DCI white point of x=0.314, y=0.351.

You could recalibrate to D60, but I think it’s better practice to just use the appropriate ODT for your calibration.

You would want to use the P3D65 ODT for the setup you describe. Unfortunately, as far as I know, the OCIO config has not been updated for ACES 1.1 as of this writing. ACES 1.1 officially added an ODT designed for P3D65 calibrations.

1 Like
6

Thanks a lot Scott!
I have managed to find an Aces 1.1 OCIO config here:
https://github.com/ezequielmastrasso/OpenColorIO-Configs

Much appreciated for your help!
It looks like we are on good tracks now!
Chris

7

Hi @ChrisBrejon,

The config you linked is not an official config and it is missing the whole Python generation code, I would be careful using it.

Cheers,

Thomas

8

Thanks for the heads-up Thomas! We will be careful then and will switch
to the official one when available. :wink:

Chris

9

Hey guys, thanks a lot for your help.
I have tried the P3D65 ODt and it looks more correct.
There is no shift of hue like before.

cornell_0170_p3d65
cornell_0170_p3d651124×449 316 KB

I would like to show this render to my supervisors but I would need for a technical
reason to justify the desaturated look of the cornell box.

Is that because the P3D65 has a wider gamut than Rec.709? Meaning the primaries
are further in the diagram and therefore you get less saturated colors?

Thanks for your input!

Chris

10

Yes! But this raises the question of whether you are looking at the image on the proper display system because it should look the same on a P3 D65 calibrated display using the P3D65 ODT than it looks on a sRGB calibrated display using the sRGB ODT.

Another way to put it: You should use an ODT that does match your calibrated device.

Cheers,

Thomas

1 Like
11

Cheers @Thomas_Mansencal !

I got just a call from our display vendor and our screens cover 93,7% of DCI-P3.
This may explain why this isn’t ‘perfect’ I guess. Our screens are definitely calibrated
with a D65 White Point.

Thanks a lot for your help!

12

But are they calibrated to P3 primaries?

13

Yes, I have been given these specifications:
gamut: P3, norme: DCI, White Point: D65
intensity: 100 cd/m2
6500K, gamma 2.2

Thanks!

14

Hi Christophe!
I just became aware of this thread last night

I’d suggest you to stick with the latest official 1.0.3.
The repo you linked to is mine, it was just a test while getting familiar with ctl, aces, and the conf builder itself.

Ps: I deleted the repo last night to avoid any confusion.

Eze

15

Hey @ezequielm, thanks for the warning! I will stop using yours then and will wait for the official ACES 1.1 release
 (Hopefully coming soon!) :wink:

Many thanks guys!

16

How was it given, is it input to the display? I guess I’m trying to understand how your chain is calibrated although at that point and given your display is not a P3 display (over 6% is quite a lot), you will probably need a custom ODT accounting for its maximum representable colours OR use an existing ODT in its capability range, e.g. sRGB.

Cheers,

Thomas

17

Thanks @Thomas_Mansencal!

Our monitors are calibrated with a xrite calibration device and a spectraview software.
Here are the monitor specs:

monitor_specs

You can see that the coverage results are better in the CIE 1976 u’v’. We were wondering if this difference between these results were significant or not?

Otherwise we will just stick to a Rec.709 ODT!

Many many thanks!

Chris

18

Your display device is unable to represent P3 gamut entirely so it precludes its usage as display gamut. You can either use a smaller gamut or build a custom ODT for it.

The CIE 1976 chromaticity diagram has better perceptual uniformity than the CIE 1931 one, so it is normal to see differences in coverage here. That being said depending on a lot of factors (viewing conditions, which colours are displayed, their colourfulness, subtended size) your eyes might be able to discriminate colour differences even when Delta E 2000 is around 1%.

19

Thanks Thomas! That’s great! Much appreciated!

Chris

20

Anyone looking for a way to use ACES in Substance should have a look at these links:

Setup by Brian Leleux.

Thanks!

1 Like