Input Transforms vs Colour transform and more fun things about colour management

I’m spending a couple of days playing with colour management and trying to consolidate my internal workflows and make my own custom templates. I use to compare results between flame and resolve.

Alexa workflows is particulary easy, but today I came up with an unexpected issue. The result of an input tranforms arriLogC → to → rec709 is different than the result of a colour transform via Arri_Log_C_to_HD_video transform.

The result of Arri_Log_C_to_HD_video transform is completely consistent with a complete workflow with this footage, transforming, using view transforms… I never had any problem with that. And it’s acurrate with the result of same resolve transformation. So, it’s clear that something is wrong (or something that I’m missing) with the input transform node. And this makes me suspicious of this node for the rest of transforms.

I wonder what is the mistake here.

On the other hand, I found another problem. This is more generic. I downloaded from arri (lut generator) the luts for arriLog C. There are two Luts: “classic” and the regular version. The regular version seems to be a recent and refined version (I think). The “classic” version claims to be the classic S1K1 lut.

Fortunatley, I have the classic S1K1 lut. Well, I compared these three luts with next results:

  • The non classic lut is not equal to the classic (well, this is expected). But:

  • The “classic” (current version) is not equal to the S1K1 lut as arri claims (what?)

  • None of the current downloable luts are equal to the Arri_Log_C_to_HD_video transform.

  • Only the S1K1 lut is equal to Arri_Log_C_to_HD_video transform and alexa_rendering view transform.

I’m totally confused. Could flame using obselete colour knowledgment from arri (or any other camera)?.

The fun is that in Resolve I get EXACTLY same results. Only the internal build LUT arri to rec709 is acurrate with Arri_Log_C_to_HD/alexa_rendering/S1K1 lut. I get same discrepancy using Resolve’s colour management or own resolve’s colour tranform node , and the specific lut. Both options have different gamma options (rect709A, rec709 scene, etc).

1 Like

Colorspace is such a moving target. My hunch is OCIO said, “K1S1 is the Arri Viewing Transform” however many years ago and no one complained.

Then Arri goes out and improves the K1S1 lut and no one cares at all, everyone keep using the old faithful. I mean I’ve heard people talk about that lut like it was pulled from the Ark of the Covenant, so it makes sense that Flame/Nuke/Resolve stick with it. Having the luts change annually is a recipe for madness. Haha.

1 Like

It`s likely, that input transform is using different tone mapping method (or not using any tone mapping at all) compared to applying ARRI LUT. Both ways of working are not optimal in my opinion, because using LUTs leads you to clamp the original dynamic range and color gamut.

The correct way would be to go to some kind of linear colorspace for the comping stage and get back LogC/ARRIWideGamut for color and finishing. Is there any reason the ACES 1.1 workflow that ships with Flame not good enough for you?

sure!! .I work with linear workflow happly since a few years ago. Specially with arri footage. I’m only trying to understand what I am doing and how colour management nodes, presets, luts, etc, works. And specially, if the colour transforms are in tune with other softs. We can see a lot of posts asking about this.

About input transform, you can read info about how they work. They are multiple colour transforms, moslty, starting by making as Aces transform and then a couple more to get the final target.

Did you watch logiklive about introduction to color management I present some time ago? I showed it in Resolve, but same principle and theory would apply to any other software. It’s a good point to wrap your head around.

Flame color transforms would work in sync with other software, if you would go with ACES workflow, math and results would be the same.

Transforms you use at this moment just use ACES AP0 as a connected colorspace, it’s not a whole workflow, just a part of ACES.

Nope. I’ll do. Thanks

I have to think that it’s totally true. In both flame and resolve.I did more tests. First, the colour transform using the input transform node in flame, matchs totally with the colour transform done by resolve, (using preferences or using its node colour transform).

Then, the luts provided by arri seems that they are ignored by flame/resolve, and third, the builded-in preset is based in an obsolete (?) lut. I’ve read a lot about the inconvenience of use luts. I bet by the colour-transformed one but it looks no-natural and pretty washed-out.

So, if we have to be in sync in a a global workflow whith more softs or other post houses that becomes in a bit crazy…

I started by arri thinking is the easier footage to test. An my binay-mind is about to blowup with this kind of quantic-parallel realities.