Colour inaccuracies and config files

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

Hi,

Here is some brief background to start with and before asking for your help…

-I am working on dual screen setup: one SDR srgb and one HDR eizo cg (I am using a 4k decklink card for video output).
-CGI animated project to deliver in Dolby vision HDR format.
-Pipeline: Photoshop&Substance (srgb 8&16bits textures saved as tiff) ----> to maya&arnold (acescg RRT - “utility srgb textures” IDT) -----> to Nuke (import rendered 32b exr) -------> to Resolve (import exr 16bit float acescg from nuke) -------> to a post house that will do the final Dolby grade.

I only recently learnt about the ACES wide colour gamut. We would like to use it for the project that we already started to work on in our studio.
These past days (…weeks) I read a lot about the colourspaces as I didn’t have any technical background nore expertise in this area… I still don’t… but I now understand the different colour gamuts and gamma profiles.
The aces idea is a great concept… Although I find that if one is not able to create his own OCIO config file (with ctl coding), a correct implementation in a full CG project (with bright and saturated colours) is pretty frustrating.
Without making your own config you will have to use the default configs files (OCIO or spi), which have their limitations:

A) sRGB textures get darker and colours loose saturation. (moreover for bright saturated ones). Although it is for the benefits of a more plausible and nicer lighting at rendering it still shifts colours from srgb designs.

B) Shading overexposed get weird artifacts (blotchy colours) on some objects.

Both issues have been mentioned a few times in different posts on this forum. I read through those a fair amount of times. Understanding little by little what was discussed… But still there doesn’t seems to be a convenient way to correct those colour flaws without making your own ctl config file. Apologies if my questions seems redundant and if I missed posts giving solutions.

The spi-anim config file does correct a lot of those issues. Shading is reacting fine when overexposed and colour fidelity is better. That config is 8 years old… why the 1.03 or 1.1 more recent config files don’t include those adjustments for the acescg RRT ? The flaw with this spi config is that it doesn’t have many HDR ODT to play with. Alex Fry, very kindly, gave one ODT (Rec 2020 ST2084 1000 nits) that doesn’t seem to work for me. And without this ODT we can’t use the whole spi-anim.
That given ODT seems to behave more correctly once the HDR display set to “PQ BT2100” has its colour gamut shifted to rec709 instead of rec2020… which doesn’t make sense… I also have the P3 ODT provided by Alex. And a sRGB one developped by Ezequiel Mastrasso. Both of those works well but won’t cut it for a HDR grading.

Which leaves me with the default OCIO config file (tested 1.0.3 and 1.1))(the syncolor have the same colours limitation/flaws). And then to amend the colour shift I am applying on my renders coming from maya a 1.45 gain on the diffuse albedo in nuke. Trick that works fairly well to get back a bit of my srgb colour look. But the colour shift in yellows is sill there. Same as the shading issues on overexposed objects…

I know it is difficult from a forum post to get the whole picture of one’s project and setup trying to use ACES. Reason why I didn’t do a post before here these past 3 weeks. Also because I didn’t have any knowledge in wide colour gamut and HDR… But now I am reaching a plateau in my research. It would be great if people who got in this particular situation could advice me. How did you solve those A & B issues?

Also I would love to access the OCIO slack… In case there is more material for me to explore. (OCIO 2.0 is discussed about on the slack?) The given email to join is not up to date anymore… Anyone could help there?

Thanks for reading all this… Apologies for the numerous technical inaccuracies and grammatical mistakes. I am looking forward any feedback!

Cheers,
Vincent

1 Like
2

Hi Vincent,

Yes, this is indeed expected and should not be seen as a defect per see. Some people find that the ACES sRGB Output Transform tends to make things a bit too dark (I tend to be one of them), some don’t mind it at all and actually like it, this is mostly subjective. That said it has been recognised that it could adopt a rendering that is a bit more neutral. Keep in mind that it was designed for Theatrical Exhibition, things are much dimmer in the Theatre compared to the average artist desk.

So I have been looking at that a bit and I think we can increase the shaper dynamic range to fix the issue:

image
image2696×1690 441 KB

Cheers,

Thomas

3

Thanks for your feedback Thomas.

A) I can appreciate that the context of a theatrical projection is important here. And that it can justify that darker look. What about the desaturation of bright&saturated colours though? (more obvious towards the yellow range).

I was wondering if there was a solution to accurately rebalance the colours in post in (Nuke or Resolve). I can play with the gain and add some saturation manually. All this in the diffuse albedo; to stay clear of the lighting and shading rendered layers…
-Is it safe to do so?
-Is there anything like a colourspace matrix to properly convert srgb colours to AP1 colours, without shift and lost?

B) That sounds and looks good! I might just miss some technical background here. How can I increase the shaper of the dynamic range? Without any ctl knowledge am I able to do that?

Cheers,
Vincent

4

Not really because what happens if you decide to change your View Transform for something else, say ARRI K1S1. You would have probably have to tweak again all your textures. I would do that when you grade your image basically.

You could compute a matrix to compensate for the ACES Output Transform effect on colours but I would probably not recommend that as per the above.

I will release a new update to the OCIO config this weekend that will use a larger shaper and fix the issue! Hang on.

Cheers,

Thomas

5

Thanks a lot for your support and work on this. It’s very much appreciated here.
I am looking forward this update.

Cheers,
Vincent

6

It should be available!

2 Likes
7

Thank you Thomas, it’s working and correcting the bad behavior of the shading.

Cheers,
Vincent

1 Like
8

Where can i download the new updated OCIO config file? OpenColorIO-Configs repository?

9

I downloaded it from there:


Aces 1.1

Cheers
Vincent

1 Like
10

Yep that would be it! :slight_smile:

11

Great!! Btw the official OpenColorIO-Configs repository is no longer update?

12

It will get there eventually or under the Academy umbrella, not sure yet. Michael Parsons and I are the blessed maintainers though for now :slight_smile:

13

Thanks Thomas!!
SO we just stick to OpenColorIO-Configs repository

14

It will likely move soon though!

I’m not exactly sure when or how and I could be proven wrong but I would say that the current trend is to have OCIO and the OCIO Configs minus ACES ones starting from 1.0.0 moved over ASWF and the AMPAS would take under its wing the 1.0.0 + configs into a new repo. The two new ASWF and AMPAS repo would be BFG cleaned so that to reduce the size of the repo. My working clone is currently 7.5go!

Don’t quote me on that plan as it might not happen like that but it is something we will be talking about with the interested parties.

15

Hi Thomas,

I have a question about your latest 1.1 config.
The ODT “P3 D60 ST2084 1000nits (ACES)” has been lost between the 1.03 and 1.1 config. Could it be added back somehow, in the 1.1?
It is a pretty useful one to have as it matches the Dolby vision standard. The closest one present in 1.1 is: “P3 D65 ST2084 108nits (ACES)”…
Let me know if that would be possible to do,

Many thanks,
Vincent

16

Hello guys, pretty interesting read on this forum. I’ll have to test the new 1.1 config.

I f you think the sRGB - ACES ODT is too dark, have you tried the Rec.709 - ACES ODT ? It is less contrast but within the same gamut. Could be handy ?

Maybe this read can help a bit with your topic : https://thevfxdesk.com/2019/04/14/color-space-for-cg-artist-part-ii-acescg/

Thanks,
Chris

17

Hi Chris,

I don’t find the ODT too dark. All the ODT profiles seem accurate.

I got to the conclusion that the “darkness” of sRGB textures (and desaturation) is from two different factors:

  1. the conversion of the textures sRGB to AP1 = that’s a big colour primaries shift.
  2. the ACEScg 3d workflow : limiting the “colour range” of the diffuse in order to leave space for highlight roll-off and shading info.

This is all to serve the more colour accurate ACES world. Ideal with live action or realistic renders… But that can be somehow a bit lacking when needing to preserve a sRGB look for a very graphic production. Lacking only if you are not able to code your own OCIO config file! as I believe that that “sRGB colour” look could be coded in your configs… Which I can’t do.

That is my humble understanding… And I know that this is all far from a semantically and technically accurate way to describe it…

Now, I am looking for an ODT to work on a HDR screen for a Dolby Vision delivery.
I have a good eizo screen to do so. But ideally I would need the 1000nits P3 st2084 ODT mentioned earlier to work in an “HDR environment” and visualize the right dynamic range (with the PQ curve). That ODT was previously part of the 1.0.3 package. Unfortunately the 103nits version is not good enough to do so in that setup.

Cheers,
Vincent

18

Interesting point. It is not in the OCIO config because it is not in the aces-dev repo for 1.1. Only Rec. 2020 HDR Output Transforms are included.

It would be fairly simple to make P3 versions (D60 or D65, as required) of the Rec. 2020 Output Transforms by duplicating and editing the CTL. The outputTransform function makes that simple.

You would then have to build the OCIO config yourself.

@sdyer, do you think it would be a good idea to add HDR P3 Output Transforms to the repo for Netflix compatibility?

19

If I remember correctly, when we asked what people needed as the “base” transforms, we were primarily told that while Dolby Cinema (i.e. 108 nits) required P3D65 color encoding, other HDR outputs still preferred Rec2020 as the color encoding.

It’s important to note that aside from comments identifying the transforms, the only difference between the two files is the “encoding primaries” and “limiting primaries” variables. For convenience I’ve pushed the additional files to the aces-dev ‘dev’ branch.

It’d be a good idea for someone to add them to the OCIO config if this is a commonly needed output color encoding.

Note:
Just because a transform is not listed as a separate transform in the 1.1 list of transforms does not mean that it is not “supported”. There seems to be a prevailing belief that if a transform isn’t present in aces-dev that it isn’t “blessed” for production use. In practice what ends up happening is that because a transform is not included as a “common output” in our repo, it leads to it not getting rolled into LUT based implementations like the current OCIO config or to be built-in natively to applications that use the aces-dev repo to decide which outputs are most important to include.

There’s a tradeoff between providing every possible combination of output transforms that we think anyone might ever possibly need and providing a simple framework to create additional versions of existing transforms that make the minor changes necessary for a unique setup (or at least one we didn’t anticipate). Too many transforms and it’s potentially overwhelming and confusing. Too few and implementations that put in the bare minimum are lacking compatibility.

This should be helped in ACES 2.0, when all Output Transforms will adopt the parametric model as their base and vendors will be encouraged to implement the base algorithm and provide the variables such as color primary encoding to the user, instead of a limited list of presets.

For now, the ‘dev’ branch has the code.

20

Hi,

Which is fine as it avoids unnecessary confusion for both users and developers, having the OCIO config tracking the aces-dev master branch is predictable and less error-prone. That said, whenever the AMPAS
takes ownership of the ACES OCIO config, it will be easier to have many branches in the OCIO config repo tracking many branches from the aces-dev repo.

Cheers,

Thomas