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
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.
Thanks for the considered response!
Then why there is an ACESproxy ? I mean,we can use cameras’ native log format on-set and convert it into ACEScc/cct, and grading or something. I would like to know the meaning of cameras’ ACESproxy output.
If you create CDLs on set viewing ACESproxy on the camera output signal, then those same CDLs work right if you grade in ACEScc.
I haven’t figured out though, what kind of workflow would allow them to work in ACEScct as well.
When using a live grading system capable of applying a live Input Transform to a camera log input (which all modern live grading systems can) ACESproxy is redundant.
I believe it was designed to allow live grading with a more “naive” CDL grading system, with the Output Transform applied by a LUT box downstream of it.
These days live grading systems usually concatenate the Input Transform, grade, and Output Transform into a single 3D LUT, and push that to a LUT box.
Thanks for your reply and that’s useful for me.
And appreciate it again.
Hello，I have another question about ACEScc.
I’ve read the ACES document which says LMTs should be used after color grading，which means after you convert ACEScc to ACES you apply LMT. But I’ve noticed another situation in some pictures where LMT is in ACEScc but not in ACES.
And I don’t know if we can apply 3D LUTs like some creative style in ACEScc. As we all know, ACEScc is 32bit floating point encoding.When we use LUTs ,what about LUT index and how they work to get results of each channel. I’m so confused about that.
