Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

ACES Proxy - what exactly am I looking at?

Bruce Schultz

Bruce Schultz

Well-known member
Joined
Jul 27, 2010
Messages
161
Reaction score
0
Points
16
Location
Malibu, CA
I noticed that clicking this box in Looks/Gamma with the Indie box also clicked gives a nice monochrome image, and goes to color when the Indie is de-clicked. But the question I have is this; what exactly are we looking at when ACES Proxy is invoked?

EDIT:
I posted this question up on CML also and got a response from an engineer working with the Academy for the coming V1.0 rollout at NAB 2015. His comments were:

"ACES proxy is a log encoding like Cineon or REDlogFilm, with wide gamut color primaries. It should look low-contrast because it's log and low saturation because it's wide gamut. The expectation is that an ACES proxy signal pipes into a LUT box or monitor which can apply the RRT/ODT for proper viewing on a 709 monitor. For final viewing, you will want to apply an Output Transform (RRT+ODT) using the BM HDLink with Pomfort Live Grade or Resolve etc. There should be more range in an ACES proxy image than REDlogFilm. ACES proxy covers the linear range from ~0 to just over 700. REDlogFilm covers the linear range from ~0 to just over 13. Of course, if the camera can't capture values over 13, ACES proxy isn't helping."

Good info about a feature in the latest build that is not well documented or explained.
 
Last edited:
Aces Workflow

Aces Workflow

Gunleik Groven open a thread sometime back, the thread got little traction. But I would love to hear how workflows are developing in the wild. Is the ACES profile provided by each camera manufacturer? Where does the IDT live? Not quite clear on the source of the IDT's and its uniformity.

From what I understand, the ACES Proxy is only for on the fly preview as its a lower quality encoding (integer only) is useful strictly for onset monitoring. The full ACES is the full floating point version for DI.
 
I'd guess that even though it is lower precission than an ACES EXR workflow, you can do Color (And also live composite) Decissions (non-destructively) on set, that still will have some relevance for post.

Just to think up two issues off the bat.

Yes.
I am interested in experiences with different ACES workflows...
 
ACES Proxy is a way to map the ACES floating point data into a log format so you can work with it live. We implemented ACES Proxy for testing purposes last year, but since then the format and specification has been updated, and we'll be putting out an update for that.

The ACES Proxy log curve is related to the ACEScc log curve, which means ASC CDL decisions on set can be applied in post.

Graeme
 
Is the ACES profile provided by each camera manufacturer? Where does the IDT live? Not quite clear on the source of the IDT's and its uniformity.[/QUOTE said:
As I understand the process, each camera mfg submits it's IDT profile(s) to the Academy. Graeme has stated in other threads that, at least in DaVinci Resolve no IDT is required because the math is correct from Red to ACES. Not sure how that works in terms of other manufacturers, but it is probably related to raw recordings already being linear and other log recordings not being linear and therefore having to be transformed to linear.

I've been experimenting in Resolve with 6K R3D raw footage using the No IDT/Rec709 ODT settings with pretty nice results. Lot's of headroom for grading, and the footage comes into the Color Page looking very good right out of the gate without any adjustments at all.

No camera manufacturer can supply an RRT/ODT profile as that is what is kept in continuity for all display devices with ACES.
Click to expand...
 
Because we like to work off the raw R3D data, we think that if you want an ACES file, it's best to make that direct from the raw data rather than by using an IDT on an intermediary log file. Because the ACES colour space is very wide, and colour space transform used to produce an intermediate file will make for a non-optimum ACES file due to clamping. Again, best to derive the ACES data directly from the R3D.

We put the ACES conversion (and we can't really call it an IDT although it does sorta fit in that category) into the SDK. In the normal course of raw development we have a stage where the data is linear light and XYZ. That means to generate ACES data we just put the Academy supplied XYZ to ACES matrix on the data and export, and this means no unnecessary clipping or clamping before the production of the ACES data too!

Graeme
 
Thanks for the additional info Graeme. As ACES moves forward it becomes easier to understand when you grasp that the huge color gamut you are working in is Linear and raw R3D is Linear so it makes perfect sense to work directly in that space to preserve the footage integrity. Log footage like Alexa ProRes Log C, Canon C-Log, and Sony S-Log(s) require IDT transforms to move into this Linear gamut. I know I've probably over simplified it, but this seems to be the basics of it.

As far as a white paper goes, the Academy has a pretty complete web page(s) about ACES here; http://www.oscars.org/node/67606 and the Academy will have a booth at NAB 2015 this year with specialists and engineers who will glady help anyone with questions who wanders in.
 
Bruce Schultz said:
Log footage like Alexa ProRes Log C, Canon C-Log, and Sony S-Log(s) require IDT transforms to move into this Linear gamut.
Click to expand...

I think you have it backwards. Pretty much all modern CMOS cameras acquire images the same way. CMOS is a linear device, so regardless of manufacturer the RAW data is linear. What you do with it later is the difference. As Graeme explained, Red decided to do the LIN to ACES matrix transform in SDK. So, debayered image already have proper ACES transform applied, so no IDT is needed. Other manufacturers don't do that and rely on IDT. What that means, is Red debayered image has ACES IDT "baked in". There are number of users, that dislike the "ACES look" and they then must grade that look out. So, in order to counteract that, FilmLight instead of RRT applies different DRT "transform", which actually can be something, like a standard Wide-gamut LOG-C LUT. LUT is much less computationally intensive, than transform and using ARRI LUT as a DRT allows FilmLight to preserve the "ARRI look". Obviously, this is great oversimplification, but I suggest stopping by FilmLight's booth at NAB and see for yourself their ACES implementation, which they call Truelight Color Spaces.
 
Just to be clear, the ACES Look is only baked in when ACES is selected as the output of the RED SDK, ACES is not part of the RED SDK output when using some the "canned" looks like RedGamma3 or RedGamma4
 
Bruce Johnson said:
Just to be clear, the ACES Look is only baked in when ACES is selected as the output of the RED SDK, ACES is not part of the RED SDK output when using some the "canned" looks like RedGamma3 or RedGamma4
Click to expand...
According to Graeme from an earlier post:
We put the ACES conversion (and we can't really call it an IDT although it does sorta fit in that category) into the SDK. In the normal course of raw development we have a stage where the data is linear light and XYZ. That means to generate ACES data we just put the Academy supplied XYZ to ACES matrix on the data and export

If you're not using ACES workflow, obviously, none of this transform use applies.
 
The ACES look doesn't come in on the camera to ACES transform though, but is instead part of the ACES processing that occurs afterwards in what they call the RRT and ODT. Responding to feedback the Academy did two good things - they simplified their RRT processing to make it more neutral and less of a "look" and they made it invertible so that you can back that processing out should you need to.

Graeme
 
@Graeme:

The three courses about Color Science and ACES that I took at FXPHD were a while ago. Perhaps I miss some changes, so my question:

I saw questions here about ACES and ProRes. – Is ACES not build around OpenEXR half float, and would leave ProRes not data out? Thanks for any update on this.
 
There's significant changes between the early pre-release versions and the v1.0 release. Although the original ACES colour space (AP0) is still the spec, the rendering and grading stages are now done in a new colour space AP1 (with real, rather than imaginary primaries - is that the right terminology?) that's pretty close (although with different white point) to REC2020. ACES Proxy also now uses the new AP1, which is good because if you're monitoring it direct (without a ACES Proxy view LUT) the colours look an awful lot nicer.

ACES Proxy is designed to be a live output on a camera and not recorded. However, I'm sure people will record ACES Proxy and use ProRes to record ACES Proxy. I'm not entirely sure that's wise, but that won't stop people trying!

For ACES, EXR is indeed the preferred container format for the files.

Graeme
 
Thank you very much, sounds all very good, Graeme.
Thank you as well for all the hard work, I really feel grateful -- especially when I see new captures from my Dragon. Thank you.
Have a great weekend.
 
Last edited:
Graeme Nattress said:
The ACES look doesn't come in on the camera to ACES transform though, but is instead part of the ACES processing that occurs afterwards in what they call the RRT and ODT. Responding to feedback the Academy did two good things - they simplified their RRT processing to make it more neutral and less of a "look" and they made it invertible so that you can back that processing out should you need to.

Graeme
Click to expand...
Unfortunately some manufacturers are trying not to use RRT and instead use their own DRT instead. That is what FilmLight is doing with their Truelight Color Spaces. And unfortunately, RRT does introduce a certain look. Hence the use of ARRI Wide gamut LUT as a DRT.
 
Dr. Sassi said:
I hope people will soon understand that UHD is not just four times HD, hence the huge REC2020 colorspace.
Click to expand...

This might have a lot more meaning if there were existing monitoring devices that could actually display Rec2020. Right now, there aren't.
 
You must log in or register to reply here.
Back
Top