ACES 1.3 Now Available

ACES Info
1

ACES Community Members,

Today we are happy to announce the release of ACES 1.3 : it includes new features and enhancements that fulfill the ACES 1.0 vision and sets the stage for ACES 2.0 development. Key new features and enhancements include:

  • A new gamut compression algorithm to deal with the “blue fringe problem” some users experienced with extremely bright saturated objects (e.g. brightly colored LED lights).
  • A minor update to the ACES Metadata File (AMF) to make it more flexible for production workflows.
  • A color space conversion transforms (ACEScsc) for supporting the Sony Venice
  • Minor bug fixes and documentation improvements (including moving the documentation to its own git repo for more development flexibility)

ACES 1.3 is a “minor” system release. This means the update does not change the Reference Rendering Transform (RRT) or modify the existing core transforms beyond addressing reported bugs and/or inconsequential formatting/whitespace changes. It also means the system will continue to be referred to ACES as “ACES version 1” in conversation and documentation.

With this release we are following a previously announced plan to ‘unbundle’ the ACES transforms from documentation and toolsets to further clarify ACES versioning. Documentation and toolset components will be released as they are available and announced separately, avoiding the need to be unnecessarily held up for a new release of ACES transforms.

Finally, this release is ready to be integrated into products. Releases of the ACES reference implementation are primarily targeted to ACES Product Partners and other manufacturers. To enjoy these new benefits, end-users should request that their preferred production and postproduction tools integrate these new features and fixes, as quickly as possible.

ACES 1.3 details:

  • Notes on the gamut compression transform

    The gamut compression transform is the result of the work of the Gamut Mapping Working Group, to create a more robust solution to issues with out of gamut colors and the resulting artifacts (loss of texture, intensification of color fringes). The delivered gamut compression transform performs well with wide gamut, high dynamic range, scene referred content and is robust and invertible.

    The gamut compression replaces the simple and less robust LMT.Academy.BlueLightArtifactFix.ctl. The ACES gamut compression transform has numerous advantages over the BlueLightArtifactFix LMT. In particular, the gamut compression transform avoids changing colors that are well inside the destination gamut. Only colors that are out of gamut or very near the gamut boundary are affected.

    As of this release, the Gamut Compression Implementation Working Group is working to provide recommendations and guidance to vendors to implement this transform directly their in products.

    For those looking for more detail, the Gamut Mapping Working Group delivered a report to accompany the technical deliverable.

  • Notes on the updated AMF specification

    ACES 1.2 included the release of the Academy Metadata Format (AMF) specification. Since that time a working group has been formed to provide guidance to vendors on the implementation of AMF into products and end-user guidance on production usage. In the process of testing and working with the initial specification, the group suggested extensions to the AMF specification to make it more useful in meeting specific use cases. ACES 1.3 includes an updated AMF specification and associated schema that allow all transforms to now be referenced by UUID, relative file path, or TransformID.

We would like to thank the members of the ACES community who have actively participated in the development of ACES 1.3 through ACESCentral.com and within the various Virtual Working Groups. We believe, through their participation in the development process, the result is a stronger ACES release that better addresses the needs of the motion picture, television and broader content creation communities.

Please check ACESCentral.com and the ACES Twitter and Facebook feeds for the announcement of an upcoming webinar where we’ll be discussing this release in more detail and you can ask questions about how this impacts you (in a positive way, we hope) as an ACES end-user or implementer.

With much appreciation,
ACES Leadership

17 Likes
2

Great work! From a colourist perspective; Anything that can be done to make the gamut mapping adjustable would be great in future releases.

There are many methods available, as found by the research group and the method used should be a subjective/creative choice IMHO. Sometimes I like using Tanh, sometimes another, so ACES should give that creative freedom to its users as gamut mapping can have an impact on the look desired.

Thank you

1 Like
3

The consensus of the group was that the “ACES badged” version should be fixed. This makes tracking simpler, as it needs to be applied in the same way on set, in dailies, in VFX and in DI.

If you want to use it in grading as a creative tool, there will be a parameterised version available (and obviously the DCTLs of the earlier iterations still exist). But that will not be the ACES gamut compressor. It’s just another tool in the colourist’s arsenal, just as none of the other grading operators you use are “ACES tools”.

4 Likes
4

Using 3rd party / non ACES tools for gamut mapping is an odd way to preserve artistic intent if combining with a fixed gamut mapping.

If you’re gamut mapping before another gamut mapping function you’re not going to get the same results as different gamut mapping methods as a whole.

Please let me know how a combined approach of an independent gamut mapping function combined with a fixed one would yield the same results as using only customisable gamut mapping. My go-to example would be using Tanh gamut mapping vs tanh+ACES power gamma, as I don’t think the results would be the same. If we (the creatives) prefer the effect of Tanh then how do we work with/together with the power gamma function to get the same results?

Thanks

1 Like
5

Hi @Toby_Tomkins,

Closest fit to TanH given the following power-based function, i.e. that of the gamut mapping operator:

def power_compression_function(x, a=0.8, b=1 - 0.8, p=2.0):
    x = colour.utilities.as_float_array(x)

    return np.where(x > a, a + (((x - a) / b) / np.power(1 + np.power((x - a) / b, p), 1.0/p)) * b, x)

has those input values: [ 0.65953861 0.34051662 4.6993435 ]

1 Like
6

Here is my strong vote for not allowing too many variations. ACES is ment to be standard and I am so happy that finally there is a standard.

I heard that joke on that topic: Standards are great! Everyone should have one! :slight_smile:

So I really appreciate such decisions that ACES uses only one unified method for such problems.

BTW: Does anyone know when this gets implemented in a new OCIO configuration? As enduser, that’s the only way I could use it at the moment.

Thanks!

Peter

2 Likes
7

I don’t think there will be an old OCIO generated config at this point. The operator can be represented by a LUT but it is not great. We are actively working on a new generator and it is most likely where it will happen with an analytical implementation for OCIO 2. Might I ask which software are you using? There are implementations for mostly everything in the repo: GitHub - ampas/aces-vwg-gamut-mapping-2020: ACES - Virtual Working Group - Gamut Mapping - 2020

8

I am using

  • Aftereffects (with the fnordware OCIO Plugin (I guess thats OCIO 2.0 now. New Version 2 released 9 April 2021)

  • MOCHA via OCIO

  • CINEMA4D with Redshift (also OCIO)

  • Resolve (which hopefully will have 1.3 integrated soon)

For Resolve a workaround until then could be the dctl. Thanks for that link. :slight_smile:

But I wonder now if I have a principle misunderstanding:
Isn’t it so, that this Gammut Compression should be integrated in the RRT or ODT in Version 1.3 now?
I thought we now can forget the so called “blulight” problem.

Thanks!

Peter

9

Interesting. Do you happen to know if anything noteworthy changed in the plugin? I coudn’t find any release/dev notes.

If I’m not mistaken it’s still an LMT that we use should we want to because it’s not always needed in a pipeline just like the legacy blue light fix. Not entirely sure though.

10

I also didn’t find official information on the new features. Considering that this is such an unique and important Plugin for all Aftereffects users and de facto the only way to have a good ACES workflow there, I really wonder why this is handled like a secret. No informations anywhere. You just have to regularly check the old blog entry :slight_smile:

Just from checking it out in Aftereffects is see:

  • Larger fields for the often long names of the transforms
  • Support of more LUT formats in Export. Also CLF :+1:t3:
  • And just guessing that the GPU checkbox might be now very useful. I am not sure, but I thought it clipped values over 1 before. But I don’t see that now. It will probably show it’s strenght where there are no more LUTs used in the new V2 configurations. Then processing power is probably a important thing. But thats just guessing.

The fact that there is CLF support and that it’s called Version 2, lets me assume that it’s the implementation of OCIO V2.

I just don’t know where we could get a configuration that uses that features. The old ACES_1.2 probably don’t uses that new features. I’ve read that old configurations are still supported. Seems to be the case. But of course then there is no advantage. But i have a feeling that we’re ready to go as soon such new OCIO V2 configuration is available.

Peter

11

There is a pre-release OCIO 2.0 ACES configuration here.

12

It is a technical release though, not really meant to be used by artists!

13

Thanks Nick! Works perfect in the Aftereffects plugin :+1:t3:

So it’s not meant to be used in production right now? Just because it’s kind of beta or is there still something wrong or missing?

We can still work with the ACES_1.2 configuration. So if that’s recommended for a good reason I will continue to do that.

Thanks again!

Peter

14

From the GitHub page :

This config is a strict and quasi-analytical implementation of aces-dev and is designed as a reference for software developers. It is not a replacement for the previous ACES configs nor the future ACES Studio Config.

It is a technical reference config for developers NOT MEANT TO BE USED IN PRODUCTION.

Chris

15

Ah! Thanks!
But still nice to have a little look into the future :grin:

Peter

16

Until the gamut compression operation is added to a point update of OCIO 2, there is no real way to apply it in applications such as After Effects which are reliant on OCIO for ACES. That is why the Gamut Compression Implementation Virtual Working Group is hoping to focus on OCIO as an early implementation as soon as possible.

17

Took a peep in to that dev reference config.
Really nice to see shortened naming conventions and addition of categories :slight_smile:
Maybe too soon to ask but why are the Display transforms not in a “folder”?
image
Or does it just look like this because OCIO is just in plugin form here instead of true integration into After Effects software.

Look forward to the official release!

18

I can’t completely see your setup on the cropped screen grab there, but it looks like you have the OpenColoIO effect set in “Convert” mode, rather than “Display”.

In “Convert” mode OCIO will perform a colorimetric conversion to the display space as that config defaults to “Un-tone-mapped”. Switching to “Display” mode will include ACES RRT+ODT in the transform, which is what you would normally want. It will also hide all the non display colour spaces in the list, and add an extra drop-down called “View” where you select options like P3 limited or D60 sim. IMHO the way that works in After Effects is quite elegant.

19

I see! That is indeed a lot more elegant! I never used the display option because the old config would only have ACES as display and a flat list of displays in view. The new layout makes a lot more sense :slight_smile:
Thanks for pointing that out. Does this mean that we should use Display instead of Convert when it releases because the latter is only converting to a Display ODT without RRT?

20

@shebbe :

Hey @shebbe,

Thanks yeah this has been noted by the Working Group a few weeks ago! I made a mental note about “fixing” that but we should probably create a specific issue on Github.

Cheers,

Thomas

Edit: Displays are not categorised/sorted properly in Reference Config. · Issue #18 · AcademySoftwareFoundation/OpenColorIO-Config-ACES · GitHub

1 Like