I purchased about a year ago a Canon EOS C300 mkiii for my production company which I often use with a Canon Cinema Gamut and a Canon CLog2 gamma. but I can’t find a way to use an Aces workflow for color grading in DVR with it because I can’t find a proper IDT or LMT for this particular camera/setup.
At first I thought that it was because the camera was still a pretty new model, but then I realized that the EOS C70 model that came after the C300mkiii was already updated in the Aces workflow
This is the main reason why i finally choose DWG as my default working color space but I really would like to give it a try within an Aces workflow to learn more about it and get familiar to the process in case i need it for any specific project outside my usual workflow.
The answer i would give my self is, if DWG is already working, stay there then, but is not my goal in order to study and learn more about Aces and make myself more resourceful in the professional color grading process
I hope you could help me with this issue
Hi William, welcome!
I’m not too familliar with Canon cameras regarding ACES IDTs. It seems like there are a lot of them!
But I do know that DaVinci Color Managed doesn’t do anything with IDTs the way ACES does. So if in RCM you pick Canon Cinema Gamut/Canon CLog2 it’s just one and the same for any camera that shot in this color space.
So what you could do is roll a custom ACES setup via nodes and use a CST as IDT as first node to convert from camera to ACEScct and turn off the tonemapping but leave White Point Adaptation on.
Then with timeline set to ACEScct the color space aware tools will still behave as expected.
You can also check if the current listed C300mkii IDT is the same and pick daylight or tungsten accordingly. I honestly find interesting that all those cameras have their own entry when the encoding color spaces are the same. Maybe someone else can explain why this is. This isn’t the case with Sony or RED camera’s AFAIK.
I agree this was confusing but is being changed. They map their individual cameras into a common encoding, so you can use the ‘generic’ IDTs that do the conversion from that encoding to ACES. In truth most of the individually labeled IDTs were identical in the code and differed in title only. This simplification might not yet be reflected in the Resolve menu, but should be over time. I honestly haven’t checked yet to see if the list has been reduced, but having 100 or so IDTs to pick from was super confusing for users and in future updates should be just the “core” IDTs for Canon Log 2/Canon Log 3 and Cinema Gamut/BT.2020 Gamut
So @casiquetoro, if you’re using Canon Cinema Gamut and a Canon CLog2 in camera, then use the IDT for Canon Cinema Gamut and a Canon CLog2.
See aces-dev/transforms/ctl/idt/vendorSupplied/canon at dev · ampas/aces-dev · GitHub
(Note that C300 MkIII is supported)
Thanks Scott for clarifying!
This is currently what the Canon list looks like in Resolve.
There is no ‘generic’ IDT with just the primaries and transfer function but I guess he can use the C300MKIII instead then?
thank you guys for taking the time to help
I’m currently running some test both on RCM and ACES to see where differences are, I’ll try to keep you updated with the results and share some stills
regarding the C300mk2 and mk3 compatibility subject, there are major changes in both sensors, the c300mk3 has a new technology called DGO (Dual Gain Output) that allow the sensor to capture two reading per frame so they can put together a highlight dedicated and a shadows dedicated reading in a single HDR 16+ stops image with low noise, similar to how Arri sensors work. but I don’t know if this changes could really translate in perceivable changes within the same gamut and gamma. in that case would be the C70 Canon camera the more close to how the sensor works (also works with DGO)
so that is why i am not sure if the other cameras IDT’s could be a fix to this
@sdyer I’m definitely going to run tests with those IDT’s you just shared
thank you guys again!
That sounds impressive. It is ‘irrelevant’ what the sensor is capable of in relation to the stored data though, in the sense that it will be limited by the encoded bit depth and transfer function (if recording to integer format in log). From what I can read CLog2 can store up to 16 stops of dynamic range so it sounds like you’re good on that.
Don’t think it matters which one you pick as IDT. The CLog2 transfer function is just the same on any model. It’s not bound to the sensor. Hence the cleanup Scott mentioned.
So thank you guys! you both were right! @Shebbe @sdyer
i test every camera model with Canon Cinema Gamut / Clog2 IDT and I got the same results every time within ACES
Then I tested an ACES and DWG transformation pipeline trough CST nodes as @Shebbe suggested and I got a similar result but with a different histogram distribution (I think because ACES’s RRT and RCM’s DRT functions but not sure)
This is the RCM result
[type or paste code here](https://www.icloud.com/iclouddrive/04esE4IUupD0hzDBIYKD8_AbQ#Untitled_1.6)
and the ACES result
[type or paste code here](https://www.icloud.com/iclouddrive/099kruIMFDV0Wft9czsZPxscw#Untitled_1.10)
Do you mean you compared the rendered result of DaVinciDRT and the ACES Output Transform? Those will definitely look different from each other. That’s expected. But using a CST or an ACES Transform node to go from Cinema Gamut/CLog2 to ACEScct should in theory do the same or at least look the same when viewed both through only DaVinciDRT or only ACES.
Display rendering transforms never really look the same. All models have their own ways and ideas about mapping captured dynamic range and color volume to smaller display ones. In Resolve you can also use IPP2 in RCM. You’ll see that it also has a totally different look to it. There are plenty others and none are really wrong or right, because next to the technical transformations there is a subjective perceptual part to it. How should your 16stops look on an 8stops display? How should a color look that was outside the target display’s gamut? Or colors outside the spectral locus captured with camera’s using virtual primaries?
The beauty of ACES is that it’s designed to serve a full production pipeline from capture all the way to delivery and archival with as minimal image quality loss as possible. This can be a solid reason to want to use ACES. This is not so much the case with RCM which primarily serves the colorist or projects that fully run within the Resolve ecosystem only.
While for a colorist it can be a preference to choose one or the other, the grade is what ultimately should inform the creative intent. The DRT offers the ease of having a perceptually plausible image before even touching the wheels and fairly easy adaptability to different target displays without redoing the entire grade.