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

Thanks Geoff. There is no *new* IDT because there's never been an *old* IDT. We don't use an IDT because we take care of properly transforming the camera data to linear light with the Academy's colour space. We were recently made aware that Resolve does its own thing with regards to extracting linear light floating point data from our camera that looks very different from our linear light output. I can only assume that any IDT that Resolve uses is of their own design and any issues with it are in their hands. That said, this is not good for end users such as yourself who expect things to work correctly so we're taking steps to ensure that you'll get a correct result. I don't think that will be ready for your tests which means that you must use RC-X.

Graeme

I love when Graeme posts facts on Reduser - I wish he posted more often - but I suspect he's a busy guy these days :)
 
Well both Canon & Sony have supplied new IDT's to ACES recently and they are a great improvement over previous ones

Good for them! But as we retain full reference to the scene referred linear light raw data through the recording and R3D format, the major part (a linearizing curve) of any IDT is irrelevant for us. As we also reference XYZ internally as our common colour space for all colour space transforms, and as ACES coords have not changed, there is little to do there in terms of mapping the camera to the ACES primaries. The only reason we'd change this math is if it's wrong. There's no "artistic" element to it, so I'm unsure why an IDT would get improved or look better?

I don't know why Resolve has gone off and made their own route for R3D footage, but as I said, we've taken some steps to rectify this. What I appreciate is you telling me about this so that I can do something about it!

Graeme
 
Hi Graeme, we are happy to implement new matrix maths in Resolve if you supply them, as we have done for a number of other vendors.

Geoff, you can also generate compressed exr in resolve from the r3d so at least the exr size is not hugh.


All, current Resolve release complies with the current Academy RRT and there are now a number of user selectable matrix/lut selections supplied with Resolve.

We also support log Aces.

Peter
 
Peter, it's not matrix math that you need to implement. I'll drop you an email!

Graeme
 
Quite! There's a tonne going on.

Graeme

Graeme can you pleas tell us if there dis going to be anytime soon a new ""dragon Gamma" and Dragon Color""" or if the much talked ""new color science"" is something that happen in camera ( sensor calibration level). It has been said that you were finishing tweaking the color science since NAB .

...so at this point i am wondering if the big color science improvements comes from ones that happen IN CAMERA or , if new color matrix and gamma curve will be released soon for RCX and SDK and if will change a lot the color performance ...

thanks

g
 
What is wrong with the Dragon colour performance that requires a change?

Graeme
 
What is wrong with the Dragon colour performance that requires a change?

Graeme

i haven't said that there is anything wrong that require fixes. I am saying that there is still a lot of talk about """"...and wait when the new color science will be released """" . We ( many ) tough that the new color science also means ""NEW DRAGON COLOR and NEW DRAGON GAMMA""".

but i assume that is not the case, and the color improvements from dragon comes from the sensor calibration. I asked you specifically to shut down those wrong rumors about ""NEW DRAGON COLOR and NEW DRAGON GAMMA""" (that will change the image considerably ) coming out anytime soon .

thanks
 
Colour science refers to vastly more than just the labels on things. Most changes occur behind the scenes and just work without any user intervention or notice.

Graeme
 
Good for them! But as we retain full reference to the scene referred linear light raw data through the recording and R3D format, the major part (a linearizing curve) of any IDT is irrelevant for us. As we also reference XYZ internally as our common colour space for all colour space transforms, and as ACES coords have not changed, there is little to do there in terms of mapping the camera to the ACES primaries. The only reason we'd change this math is if it's wrong. There's no "artistic" element to it, so I'm unsure why an IDT would get improved or look better?

I have a suggestion, if it's technically feasible. At the moment, the only way to access that is to do an export to Open EXR in Redcine X. While it's true that this gets you what Geoff and others are asking for (once you understand the "Use ACES " checkbox in the export dialog.... ;-D ) it also requires creating an intermediate file, one that is considerably larger than the original compressed R3D file. A good alternative might be to allow for the linear light interpretation in ACES space to be available as a selection in the SDK directly, much like the Redgamma and RedlogFilm selections. As I recall, this used to be a choice, although not ACES specific. Having that as an interpretation selection would solve the problem of inflated mezzanine files, and would definitely make test situations a bit simpler, even at the cost of real time playback performance. Just a thought.
 
I love these threads, these behind the scenes moments, where you literally see Graeme and the Resolve team "meeting up" for a moment, when something needs to be fixed, and then you can tell they've resumed the conversation off-line. But in that flash something happened, and possibly something major got fixed.

Love reduser.
 
Some of our VFX friends spotted the linear light issue in Resolve and told me last week, so I was already engaged on our side to get things in place to deal with it.

Graeme
 
Hi Mark, Geoff and all.

These are the kind of misunderstandings that have previously ballooned. Let's try to keep them down.

Geoff is specifically talking about the IDT (Input Device Transform) which is the first step of an ACES (Academy Color Encoding System) color-workflow.
In an ACES workflow, there are camera-specific IDTs for the first step of the process.

Geoff is not attacking RED or refering to the RED 1, but refers to the current "RED IDT" (edited: according to Graeme "in Resolve"), which is not ideal.
We vaguely touched that base in Bristol.

There is no offense at all in Geoff's request, Mark.

He just asks if there is a less destructive IDT available for Dragon, as the current IDT messes with the signal in a bad way.
In ALL ways this is a very valid request... As many (me including) like the concept of the ACES workflow. ACES is an attempt on standardizing color-transforms for different deliverables at getting a predictable similar output in for different formats.
AND simplifying color-handling in productions that involve different source-material (RED/ALEXA/PHANTOM/GoPro, comes to mind as a natural example), WITHOUT strangulating the signal from any of them. Exactly the perfect tool when you want to compare signals from different cameras, as long as the IDT is non-destructive.

ACES just needs to work for RED sourced material, too. If memory serves me, ARRI has been complaining about the current IDT, too.

As Graeme suggests, it is possible to do it through a workaround, which includes exporting EXRs for ACES in RCX. The catch is that then - all of a sudden, we are not handling R3D-sized files, but rather 16-bit uncompressed RGB UHD files (in this case), which is a bit disadvantageous over the other cameras.

The request is logical and IMHO very legit.

Keep calm and make colors... :)

Geoff knows his stuff, as do you, Mark.

You two represent very different mindsets as to how to create and develop images, though. But the cool thing is that both are available for good results.

I love these posts that explain a conversation between like-minded people that many of us do not understand. Gunleik, you are a REDuser treasure... right up there with Graeme in the explaining dept..
 
Last edited:
I love these posts that explain a conversation between like-minded people that many of us do not understand. Gunleik, you are a REDuser treasure... right up there with Graeme.

I am not and I had misunderstood some... :)

But I was at least in the ballpark that "This is nothing to get upset about"... :)
If you read Graemes further comments, the issue is not new and they are working on it with Blackmagic.

All good
 
I am not and I had misunderstood some... :)

I actually meant "up theire with Graeme in the explaining dept. I consider Graeme to be without peers in re: RED color science and probably in color science in general. You probably already understood that but I just wanted to make myself clear.
 
Last edited:
Here is a slightly off topic question but relevant. If you were to characterize the Dragon sensor how would you generate the full-spectrum test material to shoot? So if were were to create our own IDT could we just point the camera at a calibrated 10bit monitor and ramp through every color to generate a 3DLUT or would the RGB nature of the monitor cause problems and need to do something like use a prism and an extremely high CRI light source to generate a true multi-spectrum test chart?
 
The last chapter of http://www.amazon.ca/Billmeyer-Saltzmans-Principles-Color-Technology/dp/047119459X has a good guide for how to do a colorimetry calibration. (The Amazon preview seems to contain most of the relevant chapter too....) In reality, it's a bit more involved than that as you're dealing with more than one light source, but the idea is the same. Also, the Academy's ACES papers have some notes on colorimetry calibration too.

Graeme
 
A good alternative might be to allow for the linear light interpretation in ACES space to be available as a selection in the SDK directly, much like the Redgamma and RedlogFilm selections.
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.
 
Back
Top