This is very cool. I really like the UI and overall approach.
You can check out (if you haven’t already) the GLSL conversion of ACES 1.1
ACES 1.2 OFX Plugin also exports DCTLs, so that might also be worth checking out (for comparison’s sake)
1 Like
I didn’t build a specific IDT DCTL for Magic Lantern Raw (which is automatically converted to ACES anyway) but I did build a set of tools for better working with the images, in particular the LMT_DNG_OFX DCTL
The images I worked on came from a hacked 5Dmk3 (some of them were dualiso).
@rivertim I am glad to help. I haven’t use the Magic Lantern Raw before during my work, but I did some investigation on this and you might try the setting shown in the attached image file.
Then use the Davinci ACES plug-in to convert from ACES to ACEScc. It is best if you can send me some dpx file in Magic Lantern Raw (just grab a still in Davinci and export this still in dpx format) via email or in this community so that I could figure out a clear workflow for Magic Lantern Raw.
Thanks for the response! Your plugins are awesome and used by many of my colleagues. I really love the LMT part ACES TOOLS you create that provides more precise controls of sat and hue compared with the tools in Davinci Resolve.
Hi Paul. Thank you for your toolset – they are amazing; I’m only just starting to get my head around them. 
I shall pay extra attention to the LMT_DNG_OFX DCTL now. [quote=“Paul_Dore, post:6, topic:2566, full:true”]
(which is automatically converted to ACES anyway)
[/quote]
I see… Do we knowing exactly what spectral data Resolve is using to do this? So does it not require any IDT at all? Have you seen @sdyer great tests gathering SS data here from amongst others 5DMk2, and Mk3? Could this be used to create an even more accurate IDT/DCTL?
PS You might also see a post from me in the ML forum on your Resolve thread. 
Thanks so much Tommy. I will send you the .dpx file. Should the Resolve Colour settings be anything special to grab the still from?
@sdyer Would it be ok if I sent @tommyzenth a still from your 5D3 tests? If so, which would you recommend?
Hi Tommy
You are really great
This tool is very helpful for colorists without programming knowledge
There is a doubt at the moment and I hope to get your answer
I tested IDT DCTL with ARRI and RED
Found that the conversion value
Deviation from the official PDF of ARRI and RED
I do not know whether it is caused by operational reasons
Below I provide screenshots generated by the IDT DCTL tool.
And the official PDF screenshot
@Dean thanks for the valuable response! I am to check it to see whether it is caused by program systemic error or other reasons.
Continuing the discussion from ACES IDT DCTL Generator:
If there was a guide of Davinci color management setting for Magic Lantern Raw, that would be the best. I think the default setting is sufficient as the Davinci will do the de-bayer process automatically. The question is that I am not sure what colorspace it cope with Magic Lantern Raw to my knowledge.
@tommyzenth Hey. ML Raw files from the camera (.mlv) are not read directly by Resolve. They have to be made into dng using a choice of apps/methods. So Resolve is just ‘seeing’ dng. Resolve does a pretty good job of debayer-ing into ACES without any specified IDT, but it would be nice to know exactly what is going on during the automatic process, and whether a custom IDT might improve the process?
@rivertim Got it. This may means the ML IDT process is done by the certain app that could be a black box. Or the colorspace infromation could be found in the documentation of that app.
@Dean I noticed that in the screenshots, the adaptation method used is not correct. The ARRI needs to use CAT02 adaptation, not Braford. You will get correct conversion with CAT02 method 
. (There is a small info text line beneath the gamut select option UI, maybe I need to highlight them). However, I still see some deviation at .00005 to .0001 range. I would like to keep check it out.
@tommyzenth If I understand correctly maybe Resolve uses the standard transform for Adobe DNG and then into ACES AP0 > ACES cc/cct Maybe you could add this into your app as a source? I believe it is published data. https://wwwimages2.adobe.com/content/dam/acom/en/products/photoshop/pdfs/dng_spec_1.5.0.0.pdf
@rivertim thanks a lot. The document is quite informative and I think the gamut it uses is CIE XYZ and the gamma could be linear or canon c-log. The adaptation method is Braford. Given these cues, I am able to build options for Adobe DNG.
Also, I found a interesting post that validates this document about ML RAW IDT you’d like to see
@rivertim I added a testing CIE XYZ gamut and a linear option for gamma. Please refresh the tool page and feel free to play.
@tommyzenth Cool! Thank you so much. Did I miss the Linear option in the second dropdown? I couldn’t see it? I refreshed a few times.
EDIT Ah, I see the problem. It is there, but the bottom of the list is getting visually cut off by the css. Just needs a tweak to padding?
PS Is it possible for the app to take a dng sample as well as dpx? I can’t get a ‘clean’ dpx from the source dng without baking in some transform – unless someone knows how!?
Thank you very much and look forward to your news
@Dean I’ve found the problem and it is very interesting.
For Arri, the reason is that if I use the provided ACES primaries and white point ([0.73470,0.26530,0.000,1.000,0.000,-0.07700,0.32168,0.33767,0.0]) to calculate ACES(AP0) to XYZ matrix, the precision of the matrix is low compared to the matrix presented in the ACES P-2013-001document. As a result, I directly use the XYZ matrix shown in ACES P-2013-001document with the CAT02 method, I got the exact same transformation (even higher precision) as the Arri official document. (I have updated the tool)
@sdyer I think a more accurate ACES RGB primaries should be provided to make all the calculations consistent.
As for RED, there is a very tiny deviation at ~0.00002 precision caused by the Bradford matrix, as I only got 4digit precision data of the Bradford matrix. The deviation will be fixed if I find a Bradford matrix model with higher precision.
@sdyer I also found a very interesting point about the white point D65, the CIE xy data of D65 is
[0.3127, 0.3290] and its XYZ value is shown as [0.9504, 1.0000, 1.0888] on every document I found. However, when D65 xyY is converted to XYZ value mathematically, it can never be [0.9504, 1.0000, 1.08883]. It is not a precision issue. I am not sure what’s going on here.
Hi,
The primaries are what they are and they should not be changed, ever 
Likewise, the Bradford matrix is given at 4 digits and that is what you will find everywhere, should you change it for something more precise, and you would never match other sources.
The CIE xy values for D65 is not [0.3127, 0.3290] but [0.31272, 0.32903] as given in CIE 015:2018 Colorimetry, 4th Edition. The rounded value at 4 digits is the one used by virtually all the RGB colourspaces using D65. You will, unfortunately, find many variants depending on the source of the data.
>>> import colour
>>> colour.xy_to_XYZ(colour.ILLUMINANTS['CIE 1931 2 Degree Standard Observer']['D65'])
array([ 0.95045593, 1. , 1.08905775])
>>> colour.xy_to_XYZ([0.31272, 0.32903])
array([ 0.95043005, 1. , 1.08880649])
>>> colour.sd_to_XYZ(colour.ILLUMINANTS_SDS['D65']) / colour.sd_to_XYZ(colour.ILLUMINANTS_SDS['D65'])[1]
array([ 0.95046506, 1. , 1.08897024])
>>> colour.sd_to_XYZ(colour.ILLUMINANTS_SDS['D65'], method='Integration') / colour.sd_to_XYZ(colour.ILLUMINANTS_SDS['D65'], method='Integration')[1]
array([ 0.95046532, 1. , 1.08897069])
>>> colour.HUNTERLAB_ILLUMINANTS['CIE 1931 2 Degree Standard Observer']['D65'].XYZ_n / colour.HUNTERLAB_ILLUMINANTS['CIE 1931 2 Degree Standard Observer']['D65'].XYZ_n[1]
array([ 0.9502, 1. , 1.0882])
The important thing is to be aware of it and accept the fact that there will be precision issues.
Cheers,
Thomas