ACEScc vs ACEScct

acescc
colorcorrection
acescct
Tags: #<Tag:0x00007f3c5d2bcc08> #<Tag:0x00007f3c5d2bcac8> #<Tag:0x00007f3c5d2bc988>

(Scott Dyer) #6

ACES 2065-1 (linear, AP0) remains the core of ACES and is the only interchange and archival format (written to OpenEXRs conforming to SMPTE 2065-4).

The other color spaces - ACEScc, ACESproxy, ACEScct, ACEScg - are ephemeral working spaces that exist to meet very specific needs of real-world implementations. They are not intended to be written to files, stored, archived, or interchanged (possible exception: ACEScg might be written to files inside a VFX facility, but should be converted to ACES before sending out to another facility)

The color space names give a hint to their intended application. For example, ACEScg is a linear encoding used for CGI render and compositing. It uses a smaller set of primaries than ACES2065-1, specifically AP1, because tools used to synthetically render imagery (CGI) have long used certain optimizations that are different than in typical color management scenarios and sometimes do not work well with very wide-gamut primaries such as those defined in ACES2065-1.

Additionally, ACEScc is a logarithmic encoding intended for use in color correction systems whose controls expect a log relationship to relative scene exposures for proper operation. ACEScc also uses color primaries closer to achievable display primaries for more natural control with typical color grading. Because most color correction tools were built to operate on “log-like” data, the knobs and controls would feel “way off” if ACES were not converted to ACEScc, which is a space more suitable for color correction.

The additional color spaces are suggested spaces designed to allow one to remain within the ACES framework when using real-world production tools and workflows. Of course, one could choose to use alternate working spaces on-set, in VFX, and/or in the color corrector, but those choices would need to be managed carefully and poor choices will lead to poor results. ACEScc, ACEScct, ACESproxy, and ACEScg are ACES’ suggestions for color spaces that will hopefully support all production tools and workflows. Someone who knows what they’re doing can opt to use other color spaces within their workflow if it makes more sense - just don’t blame it on ACES if something breaks :smile:

To reiterate, linear ACES (i.e. encoded according to SMPTE 2065-1) is the only interchange and archival format (written to OpenEXRs conforming to SMPTE 2065-4).


(Charles Boileau) #7

I’m a bit confused about AP0 and AP1.

I thought AP0 was the “big colorspace” that is used by all others when interchanging images in linear. IE: when I work in ACEScc in Resolve and render to EXRs I render to AP0.

And… I though that AP1 was the primaries that we use in ACEScc, cct, cg. (The ephemeral colorspace like Scott so well describes).

Thanks!!


(Charles Boileau) #8

Scratch that… after reading I figures that AP0s “full name” is ACES2065-1… why call it 0 then?! Why not AP1 and AP2??


(Nick Shaw) #9

AP0 and ACES 2065-1 are not different names for the same thing.

AP stands for ACES Primaries (I believe – or is it “Academy Primaries”?) so ACES 2065-1 means scene linear image data with primaries defined by AP0 (zero because they were originally the only primaries specified for ACES). ACEScg is scene linear with AP1 primaries (the smaller “working” colour space). ACEScc, ACESproxy and ACEScct all have AP1 primaries, and their own specified logarithmic transfer functions.


(Charles Boileau) #10

Thanks for the feedback!!

I have posted in the main workflow forum. It would be great to have your feedback on these issues Nick.

Cheers!


(Charles Boileau) #11

I can’t seem to be able to post anymore. I’m getting a error message: your are not permitted to view the requested resources… Any ideas guys?

This is when trying to make a new post…

Sorry to post this here…

And, I can’t seem to be able to send any messages


(Charles Boileau) #12

I can post again. Everything is back to normal.


(Walter Arrighetti) #13

Just to make it clear:

  • AP0 and AP1 are not color-spaces, just sets of RGB primaries that can be used in a full color-space definition. AP0 includes all the chromaticities of the CIE observer. AP1 does not, but is still considered “wide-gamut”.
  • ACES2065-1 is the only ACES color-space to use AP0 primaries
  • All the other four ACES color-spaces use AP1 primaries
  • As Scott said above, ACES2065-1 is the only color space meant for archival and interoperabilty of images. All other exist due to present technical constrains (there’s a specific topic elsewhere in ACEScentral.com) but should be considered either as working (ACEScc, ACEScct) or as transport (ACESproxy) color spaces only.

Said that, if you want to dig more into the matter, the SMPTE and Academy documents describing them are ST2065-1 and TB-2014-004 for ACES2065-1, S-2014-004 for ACEScg, S-2013-001 for ACESproxy, S-2014-003 for ACEScc and S-2016-001 for ACEScct.


(Jim Houston) #14

Hi Charles,

AP0 and AP1 is an accident of naming (AP1=Alternate Primary #1). Multiple primaries were tried…
by the time we got to naming them Academy Primary #1 and Academy Primary #0 we had spent too much
time talking AP0 (untouched original) versus AP1.


(Jim Houston) #15

Nick,

Your pseudo-code is misinterpreting ACEScc to ACESproxy. ACES proxy is a truncated part of the ACEScc curve. So ACEScc has greater range but the curves are only the same ‘in the middle’.
Because ACESproxy was intended for camera playback to displays which are mostly setup for video (legal)
ACESproxy truncates to CV=64 at the bottom and 940 at the top whereas ACEScc can continue on…
Had to be done this way to go from the half-float range to an integer range. So the implication of full_to_legal(clamp(ACEScc)) isn’t the right way to look at at.


(Scott Dyer) #16

I agree that they are the same curve ‘in the middle’. In fact, they must be in order to have ASC CDL compatibility from on-set carry over into color correction.

Nick’s pseudo-code looks correct to me, and is a different way of illustrating the relationship between the two spaces. If one converts ACESproxy10 to floating point by dividing CVs by 1023, followed by a legal to full, it is equivalent to ACEScc in range 0-1. I have performed this conversion to ACESproxy10 and overlaid it (green) on top of ACEScc (red) in the plot below. I think that seeing the comparison on a plot helps to clarify the relationship that Nick is pointing out: CVs 64 and 940 from ACESproxy10 align with 0 and 1 in ACEScc, respectively.

This is not entirely correct, as ACESproxy10 does not extend above 940 to 1023. It is only defined in legal range, 64-940.

Appendix A of “Academy S-2013-001: ACESproxy - An Integer Log Encoding of ACES Image Data” states:


Getting Started with ACES
(Jim Houston) #17

OK, I am reacting to the comment that ACEScc and ACESproxy are the same… well, in the middle, yes that was by design that 1.0 in both came out where it is. If I make your assumptions, OK I guess it isn’t incorrect to show the pseudo code that way. As far as the camera range part goes, yes, just a mistype on my part.


(Nick Shaw) #18

I would defend my argument that ACEScc is the same curve in the range in which it is defined, and clamped outside that range – hence the clamp function in my pseudo code. It was intended to illustrate what ACESproxy is, and why it is that way. As @sdyer says, ASC CDL would not transfer from set to post if it wasn’t.

Saying that it’s only the same “in the middle” could be taken to suggest that it only matches for a small part of the range. In fact they match from more than 7 stops below grey, to more than 10 stops above it. An on set waveform showing ACESproxy (0-100% range) will match a waveform in post showing ACEScc in the float 0-1 range.

I felt my pseudo code illustrated the relationship between the curves more clearly than can be seen by looking at the actual functions.

(log2(in) + 9.72) / 17.52 # ACEScc

and

round( (log2(in) + 2.5) * StepsPerStop + MidCVoffset) # ACESproxy

are scaled and offset versions of the same function. But the less mathematically inclined are not likely to immediately spot that!


(dado) #19

Coming back to ACEScc to ACEScct subject.
From the colourist’s perspective ‘CCT’ is fantastic improvement. We really need blacks to be proper black and not always rounded of - which was the behaviour of ‘CC’. I am certain that with time CCT will entirely replace CC.
For me at this moment it is had to switch mid project - but my next job will certainly be CCT


(Willian Aleman) #20

As Dado Valentic has said, with all the benefit ACEScct offers in post, it would be interesting to know how to resolve the incompatibility that has been stated in this thread, between ACESproxy on-set and ACEScct in post?


(Nick Shaw) #21

There is only a problem if you use ACESproxy output of a camera. Since systems like LiveGrade and Prelight can apply an IDT themselves, you can take the feed from the camera in its native log format, and apply your live grade in ACEScct.


(Willian Aleman) #22

Nick Shaw, thanks for your prompt response and the workaround. Indeed, it’s a very helpful response to my question.


(Jordanacomba) #23

Sorry for being late here…

I am tasked with pulling VFX plates for a RED show and I want to make sure we export in a format that can be sent by the VFX vendors to online in the same format we are delivering them.

I need to select a software, Resolve or RED Cine X, to pull the preferred format of 4K 16bit image sequences. Then I need to select the colour management settings within that software. As I am more familiar with Resolve I have started there.

We are shooting in 6k with DragonColor + REDLogFilm as a base with an applied REDGamma2 and CDL to achieve the dailies look.

After importing the source I select the Resolve colour management settings tab and see the two ACES options of cc and cct. Within the other color management options of Resolve I can select the starting point in our colour workflow - DragonColor and REDLogFilm - which seems to make sense. Then there are the colour science options, ACEScc, cct and DaVinci YRGB.

Colour science question…

If I choose one of the ACES, which of cc or cct will best achieve the desired result?

Settings options questions include:

Linear or Not?

  1. ‘Process Node LUTs’ setting can be toggled between either AP0 Linear or AP1 Timeline Colour Space?

Output Tranform to the HDR Delivery Spec Requirement or leave the image sequences in the timeline export setting of DragonColor and REDLogFilm?

  1. ‘Aces Output Transform’ which has a variety of options for P3 D65 (nit 1000-4000)? Which is our finishing colour space for the HDR 4k delivery.

Thanks


(Nick Shaw) #25

If you have applied your ASC CDL corrections in REDlogFilm, you have not been using an ACES pipeline. So the CDL values you used will not be applicable. You will need to grade from scratch if you want to finish in ACES.

The choice of ACEScc or ACEScct is a personal preference. Through the majority of the range they are identical, but the shadows respond differently to grading operations. Try both and see which you prefer the “feel” of.

This only makes a difference if you are using LUTs in any nodes. LUTs need to be constructed for the colour space that they will be applied in. Generating LUTs for use in linear spaces requires the person constructing the LUT to have technical understanding of how to construct a LUT for linear input. So if in doubt, you are probably better choosing to apply LUTs in the timeline space.

You certainly do not want to set an Output Transform that matches your source footage, unless you have a very specific non-standard workflow in mind. You should set the Output Transform to match your required deliverable, and use a monitor set to receive a signal in that format.

ACES makes it possible to work with one type of monitor with the corresponding Output Transform, and then change Output Transform to match a different format. However, when you change Output Transform you still need to review the film on the new type of monitor, and make trims to the grade if necessary. For example, you would never want to grade on an SDR monitor, and then switch Output Transforms and deliver “sight unseen” in HDR.


(Jordanacomba) #26

Thanks for the considered response!