ACES...

[David Mullen ASC]

Since ACES finally moves color-correction away from the film-based legacy of 10-bit Log, I would think Red would be excited at the idea.

 

[Graeme Nattress]

There are many good concepts in ACES - the linear light reference, defined wide gamut colour space and 16bit half-float container. Where the concept comes unstuck is the idea of a reference rendering (that imparts a strong "look") for everyone to use. It's like trying to standardize art.

Graeme

 

[M Most]

Yes, the IDT and ODT are just pure math. There's no real art in them, and they're both simple and accurate. It's the RRT that's problematic, and to me, that's the area where the creatives on a project should be taking control first and foremost, and it's not something should even be attempted to be "standardized".

Are you interested in doing such a thing? Seems to me that the industry sees value in having a standardized, effectively unlimited color space for archival purposes and for color manipulation. Your posts sem to indicate that you don't feel it's all that difficult to create a rendering transform that would be more "appropriate" to Red originated footage. If that's the case, perhaps it would be a good project to undertake. I would suspect that Ray and Alex would welcome that level of participation.

 

[Graeme Nattress]

It's not about appropriate for RED originated footage, but about who should be defining a basic rendering of footage. Of course, a camera needs to display a usable image, so we have to do that raw conversion, and we also give people enough control to build their own look for that if they see fit, or give it to them in a neutral version for their own control in grading. Standards are great in technical areas (like the linear light and colour space aspect as defined) but as I mention are problematic in the creative aspects.

Graeme

 

[M Most]

It's not about appropriate for RED originated footage, but about who should be defining a basic rendering of footage. Of course, a camera needs to display a usable image, so we have to do that raw conversion, and we also give people enough control to build their own look for that if they see fit, or give it to them in a neutral version for their own control in grading. Standards are great in technical areas (like the linear light and colour space aspect as defined) but as I mention are problematic in the creative aspects.

Sounds like what you'd prefer is more of a neutral rendering transform for ACES coded images. I agree with that, and have talked to those involved about that very subject. As I recall, you and I talked about it too... ;-D

My own feeling is that things went a bit awry when the RRT became more defined as a "print dailies" kind of approach than as a neutral rendering of the original image based on scene referred color values. It began to drift more towards a one button dailies solution than an unrestricted image container, with the interpretation being less photographic truth and more idealized print-derived image. I haven't talked to them in a while, but I might call them this week and see where things currently are.

 

[Graeme Nattress]

"Sounds like what you'd prefer is more of a neutral rendering transform for ACES coded images. I agree with that, and have talked to those involved about that very subject. As I recall, you and I talked about it too... ;-D" - yup, that would certainly be a help.

The idea of a deep, wide and colourful bucket to store images in is a great one. It's hard not to be behind a sensible replacement to Cineon. However, Cineon (within it's precision limits) has some serious image processing and grading advantages over a linear light approach too, and a well defined log curve is as neutral as a linear light representation.

I have no problem with people saying "here's how we like generalized linear light images developed for viewing", but I place exception upon such a subjective thing being standardized, especially when I strongly think the evidence points to a "one size fits all approach" doesn't work.

Graeme

 

[Nick Shaw]

As I understand it, the ACES committee are working on having an ACES log "working space" precisely because standard grading tools operate in a more intuitive and user friendly manner on log or gamma coded images than linear ones. Various possibilities have been proposed, but no standard has been agreed on yet.

The Baselight ACES implementation simply uses the standard Cineon function to transpose linear values to log ones, leaving the colour space unchanged. It has IDTs and RRT+ODT combinations which convert to and from "ACES log" implemented in Truelight.

I agree completely with the idea that the RRT should be neutral. I guess the issue is how neutral should it be? Arguably the RRT+ODT should do nothing but a gamut map and a gamma curve appropriate to the particular display device, but then ACES really brings nothing to the table except a defined wide gamut colour space. I think their dilemma may be similar to the one RED faced when the first "new colour science" moved from Rec709/Rec709 to RedSpace/RedSpace. The original Rec709 gamma incorporated no tone map curve, being just the pure mathematical Rec709 transfer function, and caused many people to comment that RED images looked too flat. RedSpace/RedSpace imparted an out of the box look, but many felt that was too harsh.

 

[Graeme Nattress]

"As I understand it, the ACES committee are working on having an ACES log "working space" precisely because standard grading tools operate in a more intuitive and user friendly manner on log or gamma coded images than linear ones. Various possibilities have been proposed, but no standard has been agreed on yet." - it's worse than that - some image processing operations suitable for grading use don't work at all on linear light images, and some look radically different. It's not just an issue of scaling and intuitiveness.

"The Baselight ACES implementation simply uses the standard Cineon function to transpose linear values to log ones, leaving the colour space unchanged. " - sounds like a sensible way to do things.

"I agree completely with the idea that the RRT should be neutral. " - should, but even beyond that it's almost as if there shouldn't even be one, unless reference is to mean "example" for comparison purposes.

Graeme

 

[M Most]

I think their dilemma may be similar to the one RED faced when the first "new colour science" moved from Rec709/Rec709 to RedSpace/RedSpace. The original Rec709 gamma incorporated no tone map curve, being just the pure mathematical Rec709 transfer function, and caused many people to comment that RED images looked too flat. RedSpace/RedSpace imparted an out of the box look, but many felt that was too harsh.

If one looks at the ACES pipeline, in many ways it is very similar, if not almost identical, to a typical DI pipeline, particularly a film DI. The IDT puts the image into a proper color space and gamma for processing, creative color grading is done with the data in ACES space, and then the RRT/ODT combination is used almost identically to a display LUT and/or a baked in output LUT for various deliverable targets. In that sense, it could be said that in the DI world, targets have traditionally been either various film print stocks in combination with a particular lab process, or electronic targets like digital cinema and HD video. But if you consider the print stock scenario, stocks have sometimes been chosen because of the pallette they present, and that same print emulation has been used for the video deliverables as well. The ACES RRT has been designed to emulate an "ideal" print stock, but perhaps that in itself can be a kind of starting point to develop various RRT's for different looks, which I think is what Graeme is alluding to. In that sense, it might be useful and creatively desirable to have a kind of RRT toolkit, in which color science savvy software engineers (like Graeme, or my colleague Josh Pines, or numerous others) can create RRT's to represent not only print stock looks, but other things as well. So there might be a "Kodak Premiere RRT", but there might also be a "Redcolor 3 RRT," or an "Arri Look RRT", or even a "Company 3 Teal And Orange RRT." There might even be the possibility of a user definable toolkit, kind of a Magic Bullet RRT Creator. The nice thing about using a standardized color space is that camera differences become less of a technical problem and more of a creative choice, as long as there are IDTs available for the particular cameras that are used. Using different cameras on the same project becomes a creative and practical alternative, which was actually one of the primary impetuses for the development of ACES in the first place.

I have to confess, I find this kind of intriguing....

 

[Nick Shaw]

Presumably the fact that the RRT is subjective is why it has taken so long for it to be developed. As you say, Graeme, the IDTs and ODTs are mathematically defined (except that cameras are not scientific measuring instruments, so have spectral sensitivities for the R, G and B photo-sites on the sensor rather than precisely definable primaries) so the RRT is really the only thing up for debate.

 

[Nick Shaw]

If one looks at the ACES pipeline, in many ways it is very similar, if not almost identical, to a typical DI pipeline, particularly a film DI.

That was my first thought when told about ACES. It's not radically different to what people are already doing, it's just an attempt to standardise it.

 

[M Most]

Presumably the fact that the RRT is subjective is why it has taken so long for it to be developed. As you say, Graeme, the IDTs and ODTs are mathematically defined (except that cameras are not scientific measuring instruments, so have spectral sensitivities for the R, G and B photo-sites on the sensor rather than precisely definable primaries) so the RRT is really the only thing up for debate.

It is largely subjective, but what has added to the development curve is that the many tweaks that have been done to it have created a bit of a rat's nest. At some point, when there is agreement on things that have been constantly adjusted and re-adjusted (green saturation comes to mind.....) my guess is that the transforms will be cleaned up and simplified a bit. But that doesn't necessarily obviate the usefulness of a more open approach.

 

[Graeme Nattress]

I have to confess, I find this kind of intriguing....

The IDT puts the data in a define standard space, but I'd advocate that such a choice for a defined standard is neither ideal nor desirable for processing or creative grading. The more I learn and experiment with image processing it almost seems that there's a different preferred linearity for all image processing operations, and that some don't just "not look right" in some linearities, but don't work at all. Linear is a great unambiguous starting point, but it's just that - a starting point.

For raw development, we take a "parametric" approach whereby each aspect of the look is parameterized and can either be used (over a range of values) or not used. The monolithic nature of the RRT seems very averse to such a paradigm.

"Using different cameras on the same project becomes a creative and practical alternative, which was actually one of the primary impetuses for the development of ACES in the first place." - unfortunately it seems to have gone way beyond such reasonable goals, and firmly into the land of subjective look.

I think a reference RRT is necessary to show that the ACES colour space works for grading + transformation into a target output display, but it's not necessary beyond that as a creative choice. Unfortunately, from what I've seen, ACES to target gamut mapping was one of the major sources of strange colours (no doubt due to the size of the ACES gamut compared to any practical display).

Graeme

 

[Chuck Chae]

Mr.Go and ACES

Mr.Go and ACES

We are doing ACES colorspace workflow for all of our VFX and 3D DI mastering on our next feature as well.
I've been hearing some various different issues regards to it from the post side. I can't share now, but would be able to share some case studies at selected seminars at the trade shows.
Hope to share more when we get close to release our movie 'Mr.Go 3D'
July 2013...

And Of course, Shot on RED - 5K 3D!
Cheers,

http://dexterstudios.com/

 

[Axel Mertes]

I still see a big difference between Cineon approach and ACES.

Cineon is typically 10 bit log or 16 bit linear (the latter being rarely used, though).
Each step in log corresponds in its 10 bit log approach to 0.002 densities above Dmin (the orange film base color).
So in total we have 1024 steps representing 2.048 densities in a negative.
The goal behind Cineon was simply and only to be able to reprint this exact density range to this exact film negative, so that you can digitally manipulate film and later print a negative that matches 1:1 what has been scanned before (thinking of adding VFX elements).

However, that workflow is a thing of the past for productions and since many years.
Further, there is no correspondence to a specific captured color nor the printed result. If you have two different negatives shooting the exact same scene, they may already turn out in different densities, so there is absolutely NO standart it in it when it comes to how to represent a specific color. except that two negatives of the same type and make should be close when all other parameters are identical. And not to forget that only and roughly 0.7 densities of a negative is the maximum you can print into a positive. So only ~0.7 out of 2.0 densities can be really used, the rest will clip into white or black (however, you can move that "used range" more or less freely with your printer settings). So where input color is being placed in output color space is not even close to being specified. The printed positive has a desity range of up to ~4.0, but thats another story.


IMHO, as I understand ACES, the main goal was to MATCH different sources (cameras) to a common, well defined, true world color space. So the idea is to make a perfect connection between a true color in front of the lense and the resulting color in an ACES image file. As each sensor and camera system inbetween is somewhat different, the system should be calibrated to match, the calibration defines the IDT. Secondly, from a well formed working color gamut and real world color space, there could be transforms to various output devices to still have as much as possible matching results. However, real life tells me that colorists always want to push the edges of specific device gamuts, so they would like to grade differently for P3 than for REC709 when a budget is there to do this. That somehow sacrifices the idea from my perspective. But thats an primarily artistic question. The point is you may see gradation in P3 that is invisible in REC709, but the "common" gamut may look identical. Is that the goal?
Or is the goal to have the gradient rendition to give the same feeling, not necessarily the same color, on various devices?

If the choice of the color space in ACES is a good one or not is a different story, but it has definetly a very large gamut, allowing everything needed to be done. One could argue we could have used CIE lab 1931 XYZ space instead, as an example.

Given the above, we still have the issues that ACES will hardly be usable as intended in a archival situation (as you will be simply unable to know what was in front of the lense anymore) and that many devices are simply not calibrated at all.
The calibration process is essential to achieve the goal of camera matching inside ACES. A non-calibrated input device is more or less a free run and one isn't any better with ACES then as with any other format before, except it has potentially more bit depth. OK, you may find indications that could lead to an IDT that gets you somehow close. In turn, that makes ACES just another file and gamut standart, no argueing pro or contra here.

The RRT concept is indeed a bit strange to me. We should not standardise a look, except the real world color that was truely before the lense. How that helps the colorist is a completely different story. Given a working ACES workflow with truely matching input devices, you can add a custom look to whatever material to get the same resulting look - that could be a time saver. So to me ACES is more a thing for the input side of projects than for the real output side.

Matching artificial 3D VFX output needs then to make an IDT that transforms rendered data to match the calibration of the display it was seen on during creation. Unfortunately the gamut of the rendering is way larger than the display we look at...

That all being said, the fact that I should adopt the ACES file format for the pipeline is not always exciting me, because many apps simply don't support it and we need to transcode all over.

Just thinking loud.

 

[Nick Shaw]

I still see a big difference between Cineon approach and ACES.

Cineon is typically 10 bit log or 16 bit linear (the latter being rarely used, though).

I always use 16 bit DPXs for Cineon log material where possible (not all apps support 16 bit DPX). There's nothing that says Cineon has to be 10 bit and only linear can be 16 bit.

As the dynamic range of cameras increases, there is one limit in Cineon that is an issue. With an integer format, Cineon can only represent about 6.25 stops above 18% grey.

 

[Axel Mertes]

I always use 16 bit DPXs for Cineon log material where possible (not all apps support 16 bit DPX). There's nothing that says Cineon has to be 10 bit and only linear can be 16 bit.

As the dynamic range of cameras increases, there is one limit in Cineon that is an issue. With an integer format, Cineon can only represent about 6.25 stops above 18% grey.

Nick, I was pointing to the original Cineon specs, when the files were also called ".CIN" and which was the original format of the Kodak Cineon system filmscanner.

However, the DPX format has been based on the Cineon format. You can store even 64 bit float in it if required. I know only one app that ever did that (Realsoft 3D).

However, what most call the "Cineon" format today is actually DPX 2.0. And there is simply no reference between a specific code value inside and an output color. All you do is you build a pipeline around the format and make your own definition which code value means which color in your environment. That doesn't mean it will look like that on someone else pipeline. One of the reasons why so may play with LUTs that bend the code values to some more specific output device color spaces - which in the end is not far away from a "handmade ACES workflow" - guess you got the point.

 

[Gavin Greenwalt]

I ran some thorough ACES tests in Nuke 6.3 a few months ago and it failed miserably. A simple blue gradient did insane things to the hue. It's all been logged with The Foundry and I haven't retested in 7.0 but until the RRT/ODT round tripping with viewer LUTs is worked out in all of the post tools it seems like a great way to go down a long dark alley before reaching a dead end in its current state.

 

[Gavin Greenwalt]

I always use 16 bit DPXs for Cineon log material where possible (not all apps support 16 bit DPX). There's nothing that says Cineon has to be 10 bit and only linear can be 16 bit.

No you're right but that's the problem: what gamma people deliver DPX files in seems to be completely random. I've gotten sRGB, Rec709, Gamma 2.2, Gamma 1.8, Weird Cineon with different black/white points, AlexaLogC, etc. The nice thing about ACES is that it at least says "look, if you're saving to this file format, transform it back to linear first." That way I don't get calls from the Flame suite "Why is this DPX file all washed out?" "Because it's log." "Oh."

 

[Gunleik Groven]

The in/out phases are where things should work.
And that's really all there should be to it...