Welcome to our community

Be a part of something great, join today!

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 IDT for Dragon

Mike - Our math does work. There is no issue at all with what we're doing there (checked and double checked with me visiting the Academy multiple times and going through it all with them). There is an issue with Resolve because apparently it DOES NOT use our math. What we're discussing here is not an ACES issue, nor a RED math issue, but that Resolve is not using our math. I've had an email with Peter so that they can use our math.

I know there are various IDTs floating around for RED footage. They don't come from me, and they don't come from the Academy. If the results of using them don't match 100% (which is the issue here) with the EXR ACES output from RC-X then they are wrong.

There is really no-such-thing as an optimized IDT. There are correct IDTs (that map the scene data to linear light and with the correct colour space) and incorrect IDTs (that fail to either meet linear light, or the right grey point, or correctly implement the ACES colour space).

The Academy's RRT/ODT math is not "wrong" per-se, but renders images in ways that can show issues. As such issues are pointed out to them, they work to address them. Early on, for instance, orange on RED footage came out rather noisy. It was not a RED footage issue as our tools rendered those colours without extra noise. The Academy addressed that particular issue in their code, and now the oranges don't render with added noise. But their rendering code is very very complex (go take a look, it's open source) and tricky to debug (hence they've been working 10 years or so on this project).

Does that make the issue clearer for you Mike?

Graeme
 
Yes. My next question; what platform do you guys recommend other than Resolve that currently does all of this correctly?

Conversely, even with Resolve using it's own math, people in this thread are saying that the EXR-method works fine... I'm basically asking if there's a way to avoid going to EXR (staying in r3d -- if only to keep file sizes and transcode time down) whilst using ACES on any platform that still gives a proper/optimal/ideal image.

I wouldn't know the first thing about the math behind ACES, I just really like the idea of taking footage to a post-house that is ACESready, and the post-house having the best/easiest starting point to get the most out of the footage as quickly (and therefore inexpensively) as possible… That is something that I think ACES has the potential for once all it's kinks are worked out.
 
Any platform that produces results identical to the EXR export from RC-X.

Graeme
 
Mike P. said:
Yes. My next question; what platform do you guys recommend other than Resolve that currently does all of this correctly?
Click to expand...

Central in Vancouver did the DI for Elysium using ACES on Baselight. The film was shot on Red. So, there you go...
 
Graeme Nattress said:
There is really no-such-thing as an optimized IDT. There are correct IDTs (that map the scene data to linear light and with the correct colour space) and incorrect IDTs (that fail to either meet linear light, or the right grey point, or correctly implement the ACES colour space).

Graeme
Click to expand...

And sadly, is seems people really don't understand this.
 
Mike P. said:
I wouldn't know the first thing about the math behind ACES, I just really like the idea of taking footage to a post-house that is ACESready, and the post-house having the best/easiest starting point to get the most out of the footage as quickly (and therefore inexpensively) as possible… That is something that I think ACES has the potential for once all it's kinks are worked out.
Click to expand...

Nothing wrong with liking the idea - but just to be 100% clear - you do NOT need ACES to get "the most out of the footage as quickly as possible".
 
in resolve using aces the R3D settings such ISO and WB etc.. are disabled ... is it the case of base light ?

i fought that color matrix and gamma curve would be disabled but perhaps the rest would stay ...

thanks
g
 
Gabriele Turchi said:
in resolve using aces the R3D settings such ISO and WB etc.. are disabled ... is it the case of base light ?
Click to expand...
In Baselight 4.4, colour space and gamma are locked by default when you choose automatic colour space interpretation (essentially auto IDT). All other parameters are available. But even then you can switch off automatic colour space, and set things manually if you know what you are doing.
 
I'm not sure if this will help, but the present Beta Version of LightSpace CMS will export .ctl files from any LUT, so you can build your own IDT/ODT/RRT etc files.

When partnered with MatchLight IMS you can therefore build IDTs to match to existing cameras, ect.

You can also export ACS CDL .ccc files where they are of use, again extracting the CDL data from any LUT.

Steve
 
Nick Shaw said:
But even then you can switch off automatic colour space, and set things manually if you know what you are doing.
Click to expand...

thanks nick ,
i m not sure tough why would be allowed to keep messing with color matrix and gamma ... isn't that port of the IDT and ODT correct transformation in order to be in ACES space ?

g
 
Gabriele Turchi said:
thanks nick ,
i m not sure tough why would be allowed to keep messing with color matrix and gamma ... isn't that port of the IDT and ODT correct transformation in order to be in ACES space ?

g
Click to expand...
You're right, there is no obvious reason you would need to do it, and the IDT could well start from the wrong place, and therefore end up in the wrong place, if you did.

Nonetheless, I believe as a matter of principle that no professional piece of software should lock the knowledgable use out from overriding any automatic settings. I can't see it ever being relevant with an R3D, but in some situations you may need to override incorrect automatic settings.
 
So, Any ETA of a fix being implemented for Resolve ? Its important to us.

Im deliberately not specifying what form of fix others here are much more expert than me to specify what needs sorting.
 
Dave Blackham said:
So, Any ETA of a fix being implemented for Resolve ? Its important to us.

Im deliberately not specifying what form of fix others here are much more expert than me to specify what needs sorting.
Click to expand...

New SDK went out friday which should help deal with this particular and the EXR issue that was also reported to me.

Graeme
 
I don't write the SDK, so I don't really know about implementation stuff, just the behind-the-scenes math.

Graeme
 
You must log in or register to reply here.
Back
Top