LUT Maker: dark linearization of Alexa LogC

[sudo-interesting]

When trying to create a linearization profile for Alexa footage, I've run into an issue where the linearized footage always comes out several stops darker than expected. My current workaround is intentionally lighting the scene darker in Blender or dropping the exposure using the color management settings, but this is not a super sustainable or scalable solution.

The OCIO profile for the Alexa I'm using was generated using the LogC2Linear LUT provided by ARRI's LUT Generator (As an Alexa LogC curve has not yet been natively implemented into LUT Maker as of this posting).

This issue only seems to appear with Alexa footage, as shown in the examples below (I have included a set of images from a Blackmagic Camera as a control). I'd like to chalk this up to my own user error, but the program has worked perfectly for every other camera I've thrown at it.

Here are the example Images for reference:

[cessen]

Thanks for the report!

Yeah, this definitely looks like something fishy is going on. Can you provide the LUT files you're using, so I can test this and track it down? A Log-C encoded test image (as a 16-bit tiff or 16-bit png) from your footage would also help.

[sudo-interesting]

Of course!

Here is a .zip with all the files: LUT Maker Issue.zip

It should contain the LUT file I have been using which was generated from this site, a 16-bit tiff of the Log-C test image I have been using, and also the LUT that I generated with LUT Maker to linearize the footage in case that's useful.

Thank you for looking into this!

[cessen]

Thanks for the files!

Just to double-check: the LUT files you've provided are generated by Arri's tools, not LUT Maker, correct?

If that's the case, then it looks like the issue isn't with ETF Image Tools, but rather with the LUT that the Arri tool is generating. Here's a graph of Alexa from Arri Lut.cube (the other LUT you provided is basically the same, just with raised black levels):

(I also double-checked that this graph is correct by opening the LUT file in a text editor and checking the values directly.)

Notice that the mapping is entirely within the [0, 1] range for both input and output. That kind of [0, 1] -> [0, 1] mapping is always going to end up really dark for log-encoded footage. So the resulting too-dark image is actually correctly applying the LUT. (Aside: you can also see that the LUT is clipped at the upper right, which is odd. But again, that's actually in the LUT itself.)

It's not clear to me why Arri's tool is outputting a LUT like that. Maybe it's to avoid issues with software that doesn't like values outside of the [0, 1] range...? LUT Maker actually had an option (disabled by default) for similarly normalizing LUTs to a [0, 1] range until recently, for that reason.

What are the tools and workflow you're using to get the brighter image?

[cessen]

Also, some further testing revealed that the "Alexa LogC with ARRI's Rec.709 LUT Applied" image that you posted above isn't linear, it has a filmic tone mapping curve applied to it, with a bit of a toe and a notable shoulder. That makes sense for a final delivery image, because you usually want some kind of pleasing tone mapping applied (otherwise you get clipping instead).

But just be aware that when you do get the footage properly linearized, sans-tone-mapping it should look a bit different from that image anyway—if it looks the same, it's not properly linearized.

[sudo-interesting]

Thanks for looking into this!

If by brighter image, you mean the "Alexa LogC with ARRI's Rec.709 LUT Applied" image then yeah you're right, it's not a linearization LUT. It's just the stock Alexa LUT included with DaVinci (called "Arri Alexa LogC to Rec.709"). I mostly just included it as a reference so you'd know I didn't horrifically underexpose my footage from the get-go. Since the resulting image is not linear as you said, it doesn't help me much with VFX purposes hence why I'm trying to make a linear one with the ETF tools.

Strange that Arri's tool is spitting out odd LUTs. That is sort of what I suspected though, cause there's no obvious reason why LUT Maker would play nice with every camera except the Alexa. That's why I originally filed this under a transfer function request—I figured you could probably do a better job implementing a transfer function than what Arri's tool was giving me.

However, the plot thickens, because, in the interim, I tried to estimate a transfer function for the Alexa using the LUT Maker's tools. Since the Alexa doesn't give you JPEGs, I would simply roll for a second, adjust exposure, roll for another second, and repeat until I had a decent sample, then export single frames from those clips as JPEGs and manually add the Exif data based on the exposure settings I wrote down on the shoot. But shockingly, I had the same issue!

Here is the test image linearized with the transfer function I estimated using LUT Maker:

As you can see, the issue is much less significant, but it's still a lot darker than I would expect.

Here's the Transfer Curve that LUT Maker estimated:

It's pretty similar to the Arri-provided one, minus the clipped upper right. I've included the LUT that I generated from this below:

Alexa From Bracketed Exposures.cube.zip

However, it is worth noting, that after estimation, LUT Maker thew me this warning:

I was using 12 bracketed exposures, with manually added Exif data for ISO, aperture, and shutter speed (converted from units that the Arri cameras use like EI and shutter angle). Does LUT Maker need other data beyond exposure settings in order to calculate the sensor ceiling?

I hope I answered your question about the bright image above, but just in case, here is the process I used for all of the test images shown in the original post (minus the log ones):

  For the rec.709 images:
        Import footage into DaVinci Resolve
        Apply LUT from their stock LUTs
        Export frame

  For the linearized images:
        Create linearization LUTs with LUT Maker, and add them to the ocio config with Ocio Maker
        Import the footage into Blender's compositor (plugged directly into the output) and set the color space to the linearization profile
        Export frame

[cessen]

But shockingly, I had the same issue!

Ah, transfer function estimation always does a [0,1] -> [0,1] mapping, because there isn't really anything else sensible to do.

The vertical (a.k.a. linear output) scale of these graphs is essentially just exposure, and there's no way to know what the default exposure should be—it would basically just be guessing. For example, sRGB gamma is [0,1]->[0,1], but Sony's SLog-2 is [0,1] -> [-0.04, 22.8], and Canon Log 2 is [0,1] -> [-0.02, 65.8]. And there's no way to tell that from bracketed exposures, so leaving it as a normalized [0,1] -> [0,1] mapping and letting the user adjust the exposure later in the client application makes the most sense. The main important thing is that it (approximately) linearizes the footage, which is independent of exposure.

But indeed, that does mean that it will linearize things like log-encoded footage much darker than you would otherwise expect. It's just one of the limitations of the approach.

However, it is worth noting, that after estimation, LUT Maker thew me this warning:

Oh, that's very interesting. The error message is certainly at least partially incorrect. It indeed may not be successfully estimating a ceiling, but that's clearly not due to lack of images!

Would you by chance be willing to upload the bracketed images you used, so I can test on this side?

That's why I originally filed this under a transfer function request—I figured you could probably do a better job implementing a transfer function than what Arri's tool was giving me.

Ah, that makes sense. It's already on the TODO in that issue, I just haven't gotten around to it because it's a bit more of a pain to implement than other transfer functions, due to being parameterized. But now that there's someone (you) who would actually benefit from that, I'll bump up the priority on it.

In the mean time, though, you can still keep using the Arri-provided LUT. It does seem to be linearizing the footage correctly, just at a very low effective exposure (and maybe with a bit of clipping, looking at the LUT graph). I wouldn't recommend using the estimated LUT, since that's only approximate, and particularly for log-encoded footage can have significant inaccuracies on the dark end.

[sudo-interesting]

Oh! That makes a lot of sense. I gave it a quick test with the exposure node after the linearized image and it came out looking great. It's funny, I'm so used to looking at an image that dark and just assuming it's all crushed that I just forgot I was in a linear workflow.

Also, in case it's helpful, after playing around with the exposure adjustments, it seems like the images the transfer function makes are about 4-5 stops underexposed (4.3 seems like the closest number just from my quick eyeballing tests)

Would you by chance be willing to upload the bracketed images you used, so I can test on this side?

Sure. I was actually gonna upload them with the last post, but they're too big to upload in one zip. Here they are as a few (sorry it's a bit cumbersome):

Bracket Part 1.zip Bracket Part 2.zip Bracket Part 3.zip Bracket Part 4.zip Bracket Part 5.zip

But now that there's someone (you) who would actually benefit from that, I'll bump up the priority on it.

Thank you! That would streamline my workflow so much. It's nice to know I can at least get the results I need by messing with the exposure, but a true implementation of the transfer function would help a lot just for quality-of-life reasons. Cause while I can adjust exposure in node workspaces, there are some implementations like camera background images that, as far as I know, don't allow for any exposure adjustments. All that to say, I really appreciate it!

[cessen]

I've added ARRI LogC3 (a.k.a. Alexa LogC) to LUT Maker. Here's a dev build: https://github.com/EatTheFuture/image_tools/releases/tag/dev_build-2023_09_11-c82709a

Give it a try and let me know if you run into any issues.

(I'll keep this issue open regardless, for the weird transfer function estimation error message, which I haven't attempted to track down or fix yet.)

(EDIT: changed the build link to a new build with a bug fixed that someone else found.)

[sudo-interesting]

Thank you! Just gave it a try and it looks like it’s working perfectly.

I also saw you added LogC4 in there too! I appreciate that cause I do very occasionally work with Alexa 35 footage so that will definitely come in handy.

And yeah keep me posted on how things go with the error message, and let me know if there’s anything else I can send along to help.

On Fri, Sep 8, 2023 at 5:48 PM Nathan Vegdahl @.***> wrote:

I've added ARRI LogC3 (a.k.a. Alexa LogC) to LUT Maker. Here's a dev build:

https://github.com/EatTheFuture/image_tools/releases/tag/dev_build-2023_09_08-c8056ed

Give it a try and let me know if you run into any issues.

(I'll keep this issue open regardless, for the weird transfer function estimation error message, which I haven't attempted to track down or fix yet.)

— Reply to this email directly, view it on GitHub https://github.com/EatTheFuture/image_tools/issues/12#issuecomment-1712309027, or unsubscribe https://github.com/notifications/unsubscribe-auth/BB57YGKJPH554B6SC6LAE5LXZOOCPANCNFSM6AAAAAA32UXBLM . You are receiving this because you authored the thread.Message ID: @.***>

[MysteryPancake]

It might be useful to have an option to set the exposure within the LUT maker just to save a bit of time if you want to work with sRGB textures, maybe based on a texture preview

[cessen]

Yeah, I think an exposure adjustment parameter in the Modify and Estimate tabs is probably a good idea (for fixing and matching, respectively). I'll probably leave it out of the Generate tab, since that's already producing the correct transfer functions by default (and if people really want to, they can then load the generated LUT into the Modify tab to adjust exposure).