Aces/Academy IFF signal workflow

[Gunleik Groven]

We just had a great seminar over the weekend here in Oslo hosted by Imago, where amongst others David Stump was one of the speakers.

The Zacuto initiated test was screened, as well as the Epic demo and F65 Demo.

And a live grading session on Nucoda with Alexa and MX footage.

Lot's of great discussions and people all over and healthy debates and studies on 3d, digital cinema production and other geeky themes with partixcipants from all over Europe.

What was the biggest highlight for me (even though it was only briefly touched upon) was the ACES/Academy IFF signal-chain color-workflow presentation (which the F65 will be suporting from the Get-Go)

Curious as to how Red feels about this initiative.

To me it looked like the practical solution to most of the signal-chain issues we see daily, as it extends beyond the 16-bit half-float linear ligh open EXR encoding.

is RED on the wagon on this?

The Epic demo made my day, BTW...

Here's some info about it:
http://www.oscars.org/science-technology/council/projects/iif.html

What I really like is the convertion to a "common" linear signal platform with standardized ACES to REC/P3/XYZ/Web convertion parameters. While it would lose me a lot of work, it would make life so much easier in the same breath.

The downside is of course that this is an uncompressed workflow, so it won't be for all. But still...

And compression could come along...

Thoughts?

Cheers!

Gunleik

 

[M Most]

is RED on the wagon on this?

Redcine X has supported ACES output for at least the last 5 builds. If you select OpenEXR, then Setup, there's a checkbox to put the output into linear ACES color space. Of course, you still need a proper RRT/ODT implementation, a possible linear ACES to log ACES transform (depending on the grading system, it allows better scaling of the color controls), and a color grading system that supports it. Right now, ACES testing is being done with Lustre, Baselight, Resolve, and others using LUT implementations of the RRT/ODT based on color science supplied by the Academy, and directly implemented by the various vendors based on their own specific formats. There are also some colorists using the output transforms as a substitute for more conventional log/lin approaches, but that's not really "the ACES workflow," it's more of a personal colorist's choice based on certain aspects of that transform that they happen to like (the gamma curve and soft clipping in particular), and I wouldn't really recommend that to the average user. Having said that, there is at least one show currently being posted using a "proper" ACES path ("Justified") and a few others that are considering it. The camera manufacturer that has been the most pro-active in the movement has been Sony, and the show I just mentioned is shot primarily on F35, so setting up the path was pretty straightforward, and it represented a major improvement over the "traditional" path of coming in as S-log and correcting completely in Rec709 space. For Red footage (and Alexa footage, for that matter), the transforms supplied by the manufacturers for their specific cameras are quite good, and the improvement using ACES is more minimal as a result. In fact, in tests I've done using the most recent ACES implementations with Red footage, the initial result is very, very similar to that obtained by using Redgamma2 and Redcolor. So much so, that you might think that Graeme was influenced by some of what he's seen in the ACES results.... ;-D

Personally, I've taken to using RedlogFilm/Redcolor, and grading through a Cineon to Video LUT for my television work, as that, to me, yields the best greyscale interpretation and the most flexibility of any of the current approaches. But there are times when for artistic reasons or simply personal taste and working style, one might go another way. That's why there are choices.

 

[Tim Whitcomb]

This is an EXCELLENT post Mike. Thanks for sharing your expertise. Gunleik, thank you, these are the kinds of intelligent posts that make me come back to REDUSER - despite all the growing noise.

 

[M Most]

The downside is of course that this is an uncompressed workflow, so it won't be for all. But still...

It's only an uncompressed workflow if you transcode to an uncompressed file format prior to grading, most likely the proposed OpenEXR derived format. But the ACES system is just a series of transforms, not a file format. The file format is primarily for transport of information between facilities, vendors, and different software without color ambiguity, as well as possible archiving. More often than not, you would implement ACES as a "live" passthrough from the original compressed source, much as you might now using R3d files directly in a grading pipeline with software that supports "live" debayering, such as Resolve, Baselight, Scratch, or some others. You would do the conversion to ACES as an input LUT (that would be the Input Data Transform, or IDT) and the conversion back to whatever output format you're using as an output LUT (that would be the RRT/ODT, or Reference Rendering Transform and Output Data Transform). So for all practical purposes, the only difference from a R3d based grading path now and one using ACES would be the use of an input LUT, assuming you're working with log transforms and an output LUT already. Sony, of course, has announced support for ACES in their future camera products, specifically the F65, which might eliminate the need for the IDT in some cases, but for the moment, it's not really a big deal to implement as it currently stands.

 

[Neil W. Smith]

Single Chip Camera Evaluation (SCCE) screening - Thursday June 19th - Hollywood-DI

Single Chip Camera Evaluation (SCCE) screening - Thursday June 19th - Hollywood-DI

Please note that the date of the screening is MAY 19th not June 19th ....

Thanks for the feedback Gunleik ... for those of you in the Los Angeles area, we'll be screening the Single Chip Camera Evaluation (SCCE) at our place on Thursday MAY 19th ... Scott Lynch from Zacuto will be present and maybe some of the other participants.

There'll be two sessions ... 4pm to 6pm and 7pm to 9pm.

The screenings will take place in the Fairbanks Theater on The Lot in West Hollywood ... if you're interested in coming along please call Kalani on 323 850 3550 and reserve a place ... seating is limited and walk-ons will not be allowed by The Lot security.

Here's the link to BTS doc on the shooting of the SCCE:

http://www.zacuto.com/the-great-camera-shootout-2011

Neil

 

[Erich Ocean]

I've been working with the open source OpenColorIO from Sony Imageworks for color handling (LUTs, etc.) and they are also specifically targeting an ACES/IFF workflow later this year. I'm thrilled to see vendors across the industry come on board with this. Color is hard enough as it is.

 

[M Most]

I've been working with the open source OpenColorIO from Sony Imageworks for color handling (LUTs, etc.) and they are also specifically targeting an ACES/IFF workflow later this year.

One small correction: It's IIF, not IFF. IIF stands for Image Interchange Framework. ACES stands for Academy Color Encoding Specification. Which are actually two separate but closely related things, with IIF referring primarily to the proposed OpenEXR derived file format and the Color Transform Language (CTL), also developed by ILM, that is used to communicate color settings and other transforms. ACES refers to the color space used in the system, which is floating point and based on a theoretically unlimited color space defined in XYZ coordinates.

More than you probably wanted to know, but in the interest of accuracy, good to know.

 

[jake blackstone]

Redcine X has supported ACES output for at least the last 5 builds. If you select OpenEXR, then Setup, there's a checkbox to put the output into linear ACES color space. Of course, you still need a proper RRT/ODT implementation, a possible linear ACES to log ACES transform (depending on the grading system, it allows better scaling of the color controls), and a color grading system that supports it. Right now, ACES testing is being done with Lustre, Baselight, Resolve, and others using LUT implementations of the RRT/ODT based on color science supplied by the Academy, and directly implemented by the various vendors based on their own specific formats. There are also some colorists using the output transforms as a substitute for more conventional log/lin approaches, but that's not really "the ACES workflow," it's more of a personal colorist's choice based on certain aspects of that transform that they happen to like (the gamma curve and soft clipping in particular), and I wouldn't really recommend that to the average user. Having said that, there is at least one show currently being posted using a "proper" ACES path ("Justified") and a few others that are considering it. The camera manufacturer that has been the most pro-active in the movement has been Sony, and the show I just mentioned is shot primarily on F35, so setting up the path was pretty straightforward, and it represented a major improvement over the "traditional" path of coming in as S-log and correcting completely in Rec709 space. For Red footage (and Alexa footage, for that matter), the transforms supplied by the manufacturers for their specific cameras are quite good, and the improvement using ACES is more minimal as a result. In fact, in tests I've done using the most recent ACES implementations with Red footage, the initial result is very, very similar to that obtained by using Redgamma2 and Redcolor. So much so, that you might think that Graeme was influenced by some of what he's seen in the ACES results.... ;-D

Personally, I've taken to using RedlogFilm/Redcolor, and grading through a Cineon to Video LUT for my television work, as that, to me, yields the best greyscale interpretation and the most flexibility of any of the current approaches. But there are times when for artistic reasons or simply personal taste and working style, one might go another way. That's why there are choices.

Mike.
Do you know with RCX IFF/ACES implementation, in case of using Open EXR ACES render settings, does software applies the IDT on top of Gamma and Color metadata settings or Gamma and Color then just gets ignored?

 

[M Most]

Mike.
Do you know with RCX IFF/ACES implementation, in case of using Open EXR ACES render settings, does software applies the IDT on top of Gamma and Color metadata settings or Gamma and Color then just gets ignored?

I believe everything is ignored except for exposure (and, by definition, FLUT setting), color temperature and tint. The normal Red gamma and color transforms would be out of place in an ACES workflow, which is a true linear light/scene referred environment, and in which the gamma and color matrixing is done by the RRT.

Deanan, did I get that right?

 

[jake blackstone]

I believe everything is ignored except for exposure (and, by definition, FLUT setting), color temperature and tint. The normal Red gamma and color transforms would be out of place in an ACES workflow, which is a true linear light/scene referred environment, and in which the gamma and color matrixing is done by the RRT.

Deanan, did I get that right?

It would make sense, as otherwise, they would have to have multiple IDTs for multiple combination of Color and Gamma settings. That would, in itself, greatly simplify the workflow, as it would force everyone to be on the same page.

 

[Blair S. Paulsen]

Does anybody know the data rate for IIF compliant half-float OpenEXR in 4K res at 24fps?

IIRC 4K DPXs at 24fps are around 1.2 GBytes/sec (just shy of 10Gbits/sec).

Thanks - #19

 

[M Most]

Does anybody know the data rate for IIF compliant half-float OpenEXR in 4K res at 24fps?

IIRC 4K DPXs at 24fps are around 1.2 GBytes/sec (just shy of 10Gbits/sec).

Thanks - #19

A 2K half float OpenEXR file, with no compression (compression is an option, but possibly not in the IIF variant, which is optimized for real time playback capability) and a single layer, is about 18MB. 18MBx24fps = 432MB/sec. 4K would be 4 times that, or about 1.7GB/sec. That may not be completely accurate, but it's probably a good working number.

 

[Gunleik Groven]

Thanks Mike.

We (Norwegian Broadcasting Corp and general film projects I am working with) have also landed on a redlogFilm/Redcolor as the "defrault" startingpoint for most of our online, and 3k openEXR for all VFX work.

Really happy with these developments.

And - I guess because I am wording myself clumsily - and because we haver been discussing file-formats a bit earlier on - I was not clear enough about what I really like about the idea - which is the standarized transforms from one master to different color-spaces.

Great to know that resolve supports this. Stuff to dig into when I come back to work.

Thanks for the additional info!

Cheers

Gunleik

 

[M Most]

Thanks
Great to know that resolve supports this.

Any program that 1) processes in floating point, and b) supports input and output 3D LUTs can support an ACES workflow. It helps if the program also understands OpenEXR, but it's not required for ACES compliant processing.

 

[Gunleik Groven]

Having thought a bit more on this, it should be possible to output a "ACES compliant" signal out of the Rocket live? Which would ommit the need for a transcode in Resoolve?

Or am I getting way off here?

BTW - and on another note:
Seeing the Sony and Epic 4k screenings was really mindbogling.

Obviously the Sony is not finished, especially the colometry looked not like it was done yet, which the Sony reps confirmed, while the Epic looked utterly gorgeous.

And as I will never afford an F65, I am utterly thrilled about the powers that will be made available to me. )

Seeing those images, makes the time that has gone and the delays totally worthwhile.

Good times!

Cheers

 

[Nick Shaw]

Having thought a bit more on this, it should be possible to output a "ACES compliant" signal out of the Rocket live? Which would ommit the need for a transcode in Resolve?

I don't think the Rocket can output floating point in real time. Deanan?

But when rendering in Resolve or (anything else) it should certainly be possible to implement an ACES compliant workflow direct from the R3D files.

I am very interested in the possibilities ACES opens up. My only real concern is that if cameras and film stocks are profiled to such an extent that you are working with truly "scene referred" image data then you would be "dialling out" the characteristics of a particular film stock or camera, which are part of the creative reasons for choosing that camera or stock. In reality I'm not sure if that level of profiling is possible, as cameras are not scientific scene measuring instruments (and nor should they be IMHO) but the way the ACES spec is written makes it sound as if this is the ultimate intention.

I would be very interested in Mike Most's thoughts on this.

 

[M Most]

I don't think the Rocket can output floating point in real time. Deanan?

But when rendering in Resolve or (anything else) it should certainly be possible to implement an ACES compliant workflow direct from the R3D files.

That's the way it's usually done, as a live pass through from native, conformed files.

I am very interested in the possibilities ACES opens up. My only real concern is that if cameras and film stocks are profiled to such an extent that you are working with truly "scene referred" image data then you would be "dialling out" the characteristics of a particular film stock or camera, which are part of the creative reasons for choosing that camera or stock. In reality I'm not sure if that level of profiling is possible, as cameras are not scientific scene measuring instruments (and nor should they be IMHO) but the way the ACES spec is written makes it sound as if this is the ultimate intention.

I would be very interested in Mike Most's thoughts on this.

It doesn't really work that way, even though I can understand why one might think it would. Camera characterizations do not really dial out the camera/optical system "signature," they reverse engineer the actual values to determine what was shot. It's a little hard to describe, but easy to see. Suffice it to say that I had the same concern at first, but after seeing quite a bit of footage, I would say that the concern proved a bit unfounded. If anything, I'm finding myself a bit more bothered by the use of the same rendering transform (the RRT) being used for all footage, which quite frankly does impose a bit of a similarity. It yields a very accurate interpretation, but you don't always want that. Of course, that's what grading is for...

 

[Ian Vertovec]

The goal seems to be to homogenize the look to a particular look as a starting point. Then in grading one has to potentially fight the baked in intent to get to the creative destination. Instead of going from raw to destination, you're going from raw to a common look and then grading. All the pushing and pulling in the 3D luts really is not good as 3D luts are lossy by the nature of their imprecision.

I have to admit this has concerned me quite a bit as well. It's like saying 5219 is the best film stock so now DP's are only allowed to shoot with that.

 

[mikeburton]

The goal seems to be to homogenize the look to a particular look as a starting point. Then in grading one has to potentially fight the baked in intent to get to the creative destination. Instead of going from raw to destination, you're going from raw to a common look and then grading. All the pushing and pulling in the 3D luts really is not good as 3D luts are lossy by the nature of their imprecision.

I was wondering the same. Also correct me if I'm wrong here but, if you want to work with ACES/IIF workflow isn't this an extra transcoding step? I could see how on large VFX shows this workflow would have its advantages same way working with LOG DPX's is now to keep colors and gamma consistent throughout the pipeline but in the case of a less heavy VFX show for example wouldn't you be better off working from the source itself ie R3D's? Standards on the whole can be nice if everyone is educated in the format enough to make good use of its strengths but this workflow doesn't seem feasible for most of the shows I work which aren't VFX crazy ie no more than 50-100 shots on average. Is there another reason I should be using this instead of working from the R3D's? Doesn't sound like it yet but I'm interested in being convinced if the argument is compelling enough

 

[Gunleik Groven]

I have to admit this has concerned me quite a bit as well. It's like saying 5219 is the best film stock so now DP's are only allowed to shoot with that.

Well.. initially I kind of can see where that fear comes from, but in practicality: Not.

As long as the fileformat bitdepth exceeds what is available from the camera (in r1s case 12 bit linearlight vs 16 bit float) the only thing which is baked in is the debayereing...