Panasonic v-log not mapping correctly

Hi all,

I'm working on Panasonic S1H footage and have noticed something.

According to the v-log white paper 18% grey should map to 42% IRE. However, when converting to REC709 through Color Space Transform, the middle gray point is actually below this point.

The only 'correct' conversion I've found is with the v-log to rec709 LUT. Could it be that CST is doing a bad job here?

The same can be observed with other cameras as well, with LOG -- color managed workflows and CSTs raise middle-grey from what's supposed to be the correct value, while the LUT does not.

Maybe someone from BMD can comment, as this includes the BMPCC 4K as well, rising with a CST from about 38% to 50%.

What happens if you use ACES/RCM rather than a CST node?

Same issue ("color managed", see above).

The same can be observed with other cameras as well, with LOG -- color managed workflows and CSTs raise middle-grey from what's supposed to be the correct value, while the LUT does not.

Maybe someone from BMD can comment, as this includes the BMPCC 4K as well, rising with a CST from about 38% to 50%.

That's expected. The footage is being normalized to rec 709 gamma 2.4 which has a Middle gray at 49%

Hi all,

I'm working on Panasonic S1H footage and have noticed something.

According to the v-log white paper 18% grey should map to 42% IRE. However, when converting to REC709 through Color Space Transform, the middle gray point is actually below this point.

The only 'correct' conversion I've found is with the v-log to rec709 LUT. Could it be that CST is doing a bad job here?

No it's expected behaviour. 42 IRE is for the source footage. Once you convert to a rec 709 gamma or some other gamma, your middle gray point changes. Your CST also has DaVinci DRT mapping enabled by default which pushes that middle gray value lower.

The same can be observed with other cameras as well, with LOG -- color managed workflows and CSTs raise middle-grey from what's supposed to be the correct value, while the LUT does not.

Maybe someone from BMD can comment, as this includes the BMPCC 4K as well, rising with a CST from about 38% to 50%.

That's expected. The footage is being normalized to rec 709 gamma 2.4 which has a Middle gray at 49%

The LUT is also normalizing the footage to rec. 709, with a timeline setting of gamma 2.4, and yet middle-gray remains at its original value. That was the OP's question. Why one and not the other.

Simple answer: The LUT is a stylized look, not an accurate technical transform.

Simple answer: The LUT is a stylized look, not an accurate technical transform.

Not so -- the only advertised purpose of these LUTs is normalization (we're talking about normalizing LUTs in DR). And what are the odds a "look" LUT would leave middle-gray at the original value?

V-Log to V-709 in Resolve is a stylized look as sourced from Panasonic... See note regarding V-709:

The gamma curve equivalent to conventional V-REC or CINE-LIKE is newly defined as "V-709." The V-709 gamma provides a tone suitable for previewing on a monitor, and is also suitable for use in producing broadcast content such as TV commercials and TV series.

Panasonic does make "artistic" LUTs, but what leads you to believe the Resolve LUT is one of them? Panasonic itself names them ("Aggressive", etc.), which isn't present in the Resolve version, and it makes this distinction:

A Conversion LUT translates the flat V-Log material to a more restricted, yet contrasty, Dynamic Range and shifts the color space to match the monitor, bringing both parameters to a technical standard for viewing such as Rec. 709. These conversion LUTs provide a neutral matching of the signal to the monitor, so they can be considered technical LUTs.


Why would Resolve be using an arbitrary artistic LUT? EDIT: per your quote above, added later, "suitable for preview on a monitor" doesn't mean it's not a technical LUT.

In any event, as I pointed out, the same can be observed with the BMPCC 4K normalizing LUTs versus color management. And why would an "artistic" LUT retain the middle-gray value?

The fact that the LUT is titled V709 says it all.

V-Log to Gamma 2.4 would translate to Middle Gray at 49%
V-Log to Scene Gamma would translate to Middle Gray at 41%

Math doesn't lie. Try the math yourself.

Math is not my strength, neither is engineering, but in both cases (LUT and RCM), the output gamma is 2.4. And yet the mapping of middle-gray is different. In the case of the BMPCC 4K, the difference is sustained regardless of which normalizing LUT (rec. 709, "extended video", "film to video") is selected. The LUTs all map middle-gray "accurately".

I am an Engineer and I've done the relevant math. I tend to notice these sorts of things.

The Blackmagic LUTs seem to be outputting to Rec.709 Scene... for which the Middle Gray is correct at 41% IRE.

Also, don't forget that Resolve 17 has enabled Tone/Gamut mapping by default in Color Management. I pointed towards this in an earlier post.

In a CST, you now need to explicitly remove the Tone Mapping, otherwise it's enabled by default.

In RCM if you select the default presets, they include the Tone/Gamut mapping... so you need to select Custom and disable the Input/Output DRTs.

If you disable the Tone/Gamut Mapping and output to Rec.709 Scene, the Middle Gray should be the same for the Blackmagic LUT and the Transform or RCM.

Where they will diverge is in the highlights because the LUT will use a fixed mechanism for tone/gamut mapping whereas if you enable Tone/Gamut mapping using the CST or in RCM the calculations will be done using the available data and the designated method. Also as a consequence, your Middle Gray value may shift lower if using the default DaVinci Input/Output DRT.

I also need to highlight that there is some funky behavior in RCM when the timeline is set to Rec.709 Gamma 2.4 (as is currently the default)

I would stick to Rec.709 Scene for the timeline (if using a Rec.709 preset) until they fix it in the next release.

The 'next release' dropped today. Still wonky using the default?

Still problematic. I'm a bit surprised since I reported this issue privately some time ago.

I'll report publicly in a new thread, but as a word of advice for SDR workflows, I'd avoid the Rec.709 Gamma 2.4 timeline gamma and DaVinci Input DRT like the plague.