ACES...

[John Tissavary]

Thanks, Jim & Red, for your commitment to ACES, and thanks Peter for working to fix the issues. I think ACES is the single most promising thing for color management in post, and I look forward to working with it as soon as possible. So far our experimentation at Smoke & Mirrors NYC has seen promising results, and we agree that it is premature to implement for production.

cheers,

John

[Jason Comparetto]

This would be great. I'm really looking forward to this.

[Zack CC]

In theory in "scene referred" colorspace, the image captured with an Epic or an Alexa, or Canon of the same scene would look exactly the same.

Well, it wouldn't make a Canon DSLR have any more dynamic range or resolution, but it can be used to balance the channel gain from various sources by comparing them in a common language/ color space, if that is what you want to do. It cant artificially add resolution or data that isn't there to begin with. There will still be different advantages to shooting different cameras, but theoretically it should make designing workflows a lot easier, put to rest many compatibility issues, and allow more precision overall. If implemented correctly, I believe it should foster more accurate and explicit communication downstream of aesthetic intent that was decided at the source... anyway...

EDIT: Sorry, I know Canon makes more than just DSLRs, just choosing an example that helps illustrate the point XD

[Paul Ellington]

Jim
As I am sure Graeme has told you I agree with you and Graeme and am working to fix the ACES artifact issues with the academy

Mr. Lyons let me pick your brain again soon if you have time.

Hugz

- Paul

[Tom Hamilton]

Ok, not sure how this all works. Does this mean that Red will have a future in-camera board that outputs ACES-compliant files, similar to the ProRez Alexa output? Or does this mean that RedCineX will have an option to render R3D RAW out to ACES-compliant files?

What about monitors and projectors? Will they eventually be ACES-intelligent as well?

Huge development it seems.

As an aside, Jarred has stated the heretofore dormant GPS function will become active in the next Epic firmware build. Any chance of a security tracking function for stolen cameras?

[Zack CC]

Tom, possibly. I could see it moving in that direction as well, certainly on the monitoring side. For right now I believe all that is asked is that camera manufacturers provide what is being called an IDT or Input Device Transform, which is basically a LUT that translates the original camera output into the ACES color space. The ACES space is a really really wide space, wider than any previous standard, so there isn't a camera or monitor that can actually capture or reproduce the entire range natively.

My guess is that right now the issue is that there isn't a satisfactory IDT for translating R3Ds into ACES... Im sure that the guys responsible for doing the math will get it all sorted out :)

http://www.openexr.com/UsingOpenEXRandCTL.pdf

heres a link to an old paper from 2007 which is kind of an introduction to the basics. The spec has changed since then, slimmed down a bit, etc. gotten rid of a few acronyms..

Basically the workflow goes:
Camera -> Input Device Transform -> Color Decision List (or Look Modification) -> Reference Rendering Transform and Output Device Transform -> Monitor

For passing on values, everything stays in ACES for maximum compatibility with all systems that can work with ACES information. The reference render transformation is done when the data needs to be displayed, and is also transformed to be device specific (ODT), but all ACES values can be passed through an ODT for whatever it is you are viewing on, be it a P3 or Rec 709 monitor, DCI Projector, etc.

So in short, yeah, it would/will be really cool if/when the actual device manufacturers are able to incorporate the spec, but until then, which is probably a ways out, there are at least one-two devices that actually do the entire ACES workflow themselves, and can bypass steps accordingly depending on the capabilities of the equipment those devices are communicating with. Aside from those devices, plenty of the industry tech providers, hardware and software, seem to be picking up the spec! Pretty cool stuff.

[M Most]

Or does this mean that RedCineX will have an option to render R3D RAW out to ACES-compliant files?

Redcine X has had that option for at least 1 1/2 years now. It's in the pulldown menu when you select Open EXR as the output format.

[M Most]

My guess is that right now the issue is that there isn't a satisfactory IDT for translating R3Ds into ACES... Im sure that the guys responsible for doing the math will get it all sorted out :)

That is one issue, but the primary issues at this point have to do with the RRT. IDT's are reasonably straightforward. The RRT is not. The current and past versions of the RRT are very, very complex and due in part to this complexity have some issues with certain images. The RRT is a "work in progress" and is being constantly tweaked to make it simpler, more usable, less noisy, and less prone to "breaking" with certain image values. That's probably what Jim is referring to.

[David Mullen ASC]

What does RRT stand for?

[Tom Hamilton]

Reference Rendering Transform

"The RRT is designed to represent an “idealized” image from the ACES data that can be viewed on any device by passing it through an Output Device Transform, or ODT.. The combination of the RRT and the ODT are the heart of the ACES output system, and are roughly analogous to the use of a rendered image followed by a display LUT in a typical film targeted digital intermediate system."