After some back and forth, I uploaded two screen captures in the thread of the link shown above. Maybe someone has any idea where this bug could come from. It’s just twisted.
https://drive.google.com/file/d/1p4tXC-0j50olUgYnymPibR129qYBmHbX/view?usp=sharing
Hey Thomas,
Thank you for this - some of the pre-built configs finally seeing light of day (I know I’m late to the party here).
Anyway can you clarify a bit (for us non tech savy morons) the “completely self-contained” part here.
Does this not drop in a long side ACES 1.3 or ACES 1.2 lut files, as I believe most of us are used to?
Are they (luts) not needed at all even, in any application using this config? Which version of ACES is this equivalent to then (if built separately)?
This might all be very obvious to someone but at least I even get confused by the “…ACES-0.2.0” name part of this release against the commonly seen ACES 1.2…3…and or OCIO v1/v2 …and where this fits in in particular.
I suspect you’re actively working on ways to simplify all this magic and one thing will probably replace the other in the future. But I have to admit if someone asked me “what version of XYZ are you using”, I doubt I could answer that confidently.
Any info greatly appreciated - thanks!
Hello, here is my thought on this, if this could help you :
Developing a “product” is complicated, this step includes keeping track of the version released, especially if in our case, the final product is made of other ones. Right here we have three products ! ACES, OCIO and the ocio config in itself.
ACES alone, is a “collections” of requirements, standards, transformations, etc. Each update to one of these parts produces a new version like the well-known versions 1.3, 1.2, … that is published and tell “to have ACES be considered as X version, you have to update, modify this”.
As you may have noticed, the few years have only seen an increment in the “minor” number of the version. This is because, since ACES 1.0, the change didn’t affect enough the “product”(ACES). I can’t really tell you what does make ACES, “ACES” (it’s being discussed right now) but what I know is that ACES 1.0 defined mostly the “look” of the RRT and, this “look” has only received very minor updates/fix. (anyone corrects me here)
But ACES alone is just “a bunch of rules”, that you have to translate to your digital software. This is where OCIO came into play. See it as a language that your software can convert to its own language. Or if I may, see it like a “plugin” extending your software, so all of them implementing OCIO can understand the same language.
OCIO being an individual “product” have different versions. You might have heard about OCIO 2.0 (which was just called OCIO before) and all its subsequent releases like OCIO 2.1, …
Each of these versions includes new features, changes how you speak the “language”, fix bugs, … the usual stuff. OCIO 2.0 included a bunch of new big features (that’s why it got incremented from 1.0 to 2.0), one of them being builtins transforms. These transforms are mostly the transforms defined in the ACES standard for color transformations.
Previously (and still now), to create a color transformation (ex: from colorspace A to colorspace B), you had to specify “the mathematical formula” in the .ocio config to perform the operation you want. This transformations could be supplied as external files like LUTs, this explains why the ACES most spread configs have some luts files alongside them.
But as I mentioned in the previous paragraph, OCIO 2.0 removed the need for these LUTs because they are now part of OCIO as builtins transforms. This means that the ACES OCIO config can now be expressed as simple single .ocio file.
And our last product is the “config” itself which is here for ACES but could be for anything else. You still want to keep track of it, for example, a transform had an incorrect name and you fix it. This is specific to this config only so you will need versioning for the config itself.
This should explains the 0.2.0 you see, that is for this specific “self-contained” config, which then use OCIO 2.0 (because of the builtins transforms). And those builtins transforms + the config refers to the standards defined in the ACES specification for ACES version 1.3 (correct me here).
Which well a lot of versions to digest for the end non-technical user. But it is still a pain for developers when you have to keep track of “which version of each product needs which version of X other product and what is the current version we are using.”
I hope this made things clearer and is also not a too simplified version. Anyway if someone sees something incorrect let me know so I can update it.
Hey @Matthias,
The goal is to have the config self-contained, the Reference and CG configs will be, the Studio one, most likely too.
No LUT needed because the transforms are analytically implemented in OCIO directly, or the required building blocks at least.
We are currently targeting ACES 1.3.
If you look at the current naming of the config as generated by the latest code, (and this has not been released yet), it is looking like that:
cg-config-v0.1.0_aces-v1.3_ocio-v2.2.0dev.ocio
name: cg-config-v0.1.0_aces-v1.3_ocio-v2.2.0dev
description: |
Academy Color Encoding System - CG Config [COLORSPACES v0.1.0] [ACES v1.3] [OCIO v2.2.0dev]
-------------------------------------------------------------------------------------------
This minimalistic "OpenColorIO" config is geared toward computer graphics artists requiring a lean config that does not include camera colorspaces and the less common displays and looks.
Generated with "OpenColorIO-Config-ACES" v0.1.1-15-geb59486 on the 2022/06/05 at 11:20.
reference-config-v0.1.0_aces-v1.3_ocio-v2.2.0dev.ocio
name: reference-config-v0.1.0_aces-v1.3_ocio-v2.2.0dev
description: |
Academy Color Encoding System - Reference Config [COLORSPACES v0.1.0] [ACES v1.3] [OCIO v2.2.0dev]
--------------------------------------------------------------------------------------------------
This "OpenColorIO" config is a strict and quasi-analytical implementation of "aces-dev" and is designed as a reference to validate the implementation of the "ampas/aces-dev" "GitHub" "CTL" transforms in OpenColorIO. It is not a replacement for the previous "ACES" configs nor the "ACES Studio Config".
Generated with "OpenColorIO-Config-ACES" v0.1.1-15-geb59486 on the 2022/06/05 at 11:20.
Cheers,
Thomas
That was very clear and helpful, I’m sure it will help other ‘new comers’ getting their heads around all of this too - Thanks Liam!
Very interesting, I was always under the impression that this little .config file alone would not be enough for programs like Nuke or Maya to “get their colors down right”, sidecar files would always be needed. 
…I need to get this into our pipeline and see what happens.
Also, thanks for confirming the version, exactly what I was looking for.
Thanks again!
@Thomas_Mansencal - One last question.
The “reference” config file which is also included in this release, am I correct in assuming that that file functions the same as the “cg” one …meaning is self-contained too - except more complete with all available LUTs included, or does it require special sauce applied to operate in such fashion?
Thanks again,
Hi @Thomas_Mansencal,
Is the sRGB display pure 2.2 gamma or piecewise?
I believe it is piecewise sRGB, yes? Are there plans to include a pure 2.2 sRGB display or to replace it for the piecewise? I know there’s been a lot of discussion on that here on the forums. Curious to hear your take.
It works the same way indeed it is however geared for devs as it is missing quite a bit of transforms to be useful for production. This should be addressed with the Studio config.
The latter, i.e. Piece-Wise because it conforms to the ACES sRGB Output Transform definition. I think we might have discussed about adding a Gamma 2.2 Display at the OCIO ACES Config level but I don’t remember what was the take on it from the Working Group. Something certain is that at the minimum the Config will honour the ACES transforms and stay close to metal without replacement. It does not mean that we cannot add a new display that said! Feel free to open an issue on the repo.
Cheers,
Thomas
Is there an estimate when the Studio config will be released?
I really like the clarity of these new ones and would like to have one config file for all software I use to link to.
At the moment (Redshift, Aftereffects, Resolve, Mocha) all use their own config (which I don’t know which it is) or I manually link them to the “old” ones. Which seems to slow down things sometimes a bit.
This CG-Version worked great in all of them. But I am especially missing the cct transform for certain compositing tasks.
Thanks!
Peter
Tentatively, a first version for Siggraph!
Land in sight 
Thanks!
Hi, I have a little update to report for the OCIO config that I tried in Blender:
I did a little test today with the “OpenColorIO-Config-ACES 0.2.0” config in Blender 3.3 alpha.
The problem is still the same on my iMac, but not on the M1-MBP.
I tried today another config that is coming with Maya 2023 I believe (the folder is actually called “Maya2022-default”), also in Blender 3.3 alpha.
This config does does not twist the view transform and the result looks just fine on both the iMac and the M1-MBP.
I had a look in both configs but I understand too little to spot the difference in the configs that could introduce the error/bug that I encountered.
Best
Daniel
@TooDee Golly that does look quite skewed in that video!
The difference between the two configs I believe is that the ACES-CG config is using a built-in transform for the sRGB display:
- !<ColorSpace>
name: Display - sRGB
family: Display
equalitygroup: ""
bitdepth: 32f
description: Convert CIE XYZ (D65 white) to sRGB (piecewise EOTF)
isdata: false
categories: [file-io]
encoding: sdr-video
allocation: uniform
from_display_reference: !<BuiltinTransform> {style: DISPLAY - CIE-XYZ-D65_to_sRGB}
while the Maya one is not:
- !<ColorSpace>
name: sRGB
family: Display
description: |
sRGB monitor (piecewise EOTF)
isdata: false
categories: [ file-io ]
encoding: sdr-video
from_display_reference: !<GroupTransform>
children:
- !<MatrixTransform> {matrix: [ 3.240969941905, -1.537383177570, -0.498610760293, 0, -0.969243636281, 1.875967501508, 0.041555057407, 0, 0.055630079697, -0.203976958889, 1.056971514243, 0, 0, 0, 0, 1 ]}
- !<ExponentWithLinearTransform> {gamma: 2.4, offset: 0.055, direction: inverse}
- !<RangeTransform> {min_in_value: 0., min_out_value: 0., max_in_value: 1., max_out_value: 1.}
You could confirm that by swaping in that groupTransform in place of the BuiltinTransform in the ACES-CG config.
While you’re at it, you may want to consider using the pure 2.2 display instead
- !<ColorSpace>
name: Gamma 2.2 / Rec.709
family: Display
description: |
Gamma 2.2 monitor with Rec.709 or sRGB primaries
isdata: false
categories: [ file-io ]
encoding: sdr-video
from_display_reference: !<GroupTransform>
children:
- !<MatrixTransform> {matrix: [ 3.240969941905, -1.537383177570, -0.498610760293, 0, -0.969243636281, 1.875967501508, 0.041555057407, 0, 0.055630079697, -0.203976958889, 1.056971514243, 0, 0, 0, 0, 1 ]}
- !<ExponentTransform> {value: 2.2, direction: inverse}
- !<RangeTransform> {min_in_value: 0., min_out_value: 0., max_in_value: 1., max_out_value: 1.}
Hello,
@carolalynn, @doug_walker, @Michael Dolan, @KevinJW, @zachlewis and all the other contributors are pleased to announce that we have a first version of the Studio Config: Release OpenColorIO-Config-ACES 0.3.0 · AcademySoftwareFoundation/OpenColorIO-Config-ACES · GitHub
Please give it a crack and let us know if you have any issues!
Cheers,
Thomas
Congratulations to everyone involved!!! Incredible work!
Fantastic work all! Any particular reason AWG3/4 / LogC3/4 are missing?
Hi @Shebbe ,
This is a great question and it was asked on Slack: Yes, there is a good reason, we haven’t finished the work with ARRI (@scoopxyz) to finish integrating the ARRI transforms: DRAFT: add ARRI contributions to OCIO-ACES CLFs by scoopxyz · Pull Request #54 · AcademySoftwareFoundation/OpenColorIO-Config-ACES · GitHub and we wanted to have a release for Siggraph!
They will come soon, stay tuned!
Cheers,
Thomas
Precision landing!
Thanks for all your great work!
Peter
The same is true for the currently missing Canon input transforms too, yes?
Correct! Sorry for the delay but yes, the Canon IT’s will be in the next release as well.