FranceBB LUT Collection

[FranceBB]

Originally Posted by ProWo

Hi FranceBB

can you tell me a working FFmpeg command line to apply your LUTs?
If I apply this:
ffmpeg -i input_HDR -vf lut3d=your_lut ...
I always get wrong colors (to much contrast, to much red).

All my LUTs work in RGB Full Range, which means that you should always convert to RGB Full Range, apply the LUT and convert back.
Such a conversion is trivial in Avisynth (and probably VapourSynth too) but it's slightly less so in FFMpeg.
Now, in theory, lut3d *should* do that for you anyway, so something as simple as this should, in theory, suffice:

ffmpeg.exe -hide_banner -i "Test.mov" -vf lut3d="test.cube" -vcodec v210 -color_range 1 -color_primaries bt2020 -color_trc arib-std-b67 -colorspace bt2020nc -c:a pcm_s32le -ar 48000 -y "Test_v210_HLG_BT2020.mov"

When I ran the test:

ffmpeg.exe -hide_banner -i "Test.mov" -vf lut3d="test.cube" -vcodec v210 -color_range 1 -color_primaries bt2020 -color_trc arib-std-b67 -colorspace bt2020nc -c:a pcm_s32le -ar 48000 -y "Test_v210_HLG_BT2020.mov"
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Test.mov':
Metadata:
major_brand : qt
minor_version : 512
compatible_brands: qt
encoder : Lavf58.76.100
Duration: 00:00:01.28, start: 0.000000, bitrate: 4423685 kb/s
Stream #0:0[0x1]: Video: v210 (v210 / 0x30313276), yuv422p10le, 3840x2160, 4423680 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
Metadata:
handler_name : VideoHandler
vendor_id : FFMP
Stream mapping:
Stream #0:0 -> #0:0 (v210 (native) -> v210 (native))
Press [q] to stop, [?] for help
Output #0, mov, to 'Test_v210_HLG_BT2020.mov':
Metadata:
major_brand : qt
minor_version : 512
compatible_brands: qt
encoder : Lavf59.35.100
Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le(tv, bt2020nc/bt2020/arib-std-b67, progressive), 3840x2160, q=2-31, 4423680 kb/s, 25 fps, 12800 tbn (default)
Metadata:
handler_name : VideoHandler
vendor_id : FFMP
encoder : Lavc59.56.100 v210
frame= 32 fps=2.2 q=-0.0 Lsize= 691201kB time=00:00:01.24 bitrate=4566385.2kbits/s speed=0.0852x
video:691200kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000128%

In this case I'm going from BT709 SDR to BT2020 HLG HDR and indeed mediainfo shows the right info in the container:

General
Complete name : Test_v210_HLG_BT2020.mov
Format profile : QuickTime
Codec ID : qt 0000.02 (qt )
File size : 675 MiB
Duration : 1 s 280 ms
Overall bit rate mode : Constant
Overall bit rate : 4 424 Mb/s
Frame rate : 25.000 FPS
Writing application : Lavf59.35.100

Video
ID : 1
Format : YUV
Codec ID : v210
Codec ID/Hint : AJA Video Systems Xena
Duration : 1 s 280 ms
Bit rate mode : Constant
Bit rate : 4 424 Mb/s
Width : 3 840 pixels
Clean aperture width : 3 840 pixels
Height : 2 160 pixels
Clean aperture height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Progressive
Compression mode : Lossless
Bits/(Pixel*Frame) : 21.333
Stream size : 675 MiB (100%)
Color primaries : BT.2020
Transfer characteristics : HLG
Matrix coefficients : BT.2020 non-constant

When I index the newly created version with ffmpeg and I compare it to the Avisynth one I can see that lut3d in FFMpeg did convert to RGB Full Range, applied the LUT and converted back to YUV Limited TV Range correctly:

LWLibavVideoSource("T3_LUT_IB_UHD_BT709_v210.mov")

#From 4:2:0 16bit planar Narrow Range to RGB Planar 16bit Full Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="709:709:709:limited=>rgb:709:709:full", resample_filter_uv="spline64", dither_type="error_diffusion", use_props=0)

#From BT709 SDR to BT2020 HDR HLG with 16bit precision
Cube("C:\Program Files (x86)\AviSynth+\LUTs\5a_BT709_HLG_UPCONVERT_DISPLAY_mode-nar_in-nar_out-nar_nocomp.cube", fullrange=1, interp=1)

#From RGB 16bit planar Full Range to YUV422 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV422P10", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion", use_props=0)

VideoTek()

avisynth=last


ffmpeg=LWLibavVideoSource("Test_v210_HLG_BT2020.mov").VideoTek()


StackVertical(avisynth, ffmpeg)

Avisynth top, FFMpeg bottom:

Originally Posted by ProWo

Found it.
-colorspace -color_primaries -color_trc must be specified explicitly after the lut.

Yes of course, when you perform any kind of conversion you need to tell the encoder and container what changed so that the right header is gonna be written.
I also recommend -map_metadata -1 if you're doing it in FFMpeg directly to completely get rid of the original info before replacing it with the new one.
By the way, this needs to be done regardless of the encoder you're using; I mean, even with Avisynth + x264 for instance you still need to specify the output to make decoders interpret it correctly, for instance in x264 it would have been something like:

x264-10b.exe "Test.avs" --preset medium --profile high422 --level 5.2 --keyint 1 --no-cabac --slices 8 --bitrate 500000 --vbv-maxrate 500000 --vbv-bufsize 100000 --deblock -1:-1 --overscan show --colormatrix bt2020nc --range tv --log-level info --thread-input --transfer arib-std-b67 --colorprim bt2020 --videoformat component --nal-hrd cbr --aud --output-csp i422 --output-depth 10 --output "raw_video.h264"

[ProWo]

Thanks FranceBB for the detailed info.
ProWo

[FranceBB]

Linear Transformation v2.6 Released!

- Added preliminary RGB32 support (clips with alpha channels will be subject to the very same transformation on both the 24bit video and the 8bit alpha channel before being recomposed back to the output)

Now, as an example, let's take a look at the following fake RGB32 input:

ColorBars(848, 480, pixel_type="RGB32")
pippo=last

pluto=pippo.ConverttoY()

AddAlphaPlane(pippo, pluto)

This creates an RGB32 stream in which the first 24bit are RGB (i.e 8+8+8=24):



and the last 8 are the alpha channel (+8 = 32):





This is in BT709 SDR.
When we apply:

LinearTransformation(Input="Linear_BT709", Output="BT2100_PQ", Interpolation="Tetrahedral")

what's gonna happen is that the stream will be divided in two parts: the normal part and the alpha channel and both will be subject to the very same transformation (in this case from BT709 to BT2020 PQ) before being added back to create a proper RGB32 output:





as per mojie126's request.

[coolgit]

LinearTransformation(Input="dvhe0509", Output="Linear_BT709")

Is there a way to convert from 709 to dvhe0509?

[FranceBB]

Currently no, we can only go from dvhe0509 to BT709 SDR and even that took quite a lot of work for me and algia (Livio Aloja) one of my former colleagues, also an encoder, a senior editor and great friend of mine at Sky before he retired.
Nowadays he mostly goes fishing on the river in summer and fetching mushrooms in winter.
That being said, going from dvhe0509 was extremely difficult due to the lack of openness from Dolby about the proprietary metadata in the pixel shader, so much so that the result of that conversion comes from using the official Harmonic reference encodes in both dvhe0509 and BT709 and reverse engineering the transformation matrix used, which is why it's less than perfect as it's not based on an official spec, but it's "good enough".
Specifically, it applies to IPTc2 dvhe0509 inputs specifically, so it won't work with other kind of inputs.
This is because, on a normal pipeline, you could have:

Source dvhe0509 -> Proprietary Metadata interpreter -> standard HDR image -> LUT -> BT709 SDR

however what we've done is this:

Source dvhe0509 -> IPTc2 -> LUT -> BT709 SDR

The fact is that nothing tells us that the input is always going to be IPTc2.
Going the other way round, so from BT709 to dvhe0509 is impossible 'cause although the transformation could, in theory, be inverted, I would have no way to insert the proprietary metadata in the file so you would be left with something that no decoder could decode properly.
In other words, you could, in theory, invert and do:

BT709 SDR -> LUT -> IPTc2

then what?
You're left with IPTc2 that needs to be encoded and flagged as such with the relative metadata so that an official decoder will be able to decode it, but we have no way to do that I'm afraid, so all you're left with is an uncompressed A/V stream living in RAM coming out from Avisynth with no metadata at all and that any decoder would get wrong.

Out of curiosity, why are you trying to do this?