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

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
 
Antoine Baumann said:
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.
Click to expand...

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
 
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?
 
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.
 
Tom Hamilton said:
Or does this mean that RedCineX will have an option to render R3D RAW out to ACES-compliant files?
Click to expand...


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.
 
Zack CC said:
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 :)
Click to expand...

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.
 
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."
 
M Most said:
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.
Click to expand...

Essentially correct. We know you must use our DRX control full-on to make an ACES file that works with their rendering. That is, as far as I know, the only RED specific gotcha. With the RRT I've seen simple ones and complex ones throughout it's progress and indeed many of the iterations have had noise or colour issues. The latest one I saw was less simple than the previous iteration, so there's obviously still some work to do there. It's that kind of issue we need to deal with next, and they're not RED specific issues, but ACES rendering issues in general. The ODT (output device transform) is also somewhat problematic and needs to be looked at too in the same way that the RRT is being looked at. The present REC709 ODT is very contrasty, for instance.

Jim's comment stands though: " We strongly discourage anyone from using ACES in its current form to grade anything RED except test footage. It is critical that ACES is not considered a current solution for production quality work with RED footage."
- and I'd add that if you are using it you need to be in good communication with Alex at the Academy, and if you're using it on RED footage, you need to be speaking directly to me also.

Graeme
 
Is ACES a physical spec or is it a relative spec? And by that I mean if I shoot something at 5600k with 5600k lights does it simply save "White" as "White" or does it save 6500k as "6500k"? Similarly does it define "saturated" or does it say "200 lumens"?

I imagine ideally it would simply capture everything in "real world terms" so that if you had say an HDRx track and a normal track the HDRx track would be stored as 0.75 -> 2.0 while the normal track was maybe stored from 0.25-> 1.0 without any need for luminance offset to match the two tracks.

Today when you save out HDRx you get a "0 - 1.0" value and a second "0 - 1.0" value even though one of the tracks is actually "0 - 4.0" relative to the other.
 
David Mullen is the master.

David Mullen is the master.

David you are truly brilliant in some of your comments.

I was in the Army, and yes they also use AOA: Acronyms Out the Ass


But all kidding aside, this is something I find fascinating and unbelievably important.


Keep it up RED.
 
Tim Whitcomb said:
meantime while you smart guys figure this stuff out... a bunch of HUGE movies are coming out that didn't bother with ACES. :)
Click to expand...

I honestly don't understand your point. All technology gets improved over time, and all methodologies get refined over time. ACES is an industry wide initiative that is currently a work in progress that will hopefully provide improved and standard approaches to some current issues (archival formats are one very major one).

I could just as easily point out that a bunch of huge movies are coming out that aren't being shot on film. Or Red cameras. The statement would be equally as meaningless.
 
There are many ways to get to the finish line. ACES will be one way when it is mature. It just isn't right now. Staying R3D through to the end is another. And this way is proven.

Jim
 
Last edited:
Jannard said:
There are many ways to get to the finish line. ACES will be one way when it is mature. It just isn't right now. Staying R3D through to the end is another.

Jim
Click to expand...

But you understand that you can't stay in R3D till the end if you have VFX shots, right? Because VFX must start a long time before the grade.

For most films, staying in R3D till the end is just not an option.

It's:
- work in ACES, with tons of dynamic range, in defined, vendor-neutral color space (best)
or
- work with log DPXes or EXRs, with RGB primaries aligned to color science of primary camera (costs more because VFX team must match their stuff to RedColor3, which is undefined and non-standard, easier if you use Alexa because Arri has a website that gives you every LUT you need)
or
- work with log DPXes or EXRs, with all footage converted to primary post facility's color space (OK if Technicolor or whoever defines your LUTs - and they do, thank heavens... defined as "bad" by RED because facility color spaces are seen as "film-based")
or
- work with log DPXes or EXRs, with 709 or P3 primaries (okay in P3 case, ore limited color range in 709 case)
or
- work with HDTV standard - eg no log space, limited dynamic range (what people do - which is really bad because you clip stuff)

Bruce Allen
www.boacinema.com
 
It is all about how you get to EXR... we understand that VFX needs this. It is just about how you get there. You can't screw it up by putting a predetermined look on it or inducing artifacts in the process. Currently ACES does both.

Jim

Bruce Allen said:
But you understand that you can't stay in R3D till the end if you have VFX shots, right? Because VFX must start a long time before the grade.

So for 95% of films, staying in R3D till the end is just not an option.

It's:
- work in ACES, with tons of dynamic range, in defined, vendor-neutral color space (best)
or
- work with log DPXes or EXRs, with RGB primaries aligned to color science of primary camera (costs more because VFX team must match their stuff to RedColor3, which is undefined and non-standard, easier if you use Alexa because Arri has a website that gives you every LUT you need)
or
- work with log DPXes or EXRs, with all footage converted to primary post facility's color space (OK if Technicolor or whoever defines your LUTs - and they do, thank heavens... defined as "bad" by RED because facility color spaces are seen as "film-based")
or
- work with log DPXes or EXRs, with 709 or P3 primaries (okay in P3 case, ore limited color range in 709 case)
or
- work with HDTV standard - eg no log space, limited dynamic range (what people do - which is really bad because you clip stuff)

Bruce Allen
www.boacinema.com
Click to expand...
 
Last edited:
You must log in or register to reply here.
Back
Top