ACES IDT for Dragon

[Gabriele Turchi]

a while ago (might have changed) I thought that the issue in resolve ( about red and ACES) was about the IDT not properly working with ISO different than 800 , like if the linear light transfer happened before the SDK decode and always expected 800 iso ...

 

[Gunleik Groven]

a while ago (might have changed) I thought that the issue in resolve ( about red and ACES) was about the IDT not properly working with ISO different than 800 , like if the linear light transfer happened before the SDK decode and always expected 800 iso ...

That would not be an issue with the current files (and I cannot really understand why that should be an issue at all...) as we shot at 800.

 

[Gabriele Turchi]

That would not be an issue with the current files (and I cannot really understand why that should be an issue at all...) as we shot at 800.

it was an issue for sure , images that were exposed for 300 iso they would come up super bright in ACES , images that were shot for proper exposure at 800 they would come Ok in ACES. As i said it might have changed since ( i have not tested it in months).

and i was not referring to you tests ..i was referring to genera Resolve- RED issue ...

g

 

[M Most]

That's not necessary. It is perfectly possible to implement using options which are already in the SDK, plus transforms which are known and published.

I just simulated this in Nuke, and can get a near perfect match to REDCINE-X "use ACES" EXRs, direct from the R3D.

But unlike many people, including some who want to conduct tests, you understand all of those parameters and how to use them. My suggestion was to make that functionality available to civilians directly in Redcine X and via the GUI that most people seem to want to use.

 

[Gunleik Groven]

But unlike many people, including some who want to conduct tests, you understand all of those parameters and how to use them. My suggestion was to make that functionality available to civilians directly in Redcine X and via the GUI that most people seem to want to use.

Not meaning any offense here, but I smile and agree...

 

[Scott Crawley]

But unlike many people, including some who want to conduct tests, you understand all of those parameters and how to use them. My suggestion was to make that functionality available to civilians directly in Redcine X and via the GUI that most people seem to want to use.

That is the whole point of ACES anyway, right... to take the need for everyone to have a Nick Shaw out of the equation? ;-)

 

[Gunleik Groven]

That is the whole point of ACES anyway, right... to take the need for everyone to have a Nick Shaw out of the equation? ;-)

Do not say that!

Nick is one of the image-guys I appreciate the most.
I can very much understand why he does not post a lot. But I will always need his input!
Even if things "just work" to the extent that I do not have to understand "how"

 

[Nick Shaw]

But unlike many people, including some who want to conduct tests, you understand all of those parameters and how to use them. My suggestion was to make that functionality available to civilians directly in Redcine X and via the GUI that most people seem to want to use.

I wasn't thinking of end users building their own colour space transforms, but rather that application developers can use the existing SDK to get linear float ACES image data from R3Ds without the need for intermediate EXR files.

That is the whole point of ACES anyway, right... to take the need for everyone to have a Nick Shaw out of the equation? ;-)

Wait, the purpose of ACES is to stop me making a living! I didn't realise I was such a threat ;-)

 

[Brad Hawkins]

Do not say that!

Nick is one of the image-guys I appreciate the most.
I can very much understand why he does not post a lot. But I will always need his input!
Even if things "just work" to the extent that I do not have to understand "how"

I think he means that not everyone has access to Nick's level of knowledge/expertise (or someone like Nick), not that they those people should be done away with, but rather that they are a rare breed. Thus ACES makes it simple for the rest of us, (or at least simpler).

 

[Scott Crawley]

I think he means that not everyone has access to Nick's level of knowledge/expertise (or someone like Nick), not that they those people should be done away with, but rather that they are a rare breed. Thus ACES makes it simple for the rest of us, (or at least simpler).

Yes Brad, thanks. Sincerely. I think they know that is what I meant.

Wait, the purpose of ACES is to stop me making a living! I didn't realise I was such a threat ;-)

No it is because there is not enough of you to go around. ;-)

 

[Gunleik Groven]

Yup. Nick and Graeme and M Most are a rare breed. I only feel fortunate when I sense some of their knowledge and I can only appreciate when i can chat with them.

 

[Brad Hawkins]

Yes Brad, thanks. Sincerely. I think they know that is what I meant.





No it is because there is not enough of you to go around. ;-)

Yup. Nick and Graeme and M Most are a rare breed. I only feel fortunate when I sense some of their knowledge and I can only appreciate when i can chat with them.

Exactly! :thumbsup:

 

[D Fuller]

I love when Graeme posts facts on Reduser - I wish he posted more often - but I suspect he's a busy guy these days

I hope he is! ;-)

 

[Bruce Allen]

That's not necessary. It is perfectly possible to implement using options which are already in the SDK, plus transforms which are known and published.

I just simulated this in Nuke, and can get a near perfect match to REDCINE-X "use ACES" EXRs, direct from the R3D.

Awesome! Sounds like all we'd need then would be a whitepaper from RED on this confirming your steps as the "official" solution.

Or do what Mike Most says - eg have an option to make the SDK just provide linear light ACES directly.

But it sounds like you're saying that can be done already. Just needs to be made friendlier.

RED is friendly and awesome in general. Graeme posts here, which is fantastic. I don't see Sony or Canon's equivalent of Graeme chatting with users on their forums! However it would be nice to have some friendly "official workflow" information here. In that regard, the others are ahead a bit with their PDF whitepapers, IDTs, LUTs, and other acronyms

Bruce Allen
www.boacinema.com

 

[Blair S. Paulsen]

IDTs in practice

IDTs in practice

This sure seems like a great opportunity for RED to sort whatever issues stand between R3Ds and optimizing their usage in ACES pipelines. A situation where people have to create ginormous mezzanine files is not going to be very popular.

FWIW, if properly implemented (and we may be a couple more RRT revisions away) a viable R3D IDT would open up workflow options, including a much simpler path for multi-format shows.

There has been much discussion about base ISO - why we need it, why it's meaningless, etc. Does the core equation built into IDT creation require a fixed ISO? Logic tells me it likely does. If RED likes 800ISO as default, how is Resolve (or any other similar tool) supposed to deal with whatever ISO is in the metadata? Ignore it? In a "pure" two step process where the metadata created during capture is tossed and replaced by new metadata (updated RMD) during "RAW development" (virtual darkroom) this seems like the simple path. Of course a lot of shows utilize the camera generated metadata as a way for the DP to communicate intent to the colorist and perhaps the holy grail is to do this "development" step prior to opening the file in Resolve/Scratch/Baselight in an ACES compliant IDT.

If the IIF IDT format can deal with variable ISO settings, how would that play in terms of hitting the RRT "benchmark" values that are the key to the whole IIF/ACES concept? Unless I'm missing something, creating an IDT for any capture device would require a reference ISO (or its equivalent) in the formula...

Cheers - #19

 

[Adrian Jebef]

This sure seems like a great opportunity for RED to sort whatever issues stand between R3Ds and optimizing their usage in ACES pipelines. A situation where people have to create ginormous mezzanine files is not going to be very popular.

FWIW, if properly implemented (and we may be a couple more RRT revisions away) a viable R3D IDT would open up workflow options, including a much simpler path for multi-format shows.

There has been much discussion about base ISO - why we need it, why it's meaningless, etc. Does the core equation built into IDT creation require a fixed ISO? Logic tells me it likely does. If RED likes 800ISO as default, how is Resolve (or any other similar tool) supposed to deal with whatever ISO is in the metadata? Ignore it? In a "pure" two step process where the metadata created during capture is tossed and replaced by new metadata (updated RMD) during "RAW development" (virtual darkroom) this seems like the simple path. Of course a lot of shows utilize the camera generated metadata as a way for the DP to communicate intent to the colorist and perhaps the holy grail is to do this "development" step prior to opening the file in Resolve/Scratch/Baselight in an ACES compliant IDT.

If the IIF IDT format can deal with variable ISO settings, how would that play in terms of hitting the RRT "benchmark" values that are the key to the whole IIF/ACES concept? Unless I'm missing something, creating an IDT for any capture device would require a reference ISO (or its equivalent) in the formula...

Cheers - #19

Well not necessarily as all digital cinema cameras that shoot raw like the DRAGON or ALEXA or F65 only capture and record what they can at their respective Base ISO / Sensitivity / DR. Development ISO is really just a transform that uses this Base exposure as a start point. I could be wrong but I believe ACES is attempting to map multiple devices into a linear space not a log-encoded space? If we stay linear we basically stay native or raw. It's when we go logarithmic or gamma-encoded that we need additional transforms that may or may not be ISO developmentally specific.

 

[Blair S. Paulsen]

AFAIK IIF/ACES does use linear values. I assume that part of what an IDT does is fix a reference value like 18% grey at a known point on the scale with all other values proportionally distributed.

I think of "development ISO" as part of a processing step done in a tool like RCX-P and could conceive of a pipeline where a "virtual darkroom" tool might be used upstream from application of the IDT. For most folks, I'm assuming they would open the R3Ds as written on camera and modified by the IDT before viewing/adjusting.

IMO, a robust IDT for R3Ds that results in a default image from the RRT that the ODT can display accurately in terms of scene referred values is the keystone. That said, without a RRT that can maintain the proper relationships between values across a wide spectrum of source device technologies/types the fundamental utility of IIF/ACES is quickly lost.

Cheers - #19

 

[geoffboyle]

FWIW, if properly implemented (and we may be a couple more RRT revisions away) a viable R3D IDT would open up workflow options, including a much simpler path for multi-format shows.

Cheers - #19

Exactly why I want it

I do a lot of work with multi formats and including a Dragon would be much easier with an ACES route.

 

[Graeme Nattress]

AFAIK IIF/ACES does use linear values. I assume that part of what an IDT does is fix a reference value like 18% grey at a known point on the scale with all other values proportionally distributed.

I think of "development ISO" as part of a processing step done in a tool like RCX-P and could conceive of a pipeline where a "virtual darkroom" tool might be used upstream from application of the IDT. For most folks, I'm assuming they would open the R3Ds as written on camera and modified by the IDT before viewing/adjusting.

IMO, a robust IDT for R3Ds that results in a default image from the RRT that the ODT can display accurately in terms of scene referred values is the keystone. That said, without a RRT that can maintain the proper relationships between values across a wide spectrum of source device technologies/types the fundamental utility of IIF/ACES is quickly lost.

Cheers - #19

The ACES starting point is linear light with scene mid grey at 0.18f. That is what we provide via the EXR output, and it's dependent on ISO as that is what decides which sensor code value maps represents mid grey and hence which sensor code value maps to 0.18f in the linear light data.

Again, just to re-iterate that we don't use an IDT because that is really only necessary for cameras that shoot something "video-ish" that needs to go through special transforms to map back to linear light and then to go through the colour space transforms. Because we take all raw development through a linear light XYZ stage (as it's necessary to do so for proper raw development) we just export that stage with an XYZ to ACES matrix (as defined by the Academy). In this sense there is no IDT.

So what we do provide is the linear light floating point data with mid grey mapped to 0.18f that does result in an a default image through the RRT and ODT that displays as accurately and as nicely as the Academy's math allows for.

Graeme

 

[Mike P.]

If that's the case Graeme, why not create a transform (IDT) that plays nice with the Academy's (apparently incorrect) RRT/ODT/Math? Whether RED's math is right/more-accurate/objectively-correct, clearly there is an issue that the Academy is going to be way slower than RED to rectify… As an end-user, the way I'm seeing it is that RED doesn't see the need to release anything because they're math *should* work perfectly with ACES (but doesn't in practicality), whereas the Academy/ACES is so friggen slow to react/change/correct the problem that the only people suffering from this bs is the end-user (and indirectly RED, because it makes their images look less than ideal under ACES, unless transcoded to massively huge files sizes that take forever to render out… as in, 4k to 6k 16bit EXR files)...

…Or is there a reason for NOT implementing an "ACES-correcting IDT" like other manufacturers? I could see it giving way to even more confusion down the line if the Academy eventually corrects the problem, but to be fair, every other camera apparently has their own optimized IDT anyway...