Canon Input Device Transform (IDT) files are published on the following websites. Set “OS Version” to Windows 7, and select the “Software” tab to see them.
Could anyone tell me how I might get DaVinci Resolve to ingest and use a new .ctl file or IDT? There doesn’t seem to be any documentation on how to do it. Specifically I want to use the .ctl file for the C100 Mark II.
Thanks
RS
Although you can download all of the IDT‘s for various Canon cinema cameras from their website, I also cannot find any information on how to get these input transforms into Resolve – I’m looking everywhere and really can’t find anything – I think the ACES workflow might be the answer to many of the shortcomings I’m finding with other workflows but the lack of information is really frustrating.
Resolve does not support adding custom IDTs so that they appear in the drop-down with the built in ones. It also does not support CTL directly.
But you can manually convert CTL code to Resolve’s DCTL, and apply custom IDTs using that. I converted the ALEXA EI800 IDT in that way, and provide it via my website at no charge as an example of CTL to DCTL conversion. I also have a few other converted IDTs available there at $30 each, for those who don’t feel up to doing it themselves, but that does not include any Canon ones at the moment.
I don’t I’m afraid. I don’t believe the Z-Log curves are published anywhere. I’ve only ever seen Z-Log to display-referred Rec.709 LUTs, which don’t help with making an IDT.
If I wanted to learn the process of accurately creating log to log DTs in the future what sources would you recommend looking into?
Currently working as a data manager doing onset dailies colouring so this is definitely of some interest to me but I can’t seem to find out where to start.
I believe that the working group will be updating that documentation shortly, among other things adding a description of the process for creating an IDT for a “black box” camera, i.e. one for which information about its encoding is not available.
A while ago I also talked about ZLog2. I didn’t get very far but your best bet is to download their LUT package you can convert ZLog2 to ACEScct, from there you could use other transforms to get to the space you want. But as Nick said, I don’t think Z-Log2 is documented anywhere publicly.
I hadn’t seem those LUTs. I don’t see an ACEScct LUT in the package, but there is one called zLog2_ACESAP0_64_noGain_normal.cube, for example. But the output of that is clamped at 1.0, so it is not suitable for use in an IDT.
In the second download link in the right column: Z CAM LUTs V1.8 you’ll find a different set. There is a huge list but amongst it are zlog2_ACEScct_33_normal.cube and a 64 size one. Z-Cam is definitely not the most elegant when it comes to colour workflows…
I realise this is an old thread, but I’m wondering if we can get some statement as to the source of the primaries in the current IDT: CSC.Canon.CLog3_CGamut_to_ACES.a2.v1. It seems to be consistent with a CAT02 interpretation of the Canon-published IDT for the camera in ‘daylight’, but I’m wondering why Canon’s ‘tunsgten’ IDT appears to have been overlooked (e.g. IDT.Canon.EOSC700_CanonLog3_CinemaGamut_TypeE_Tng.a1.v1.ctl which you can find at https://www.usa.canon.com/support/p/eos-c700-gs-pl).
I was not the one who did the porting and staging of the IDTs as CSCs in the new structure, so I’m not sure if this was intentional or just an oversight. If it wasn’t done intentionally, then I’ll open a PR to add them back.
I thought the current Canon Log 3 Cinema gamut IDT might originate from the CSCs that I made. But looking at the history, it seems Canon wasn’t included in that, I guess because I had no official source of a white paper. The primaries match those in this paper.
Also, is there a reason why the ctl lists its own transform ID as urn:ampas:aces:transformId:v2.0:CSC.Canon.ACES_to_CLog3_CGamut.a2.v1 while in the transform.json file it shows as urn:ampas:aces:transformId:v2.0:CSC.Canon.ACES_to_CLog3_CGamut.a1.v1. Which ID should I be using AMFs?
This discrepancy was previously reported and identified as a typo that has been fixed and had changes pushed to the aces-input-and-colorspaces repo but not reflected in transforms.json.
As of now transforms.json reflects the transforms that are in the most recent dated snapshot release. But the TSC has been talking about how we can improve clarity to users and implementers on how they should interpret the aces bundle vs the head of the sub-repositories containing component types. Right now head of each sub repository reflects the latest changes, but those changes are not tracked at the package level until a new release is made on aces.
We know it’s complicated, that’s why we’re trying to make it clearer without adding more levels of complexity. If you have any comments or suggestions on what type of information would make this more logical to you, please post it here or send your thoughts directly to any one of the TSC members.
