OpenColorIO 2 Configs for ACES

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

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)

OpenColorIO

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.

the .ocio config

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.

2 Likes

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

2 Likes

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. :stuck_out_tongue:
…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 :slight_smile:

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.}
1 Like

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!

Summary of the Studio Config

Displays

  • sRGB
  • Rec.1886 / Rec.709 Video
  • Rec.1886 / Rec.2020 Video
  • Rec.2100-HLG
  • Rec.2100-PQ
  • ST2084-P3-D65
  • P3-D60
  • P3-D65
  • P3-DCI

Linear Colorspaces

  • ACES2065-1
  • ACEScg
  • Linear P3-D65
  • Linear Rec.2020
  • Linear Rec.709

Camera & Grading Colorspaces

ACES

  • ACEScc
  • ACEScct

Blackmagic Design

  • DaVinci Intermediate WideGamut
  • Linear DaVinci WideGamut
  • DaVinci Intermediate Log - Curve

Panasonic

  • Linear V-Gamut
  • V-Log V-Gamut
  • V-Log - Curve

RED

  • Linear REDWideGamutRGB
  • Log3G10 REDWideGamutRGB
  • Log3G10 - Curve

Sony

  • Linear S-Gamut3
  • Linear S-Gamut3.Cine
  • Linear Venice S-Gamut3
  • Linear Venice S-Gamut3.Cine
  • S-Log3 S-Gamut3
  • S-Log3 S-Gamut3.Cine
  • S-Log3 Venice S-Gamut3
  • S-Log3 Venice S-Gamut3.Cine
  • S-Log3 - Curve

ITU

  • Camera Rec.709

Texture Colorspaces

  • Gamma 1.8 Rec.709 - Texture
  • Gamma 2.2 AP1 - Texture
  • Gamma 2.2 Rec.709 - Texture
  • Gamma 2.4 Rec.709 - Texture
  • sRGB - Texture

Utility Colorspaces

  • Un-tone-mapped
  • CIE-XYZ-D65
  • Raw
  • Rec1886 - Curve
  • Rec.709 - Curve
  • sRGB - Curve
  • ST-2084 - Curve

Cheers,

Thomas

4 Likes

Congratulations to everyone involved!!! Incredible work!

1 Like

Fantastic work all! Any particular reason AWG3/4 / LogC3/4 are missing?

1 Like

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

2 Likes

Precision landing!
Thanks for all your great work!

Peter

1 Like

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.

2 Likes