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).
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.
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:
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.
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.
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.
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:
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
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?
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.
Nick Shaw, thanks for your prompt response and the workaround. Indeed, it’s a very helpful response to my question.
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?
Output Tranform to the HDR Delivery Spec Requirement or leave the image sequences in the timeline export setting of DragonColor and REDLogFilm?
Thanks
