ACES workflow tested and verified?

[fred gasc]

Hi.I'm currently learning ACES, Not talking about generalities but in this forum,Red only.Have hard time to find reliable infos in internet on Aces with Red.Most of the "info" have read are debates that goNowhere, guessings and ultimatly desinformation.Do you have links with people who know what they are doing?Don't get me wrong, I don't bark on internet, Because on the net, everybody opinates but littleActually know, and that's just the way it is.just thatI'm learning the job in this industry and try to see who'sGot it right and who I can listen to.The only reliable info I have so far (wich is important) isA Graeme post saying: no IDT with Red.Elsewhere it's a mess.If you have links or rock solid imputs on that topic,Please post.Many thanks.

 

[Graeme Nattress]

Yeah, just make sure whatever is decoding the R3D is using the SDK properly to get out the half-float ACES data. You can always confirm that by using REDCine-X to make and EXR and checking it looks the same as whatever app you're using is creating. If that's all good and checked, then everything follows through from that point just fine.

Graeme

 

[fred gasc]

Many thanks Graeme. It's a great idea.
I wanted to avoid the EXR route but actually it's worth
Using it to see if things are on track.
So there is always a reliable material to refer to.
Didn't thought about that and this is really usefull!
Cheers.

 

[Blair S. Paulsen]

Props to Fred for asking questions. Props to Graeme for stepping in to help Fred. Ironically, it's often the new recruits who do their research who end up with the smoothest experiences in RED post operations. It's often the old dogs who try and push R3Ds down a pipe poorly suited to the task, then blame RED when it's a PITA.

This is RedUser at it's best.

Cheers- #19

 

[Nick Pasquariello]

ACES is going to take a while for everyone to fully wrap their heads around. Perhaps we could get a good article up on red.com/learn that has some best-practices and overview straight from the horse's mouth? Would cut down a lot of misinformation and arguments on set and in post, I can assure you.

 

[fred gasc]

Well, or I am crazy and it's actually too simple, or people indeed like to
Complicate everything.

...ok, so far I'm just testing, right? So don't consider me reliable, but I
Got consistent results using or the
EXR from RCX, or directly the R3d,
In both Scratch or Fusion.
From what I'm seeing, things could not be more simple and my exr match the r3d.
Logically, if I enable in the read node the Aces (reading the r3d),
I loose gamma settings wich is logical and normal and the inmediate result is exactly the same image as an EXR generated
By RCX. Not similar but absolutly the same.

Then, if I apply a gamut node to perform a display transform to rec709, in Fusion, I got the exact same image in Scratch with the dual view in rec709 colorspace enabled. Again, not similar but the exact same.
Bottom line, from EXR rcx export, or directly R3Ds in Fusion and Scratch, the image remains exactly the same in Aces.

I don't see any weired thing or complicated hidden secret from Red team and all the noise
I read in internet puzzles me. It couldn't be simplier.

But hey...maybe I got it all wrong...
Or maybe not?

Is it that simple?

 

[fred gasc]

...Maybe should we demystify ACES?
And take it relax.

After all, it's just a colorspace like any other.
The image that display both Fusion and Scratch are 100% identical, using
Different methods, and similar to linear Raw when canceling all curves but with a different mapping, (sort of greenish).

True that I've been trying to push values and it's quite amazing because it seems impossible to clip. What a room!

 

[Stacey Spears]

I would not say ACES is like any other color space. It moves from the traditional perceptual display referred to a linear scene referred. Then again, so many don't grasp display referred, which is why we have so much misunderstanding when it comes to the word gamma.

Not everything should be done in linear light. e.g. The saturation control is a great example. REDCINE-X Pro has two saturation controls. One that is done in linear light, which is the SDK control and one that is done in perceptual (gamma corrected space). You want to use the perceptual saturation control. So don't use the saturation on the RED settings page. Here is a good thread on Reduser about this very issue:

If it's a photographic process it should be done in linear light. So that would be exposure, compositing, blending, additive operations etc. Gamma corrected space should be for subjective adjustments such as curve adjustments, saturation, Hue shifts and other "looks".

Another way to think about it is to ask yourself if there is an optical equivalent (e.g. grad filter, vignette, print lights, diffusion, flares, defocus/blur, CTB, etc) if you can think of an optical equivalent it's a linear operation. If it doesn't have an optical equivalent (for instance there is no "curves" 4"x4" filter or an "increase saturation" by schneider.)

I am a fan of the idea of ACES. I would recommend everyone check out Poynton's classes on FXPHD.com as well.

 

[fred gasc]

I agree Stacey. I wrote "like any other colorspace" in the sense of demystifying a bit but you're right, ACES is a different animal to what we are used to.
Probably not as complicated nor so simple
But we'll end to get familiar with.

Great interesting link on linear/post saturation. Thanks.

As I said, I'm learning the job and still a lot to understand.
I got the sensation that the all story consists in not messing with the displays
Transfers.

I like to strip things (and not only girls) because they reveal how things are done.
I'm thinking for ex of Alexa: if we take a log
Arriraw and change the colorspace from raw level to rec709, we got image A.
Now, if we use an official Lut from Arri lut
Generator and instead of applying the transform from the SDK, we apply the Lut
Above the log image we got image B.
And image A and B are absolutly identical.
Tested and verify. You can put those 2 images on layers and turn on-off, they are the very same. So things comes from logical maths if I might say.

Engineers (wich I'm not) are generally not
Extravagant people but hard core logical
Maths and what they do is driven by logic.
Once we got it, it should be simple.

In a way, this ACES reminds me a bit of the RLF wich is exactly Cineon standart and therefore logical that Red didn't provide any "official lut". Arii being a different curve
They had to.

The problem I see with Aces are the displays.
My workstation displays are 10bit but they
Aren't suitable for handeling such a huge color range. Unless I don't bake the output
To a colorspace those monitors allow,
It's pointless because grading is dependant to the performances of our displays, but that's not just Aces.

So far, I've been testing with Red and Arri. In both cases the starting point image for
Grading is way richer and maleable than
Any other colorspace I knew.
Yes, we loose Raw but IMO it's worth.
I'am sill very clumpsy on the process,
Like a kid in legoland. Hope we'll get more and more imputs with time.
Cheers.

 

[Christoffer Glans]

Found this about ACES. http://negativespaces.com/blog/2014/5/16/aces-in-10-minutes

Might be good for the ones in the dark (like myself)

If I'm going to grade and master an ACES master file of a movie, how would I do that with R3Ds using Resolve?
Should I use the R3Ds directly in Resolve together with a ACES colorspace or should I render out to ACES files before grading? How do I handle VFX? If I render out DPXs in 4K for work in let's say After Effects, how do that transform into ACES when going back to the grade?
The VFX and CGI part always confuses me since we need to work with files that aren't too heavy.

 

[Björn Benckert]

https://vimeo.com/98590311

 

[fred gasc]

Red provides the EXR export in ACES precisely
To avoid hassles when we don't really know
What we are doing. (a bit like they provide
Rg3, 4 if we don't want to go Cineon route)
But EXR means a transcode and heavy storage also.

I think that Graeme had a great imput: use the EXR has reference to see if we are on track.

I would personaly choose to use the R3D directly, after all we need to get it right, no?
With no IDT and if you exported a few frames
In EXR, using those as a "checker". Images
Should match (exr export and r3d). In my case they absolutly do.

The color grading occurs at linear level but
We need to work with a proper display
Because we need to see what the final image
Will looks like.
I beleive (correct me if I'm wrong) that this is where confusions happen.
Scratch for ex, treats ACES like it would treat
Redgamma4 for ex. It's a colorspace. Bigger, wider, but a colorspace in the end. So sometimes the software
Actually does the correct transform to the output
Space and we just have to grade as we would grade any other stuff, just that we have infinite room.

This is what I understand, and yeah, not sure yet
If I got it right. I feel the same as you do.

But insisting, we will get it. For sure! Soon or later.

 

[fred gasc]

https://vimeo.com/98590311

Great link Bjorn. I knew Cedric Lejeune videos, his
Got some great stuff in Nuke too. Very usefull.

Yeah, this is what I thought too. The big stuff is in
Going from such wide gamut to something manageable
That we can handle and predict results to work reliably.

 

[Graeme Nattress]

For ACES, you really need the precision of the EXR, either as a file or decode for the system to work. Although the Academy have defined ACES Proxy and their ACES CC log encoding neither are designed for, nor recommended for an encoding for a written file. ACES Proxy is for a live feed from a camera for on-set grading decisions and "should not" be recorded. Similarly for ACES CC, it's for operations that occur better in a log space and for compatibility with grading decisions from ACES Proxy. ACES doesn't really make room for a DPX or compressed video style workflow, although I'll predict that even though such routes are strongly recommended against, people will adapt and use them.

It should be noted that although there is the original ACES colour space, there is also the new AP1 space as used by the ACES Proxy and ACES CC, and is designed for grading. The original ACES space (AP0) has issues for grading as it's over-wide and has un-real primaries. AP1 has real primaries and hence works better, but is of lower gamut (very similar to REC2020, albeit still with the ACES white point). Again like the log formats, AP1 colour space data is not designed to be written to a file, but similarly I expect that some people will do so against recommendation.

If you're reading any guide to ACES, make sure it's up to date with ACES Proxy, CC and AP1!

Graeme

 

[fred gasc]

Does that means that we should avoid AP0 for grading?

 

[Graeme Nattress]

Internally, the math is always the same.... The sensor data is always linear, and then we colour space convert to calibrated XYZ and from there to whatever the desired output space is. For ACES EXR we go from XYZ to ACES via the Academy's matrix for that transform, and then map the linear light data to EXR code values and export.

Yes I think the math is exactly the same no matter if it's done to EXR on via the SDK in an app. Either way the image should be identical.

Yes, when I refer to precision of the EXR I mean the half-float precision is necessary because of the wide colour space and wide dynamic range encoding. If you attempt to squeeze that same gamut and DR into a 10bit DPX you'll begin to loose precision.

For mapping linear light ACES to a monitor there's two transforms - the RRT which is the reference rendering transform, and then the final stage is an ODT or output device transform. If you're not grading then to view an ACES image you do ACES->RRT-ODT (picking the ODT suitable for your monitor).

Because linear light is not always suitable for grading operations, the Academy have made ACES CC (a log encoding) and AP1 (real primary grading colour space) for you to work in. I'm not exactly sure at what stage in the process you go from ACES -> ACES CC and back, but I think the intent is that grading operations occur in ACES CC. Of course, as the math is open you could pick your own grading space and define the transforms ACES->grading and grading->ACES and do ACES->grading (do grading here) grading->ACES->RRT->ODT and have that flexibility you desire and it "should" work, especially if you don't clamp on your grading transforms and keep everything float. But really at this point, it would make sense to pick a grading tool that basically does that for you which I think is what Baselight is doing at the moment (my knowledge here is limited, so there could be other grading tools that act similarly).

Graeme

 

[fred gasc]

Graeme. Many thanks!!
Now things are getting much clearer to me.
Very usefull.

Red forum is great.

Ps: I edited my latest post because I didn't read you correctly on the AP0, english not being my native lenguage. But you brought clear precisions.

 

[Graeme Nattress]

The initial conception of ACES workflow as I understand it had the operations as followed ACES (AP0, linear light) -> grading -> RRT -> ODT. This is problematic as although compositing works well in linear light, grading operations generally work better in a more perceptual space. Also problematic is that if you look at AP0 to XYZ, Y = 0.3439664498 * R + 0.7281660966 * G -0.0721325464 * B; Note the negative coefficient on blue. That is partly why now it's suggested we grade in AP1 where Y= .2722287168 * R + 0.6740817658 * G + 0.0536895174 * B; making it behave with respect to luma much more like how we're used to.

Graeme

 

[Stacey Spears]

The initial conception of ACES workflow as I understand it had the operations as followed ACES (AP0, linear light) -> grading -> RRT -> ODT. This is problematic as although compositing works well in linear light, grading operations generally work better in a more perceptual space.

From an outsider looking in, it seems like ACES CC was bolted on at the last minute. You would think someone would have tested grading in ACES.

That is partly why now it's suggested we grade in AP1 where Y= .2722287168 * R + 0.6740817658 * G + 0.0536895174 * B; making it behave with respect to luma much more like how we're used to.

Wasn't this one of your biggest complaints with ACES? I thought part of the overly large size of the ACES color space was to prevent colors from clipping. How are things now in that department? Thank you for sharing the details, I had not read up on AP1.

While not ACES specific, some good info on bit depths.

I have attached a graph showing various bit depths in regards to the Barten ramp. 16-bit EXR is well below the Barten ramp. 12-bit PQ is also below it. You need around 15-bits of gamma to stay below it when going over 100 nits. 13 bits for log. You can read more about it in ITU-R BT.2246. The details start on PDF page 42. PDF page 39 has a nice image showing the CIE diagram and objects that fall outside of 709 primaries.

Here is a nice paper on PQ from SMPTE.

 

[Graeme Nattress]

ACES CC and AP1 were I think in response to practical use of ACES workflows and grading. All along the Academy have taken feedback, although quite frankly the use of AP1 as the grading space makes AP0 redundant because there's no benefit to it over the master colour space of XYZ. Anyone who is matching or converting between colour spaces already has everything defined against and moved through XYZ.

Large gamuts can stop colours clipping, but that's only part of it. When you're dealing with cameras, you're dealing with devices that can and do create colours not just outside of any reasonable RGB space, but colours than can potentially be outside of XYZ too. What is more important than size of gamut is how that gamut is used. From the ACES discussion board it would appear people understand this aspect, but I don't see anything specific in ACES1.0 that addresses it. It's certainly an area for them to improve in, which I'm sure they'll do. In the meantime traditional secondaries can be used to manually deal with this.

PQ curve is well designed and I like how specific code values map to specific measured brightnesses. It does tidy up a lot of the "gamma mess" issues....

Graeme