this is my first post ever on ACES Central. I´m currently researching for my bachelors thesis in Media
Engineering. As the title already tells, I´m trying to build an IDT using CTL for the Filmic Pro 10-bit Log v3 profile. As i couldn´t find any up to date white Paper about Log v3, i contacted FiLMiC Pro and they did send me one.
Here´s a quick summary about the transferfunction, linearization and HLG conversion.
However, as you can see, the pseudocodes are written in Open GL SL, which unfortunately, I am not familiar with.
After trying around a bit, I came up with this function:
It produces horrible results and is just unusable. Obviously I made a mistake, interpreting the
Open GL SL Pseudocode.
My question is: Can anyone help me to convert from Open GL SL to a “normal” mathematical function, so I can implement it in my DCTL File ? Is it even possible to convert it ?
Oki doki. I’m willing to help but you’re probably going to have to start over as a quick glance at your code shows me that it isn’t valid DCTL so that explains the look horrible part of things. When you feed invalid DCTL to Resolve, it just dumps back the input image at ya.
To avoid the kind of mistakes I’m seeing : unmatched brackets, missing multiply operator, I would recommend that you follow the structure of the original GLSL code that you were sent. The only pseudocodey thing about it is that it preprends a "t: " before the 3rd parameter of the mix function and that makes the code invalid GLSL. Also, while DCTL supports a 3-component vector type: float3, I would recommend that you stick with your single float approach and apply the transfer function once per component just like you’re doing in the DCTL file you’ve uploaded. Finally, you might want to know about the following GLSL → DCTL translations :
exp2 → _exp2f
pow → _powf (but you already knew that one)
mix → _mixf
I see that you also have a 3x3 matrix transform in your code which is not mentioned in the white paper. Protip for debugging DCTL : debug one thing at a time. Otherwise, an error somewhere else in the code might make Resolve bork and dump the input image back at ya without any helpful error message.
@jmgilbert Thanks a lot for your tips. Appreciate it really much! The 3x3 color matrix I implemented should transform from BT. 709 to ACES AP0. However I took another look at the metadata of my Log v3 footage and realized that the color model is YUV instead of RGB. Do I have to convert from YUV to RGB first, before transforming to ACES AP0 or does Resolve do any conversions “under the hood” ?
FYI My Timeline is set to Rec. 709 without RCM as I´m building the ACES Pipeline with the use of Color Nodes.*
Thankfully no! As for the primaries being BT.709, I see that is what your video is tagged with but are you sure that is what the native colour space of the camera is? Notice that the video is also tagged as using BT.709 transfer characteristics. I don’t believe there’s a tag for Filmic Log Pro transfer characteristics anyway Also, tags are just that tags, i.e. hints for applications about what to do with the file. They can be right or they can be wrong but if they’re wrong then the video will be decoded incorrectly but, in some cases, it’s fine especially if the proper set of tags doesn’t exist or if the video isn’t meant for final delivery
And for a Y’CbCr format, the only tag that should affect anything is the matrix coefficients. Since there is no special Y’CbCr matrix for Filmic, the fallback is pretty much always BT.709 for HD resolution or above. So Resolve will convert to R’G’B’ for you using the BT.709 matrix, and assuming the tag correctly represents how it was encoded, the Y’CbCr encoding will be correctly inverted, and you will have the correct R’G’B’ data to convert to ACES2065-1.
So I´ve done some testing and was able to write a DCTL, which doesn`t produce horrible results like my first try but still has some way to go as you´ll see in this post.
@jmgilbert@nick Thank you again for providing me useful information. I was able to implement all of this into my DCTL. It turned out that _mixf doesnt exist/not defined. mix() performs a linear interpolation between x and y using a to weight between them. The return value is computed as x × (1 − a) + y * a.
With that in mind I was able to convert the GL SL Code to a valid DCTL operation. I implemented the DCTL into the ACES Transform folder and it “worked”. My logical next step was to evaluate the results. Since I don’t own a ColorChecker, I know that i have to be careful about a serious evaluation. Hence this should be seen as some kind of amateur -ish test to point me into the right direction about my next steps.
Filmic Pro delivers a free deLOG LUT that transforms to Rec 709
My first approach was building a very simple ACES Pipeline that just uses the ACES Transform OFX. IDT was my DCTL transforming from Logv3 to Linear and from Rec. 2020 to ACES AP0 and the ODT was set to Rec 709.
IDT: Filmic Pro Logv3 to ACES AP(0)/Linear ODT: Rec 709
As you can see the image lacks an overall dynamic range and saturation. It´s too flat overall.
My next approach was to build a DCTL file that I can use as a LUT outside of the ACES transform Node.
So I wrote a DCTL that does nothing but linearizes my footage to look step by step where my IDT isn´t correct.
Logv3 to Linear LUT followed by a Color Space Transform that transforms from Rec 2020/Linear to Rec 709/Rec 709
I´d say that this approach provides me more dynamic range but still lacks of contrast and saturation.
The almost same approach but instead of transforming to a Rec 709 Gamma, the footage gets transformed to Rec 709(Scene) as my timeline is set to, provides me with way better results:
Logv3 to Linear LUT followed by a Color Space Transformation that transforms from Rec 2020/Linear to Rec 709/Rec 709(Scene)
So far so good. Now comes a very interesting approach - at least for me. I took another look at the white Paper and in Chapter HLG Conversion which I kinda overlooked as I was using Log v3 and not the Filmic Pro HLG they write:
"On Apple devices, dynamic tone mapping can make strict linearization challenging. Assuming typical conditions, LogV3 can be converted to an approximation of Hybrid Log Gamma (HLG) with a function derived from the following pseudocode:
In my understanding, if you are using apple devices, you are not able to linearize the footage. The only way is to go from Log v3 to HLG and then from HLG to Linear ? Does that make sense ?
Anyway I tried to write a DCTL file that transforms from Logv3 to HLG and then used the HLG to Rec709 LUT provided by Filmic Pro to evaluate my DCTL. And this is the result:
DCTL that transforms from Logv3 to HLG + Filmic Pro LUT HLG to Rec709
It looks way better. I know that the LUT from Filmic Pro shouldn’t be my master reference in evaluating my DCTL files but I like to think of it as some kind of a first reference point.
My main questions:
Am I missing something when transforming from Logv3/Rec 2020 to Linear/ACES AP0 or why does it look that flat after the transformation. Does the lack of dynamic range come from the different gammas ACES and Filmic Pro are using for Rec 709 ?
Is there any DCTL that linearizes HLG footage and if not do I need to pay attention for anything special happening in HLG?
Here’s a link that grants you acces to the video itself + the Filmic Pro LUTs if you are interested in testing it yourself:
I’ve only briefly looked at your DCTLs, but they seem reasonable to me.
Bear in mind that a LUT is often designed to have some degree of finished look “out of the box”, whereas with ACES an IDT + RRT + ODT is only a start point. Although it is intended to look reasonable, it is also designed to be relatively neutral, to give you the flexibility to sculpt your own look in grading.
The linearization function for HLG is described in ITU-R BT.2100, so I see no reason that you should not be able to combine the Logv3 to HLG function with the BT.2100 HLG inverse OETF in a single DCTL.
However, since their documentation describes a transform to “an approximation of Hybrid Log Gamma” this may be designed for a more display-referred HLG workflow, and not be suitable for ACES.
I’m not a pro at this but looking at your results gives me the idea that, whilst you might be successful in linearization or converting the file’s colorspace to scene space, the results are very “yellow” compared to using their provided LUTs because the step to actually converting the sensor (or filmic log created?) primaries is still missing. Just like an ARRI camera captures log in Arri Wide Gamut / LogC but stores a rec.709 tagged file.
Maybe you can ask FiLMiC Pro about this. They might have some matrix to go from filmic to rec.2020 or rec.709.
@shebbe Thank you for the input. I contacted FilmicPro and hope they can answer the question.
Since I was busy the last weeks submitting another paper, I finally had the time to go back to this IDT. As @nick already suggested, I tried to implement the in ITU-R BT.2100 described EOTF in the same DCTL after converting the Log v3 function to an approximation of HLG.
As you can clearly see, the image offers way more detail and doesn`t seem yellow-ish at all like the 1st version. It´s a way better “starting point” for color grading operations. Here´s a direct comparison of both results ( left side: version 2.0 / right side: version 1.0 )
I still have some questions about constructing this IDT the right way:
As written in P-2013-001Recommended Procedures for the Creation and Use of Digital Camera System Input Device Transforms (IDTs)
the required and most common optional responsibilities of an IDT are six-fold: linearization, white balancing, clipping, color analysis, neutral chromaticity difference compensation and encoding
as ACES RGB relative exposure values.
How would I implement clipping in this IDT?
Does this IDT miss anything else?
I am not sure if I am handling this technically correct, as I never did this before. Even though I am quite optimistic since the “look” I get out of using this IDT seems correct.
If I would like to evaluate this FilmicPro Log v3 IDT, would it be a reasonable option to compare it with a colorchecker and a camera, that already has a valid IDT (like Sony or Panasonic) ?
Hola buenas
Disculpe mi inexperiencia o poca sabiduría
Estoy en busca de cómo hacer un color space transform de un fílmico pro log V2 a rec709 no se si sea apropiado usar el lut de fílmica o algún otro método para sacarle el máximo potencial a mis archivos de celular
Hola @marcelo.miranda.puen
My Spanish is pretty bad, so I have to answer in English. If you only want to convert from Filmic Pro Log v2 to Rec709, you can definitely use their own LUT. You will probably find that the final image will be very saturated and have a slight green cast. If you want a more subtle starting point, you can create your own LUT or DCTL.
Also, tags are just that tags, i.e. hints for applications about what to do with the file. They can be right or they can be wrong but if they’re wrong then the video will be decoded incorrectly but, in some cases, it’s fine especially if the proper set of tags doesn’t exist or if the video isn’t meant for final delivery 
