Welcome to our community

Be a part of something great, join today!

  • 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 workflow?

Christoffer Glans

Well-known member
Joined
Jun 11, 2007
Messages
4,993
Reaction score
36
Points
48
Age
42
Location
Stockholm, Sweden
I've not jumped into ACES workflow yet so I feel a bit fresh in how it all works. Is there someone who could do a crash course for this explaining the whats, whys, wheres, hows of ACES workflow? :001_smile:
 
ACES is a color management system. It allows you to color in one color space , then select another output color space and be able to output that with minimal adjustments.
DaVinci has 2 options DaVinci ACES and ACEScc. DaVinci ACES keeps similar feel to panel control. You select input transform to bring original into ACES space. Red is automatic. Then you select output transform to select what space you are coloring in. If you have a monitor with multiple color spaces like a Flanders and you switch output transform and corresponding monitor colorspace the image should look very similar.
This saves a lot of time when you have to deliver multiple formats, cinema, HD. UHD, HDR, web. You can also output a ACES archive format from which you can make any future format without loss. And Effects can work in ACES to avoid clipping any color info.
 
Coming from regular grading in traditional rec709, what does this mean for me in practice? If I switch to ACES color, I would first need to have the monitor calibrated according to ACES, right? Then grade as normal and just have an output for the color space needed for the delivery? Or can I grade in ACES with my current calibrated monitor with an rec709 output to that screen?

In essence, if I switch to grading in ACES, can I just keep using my current gear and later when I get an HDR calibrated monitor I could just transfer my grade onto that with the correct output?

What are the proper setting changes in Resolve for this? Just so I don't screw things up for me :tongue_smilie:
 
What are you trying to accomplish for the final? What do you believe ACES will give you in terms of advantages?

I'm in agreement with Steve Shaw of LightIllusion, who said this:

The desire to use ACES for any project needs to be fully reviewed and assessed before its adoption, as its use can often prove to be more complex and costly, with no direct discernable benefit, when compared to alternative workflows. ACES is best suited to large productions, that will involve a large number of facilities, with a large quantity of VFX shots.

http://www.lightillusion.com/aces_overview.html

I personally think that ACES has a lot of theoretical benefits, but I don't think they're necessary in the real world provided there's close communication between the DP and the Post team, and the DP is available to supervise and/or approve the final look. The main thing you can get is an "even playing field" between multiple cameras -- say, Red with Canon with Alexa -- but I don't think that happens that often.

I'm sure Scott Stacy will have more to say, since he's the real expert on color science and display technology around here.
 
The desire to use ACES for any project needs to be fully reviewed and assessed before its adoption, as its use can often prove to be more complex and costly, with no direct discernable benefit, when compared to alternative workflows. ACES is best suited to large productions, that will involve a large number of facilities, with a large quantity of VFX shots.

Now, this here is why I'm confused. I read everywhere that it's more complex and costly but isn't this just a color handling/color space? How can that be more costly? If I grade R3D material in ACES using Resolve and have a rec709 output for delivery and ACES output for archival, how can that be more costly? My main purpose on why I want to use ACES is to be able to archive projects to later be finished in 4K HDR when that is a more adopted standard by audiences and viewers.

This is why I find ACES confusing, on one hand it's supposed to be just a color management system and on the other hand it's costly and complex?
 
My understanding is that ACES is a very large color space, one that goes beyond the visible wavelengths, while most colorspaces are limited to less that what our eyes can resolve.

Shouldn't this in practice mean higher data rates, and less banding and the certainty that within your post workflow you won't lose any image data?

How much bigger is a ACES encoded file than, say, one in REC709 or P3?
 
My understanding is that ACES is a very large color space, one that goes beyond the visible wavelengths, while most colorspaces are limited to less that what our eyes can resolve.

Shouldn't this in practice mean higher data rates, and less banding and the certainty that within your post workflow you won't lose any image data?

How much bigger is a ACES encoded file than, say, one in REC709 or P3?

That's my thinking as well and it would explain the "more costly" argument. But as you way, at the same time it would in theory mean more possibilities to push the grade without breaking the image, while keeping a master of the finished grade that is much more future proof. I cannot see any reason not to go with ACES for everything other than projects that will only be viewed once by an audience.
 
Now, this here is why I'm confused. I read everywhere that it's more complex and costly but isn't this just a color handling/color space? How can that be more costly? If I grade R3D material in ACES using Resolve and have a rec709 output for delivery and ACES output for archival, how can that be more costly? My main purpose on why I want to use ACES is to be able to archive projects to later be finished in 4K HDR when that is a more adopted standard by audiences and viewers.

This is why I find ACES confusing, on one hand it's supposed to be just a color management system and on the other hand it's costly and complex?

You're right, It's just couple of color management settings...
 
ACES caches are uncompressed 16 float, often EXR.. so they are bigass files if you have a feature film's worth of them on your array, and ht array has to be fast enough to play them back at 24fps

that's an expence to be considered, and workflow as well if (like i have today) , one has 3 diffrent features in ACES all on my array at the same time.. 48-96 Tb is reasonable and workable, less than that and you may have to do some data juggeling

Gradeing controls work diffrently in ACES, i tend use filmstyle controls anyway; exposure / contrast / pivot arather than the video style; lift / gamma / gain controls, and find them a better fit when working in ACES for me

you set the ODT to match your mon...
 
ACES caches are uncompressed 16 float, often EXR.. so they are bigass files if you have a feature film's worth of them on your array, and ht array has to be fast enough to play them back at 24fps

that's an expence to be considered, and workflow as well if (like i have today) , one has 3 diffrent features in ACES all on my array at the same time.. 48-96 Tb is reasonable and workable, less than that and you may have to do some data juggeling

Gradeing controls work diffrently in ACES, i tend use filmstyle controls anyway; exposure / contrast / pivot arather than the video style; lift / gamma / gain controls, and find them a better fit when working in ACES for me

you set the ODT to match your mon...

Reasonable calculation. But what is it that differs exactly in how you grade? Using the Resolve tools as a reference point? I use the traditional lift / gamma / gains as well as curves, the VS-tools and normal qualifiers?
Wouldn't a rec709 video output conversion solve dealing with ACES calibration? Meaning I could keep my rec709 calibrated monitor for now but grade in ACES ("internal")
 
Reasonable calculation. But what is it that differs exactly in how you grade? Using the Resolve tools as a reference point? I use the traditional lift / gamma / gains as well as curves, the VS-tools and normal qualifiers?
Wouldn't a rec709 video output conversion solve dealing with ACES calibration? Meaning I could keep my rec709 calibrated monitor for now but grade in ACES ("internal")

yes, set your display to match your ODT

the video style Lift/Gamma/Gain are written for a display refered workspace, so they are written to deal with 7-9 stops of incomeing dynamic range, and ACES with say a Dragon has 16 stops of dynamic range to modify.

Working with exposure (offset in Resolve), contrast and pivot controls means you are not working inside a pre-defined idea of what the ranges are, and in ACES the range is absolutly massive given a high dynamic range camera like Dragon or Alexa, far beyond what the tv broadcast engineers thought woudl be possiable when they defined the ranges LGG controls work in decades ago

Filmstyle controls are not bounded by such limitations, they are somewhat crude and basic in Resolve, as it has it's roots deeply set in video gradeing, but the minimumal tools are there, Baselight and Nucoda are much (MUCH) better in this regard tho.

Curves are something i rarely use anyway, so i can offer little experience with them, and when i do use them it tends to be at the end of the node tree or layer stack so the image is already normilised for display, i see no big diffrences in those tools

Keyers are working ok for me when needed in ACES, but again this is after normilasition nodes or layers. i often use LGG at the end of a tree or stack for fine tweaks, but the heavy lifting is done with flimstyle tools
 
One of the advantages of using ACES, is Resolve can tag the material automatically (you can always manually help, if necessary metadata is missing) which by assigning proper IDT transforms it into a linear light into the same ACES gamut as per ACES specs. Once that is done, theoretically, any grading tools with any material should work the same way, regardless, if it's video, log or linear. Well, that is the theory:) In reality is not quite so. The new Basegrade tool in Baselight does those transforms going IN and OUT of that tool and that is much closer to that promise. Said that, neither Resolve color spaces nor Baselight Truelight color spaces is exactly what academy had in mind. And that is why, if desired, both systems can be used with standard ACES and ACEScc. And if there is any difference in cost, I'd say, using ACES timeline, you will see cost savings, as all your material can be tagged automatically, so there is no need for manually assigning IDTs or in non ACES timeline proper LUTs and multiple deliverables from the same timeline is another huge time saver, which is again in non ACES timeline will fall back on using LUTs and trim passes.
 
Marc Wielage said:
I'm in agreement with Steve Shaw of LightIllusion, who said this:


I am in agreement with both Marc and Steve. And just to re-ask what Marc said, "
What are you trying to accomplish for the final?" If you just want to play around and learn about ACES, seems like a good thing to do. Below are just some random comments. Not sure if they are of value or not.

ACES has two color spaces:

AP0 - A space bigger than XYZ. Not a space you should be doing image processing or grading in, but people do. When you export an ACES EXR from RCP-X, it is in AP0. I believe most apps assume AP0 for input and output.
AP1 - A much smaller space than AP0 and XYZ. Closer in size to BT.2020. This is the space that ACEScc grades in. This is probably the space you would want to do image processing in. SCRATCH, (don't laugh jake! :)) for example, gives you the option of grading in either AP0 or AP1. I suspect other apps are the same. It is important to know if you are in AP0 vs. AP1 when performing image manipulation. Hopefully the apps are doing the right thing here.

One might wonder if we already had XYZ and 2020, why did we need AP0 and AP1. I don't know the answer to that myself. I do know that 2020 does not fully encompass P3. When you convert P3 into 2020, the tip of red can go negative as it is outside of 2020s gamut. I believe AP1 does fully encompass P3.

I think the idea of getting all of these various cameras, with who knows what EOTF type transfer function, into a common space (scene refereed linear light in this case) is a good idea, at least on paper. ACES is built around OpenEXR, which is a wonderful file format. A 6k Weapon frame is around 100 MB in a .exr. You want fast I/O for reading and writing exr files.

Gary Adcock is a great resource for ACES questions, but I don't believe he is on RU. Blair and I briefly discussed ACES at NAB. It was more like me asking Blair if he knew of projects actually using ACES. :) To go out on a tangent, this years ACES hat, handed out at the colorist mixer, is nicer than last years. :)


 
SCRATCH, (don't laugh jake! :)) for example, gives you the option of grading in either AP0 or AP1. I suspect other apps are the same. It is important to know if you are in AP0 vs. AP1 when performing image manipulation. Hopefully the apps are doing the right thing here.
Baselight and Daylight allows you to work in many color spaces beside traditional AP0 and AP1, such as Arri wide gamut, Red RLF, Sony S-Log, Panasonic V-Log etc. I also happened to think, that grading in huge color space, like AP0 or in very small color space, like Rec-709 is not the best idea, unless it is Rec-709 material to be graded in Rec-709. On the other hand, working in all these scene reffered color spaces is much more natural and they are more easily manageable in respect to the out of gamut errors. And if that doesn't quite work, Filmlight just introduced a new gamut tool in Baselight 5.0, that can help to get rid of those error with a simple slider. Additionally, as we discussed at NAB, they also introduced an idea of RRT families, where you can change white point in one deliverable and the rest will automatically follow.
Basically, FilmLight works really hard to take all this complexity out of colorists hands, while hiding all those crazy transforms. All you need to do at the beginning of the session is to declare the working color space- ARRI wide gamut, Red RLF, Sony S-Log, then you need to select what monitor you're grading on- Rec-709, P3, XYZ and Baselight will attempt to automatically identify the correct camera and apply correct IDT to it. From the creative point of view, again, you can choose from a number of RRTs- Arri photometric, various ACES versions, Film and some others. I prefer Photometric. When you delivering, all you need to do is to select the deliverable format- Rec_709, P3, DCI etc and Baselight will again automatically apply the correct transform. The good news, Baselight has a wonderful gadget called Color Journey, where it will show you every color transformation during grading from the original format all the way to display. It will warn you if there are issues, that needs attention and will actually suggest ways to deal with those issues. And if that is not enough, you can use color transformations on a layer by layer basis, which can help with some particularly difficult cases. All in all, this system can be a huge time saver and as a side effect, because Filmlight does all the heavy lifting behind the scenes, I feel, that Baselight or Daylight can actually create higher quality images, rather than utilizing various LUTs.
 
All in all, this system can be a huge time saver and as a side effect, because Filmlight does all the heavy lifting behind the scenes, I feel, that Baselight or Daylight can actually create higher quality images, rather than utilizing various LUTs.
I am a big fan of the TrueLight Colour Spaces system in Baselight, and there is no doubt that when transforming between different high dynamic range colour spaces is far less potentially destructive to do it mathematically, as TCS does, rather than with LUTs. However bear in mind that the ARRI photometric transform in Baselight IS a LUT, as are the other DRTs, including the ACES ones. There is not a problem with using appropriate LUTs, used appropriately.
 
I am a big fan of the TrueLight Colour Spaces system in Baselight, and there is no doubt that when transforming between different high dynamic range colour spaces is far less potentially destructive to do it mathematically, as TCS does, rather than with LUTs. However bear in mind that the ARRI photometric transform in Baselight IS a LUT, as are the other DRTs, including the ACES ones. There is not a problem with using appropriate LUTs, used appropriately.

Of coarse you're correct Nick, but my understanding that this was done for purely practical reasons in saving computer resources and at some point it is planned to be changed to a transform.
 
Of coarse you're correct Nick, but my understanding that this was done for purely practical reasons in saving computer resources and at some point it is planned to be changed to a transform.
The ACES RRT was done as a LUT because it was more efficient to do so as that way. The ARRI photometric transform uses a stock LUT from ARRI, but it is in fact quite simple to implement as a GPU shader (I have shown FilmLight my own GLSL version of it) so it may well move over to that at some point.
 
Are ODTs beeing used for monitoring device art only (sRGB, P3 or YXZ for example), or are there different ODTs for different models too...like camera manufacturers with different IDTs for different camera models?
 
Back
Top