Welcome to our community

Be a part of something great, join today!

Register 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 workflow tested and verified?

Note there is now a newly-modified implementation of ACES in Resolve 12 with Display-Referred and Scene-Referred color Management. I'm curious to see how well this will work with different camera workflows within a single project, and if it overcomes some of the roadblocks we've had in the past. Their explanation:

Resolve Color Management(RCM) and ACES are both Scene Referred color management schemes designed to solvethe same problem. However, if you’re not in a specific ACES-driven cinema workflow, DaVinciResolve Color Management can be simpler to use, and will give you all of the benefits ofcolor management, while preserving the the same “feel” that the DaVinci Resolve Colorpage controls have always had.
 
We were playing around with the Resolve 12 beta on Thursday. It sure does crash a lot. Anyway, we were feeding a PRM4220, set to dynamic and PQ. We had resolve set to 750 nits PQ mode. It was pretty cool.

I am not a Resolve user, so I don't know the ins and outs, but the color space and gamma setting on the Red settings page were disabled. All of the other settings were enabled.

Marc, have you done an grading with an ACES pipeline yet?
 
What is a bit intriguing is that there is
Not a single educational video on Aces
Workflow from A to Z done by people who know
What they are doing when we can find even high-end compositing tutos, advanced color tutos etc...
There are a few intents, most are or amateurish
Or pros that are over-complicating everything and
Don't really seem to know much better.

This big silence is very strange.

Parenthesis on Resolve 12, the big question I'm asking myself
Is this: On one side I applaude the all-in-one stuff.
It surely will serve many users.
Now...how much heavier is it compared to 11 for just
Color? That's the dilema.
I do not want to cut in that to be honest. It's good enough
For sure but runnin Avid and LW and LW with the console
And the intrface implementation is just another planet when
It comes to editing.
So is it still suitable for color only? Mmmmm....?
?

Close parenthesis cause not really the thread.
 
Last edited:
ACES is a colour space (or two), a standard (set of renderings and transforms) and a system, but it's not in of itself a workflow. That's where the 3rd parties who support ACES as part of their system come in, and define workflows with their software with ACES helping on the interoperability.

Graeme
 
But then, and sorry being a bit philosophical,

We have camera makers who want to be specials, have their own signature and it's normal.
And we have post prod who want maximum standardization, wich is also normal.
But both desires are contradictory and this
Industry has been inmerged into a holy mess for decades. No other industry I can think of has been so caotic.

Aces IMO is a very welcome proposal to
Unify both camera makers and post prod
Requirements.
Let's face it, cinema DNG will not bite so much, look what happended in still.
Phase wants to have their special sauce, Hassy wants the same. DNG doesn't sell.
So the only way was a system like Aces.

But...if now it's third party workflow dependant, it means that the holly mess will be in the software industry itself.
Resolve will sell its Aces, Scratch its one, and all workflows will be differents according to software brand?
So in the end, what was thought to erradicate a mess that lasted too long, will
End in a different type of caos??
 
Interoperability and standardization doesn't actually lead to homogenization and reduction of the "specialness" of cameras or grading tools or whatever. What such standardization does is allow you to clearly see the real differences rather than the more cosmetic differences.

However, for long enough those interested in colorimetry and colour science and interoperability of images have been able to reference linear light and XYZ, and from there, it's all just math to whatever space you want things. But also for long enough video cameras have had all manner of tonal and other processing that kept you far away from linear light data and that was not because it was deliberate, but because they recorded (traditionally to a physical media) a processed ready-to-view output referred video signal. So what that means is that the real breakthrough here is not ACES, or linear light XYZ, but cameras recording RAW that allow the user to define the processing and not have it burned into stone at the point of recording. That is always why we don't go the IDT route but directly transform the RAW data into ACES. Other cameras get you to back-track from their video or log decodes in their chosen colour space all the way back to linear light XYZ, and then from there to ACES. That works, but I don't see it as the optimum way to do things.

Graeme
 
I've been learning a lot all along this thread. Thanks guys.

Great infos!

I agree Graeme, big part of the mess came from processed output signals.
I'm not a big fan of house's lut dependant workflows.
Red did it right to use Cineon standart as the RLF. I applaude.
No weired things. Just the raw, a cineon log and a s curve as a facility if
We need it. Stability and predictability.
The redgamma(s) by the way are easy to isolate and picture in post by simply disabling the rlf itself so it's easy to picture their impact above the linear so we can see what they do.
In the end, Red is dead logic and transparent.

But Aces seems to puzzle almost everyone apart from the scientists and the most advanced dits and color artists. Even in the high-end, I've been following debates where old foxes were confused or contradicting each others and doing sort of "color engineering" experiments.
How do I know it was color engineering? Too complicated!
When it's complicated, it's suspicious.

And for new recruits like me, I was watching all the ww mess on Aces and thought: "what the hell is that?"
Looks not ready.

Now it's clearer. Thank to you guys.
 
fred gasc said:
But Aces seems to puzzle almost everyone apart from the scientists and the most advanced dits and color artists. Even in the high-end, I've been following debates where old foxes were confused or contradicting each others and doing sort of "color engineering" experiments.
How do I know it was color engineering? Too complicated!
When it's complicated, it's suspicious.
Click to expand...
Nothing like a good old FUD, right?
It's all about ACES implementation. If software manufacturers are lazy, then yes, ACES can be puzzling.
On the other hand, companies, like FilmLight, ACES implementation is stupidly simple. It just requires two steps:
Step 1. Declare your desired working color space- ACES, ARRI wide gamut, Rec-709 etc
Step 2. Set your monitoring- P3, Rec-709 etc.
Baselight will do the rest for you. You can mix and match different cameras and Baselight quietly will apply correct IDT, if it needs it, to the correct camera automatically. If you do something stupid, Baselight will gently advise you how to remedy it, but if you insist on being stupid, it will do it's best to minimize the damage. If you need multiple deliverables, again, Baselight will do the proper color transforms for you. Unlike other software manufacturers, Baselight even allows you to manipulate working color spaces on a layer by layer basis. So, if certain tools doesn't work correctly, you can transform to a necessary color space, apply the effect and on the next layer you can go back to a working color space.
Easy enough for you?
 
Baselight does indeed make use of ACES easy because Baselight is very well thought out with regards to colour management. But ACES in of itself is not easy to understand, not least because it's so new (yet so old - many years in development) and even the terminology the Academy use with respect to ACES has changed quite a bit (no more mention of IIF for instance - ACES now refers to colour space and system), and with the push to the 1.0 release a lot of new (and necessary like ACES CC, AP1) changes were implemented which are not represented in the blogs and articles writing about ACES from the previous couple of years.

Graeme
 
Graeme Nattress said:
ACES has changed quite a bit (no more mention of IIF for instance - ACES now refers to colour space and system), and with the push to the 1.0 release a lot of new (and necessary like ACES CC, AP1) changes were implemented which are not represented in the blogs and articles writing about ACES from the previous couple of years.

Graeme
Click to expand...

This is exactly what I was trying to say.
The already little and confused infos circulating are NOT updated.

And finding the right nodes for ACES CC (in-out) where?
In OCIO? Can't find them.

The Academy only provides
Tech sheets.

Jake, I certainly agree that a well thought implementation is making life easier.
I love Baselight, I had the chance to try it and really is a superb software. But Baselight*full featured is currently out of my range.

Is it easy enough for me? In what you described, yes!

But....this can also be a trap. I make the // with car. Basically what you said is that this car thinks and if I don't know how to drive it would take the decisions for me. And then, if I insist in driving crap, a lady voice would pop saying "warning, you're stupid" and if still insisting the
Nice lady voice would say "you're f....g ignorant"
Etc...but what I want is to learn how to drive, even if a software takes
The rights decisions.
And that means to strip all the parameters and trying to fully understand every single step.
I don't want to ride a KIA.
That's why this thread.
 
And that's where things
Get difficult.
I've been in Nuke, Fusion forums,
It's the absolute caos.
Someone says A, then another says B and a third pretend A and B are ignorants
Because it's C.
Like the Who"s song changing a word: "mess reign on me"
 
If I find updated links, I'll post them here.
 
Here is another flame tutorial that explain how to work in a scene linear color space for compositing, He is for good reasons not working / composting in ACES. But the film shows quite well what luts are need and how they need to be applied to be able to jump/roundtrip between linear an ACES.

To me the flame way of handling the color transforms makes most sense. Wtih the options of destructive luts on import, soft luts within clips and then color management nodes that can hold stacks of luts and also create reverse luts and keep track on them. And then also very importantly being able to apply monitor output calibration luts for each and every screen and on top of that have the toggle switch for lin log or video for each screen.

I think even if you are not using flame this little film is quite easy to grap and apply in resolve or what ever your choice of software is.


And this tutorial shows the exporting part of it all:

 
I must admit that I find that video confusing. Using the term "colour space" to cover both linearity (scene linear, logC, video etc.) and primaries (ACES, sRGB, REC709) is probably not the best way to describe things. The concept, of course, is great - transform all media into a common working colour space, adjust linearity as appropriate for the task at hand (linear light for compositing, log for grading etc.).

Graeme
 
Graeme Nattress said:
I must admit that I find that video confusing. Using the term "colour space" to cover both linearity (scene linear, logC, video etc.) and primaries (ACES, sRGB, REC709) is probably not the best way to describe things. The concept, of course, is great - transform all media into a common working colour space, adjust linearity as appropriate for the task at hand (linear light for compositing, log for grading etc.).

Graeme
Click to expand...

Possibly a bit confusing. But personally I think thats the only way to do get things right. As I see it doing composting in Log is not right. All transfermodes keys etc works best in linear. Then as you very often need to do your compositing upstream from the grade the only way to do so correctly is to roundtrip to from log to lin and then back again and then further down in the node tree do the grading in log while looking at a screen correct signal in REC709 or ACES or what ever while the material actually is log. And by doing so have a graded rendered log file that can be pushed out in multiples to what ever colorspaces with different "primaries luts" One for TV, one for web, one for cinema and so on all coming from the "native" log file.

But yes the terminology in the video is a bit flameish I have to agree.
 
Certainly defined transforms back and forth between linear light and log and a video output stage at the end is the way to go. I just wish they had used clearer terminology to describe it. A few years back so many people were using "linear" to mean "not-log" or "video gamma" that we all had to get really explicit and say "linear to light" to make ourselves clear.

It's also somewhat confusing to refer to every transform as a "LUT" even when it's either a math function or matrix transform behind the scenes. I know that use of language is common place, but I see a LUT (be it 1,2 or 3D) as an implementation or interchange of a transform rather than what the transformation is in of itself.

Graeme
 
Spot on Stacey! That misuse of Lin to mean video gamma has been one of the most confusingly bad uses of terminology I've come across and I've had meetings where you ask what you think is a simple question but have to go back to the start and careful define out terminology because the answer you were given made no sense!

Graeme
 
Graeme Nattress said:
Certainly defined transforms back and forth between linear light and log and a video output stage at the end is the way to go. I just wish they had used clearer terminology to describe it. A few years back so many people were using "linear" to mean "not-log" or "video gamma" that we all had to get really explicit and say "linear to light" to make ourselves clear.

It's also somewhat confusing to refer to every transform as a "LUT" even when it's either a math function or matrix transform behind the scenes. I know that use of language is common place, but I see a LUT (be it 1,2 or 3D) as an implementation or interchange of a transform rather than what the transformation is in of itself.
Click to expand...
I agree, and terms like this do get thrown around far too much. The LUT has to be defined, so ideally it would actually be called a "Rec709 LUT."
 
You must log in or register to reply here.
Back
Top