Hi there all the colour scientists!
I am working on a stop motion project, that is shoot on Canon 5D 5K cr2 stills. Last time we have used the debayering of cr2 via CameraRaw and AfterEffects. That works quite nice, we get the sRGB linear EXRs for Nuke compositing and feel quite good. But want to expand more and trying to get a solution to convert cry RAW to linear ACES EXRs. Anyone have a suggestion/experiences doing stills cr2 images to ACES? I know everybody is doing it like R3D to ACES and other RAW camera formats to ACES.

Another part of workflow that doesn't work 100% good is form Nuke linear EXRs to DaVinci DI grading. By now I have created very good LUT in LightSpace to get me the image looking the same in NukeX and DaVinci, but manipulations on image (before or after LUT) are quite bad in Resolve comparing to same similar tweaks (contrast, basic primaries etc) working in Nuke. How do you handle linear EXRs form compositing to DI? Would it feel and work better grading id in log? To export log EXRs form Nuke and grade on log with log-monitor profile LUT in DaVinci? Like we do for film scan projects and similar like Red log and Alexa LogC grading? It "feels" like Resolve is not manipulating colours well with linear inputs?

Thanks to all for some answers!

I will build a 1D lut that is very very dense to use in resolve that will bring the color space from where it is (your EXR) to ACES if you like the ACES color manipulation.

We used a Canon 500 and converted the CanonLog to ACES with a 33x LUT and it was doable (basically we build a custom IDT as input LUT in resolve and setup the shots as [no IDT][3D lut Canonxxxxx] and worked very well. (canon Tap showcase at NAB)

Email the guys at the Academy
There is nothing out in the wild, but a 5Dmk2 RAW IDT does exist.

Basically the process is debayer the CR2s using dcraw (using some very locked down flags), then run that image through the IDT into ACES (after baking the IDT's ctl code into a lut of some description)..

As for Resolve's controls feeling off, it's mainly just a case of the tools needing to evolve. Nuke is designed from the ground up for working in Linear, Resolve has just recently added support and it shows..

Alex, we tried to work in a similar situation but the cr2 debayer in Nuke to linear light was given us a lot of false flashes/flickers. We resorted to go back to AE for the project.

The Idea was to make linear light and do some color space conversion (main project is RedLog/RedColor3) but I think you can manually create a IDT for your case.

Until we find out what is wrong with Nuke i cannot really say that there is an alternative to AE and AE does not particularly like Linear light.

BTW, resolve (like all the other color corrector) convert implicitly ACES to a sort of LOG environment: LogACES/FF23 Log Aces with an 1D or 3D internal math and so forth. Then your controls surfaces are applied to this intermediate image, then the rest:

[ACES image]-[LogACES]-[color correction]-[Inverse LogACES]-[RRT]-[ODT]...[Display]

In nuke, when you color linear light there in no RRT-OTD, is a linear 1D+matrices transformation to your display.
The current RRT used by the manufacturer is based on a "film like" curve and is a mess. The Academy is evaluating a more linear curve for the next implementation (that it will make all the projects done so far stupidly wrong... ;)

Whilst some colour correctors implement ACES this way (Baselight 4.3 for instance), I'm fairly certain Resolve isn't one of them..

For starters, the corrections simply don't behave like they are being applied to the data in a log state. If you take a linear ramp into Resolve as an EXR, apply Gain to it, then render it out again the result is a pure Multiply on your data, which is what you would expect. If gain/multiply was being applied to the data in an intermediate log state that ramp would be bent.

Same thing with Gamma, the result is a straight Gamma function pinned between 0 and 1. if it was being applied to the data in a log state it would be pegged to whatever linear value you are mapping to log 1.

Now you could get this same result if they were storing the data in a log state, then flipping to linear for the correction operation, then back to log again.
But, you can take a file with ACES float values all the way up to 65535.0 in floating point (The limit for a 16bit half-float image), make a correction, and render it out again maintaining those values. If they were flipping to an intermediate log state there would be clipping, with a bone stock cineon curve somewhere like 13.5, with some of the draft ACES Log encodings well up into the hundreds, but not all the way to 65535.0.

I'm not sure what you mean when you say there is no RRT/ODT in Nuke..
When you use ACES in Nuke the display is handled by OCIO, which uses a Log shaper to normalise the floating point data before handing off to a 3D LUT approximation of the RRT and ODT.

As for the current RRT being a "mess", I honestly don't agree. I understand it has a lot of "look" in it, which makes it tough to use if thats not what you're looking for, and I can see why they Academy are working on a more neutral version, but they are also implementing the "look" of the current RRT as an LMT, and I'm very glad about that.

"For starters, the corrections simply don't behave like they are being applied to the data in a log state. If you take a linear ramp into Resolve as an EXR, apply Gain to it, then render it out again the result is a pure Multiply on your data, which is what you would expect. If gain/multiply was being applied to the data in an intermediate log state that ramp would be bent."

That is not my experience: if you setup the Math as ACES the result is not linear as you described... if you use the YRGB it is...

"For starters, the corrections simply don't behave like they are being applied to the data in a log state. If you take a linear ramp into Resolve as an EXR, apply Gain to it, then render it out again the result is a pure Multiply on your data, which is what you would expect. If gain/multiply was being applied to the data in an intermediate log state that ramp would be bent."

That is not my experience: if you setup the Math as ACES the result is not linear as you described... if you use the YRGB it is...

"As for the current RRT being a "mess", I honestly don't agree. I understand it has a lot of "look" in it, which makes it tough to use if thats not what you're looking for, and I can see why they Academy are working on a more neutral version, but they are also implementing the "look" of the current RRT as an LMT, and I'm very glad about that."

My comment on being a mess is due to the fact that it's generate non linearity in the color space that make really difficult to invert if needed, and, on top of it, is changing and evolving: this mean that a project that use the current implementation of RRT will look different when the new one will came in place and viceversa when you will open a 10 year old project for remaster/resoration.

In a LogACE, not all the values will be retained, some will be lost, and in Resolve some of the limitation will be minimized by the internal 32bit math

For Nuke you night be right, i have to give another close look at it. last time I tried i was not getting the result expected, but it might be a combination of bad testing and old version of Nuke. We recently update that to v7, I will check with my color science Joseph (this week I think) and i will let you know.

Quantel for example use a modified version of LogACE for he internal math and I will test that as well...

BTW, i debayered cr2 stop motion in Nuke (from canon i think) and I'm getting consistently flashes: anyone ever experienced that?