ACES 1.1 Discussion - Tell us what you think!

Tags: #<Tag:0x00007f0dd5dba648>

We’ve just released a minor update to ACES. Details are here: ACES 1.1 now available

This is the place to discuss that update. Tell us what you think of the new parametric Transforms or any of the changes.

The ACES Team

Hi,
are you already working on an updated OCIO config?
Is there any ETA on this?

Best,
Tobias

1 Like

Hi Tobias,

Unless somebody else steps up and implement the changes required, it is not going to happen before HPD or I get some free cycles to do so and given we are both extremely super busy, I would recon it is not before a few weeks.

Cheers,

Thomas

Hi Thomas,
thank you for the heads up.
Best,
Tobias

1 Like

Thanks for the heads upon OCIO config for ACES 1.1. Really excited about ACES 1.1 update.

1 Like

Resolve 15 does not work in ACES 1.1 yet, hope in a soon update!

Hello guys,

first of all, happy new year and best wished for 2019 !

I had a couple of questions concerning ACES 1.1 if that’s okay with you. :wink:
1- I was wondering if there was a release date for it ? Has it been compiled by anyone ?
2- Any chance it could include an IDT for the canon EOS 5D Mark III ? There’s an interesting paper about some tests for it.

Thanks for your help!

Chris

ACES 1.1 OCIO Config

Hi,

There is an official WIP ACES 1.1 OCIO Config available on our fork: https://github.com/colour-science/OpenColorIO-Configs/tree/feature/aces-1.1-config/aces_1.1

It needs to be tested thoroughly but initial tests are positive. There are some ongoing discussions about better shapers and potential definition of both to_reference/from_reference for some difficult colourspaces. There are also discussions about cleaning the repository from old configs and move the ACES part somewhere else. More to come in that respect.

Please not that the above fork and especially its feature branch are subject to history rewrite so that the Build “ACES 1.1” config. commit stays on top to avoid disk-space explosion.

Please let us know if you have any issues or questions.

Cheers,

Thomas

3 Likes

Thanks ! That’s awesome ! We’ll give it a try !
Chris

Hi,

The ACES 1.1 config received some updates recently, notably:

  • A cleaner implementation for the Blue Light Artifact Fix LMT.
  • A direction reversal of the following LUTs to improve round-trips precision as per @KevinJW suggestions:
    • rec709_to_linear.spi1d is now linear_to_rec709.spi1d
    • rec1886_to_linear.spi1d is now linear_to_rec1886.spi1d
    • rec2020_to_linear.spi1d is now linear_to_rec2020.spi1d
    • sRGB_to_linear.spi1d is now linear_to_sRGB.spi1d

Cheers,

Thomas

3 Likes

Hi,

I have been looking at reducing the error between CTL and OCIO by testing various covered ranges for the Log2 48 nits Shaper in the config generator and here are some images and numbers.

On the left is the CTL render reference and next images are OCIO renders the Log2 48 nits Shaper domain varying. The second row is the difference between the CTL and OCIO multiplied by 10.

Over-Exposure
Imgur

Imgur

Imgur

Base
Imgur

Imgur

Imgur

image

The takeaway is that increasing the covered range increases the error of well-exposed image areas but it also reduces significantly the error of saturated and over-exposed areas. Ideally, we should test with more sample images to avoid bias that said it is quite a bit of work. In any case, I would probably be inclined to use [-6.5, +10] instead of the current [-6.5, +6.5] for the Log2 48 nits Shaper.

I might look at how an ACEScc shaper would perform too.

Cheers,

Thomas

2 Likes

Hi,

I pushed an updated config that uses [-7.25, 10.27] thus matching ACEScc. ACEScc does not have the linear toe of ACEScct but it is already a significant improvement and it comes at a cheap price in term of implementation. I might do ACEScct in the future, but days are short, so it is marked as a stretch goal for now.

My gut feeling is that this change as is will solve the current main pain points anyway.

Cheers,

Thomas

To match ACEScc, rather than giving those numbers to a ton of decimal places, you could calculate them in the code, using the constants from ACEScc:

>>> -9.72 - log2(0.18)
-7.2460688116675884
>>> 17.52 - 9.72 - log2(0.18)
10.273931188332412

Sure, that said we have a few places where we have 15+ decimals and the statements would actually be longer than the decimals form.

Hi,

I have just pushed a minor OCIO Config update increasing the cube size to 65^3 instead of the default 64^3.

Cheers,

Thomas