Christoffer Glans
Well-known member
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:
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: this_feature_currently_requires_accessing_site_using_safari
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.
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?
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?
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")
Marc Wielage said:I'm in agreement with Steve Shaw of LightIllusion, who said this:
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.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.
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.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.
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.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.