Fujifilm F-Log in Resolve without an IDT

Thanks a lot @OwenYou and @nick.

I am glad that I decided to write this post, cause I’ve learnt a lot from it! It’s great to understand the logic behind a software, other than just using automatic processes


I have tested both of your approaches and the result is almost identical. I’m putting it here just to confirm that I’m doing it right.

A question that came to me was “what method to use for Chromatic Adaptation”. On email exchanges with @Attila_Bakos (he developed a DCTL IDT for Fuji), he mentioned that he uses the Bradford method. Any suggestion in particular? or resources to study about it?

Following images for comparison of the results with both approaches (exactly the same results to my eyes and scopes):

Nick’s approach

Owen’s approach



With Attila Bakos IDT:

Thanks to all of you guys.


I believe ACES is using Bradford method, but not so sure about that.

1 Like

Different IDTs use different chromatic adaptation matrices. The ACES default is Bradford, but ARRI for example use CAT02.


The difference is subtle, but I would expect it to be present. D60 and D65 aren’t hugely different. With chromatic adaptation, equal RGB values in the source produce equal ACES values. Without it, equal source values produce slightly cooler whites in ACES. A D65 sim in D60, if you like, the same way the “D60 sim” ODTs produce a warmer white on a D65 display.

Unless the Resolve Color Space Transform OFX now includes chromatic adaptation. I will have to test.

@sermiranda @nick @OwenYou Please have a look of my tool for generating IDT DCTL that could be used for build a XT-3 based IDT pipeline. From my research, I believe XT-3 uses Bradford CA based on the data in Fujifilm official doucment.


This looks amazing! great work, thanks for that!

Great thread, I’ve always struggled with Fuji :slight_smile:

Now lets try the real approach and keep bullying Fuji until they produce an IDT!


What a wonderful thread… so amazing to see the help being given here by the experts! Thank you all for having such a great community here for learning.


This Currently goes a bit over my head, How do I incorporate this tool into my Resolve Grade? Is this a step to input into the node trees above via @nick and @OwenYou? or A replacement to that manual node tree? I have XT-3 F-Log footage to correct and Grade.

This thread is precisely what I have been looking for and struggling with to correctly grade my XT-3 F-Log. Thank you to all of you. Perfect descriptions and Screenshots.

1 Like

It has become easier in Resolve 17, as you can add custom IDTs.

If you take a DCTL generated by @tommyzenth’s tool, and place it in the IDT folder under:

    - MacOS: "~/Library/Application Support/Blackmagic Design/DaVinci Resolve/ACES Transforms"   double check folders again
    - Windows: "%AppData%\Blackmagic Design\\DaVinci Resolve\\Support\\ACES Transforms"
    - Linux: "~/.local/share/DaVinciResolve/ACES Transforms"

(this is copied and pasted from the DCTL ReadMe. I can confirm the MacOS one is correct, but haven’t verified the others)

You then need to add one extra line to the top of the DCTL in a text editor:


Restart Resolve, and your custom IDT will now show up at the bottom of the built-in IDT list.

Hi , This is amazing! Thank you for that ! Is it possible to include F- log2 ?Currently is not supported in Davinci and would be great if we can generate DCTL for it.

I generated the FLog DCTL with the tool and piped in the numbers from the FLog2 paper.
I do not have access to proper test material for it so can’t claim it’s working as intended.

I also noticed a typo in the comment line at the top of the tool stating “ACES DIT” instead of “ACES IDT” :slight_smile: if he reads this, could be nice to correct it.

// ACES IDT FujiFGamut(Rec.2020) - F-Log2 to AP0 - Linear

__DEVICE__ inline float Log_to_linear(float inv)
  float outv;
if (inv > 0.100686685370811f)
 outv = (_powf(10.0f, (1.0f/0.245281f * inv - 0.384316f/0.245281f)) - 0.064829f) /5.555556f;
 outv = (inv - 0.092864f) /  8.799461f;
  return outv;

__DEVICE__ float3 transform(int p_Width, int p_Height, int p_X, int p_Y, float p_R, float p_G, float p_B)
  const float mtx[9] = {0.6788911506598102f,0.15886842237789234f,0.16224042703562752f, 0.04557083087232135f,0.8607127720474108f,0.0937163970408747f, -0.0004857103518124508f,0.025060195735059528f,0.9754255145687619f};

  float r1 = Log_to_linear(p_R);
  float g1 = Log_to_linear(p_G);
  float b1 = Log_to_linear(p_B);
  float r2 = r1 * mtx[0] + g1 * mtx[1] + b1 * mtx[2];
  float g2 = r1 * mtx[3] + g1 * mtx[4] + b1 * mtx[5];
  float b2 = r1 * mtx[6] + g1 * mtx[7] + b1 * mtx[8];

  return make_float3(r2, g2, b2);

Pretty cool :slight_smile: ! Logicly It should work if the formula didn’t change. I will test it . Thanks a lot for that !

BTW I also found that if you use Fuji (Rec.2020) for Gamut and ARRI Log C(SUP 3.x) for the gamma, even is not correct it gives me very nice result and I like it much better than the Fuji’s F-log2 LUT. The highlights rolloff seems much better. Not sure why but result from Fuji F-Log2 LUT gives sharper image and it looks more digital and pretty bad to my eyes .

So just test it and it seems that works and the difference from ARRI Log C(SUP 3.x) is almost not noticeable and definitely looks better than Fuji’s F-Log2 LUT
Thank you !

1 Like

With this node based approach how would you output to AP0?

What do you mean exactly?
The DCTL code I posted converts Rec.2020/FLog2 to AP0/Linear. You can store this file in the IDT folder of Resolve so it pops up in the ACES Transform list. (See Nick’s post in this thread) granted you add that line in he mentions.

I think if you use it as node DCTL it still does the same pretty much but I never tested that.

Sorry, I was referring to the method way back at the beginning of this thread that used nodes in Resolve to “manually” build an ACES pipeline, rather than the color management.

I was unclear there how to go from AP1 ACEScct to AP0. I suppose one could disable the ODT node and add a Color Space Transform that goes from AP1 ACEScct to AP0 linear?

At the end of the day, I feel like your approach of using the built-in ACES color management with an added DCTL for the Input is more elegant.

Ah, yes of course, that would be the way to go.

I always use manual management as I prefer to have full control and visibility of the pipe. Typically I would place the ODT on the timeline node tree. For full ACES where I don’t need to exclude clips this is practical and I can also place my showlook under it on the same tree. If stuff is more mixed for the project I tend to place them on the group post clip tree so other groups can have different setups. With multiple cameras I use groups for each camera and have the showlook under timeline. With single camera I use the post group for the showlook so it’s easier to turn the entire look on or off without disabling the ODT. In both setups you get at least the benefit of disabling your clip grade tree without disabling your color pipeline.

So yea it’s flexible enough but not perfect. Especially because your groups are always occupied for colormanagement rather than creative grading. I can fully understand other users preferring a project lead color management setup :slight_smile:

1 Like