Re: ACES 1.0 released

Steve Agland <sag...@...>

Hi HP,

I'm looking into rolling an internal project's OCIO configuration forward to use as much of your ACES 1.0 config as possible. I've run into a couple of issues and wanted to run them by you.

Firstly, the allocation for most of the linear spaces (including ACEScg, and our current working space "Linear - P3-D60") is currently defined as:

    allocation: uniform
    allocationvars: [0, 1]

This causes clipping of values > 1 when converting from the linear space into an Output Transform. It seems to only be a problem in certain OCIO implementations (I believe those using the GPU code path). In our case is was first noticed in RV. Changing these allocation settings to something like this seems to resolve the problem:

    allocation: lg2
    allocationvars: [-8.5, 5, .003]

I'm not sure if those values are optimal. Since it's only for interactive display it's probably fine. Using the lg2 allocation method seems to be the recommended approach for linear spaces.

The second issue I've run into is with experimenting with the ACEScc space for use in grading/DI.

We're using Nucoda. The current test workflow is I'm delivering ACEScc-encoded proxies of the final comps to DI, and supplying them with a couple of baked LUTs for display (ACEScc -> P3-DCI) and for a hypothetical future archive master (ACEScc -> ACES2065-1). This seems to work well for interactive grading and display with the few production images we've tested but I'm concerned about preserving as much information as possible in the final ACES master.

The ACEScc_to_ACES.spi1d LUT bundled with the config has a range of 0.0 - 1.0. I think this could be wider. (Also, should this file perhaps should be called ACEScc_to_ACESccLin.sp1 since it doesn't include the matrix transformation?).

The S-2014-003 document (Annex A, pp. 10) suggests that negative ACEScc values are to be expected - either from very dark linear values (< 7.25 stops below 18% middle grey), or from colors outside the AP1 gamut. At the other end, a value of 1.0 in ACEScc maps to ~223 in ACESccLin, but the spec suggests that the ACEScc -> ACESccLin conversion formula doesn't clip until you reach a linear value of 65504 (pp. 9). This seems to correspond to a value of about 1.468 in ACEScc. At the low end the curve seems to hit linear 0 at about -0.358.

It seems like these values ( -0.358, 1.468 ) might be a reasonable range to use in the ACEScc_to_ACESccLin LUT - perhaps with more samples - in order to preserve more information when transforming in and out of ACEScc.

To test this I generated my own alternative ACEScc_to_ACES.spi1d with that range and tried a back-and-forth conversion: ACES -> ACEScc -> ACES. It seems to better preserve very dark (esp. black) and very very bright values in the admittedly contrived syntheticChart.01.exr ACES test image. In practice maybe this isn't going to matter much but it seems like an opportunity for a little more accuracy for no extra cost.

That's all a long way of saying "can we change a few of these numbers?" :)  Let me know what you think.



On 14 January 2015 at 05:53, Haarm-Pieter Duiker <li...@...> wrote:

The ACES 1.0 Developer Release is officially available! Full product information can be found on the revamped website, To give you a preview, the ACES 1.0 release includes the following components:
  • Core ACES color transformation implemented in the Color Transformation Language (CTL)
  • Documentation on the expected use of these transforms
  • Technical specifications for other ACES core components
  • Documentation for implementers and end users
  • Test images in a variety of color encodings and formats, demonstrating the results of applying core ACES transformations
  • An OpenColorIO (OCIO) configuration package for core ACES transforms
The components of the ACES release can be found here
    Thanks for your feedback on the needs of the ACES OCIO config in particular and the system in general.

    Please take a look at the source code, documentation, configs and let us know what you think. Send in feedback on this list, the ACES Google Group or the direct email ac...@... address.

    Thanks again for all the feedback. Please keep it coming.

    You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
    For more options, visit

    Join to automatically receive all group messages.