V-Log / VARICAM support

[lvml]

Encouraged by recent progress in issue #2572 "HDR video / SMPTE-ST-2084 support" I would like to ask for support of another electro-optical transfer function: V-Log, as supported by both consumer, "prosumer" and professional video cameras sold by Panasonic.

Such support would allow for immediate review of the files recorded by popular video cameras like the GH4R in V-Log mode, which allows to record at a higher dynamic range than the usual modes.

This would also allow to look at the material with correct luminance when "cutting in the compressed domain", as facilitated by https:/lvml/mpv-plugin-excerpt

I hope this is not much effort, given the transfer function formula in the specification, automatic detection of V-Log material is probably not required, as people reviewing material they shot on their own will probably know well they used V-Log mode ;-)

Here's a link to a few second short 116MB sample video recorded in V-Log mode, ProRes 422 HQ format (the blue download button is at the upper right of that page).

[haasn]

Fascinating. This might be the first exponential transfer function I have come across. I'll give it a try later, shouldn't be too difficult.

LittleCMS integration will probably not be possible, though, so we will have to use the same trick as with HDR.

Do you know if this transfer is also designed to map to a fixed absolute brightness (as SMPTE ST2084 does), or is it screen-referred like typical transfer curves?

[lvml]

V-Log is not meant to map absolute brightness, it's kind of also not screen-referred, it's "camera sensor-referred". Its primary purpose is to stuff all the dynamic range that the camera can record into "ordinary" video formats such that in post-production, the editor still has all the information from the very dark and the very bright areas available, so he can choose what part of this information "to throw away" while grading colors.
Technically, it would of course be better to just record the raw camera sensor data, but this requires such high data rates that video recording becomes expensive and the huge files cumbersome to deal with.
So V-Log is kind of a reasonable compromise for video makers who are going to edit colors in post-production anyway.
Yet, the ability to look at (unprocessed) V-Log recordings on the set / in the field is valuable - so much that some manufacturers of field monitors actually advertise their ability to map V-Log material to "what it would usually look like if it wasn't V-Log". But not everybody owns such a field monitor, and for those who don't it would be valuable to be able to replay/review V-Log recordings quickly on their computer - in reasonably average contrast/color, before post-processing.

So a transformation from V-Log to whatever colorspace and dynamic range the display supports, for the "quick review" or "compressed domain edit" purpose should not clip away darks/lights, but enhance the contrast to some "normal" level, as if the material had not been recorded using V-Log.

Unlike with (already post-processed, color graded) HDR material, the purpose here cannot be to match some reference image, as there is none at the time when the V-Log material is reviewed.

(Here's some Blog article explaining some pro's and con's of using V-Log as background information.)

[haasn]

I tried implementing it but I still don't really understand how V-Log is supposed to make sense.

If I just plug in the formulas from the document, I get results like V-Log 1.0 translating to a value of ≈46.0855. How am I supposed to work with a weird value like that? Just brute-force renormalize to [0,1] and then treat it as being relative to target-brightness * 46 lux?

This spec might make some sense for cameras but it certainly doesn't really make sense inside a video player.. would probably be a better idea to just use a custom user shader for your particular use case (if you just want to get a useful display out of your V-Log sources).

[lvml]

Your calculation is correct: V-Log "1.0" (meaning the highest code value, so code 1023 for 10-bit code) indeed exceeds "100% IRE" by a lot. For 10 bits, code value 613 (aka V-Log 0.6) seems to be the one associated with "100% IRE". I can only assume they understand IRE here as "the white in a standard non-glossy reflective color target, as illuminated by the ambient light" - such color targets are often shot with cameras for calibration purposes - but of course an active light source or a glossy reflection of a point light source on a metal orb would be recorded "brighter than the 100% IRE region on the reflective color target" by the camera, and thus yield a higher code value.

The V-Log function seems to have been defined with lots of "headroom" for cameras with higher-than-currently-available-dynamic-range. According to the X-axis, the 10-bit code values from 128 to 1023 cover 16 f-stops of dynamic range - but there is no Panasonic camera with that much dynamic range on the market. The GH4, for example, which recorded the sample linked above, has a dynamic range of only 12 f-stops.

If you look at this image: https://suggestionofmotion.com/wp-content/uploads/Panasonic_V-Log_Graph-693x434.jpg we can see that the camera is supposed to use the "left aligned" codes (starting from 128) up to some clipping value it is capable of at max.

So I think the right thing to do here is to create a parameter to input either the clipping code value or the respective number of f-stops (which has the advantage of not being dependend on 10-bit or 12-bit code values), and then clip all higher code values (which should never occur in the encoded material) to the maximum display luminance.

For the GH4 sample linked above, here is a download of 3d LUTs from Panasonic which are meant to map the V-Log codes into bt.709 - maybe you can use this for verification. (BTW: Panasonic calls the part of the V-Log code space that the GH4 can use "V-Log L" with "L" for "Light".)

One more link to mention here, to an article on some properties of V-Log on the GH4, might also help.

[haasn]

@lvml I gave it a shot. May work, may blow up. (I haven't been able to access your test clip yet)

Edit: Managed to grab a mirror of the test clip. Seems to display okay (as in: not obviously broken), but I don't really have anything to compare to so..

You can build bf335193 if you want to test it yourself.

Use it like vf=format=colorlevels=full:gamma=v-log:primaries=v-gamut to select both V-Log and V-Gamut. (Note also the need to override the auto-detected color range, which is “wrongly” reported as TV-range by ffmpeg)

Also keep in mind that you can adjust the tone mapping with hdr-tone-mapping, and also play around with the contrast and brightness levels during playback (since this is ungraded material and will presumably vary greatly in its brightness distribution).

[lvml]

Thanks a lot - I tried your changes, and played with the settings quite a lot, the bottom line of these experiments so far is: I cannot get a good image (regardless of brightness/contrast/saturation) settings when I use the vf=format=gamma=v-log part - which seems strange.

But I can get a good result when using the vf=format=primaries=v-gamut part, along with appropriate settings for the remaining parameters - here's the command line I got the best result for with the sample file linked above:
./mpv -fs --pause VLogL-SHOGUN_S001_S001_T008b.mov --vf=format=colorlevels=full:primaries=v-gamut -vo opengl:target-prim=bt.709 --contrast=58 --brightness=0 --gamma=-37 --saturation=-20
(Screenshot taken with Ctrl-s in mpv.)

Whatever I tried with gamma=v-log, I could not get even close to this "natural" look. Any idea why that could be?

[haasn]

That looks extremely similar to what I see with just --vf=format=gamma=v-log:colorlevels=full:primaries=v-gamut -vo opengl-hq:hdr-tone-mapping=clip.

[lvml]

Really? Here's a Ctrl-s screenshot of what the picture looks on my computer when I use just
./mpv -fs --pause VLogL-SHOGUN_S001_S001_T008b.mov --vf=format=gamma=v-log:colorlevels=full:primaries=v-gamut -vo opengl-hq:hdr-tone-mapping=clip

(With of course, saturation/brightness/contrast being 0 by default.)

What could make such a big difference between our results?

[haasn]

Oh, I think I know what's going on. mpv's stupid default behavior of “don't map colors/gamma unless the user specifies a target manually” is kicking in. For common spaces like BT.2020 we actually have a hard-coded exception to this “rule”, but for v-log/v-gamut there is no logic at all.

The reason it looks fine for me is because I am using mpv with an icc profile configured (via icc-profile-auto + argyll-dispwin). If you have an ICC profile for your target device (or can generate one), you should use that.

Failing that, if you can estimate your target device's gamut and gamma, you can use mpv's built-in adaptation algorithms, e.g.: -vo opengl-hq:hdr-tone-mapping=clip:target-trc=gamma2.2:target-prim=bt.709. (But note that this will hard-clip out of gamut values, which can introduce color distortions if the primaries are not linearly dependent - using an ICC profile is preferred)

Edit: Also note that I found a bug that prevented the brightness adaptation from correctly working when not using an ICC profile; make sure to test with this fix applied, that is haasn@d192305.

[haasn]

I also added v-log and v-gamut to the “wide gamut and HDR” blacklist for the default behavior, so it should just work with just the --vf metadata now.

[ghost]

mpv's stupid default behavior of “don't map colors/gamma unless the user specifies a target manually” is kicking in. For common spaces like BT.2020 we actually have a hard-coded exception to this “rule”, but for v-log/v-gamut there is no logic at all.

That logic exists mainly to not make mpv a special snow flake compared to other PC players when doing bt.601/bt.709, from what I remember.

[haasn]

Yeah, exactly. It's a purely selfish decision, made to reduce bug reports in “common” cases at the expense of bad behavior in exceptional cases (like this).

(Treating BT.601 as BT.709 on a BT.709 monitor is wrong behavior, but people compare mpv against every other player that also gets it wrong and then decide mpv is the one fucking it up)

[lvml]

Great, works for me now (without additional saturation/brightness/gamma parameters):
--vf=format=gamma=v-log:colorlevels=full:primaries=v-gamut -vo opengl-hq:hdr-tone-mapping=clip

Adding target-trc=gamma2.2:target-prim=bt.709 to "-vo" doesn't change the image for me, so I suppose these are the defaults, anyway - right?

Without "hdr-tone-mapping" the image loses some contrast and gets darker, but is still ok to look at.

Using hdr-tone-mapping=reinhard instead of "clip" gives an image with slightly less contrast than desired. Using hable instead of "clip" results in much less contrast than desired. But I guess both options could still be useful if the camera and the image made use of more dynamic range than in this example.

Thanks a lot again!

[haasn]

Adding target-trc=gamma2.2:target-prim=bt.709 to "-vo" doesn't change the image for me, so I suppose these are the defaults, anyway - right?

Yes, those are pretty much the defaults now.

But I guess both options could still be useful if the camera and the image made use of more dynamic range than in this example.

Yeah, hdr-tone-mapping=clip is the obviously best choice if your source's dynamic range is low enough that it won't clip. The other two sacrifice contrast in exchange for preventing clipping. Another way you could compensate for both clipping and the darkening introduced by hable etc. is by simply increasing your display's brightness (and adjusting target-brightness to the new brightness value).

(You should probably also set target-brightness to a fitting value to begin with, it defaults to 250.)

Edit: Nevermind, target-brightness only matters for SMPTE ST2084 HDR, not V-Log since the latter is treated as display-referred.