ACES Proxy - what exactly am I looking at?

[Bruce Schultz]

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.

[Bruce Schultz]

bump for added EDIT info

[Sidney L. Plaut]

interesting:)

[M.Halsell]

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.

[Gunleik Groven]

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...

[Graeme Nattress]

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

[Bruce Schultz]

[QUOTE= 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]

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.

[Graeme Nattress]

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

[Sidney L. Plaut]

Easy to follow white paper, plz - or it didn't happen...:)

[Bruce Schultz]

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.