Colour inaccuracies and config files

Tags: #<Tag:0x00007fd5aeabad70> #<Tag:0x00007fd5aeabac30> #<Tag:0x00007fd5aeabaac8> #<Tag:0x00007fd5aeaba910> #<Tag:0x00007fd5aeaba758> #<Tag:0x00007fd5aeaba5f0> #<Tag:0x00007fd5aeaba410> #<Tag:0x00007fd5aeaba2d0> #<Tag:0x00007fd5aeab9fb0>
(Vincent) #1


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!


1 Like
(Thomas Mansencal) #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:



(Vincent) #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?


(Thomas Mansencal) #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.



(Vincent) #5

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


(Thomas Mansencal) #6

It should be available!

(Vincent) #7

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


1 Like
(Karas) #8

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

(Vincent) #9

I downloaded it from there:

Aces 1.1


1 Like
(Thomas Mansencal) #10

Yep that would be it! :slight_smile:

(Karas) #11

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

(Thomas Mansencal) #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:

(Karas) #13

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

(Thomas Mansencal) #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.