Hi to all
First post…
What’s the difference between ACEScc and ACEScct?
Thanks!
ACEScct is very similar to ACEScc across most of the range, except that it adds a “toe” to make it more akin to traditional “log” curves (e.g. Cineon, LogC, S-Log, etc.). The addition of a “toe” results in a more distinct “milking” or “fogging” of shadows when a lift operation is applied (and compared to the same operation applied in ACEScc). This difference in grading behavior is being provided in response to colorist requests for behavior more similar to that of traditional legacy log film scan encodings when grading using a working space from the “ACES” family of color spaces.
Specifically, for ACES values greater than 0.0078125, the ACEScct encoding function is identical to the pure-log encoding function of ACEScc. It is only below that point that the curves differ. However, note that because of the toe, ACEScct is not compatible with ACESproxy.
7 Likes
This also means that, due to the difference in the transfer characteristics of ACEScct and ACESproxy (whose latter “Log.” curve is shaped after that of ACEScc) the numerical values of a Color Decision List (CDL) applied on-set and transported in ACESproxy to a reference monitor are not repeatable in a grading room where ACEScct is used as working space instead of ACEScc. At least as regards values below ACES codevalue 0.0078125.
Besides, as per Academy document S2016-001, additional care is needed if CDLs are applied on top of ACEScct. Specifically, the “Power” coordinates should not be applied (or be set to 1.0) to any values that are negative after “Slope”'s and “Offset”'s are applied (with current CDL operators ordering being S-O-P).
I have to say that I am a bit doubtfull, that it’s a good thing to release new versions every few weeks. As far as I know we now have at least: ACES linear, ACEScc, ACESproxy now ACES cct. And all of that in 2 color spaces AP0 and AP1…
I thought this was set out to generate a simple, easy to use standard workflow.
Which it was with ACES linear V1.0. Period. 
But I fear we are loosing that advantage as more and more variations are added.
Peter
As far as I know we now have at least: ACES linear, ACEScc, ACESproxy now ACES cct. And all of that in 2 color spaces AP0 and AP1…
Only ACES linear may be in either colour space (ACES2065-1 and ACEScg). ACEScc, ACEScct and ACESproxy always have AP1 primaries. So there are not quite as many permutations as you suggest.
On a separate note,I would not say that the ACESproxy curve is “shaped after that of ACEScc”. It is the same curve. In pseudocode:
ACESproxy10 = round(1023 * full_to_legal(clamp(ACEScc)))
For ACESproxy12, simply replace 1023 with 4095 in that equation.
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 
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).
3 Likes
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!!
Scratch that… after reading I figures that AP0s “full name” is ACES2065-1… why call it 0 then?! Why not AP1 and AP2??
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.
2 Likes
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!
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
I can post again. Everything is back to normal.
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.
5 Likes
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.
1 Like
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.
1 Like
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:
1 Like
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.
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!
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
1 Like
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?