LUT Maker: add additional transfer functions.

[cessen]

There are plenty of transfer functions that haven't been implemented yet in LUT Maker. This issue is a place to collect a list of the transfer functions that people want, so that I can implement them.

Please leave a comment with any not-yet-listed transfer functions you want added. And if you can find the white paper with the formulas (which are needed for implementation) even better!

So far:

• Panasonic's V-Log: white paper
• Fujifilm's F-Log: white paper
• DJI's D-Log: white paper
• Nikon's N-Log: white paper
• RED Log3G10: white paper. (Added in 1158fec.)
• Blackmagic Design's Film Gen 5 transfer function: reverse engineered. (Added in 1158fec.)
• DaVinci Wide Gamut Intermediate: white paper. (Added in a134abc.)
• ARRI LogC3 (a.k.a. ALEXA LogC v3): white paper
• ARRI LogC4: white paper
• Apple Log: the white paper is currently behind a paywall, because Apple. Independent implementation.

[Leonobu]

Would be great to see an S1 V-Log also.

[cessen]

@Leonobu
Ah, thanks! Looking into it, it seems there's only one V-Log. I only listed it as "GH5's V-Log" because that's how the person who requested it did so (I'll fix that now). But it's all just Panasonic V-Log, and is the same for all of their cameras.

[Leonobu]

Awesome! Already playing with it. Thank you so much for this tool! Completely changed my CGI and Cinematography Color Workflow.

Small Question: I'm using a color checker for the WB and taking photos of the color chart for the bracketed exposure part. Does that make any difference at all to the results?

[cessen]

I'm glad the tools have been useful to you!

I'm using a color checker for the WB and taking photos of the color chart for the bracketed exposure part. Does that make any difference at all to the results?

The scene you use for the bracketed exposures can make a difference, yes. But it's mainly a matter of how much useful data the scene gives the software to work with.

For estimating transfer functions, the number one thing that matters is luminance variation. Hue/saturation variation doesn't really matter at all, and even a grayscale scene (i.e. the actual scene is grayscale, not that you're shooting in black and white) will work great. On the other hand, just a handful of color swatches from a color checker is actually starving it of data to some extent: uneven lighting notwithstanding, it will only end up with as many data points as there are color swatches, whereas in a natural scene it could potentially find hundreds of data points.

(Also, the algorithm I'm using is pretty insensitive to minor scene changes between exposures. So, for example, rustling leaves and grass, trees swaying in the wind a bit, or ripples in the water don't bother it--it can still produce good estimates. Of course, the stiller the scene, the better. But you don't have to avoid outdoor scenes for fear of minor variations between exposures. As long as the over-all scene looks the same, you should be good.)

So, in short: the more luminance variation there is in frame, the better.

In theory, the best possible scene would be an HDR grayscale gradient that spans from ultra black to over-exposed white in your medium exposure. You might be able to make something close to that with some strips of different brightness paper and very uneven lighting coming in from the side, like this (artificial render, just to illustrate): https://perm.cessen.com/2022/lut_maker/gradient_strips.jpg

But in practice, natural-ish outdoor scenes with lots of luminance variation and a high dynamic range (including e.g. the sky, in-shadow areas on the ground, and everything in between in frame) are actually quite good. To be a little more concrete, this kind of shot is pretty good: https://perm.cessen.com/2022/sensor_noise/noise_calibrated.jpg

Hope that helps!

[cessen]

Also, to clarify just in case this wasn't clear (I think a lot of people got confused about this in our intro video for these tools):

LUT Maker and the LUTs that it generates have absolutely nothing to do with color gamut. They're only getting your footage into linear color, they don't handle color gamut/color space. This is why hue/saturation variation doesn't matter in the bracketed exposure images. In the future, I'm hoping to add functionality that will take color checker images and generate 3d LUTs to handle hue/saturation as well, but that's probably a ways off.

In the mean time, in OCIO Maker you can select the color gamut you were shooting in, and then the generated OCIO config will do its best to transform your colors into a more-or-less consistent color space. It's not a perfect solution, but it should be reasonably good-ish. Although you still have to handle white balance yourself.

[Leonobu]

Gotcha! Finally had some time to properly read your answer. I'll re-create my LUTs using your picture as a reference.

From what I understood my Color Workflow using the Color checker or Leeming LUTs will stay the same.

The main difference will be when it comes to adding VFX and 3D to my live footage. I'll composite them together using linear workflow, exporting it back the same way it came from my camera (in this case V-Log), and applying my corrections on DaVinci Resolve like usual.

Thanks for the clarification and hard work!

[cessen]

Added V-Log, F-Log, D-Log, and N-Log in 57a3c5a.

[cessen]

Added RED's log transfer function and Blackmagic Design's latest log transfer function in 1158fec.

(As an aside, it's difficult to fully express just how bizarre it is that Blackmagic Design has so many different transfer functions... and on top of that has only ever documented one of them. In any case, I've just included their latest log transfer function, which also happens to be the only one they've ever documented.)

[sudo-interesting]

I've been trying to make an Alexa linearization ocio using these tools and the Alexa linearization LUT provided by Arri's LUT generator, but for some reason, the linearized images come out several stops darker. I've been able to get around this by just lighting my blender scene significantly darker, but that doesn't feel like a long term solution. I've also only had this issue with Alexa footage—everything else has worked perfectly.

I would just do the bracketed exposure thing, but I don't know how to get stills out of the Alexa footage with exif data.

I imagine it's just that I'm missing something obvious, but I feel like I'm doing everything correctly. If you could implement the Alexa Log-C transfer function, that might remove some of my error.

[cessen]

@sudo-interesting Can you file a separate issue for this? This issue is for tracking transfer function requests.

[cessen]

Added ARRI LogC3 and ARRI LogC4 in c8056ed.