Fujifilm F-Log in Resolve without an IDT

[sermiranda (Sergio Miranda)]

Hey there, I’m Sergio Miranda, beginner DIT and experienced digital stills photographer.

I’m quite new to ACES and just finished a training where I learnt that with Resolve we can select given IDTs and respective ODTs to set up our workflow.

I wanted to try it with footage of my Fuji XT3 camera, F-log, but is not listed on the options by resolve (I guess fuji didn’t provide a standard one as of yet, or did they?).

I’ve got the white paper of Fuji and it gives some information that helped me reach a workaround, but I’m not sure that what I’m doing is correct and maybe someone here can help me:

The white paper says that Fuji’s primaries match those of the ITU-R BT.2020 spec. With this, I understand that Fuji’s Gamut and Rec.2020 gamut are the same, am I right?

But then there’s the gamma, which is coded in F-log by fuji and I need to decode to make all the information available to ACES.

Resolve does include information for Fujifilm F-log gamma curve in some places (like in OFX Color Space Transform).

So, this is what I’m doing and I want to know if has some logic:

1. I start setting the project like this:
   
   

With my clips imported, I change data levels to Full for all clips and this is what I see first:

Then, I change the Aces Input Transform by right clicking on the clip thumbnail, to Rec.2020. (*)(**)

And this is the visual result:

Lastly, with the ColorSpaceTransform OFX I change the Gamma curve:

This is the visual result of the process:

.

It looks quite pleasing to me and resembles a lot what I’ve shot, both visually but also with the scopes.

But I’m a beginner with this and I understand I could be missing some parts, for example:

1.- When choosing rec.2020 for Input device (both at project settings level or each clip individually) am I just changing the gamut and no change to gamma is happening?

2.- When transforming the gamma with OFX plugin, and assuming the supplied Fujifilm F-Log is provided by the manufacturer, the de-codification should be correct, right?

3.- When transforming with the OFX Plugin, should I also add there the information of Input color space and Output color space?

4.- (*) I have other options for Rec.2020 to choose from (and I’m not familiar with the ST2084 with extra nit ones, although I believe they relate to HDR workflows), so I don’t know if any of the others would be more suitable?

I hope it wasn’t too much information, thanks to all for your time and for this community.

Sergio Miranda
Photographer and DIT from Barcelona

[OwenYou (尤子元)]

Just to add, when using Rec.2020 IDT and Rec.709 ODT in ACES, you will get a F-Log+Rec.709 final image. Because Rec.2020 and Rec.709 use the same OETF Curve and this makes the gamma processing become a simple linear throughput，which means F-log in F-log out.
In your setup, the pipeline is like:
F-log(original) -> rec.2020 gamma decode(wrong decoding) -> F-log to gamma2.4 encode(wrong encoding) -> ACEScct to rec.709 encode(wrong encoding again)
Basically, every step is mathematically wrong, the output you get might seems acceptable but technically you shouldn’t do so because this might cause problems when doing turnover or such thing.

[OwenYou (尤子元)]

The ACES Rec.2020 IDT in Resolve defines both color space primaries(including white point) and gamma. It uses the gamma specified in ITU-R-REC BT.2020, you can see that in the screenshot I gave bellow. This means using the Rec.2020 IDT and then using the F-log to Gamma 2.4 setting is wrong. (Because the IDT gives the wrong output and then the OFX plugin gets the wrong input)

So, my suggest is, you can disable the color management (i.e. choose Davinci YRGB in Color Science tab) and setup your transform pipeline using the node structure shown below.

Then you can get “technically right” Rec.709 RRTODT output:

Or you can use RCM to setup the same structure but you can’t get ACES RRTODT with that.

Hope that will help!

[nick (Nick Shaw)]

@sermiranda, @OwenYou is correct that your approach is incorrect and that despite the fact that you like the visual result it may well be problematic if trying to pass material to others (e.g. VFX) for a standard ACES pipeline. His node structure is much better. However, it misses one step. The Color Space Transform OFX does not (I believe) apply the chromatic adaptation which is part of a standard ACES IDT.

You would get a more correct result by using the Color Space Transform to convert to another space which uses D65 white, the same as F-Gamut, such as LogC ALEXA Wide Gamut. Then you would use an ACES Transform to convert from “Alexa” to “ACEScc(t)”, followed by your grade, followed by another ACES transform from “ACEScc(t)” to “Rec.709”

[sermiranda (Sergio Miranda)]

Owen, thanks a lot for your help. Theres a lot of your answer that I will have to study and learn more about as I dont fully understand it. But I do understand now that the Rec.2020 option in the color management tab in project settings, also includes gamma on it as per the standard.

I will try today your suggestion for the use of the OFX CST and ACES Transform plugins.

Thanks a lot!
Sergio

[sermiranda (Sergio Miranda)]

Ok, so, what I understand is that with the nodes in Owen’s suggestion, I could convert in the first node to ACES AP1; then do color grading, and finally convert to rec.709 for a delivery, but in that way, keeping inside the project all the ACES info, right? (sorry if I don’t use the right terms).

And you suggest that I add an extra CST to switch first to the Alexa LogC Wide to incorporate like that the chromatic adaptation?

Also, I want to clarify that this process I’m going through is about learning for now, and I’m using Fuji because is the footage I have in hand, but my overall point is to understand the math and logic inside the ACES system, and I think is a good opportunity.

The real final question is, by doing the things you are both suggesting, and not choosing “ACES cct” in my project at the beginning, would I still be working in the ACES environment with the exact same results, when using CST?

I work as a DIT, and understanding ACES processes is a priority right now, particularly because I do have a lot of time for studying.

Thanks a lot for your inputs!

[OwenYou (尤子元)]

If you are not using RCM then the timeline color space tab will only affect how the node process color when changing node gamma/colorspace.
PS:@nick is right about me forgetting to add a chromatic adaptation in my node structure(because ACES is using a white point not the same as D65)

[OwenYou (尤子元)]

You can add another node of Chromatic Adaptation between CST and Grade, which will work(but you need to figure out the difference between different chromatic adaptation algorithm). So the better approach for you might be @nick 's approach: transform to LogC/AWG and use the ALEXA IDT.
The math behind this is: transform the mismatch colorspace and gamma setting into a combination that fits an existing IDT. And the Resolve CST ofx is doing a great job. And besides that, AWG is using the D65 whitepoint and it’s the same as rec.2020(f-gmaut) so there is no need for chromatic adaptation.

[nick (Nick Shaw)]

@sermiranda

The real final question is, by doing the things you are both suggesting, and not choosing “ACES cct” in my project at the beginning, would I still be working in the ACES environment with the exact same results, when using CST ?

What you are doing, is manually constructing an ACES pipeline, rather than using Resolve’s built in ACES mode. But if the sequence of transforms is correctly constructed, there is no difference, and you are still “using ACES”.

[OwenYou (尤子元)]

Here is a sample setup for @nick 's approach:

And here’s some sample for manual chromatic adaptation setup(the input CST setup is just like my original approach):

I believe you can easily tell the difference, but it’s easier to visualize that using the vectorscope:

[OwenYou (尤子元)]

Just like @nick said, manually build a ACES pipeline is the same as using the Resolve built-in one. But in my opinion, build one by yourself gives you more control of the pipeline, because you can easily fit all kinds of footages into ACES but still get the advantages of ACES. In this case it is fujifilm footage, in other cases it might be DJI, Nikon or some other footages. Math is still the same, but you get more versatility.

[sermiranda (Sergio Miranda)]

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

[sermiranda (Sergio Miranda)]

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

Nick’s

Owen’s

With Attila Bakos IDT:

Thanks to all of you guys.
Sergio

[OwenYou (尤子元)]

@sermiranda

what method to use for Chromatic Adaptation” .

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

[nick (Nick Shaw)]

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

[nick (Nick Shaw)]

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.

[tommyzenth]

@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.
http://acesidtdctl.tcolorscience.com/

ACES IDT DCTL Generator

Hi, everyone I developed an online ACES IDT DCTL generator. It is a tool that mainly provides a function of immediate building an IDT(Input Device Transform) into a format of DCTL (Davinci Resolve Color Transform Language) based on the guide of ACES documentation, camera vendors white papers and technical specification of some color science algorithm. Its usage includes: Generating DCTL for trending and more diverse camera types and a combination of gamut and OETF. I understand that the ACES…

[sermiranda (Sergio Miranda)]

@tommyzenth

http://acesidtdctl.tcolorscience.com/

This looks amazing! great work, thanks for that!

[cmlgeoff (Geoff Boyle)]

Great thread, I’ve always struggled with Fuji

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

[TeeJay (TJ Marbois)]

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.