FranceBB LUT Collection

[LouieChuckyMerry]

Thank you for sharing your LUTs, FranceBB :) . I think I've wrapped my head around their use enough to run some tests, but I'm unsure which to use for a BT.2020 PQ source that I want to transform into BT.709 ??. I've a 4K source but no 4K TV, so I want to downscale to 2K but don't know all the technical language. Here's a Test Clip (https://www.mediafire.com/file/tjhzaxbdhkfaw7g/TestClip2%255B2160p%255D.7z/file).
_____________

Edit: Please ignore the above; I just remembered that the reason I'm even here is because you posted a link when helping me on the HDRTools Plugins thread (which has your script :o ).

[FranceBB]

I just remembered that the reason I'm even here is because you posted a link when helping me on the HDRTools Plugins thread (which has your script :o ).

LOL and you posted the same example clip with trees xD

I'm unsure which to use for a BT.2020 PQ source that I want to transform into BT.709 ?

It's as easy as it sounds: to go from BT2020 PQ to BT709 you need, quite intuitively, the PQ_to_BT709_v1.cube or the PQ_to_BT709_v2.cube.

In other words, if you were to run it manually in Avisynth, it would be:


#Indexing
FFVideoSource("D:\TestClip2[2160p].mkv")

#Bringng everything to 16bit planar
ConvertBits(16)

#Going from YUV limited tv range to RGB full range
ConverttoPlanarRGB(matrix="Rec2020")

#From BT2020 PQ to BT709 SDR
Cube("PQ_to_BT709_v2.cube", fullrange=true)

#Going back from RGB full Range to YUV limited tv range
Converttoyuv420(matrix="Rec709")

#Dithering down to 8bit planar with the Floyd Steinberg Error Diffusion
ConvertBits(bits=8, dither=1)




OR if you use my plugin, LinearTransformation(), you can easily just do:

FFVideoSource("D:\TestClip2[2160p].mkv")

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

as described here: https://github.com/FranceBB/LinearTransformation

[LouieChuckyMerry]

Happy Saturday! I finally found some time to figure things out and run some tests, and was curious for your learned opinion. I tried your LinearTransformation:

ConvertToPlanarRGB(Matrix="Rec2020",Interlaced=False)
ConvertBits(Bits=16)
Spline36Resize(1920,1080)
Cube("F:\InstalledPrograms\AviSynth+\LUTs\PQ_to_BT709_v2.cube",Fullrange=True)
ConvertToYUV420()

and Donald Graft"s "DGHDRToSDR()":

ConvertToYUV420()
ConvertBits(Bits=16)
Spline36Resize(1920,1080)
DGHDRToSDR()

and Avidemux's "HDR tone mapping" feature with the "RGB Hable" option and "Spline" resizing. All default values and encoded with UtVideo. Here are my results:

https://i.ibb.co/TYL9W0s/1-Test-Clip-2160p-F.jpg

and

https://i.ibb.co/MC8S74K/1-Test-Clip-2160p-D.jpg

and

https://i.ibb.co/6g26D0L/1-Test-Clip-2160p-A.jpg

and

https://i.ibb.co/4Nt4sBp/2-Test-Clip-2160p-F.jpg

and

https://i.ibb.co/p1kyB64/2-Test-Clip-2160p-D.jpg

and

https://i.ibb.co/gJH8LrQ/2-Test-Clip-2160p-A.jpg

I think the results with Avidemux look the best, but I'd prefer to use your LinearTransformation because it's faster and I can fine-tune the resizing and encoding options. Would you have a suggestion(s) how to tweak the settings to "brighten" the results?

Edit: Apologies for the massive images; not sure how fix that...

[Emulgator]

No apologies needed, nice comparison !
Judging from two panels (10bit-100%DCI-P3 + 8bit-100%NTSC) both France BB and Donald Grafts look fabulous,
France BB seems to match the hi-end panels, DG seems to match the majority of panels ATM (and AviDemux seems overdone).

[LouieChuckyMerry]

Emulgator: Thanks for your informative reply :) . I agree that the Avidemux results seem a bit overdone but, on both my laptops, they appear much less overdone than the other two appear underdone, at least to my eyes. Granted, both laptops are at least ten years old and have 1600x900 14" screens. By underdone I mean that they're slightly dark, with the FranceBB's looking a bit darker than the Donald Graft's; it's as if I'm wearing sunglasses relative to the Avidemux's, and with slightly darker lens when viewing the FranceBB's. I guess I'll check things out on my HDTV.

[FranceBB]

I noticed that you're using the v2 cube.
That version targets 50k$ Sony reference monitors for up to 4000 nits PQ contents (technically also above as it doesn't clip but rolls back to 100 nits all values 'till 10000 with a knee, but still).
Your content clearly has a much lower MaxCLL, therefore you should really use v1.

To put it in your own code:

ConvertToPlanarRGB(Matrix="Rec2020", Interlaced=False)
ConvertBits(Bits=16)
Spline36Resize(1920,1080)
Cube("F:\InstalledPrograms\AviSynth+\LUTs\PQ_to_BT709_v1.cube", Fullrange=True)
ConvertToYUV420(Matrix="Rec709")



Judging from two panels (10bit-100%DCI-P3 + 8bit-100%NTSC) both France BB and Donald Grafts look fabulous,
France BB seems to match the hi-end panels, DG seems to match the majority of panels ATM (and AviDemux seems overdone).

:D
Yeah, Avidemux is really off in this case.
And you're right, I did it targeting the professional broadcast monitors we have here at work while looking at the Tektronix Waveform Monitor connected via SDI, so not really surprising ehehehehehehe
But I'm glad it all checks out. :)

[LouieChuckyMerry]

Emulgator: Oooweeee! I'm glad I checked things out on my HDTV. And I admire your restraint, as "overdone" is very generous of you. Actually, "...France BB seems to match the hi-end panels, DG seems to match the majority of panels ATM..." seems spot on. Thanks again :) .
_____________

FranceBB: Thanks for the information and suggestion; I'll run new tests comparing The Donald Graft Method to The New, Improved FranceBB Technique then make a choice. Ahhh, and don't blame Avidemux; it was 100% operator error ;-) .
_____________

EDIT: Happy Friday! The results with PQ_to_BT709_v1.cube are excellent for color and black & white sources, and I thank you again for your kind help :) .

[FranceBB]

Linear Transformation v2.5 Released! (https://github.com/FranceBB/LinearTransformation/releases/)

- Introduced a new optional parameter "Interpolation" which is a string and can be set either to Trilinear or to Tetrahedral (default is Tetrahedral)
- Temporarily removed x86 support as version 1.4 of the main dependency, Donald Graft's avscube (http://avisynth.nl/index.php/AVSCube), is now x64 only :(

As an example, a new way to call the function is now:

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


The interpolation parameter can either be set to "Trilinear" or "Tetrahedral" and by default it's set to Tetrahedral as it achieves better results.
Source (left) - Trilinear (center) - Tetrahedral (right):
https://user-images.githubusercontent.com/18946343/270301165-f742fb52-e382-4317-abf4-342c55a1790c.png

As you can see, in the right hand side waveform (tetrahedral) there are no ripples, unlike the ones you can see in the trilinear interpolation at the center.

I've already ported the new parameters to FFAStrans 1.4 as well so that they can be selected from the GUI

https://i.imgur.com/MgNhTFJ.png

although FFAStrans 1.4 is still in beta so it's not public yet as we're testing it extensively.

[spoRv]

Great FranceBB, thanks!

[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).

TIA
prowo

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

[FranceBB]

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:

https://i.imgur.com/ncaoDaq.png
https://i.imgur.com/JcHt2hX.png





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! (https://github.com/FranceBB/LinearTransformation/releases/)

- 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):

https://i.imgur.com/hicOV8a.png

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

https://i.imgur.com/OemhDyz.png



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:

https://i.imgur.com/92chDr2.png
https://i.imgur.com/Y7iiCBA.png


as per mojie126's request (https://github.com/FranceBB/LinearTransformation/issues/3). ;)

[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 should have:

Source dvhe0509 -> IPTc2 -> Proprietary Metadata interpreter (RPU) -> 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, for instance if the input is dvhe0509 with ITP PQ, that LUT can't be used.
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 (RPU) 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 interpret wrongly.

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

[coolgit]

Is dvhe0509 (dvhe.05.09) the HDR format as my video has dvhe.08.06, so doesn't work?

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

I am just curious to why you have dvhe to 709 but not the other way around. I am sure some computer geek will crack the Dolby metadata one day.

I have just bought a new 4k tv with HLG, HDR10, HDR10+, dolby vision after the last tv went kaput last week just before Black Friday... perfect timing. I have been using different HDR versions of a film to see one is best. There isn't much different between HDR10, +, dolby. Dolby is slighty better when dealing with white levels as both HDR10 and + brightness tend to stick out like a sore thumb sometimes. Dolby is more subtle.

[FranceBB]

Is dvhe0509 (dvhe.05.09) the HDR format as my video has dvhe.08.06, so doesn't work?

That's correct, you can't use the dvhe0509 LUT on dvhe0806, it's not gonna work.


There isn't much different between HDR10, +, dolby. Dolby is slighty better when dealing with white levels as both HDR10 and + brightness tend to stick out like a sore thumb sometimes. Dolby is more subtle.

Well the difference between HDR10 and 10+ is literally just dynamically changing metadata in the header so you would benefit from it only if your TV has less nits than the actual ones the content was mastered for.
This is because if the content was mastered on more nits than the ones of your actual TV, your TV would have to read the maxCLL value declared in the header and remap it to its own maximum (HDR10) however if we have something extreme like with lots of computer generated graphics that skyrockets to 5000 nits (I'm saying this 'cause afaik there's no camera with enough stops to capture more than 3300 nits currently, so it has to be computer generated content) and your TV is, let's say, an 880 nits OLED TV, it would have a really hard time with all the other scenes as they would have to be remapped much lower. This is where HDR10+ comes in to help with dynamically changing metadata in the header, the maxCLL value now refers to the scene so that you don't have the global one only. There's still the global one to be backwards compatible with normal HDR10 devices, however for those that can read the metadata in the header they're gonna be able to adapt and remap the peak dynamically thus achieving a far better result.

Last but not least is Dolby Vision which has so many flavors right now unfortunately that it's hard to compare them all.

IPTc2 dvhe0509 has no technological advancement over HDR10 and HDR10+ 'cause those two are PQ based while IPTc2 is more on the SDR side. It's still considered HDR but the luma is shaped to peak at around 80% turning pseduo-logarithmically to preserve the highlights while the blacks start lower as in SDR. The idea being that the shader interpreting the IPTc2 and the metadata can produce either an HDR version close to what HLG would look like on an HDR display and output a very good SDR version on an SDR display.
PQ on the other hand is a totally logarithmic curve which yields far better results on the HDR side as it preserves both blacks and highlights (but HDR10/10+ can't be displayed on an SDR display as a drawback).


Now going to what Dolby Vision should have actually sticked to, the dual layer profile, that one makes sense and does have some technological advancement over HDR10 and 10+. This is because it's literally two layers, so one layer with a normal UHD H.265 10bit HDR PQ encoded video and the second layer carrying dynamically changing metadata (you're gonna see it as a "fake" FULL HD stream that is completely green if you try to play it on a normal device). That thing there is the metadata layer and with that not only you have dynamically changing metadata like in HDR10+ but a proper Dolby Vision Dual Layer decoder would use it to display a perfect 12bit output and that's where Dolby Vision makes sense.

I have been using different HDR versions of a film to see one is best. There isn't much difference

Charles Poynton, the inventor of luma, once told me: "once the director signs a version off, no art should occur in the encoding process".

In other words, the goal of an encoder at that point is to make the different versions a movie is encoded to look as close as possible to each other while retaining the director's view and exploiting the advancement of one technology while compensating for the lack on another and so on.
The fact that you haven't been able to see major differences between the different versions of a movie means that such a job was done right by the person who encoded the movies. :)
For instance, when you target a DCI P3 XYZ theatrical release, you have to keep in mind that the peak is gonna be 48 nits but that the cinema room is gonna be completely dark and given that human vision separates in Photopic, Mesopic, Scotopic according to whether you're using rods, cones or both and that the less photons there are the less chroma you see, to make it look more "natural" you have to compensate for that on the chroma side. This is just one of the several things that encoders take into account when producing the final encoded output.
I'm just a guy who works on TV, so I haven't made many movies that ended up in the cinemas in my life (just a couple of documentaries, really) but, to a very lesser extent, I face those challenges too when producing the different TX Ready versions starting from the same master that need to then go on air. ;)

[coolgit]

Charles Poynton, the inventor of luma, once told me: "once the director signs a version off, no art should occur in the encoding process".

That would obviously be the standard policy. Makes sense too. I think the slight differences is that Dolby, hdr10+, adjusts the brightness and tone mapping per scene, so in some darkish scene the shadows on the face are subtle and better than hdr10, 709. In normal day brightness there is hardly anything. But if i watch it normally, instead of pausing, one doesn't see any differences unless one knows where to look and concentrate on finding the differences. In the real world no one going to do that, they just accept the marvellous quality output of colours. Having said that is there really any need for Dolby when hdr10+ does the same but better? When streaming and if the tv doesn't have hdr10+, it can default to hdr10. With Dolby it would default to SDR.

second layer carrying dynamically changing metadata

This is similar to overlay isn't it?

Here the thing that got me thinking for ages now. When you watch the Lord of the Ring, there is a lot of action/violence but given 12 rating, but a film with less violence is given 18 rating, simply because there is blood, whereas there isn't any in the Lord of the Ring. But in terms of cinema and dvds sales, the 18 rated film would earn less than a 12 rated film. What if the blood parts of any films is on the 2nd layer. There would be 2 versions, 12 and 18. In the cinema, especially most are multiplex, one room would be 12 rated so adult can dump their children in and squeamish people in, in another room 18 rated for adults only. The same for dvds. The menu can at the beginning would show 12 or 18 and the parents can decide which version they want. Surely this way could maximise the income/sales/ by not excluding a large share of the market. For me i wouldn't mind seeing blood squirting out of the chopped head in the Return of the King. The same would go for swear words not appropriate for under 18 by having 12 rated sounds and 18 rated sounds.

[FranceBB]

What if the blood parts of any films is on the 2nd layer. There would be 2 versions, 12 and 18

That ain't gonna work, unfortunately. One thing is adding an LSB kind of metadata to create a 12bit output, another is having a completely different version of the same movie (TL;DR you can't just add VFX).

Anyway it's an interesting idea, but it can't be done the way it currently is implemented.

is there really any need for Dolby when hdr10+ does the same but better?

dvhe? Nope, no advantage at all.
Dolby Vision dual layer? Yes, it would still default to 10bit HDR10 when watched on a standard decoder, but when watched on a proper Dolby Vision decoder it would not just have dynamically changing metadata like HDR10+ but it would also deliver 12bit and that's very important 'cause by standard on a totally logarithmic curve like PQ if you use only 10bit limited tv range code values you don't have enough bits to go all the way up to 10'000 nits, while with 12bit you do. Of course currently is a bit overkill 'cause there are no movies whatsoever graded at 10k nits, there are no monitors that can get to 10k nits and there are no cameras that can record enough stops to get to 10k nits, but eventually, in the future, we'll get there and that's where 12bit is gonna make a difference.

[coolgit]

That ain't gonna work, unfortunately. One thing is adding an LSB kind of metadata to create a 12bit output, another is having a completely different version of the same movie (TL;DR you can't just add VFX).

Anyway it's an interesting idea, but it can't be done the way it currently is implemented.

Maybe not 2nd layer but some sort of overlay like subtitles do in a separate file. If there can be many sub files and audio files then why not many video files?

Theoretically it should be possible.

[StainlessS]

That ain't gonna work, unfortunately. One thing is adding an LSB kind of metadata to create a 12bit output, another is having a completely different version of the same movie (TL;DR you can't just add VFX).
Maybe alternate 'angle' like DVD (I assume BD also has alternate angle capability).

[spoRv]

I know that conversion from(to) rec709 to(from) rec2020 is not lossless, but I assume (wrongly, perhaps?) that after a dual conversion, result should look *mostly* similar to the original clip.

I mean, given the clip as original source, then


clip
LinearTransformation(Input="Linear_BT709", Output="BT2100_PQ")
LinearTransformation(Input="BT2100_PQ", Output="Linear_BT709")


should look similar to untouched clip, right?

If so, why the dual conversion result is brighter than the original clip? There may be three options:

1) conversion from 709 to 2020 makes the clip brighter
2) conversion from 2020 to 709 makes the clip brighter
3) both of the previous ones

France, please help!

P.S. using the default PQ_to_BT709_v1.cube

[FranceBB]

The real answer is: "is complicated".
Let me explain.
What you said is absolutely true, you can't go to BT709 SDR and go back to BT2020 PQ losslessly as for such a transformation to be lossless you would need to map as many points to the output as the ones you have in the input (i.e a 1:1 and onto transformation). I'm not gonna say the word "isomorphism" 'cause otherwise mathematicians will scream at me saying that you can have lossless conversions even if they're not isomorphism 'cause an isomorphism is also preserving the structure, but anyway, that minor detail aside, you're right, such a conversion is not lossless.

The reason why you're seeing two very different results, however, has nothing to do with linear algebra in this sense, but rather to how those LUTs were made.
Essentially, the two LUTs you used were made with 2 very different inputs in mind.

Let's start with BT709.
As we can see, this peaks at 100 nits:

ColorBars(1920, 1080, pixel_type="YV24")
VideoTek(Mode="SDR", Type="nits")

https://i.imgur.com/1O7ClT2.png


Now, let's bring everything to BT2020 PQ:

ColorBars(1920, 1080, pixel_type="YV24")

ConvertBits(16)
ConvertToPlanarRGB()
Cube("C:\Program Files (x86)\AviSynth+\LUTs\BT709_to_PQ.cube", fullrange=1, interp=1)
ConverttoYUV444(matrix="Rec2020")

VideoTek(Mode="PQ", Type="nits")

https://i.imgur.com/juASK3O.png


As you can see, we went to around 400 nits.
This is because when we have BT709 SDR signals those might have completely white and clipped out stuff, especially for outside footages, so you don't really want to map the white too high to PQ otherwise you're gonna blind people at home. Remember that a completely clipped out sky at 100 nits is tolerable but if you bring it to 1000 nits or more, it can literally make the person sitting at home watching it very uncomfortable, especially if it's in a transition from a darker scene.


Anyway, if we apply the LUT to go back to BT709 SDR we're gonna be in trouble 'cause that LUT assumes a much higher MaxCll (not 1000 nits but it definitely something around that), while our content (the fake BT2020 HDR PQ we just converted from BT709 SDR) only really has 400 nits.

So... what's gonna happen?
Well, everything will be dimmer.

ColorBars(1920, 1080, pixel_type="YV24")

ConvertBits(16)
ConvertToPlanarRGB()
Cube("C:\Program Files (x86)\AviSynth+\LUTs\BT709_to_PQ.cube", fullrange=1, interp=1)
Cube("C:\Program Files (x86)\AviSynth+\LUTs\PQ_to_BT709_v1.cube", fullrange=1, interp=1)
ConverttoYUV444(matrix="Rec709")

VideoTek(Mode="SDR", Type="nits")

https://i.imgur.com/eSyxMyl.png


As you can see, the peak brightness (i.e the white) isn't at 100 nits any longer once we got back to BT709 SDR but it's actually lower.

If we use PQ_to_BT709_v2.cube then things will get even worse as that one is gonna assume an even higher MaxCll (more than 1000 nits) thus lowering the peak brightness of the BT709 SDR clip even further at the end of the roundtrip:


ColorBars(1920, 1080, pixel_type="YV24")

ConvertBits(16)
ConvertToPlanarRGB()
Cube("C:\Program Files (x86)\AviSynth+\LUTs\BT709_to_PQ.cube", fullrange=1, interp=1)
Cube("C:\Program Files (x86)\AviSynth+\LUTs\PQ_to_BT709_v2.cube", fullrange=1, interp=1)
ConverttoYUV444(matrix="Rec709")

VideoTek(Mode="SDR", Type="nits")

https://i.imgur.com/AKZlpki.png


By the way, apologies for the late reply.
I didn't really have that much time these days as I spent from 08.30AM to 10.00PM in the office with 30 minutes lunch and dinner breaks in between.
Once I got home I couldn't do anything other than getting undressed, brushing my teeth and crumbling to bed.
Then it was just a matter of opening my eyes and doing this all over again.

[wswartzendruber]

By the way, apologies for the late reply.
I didn't really have that much time these days as I spent from 08.30AM to 10.00PM in the office with 30 minutes lunch and dinner breaks in between.
Once I got home I couldn't do anything other than getting undressed, brushing my teeth and crumbling to bed.
Then it was just a matter of opening my eyes and doing this all over again.
Everyone here is happy about your community involvement and benefits from it, but don't forget to take care of yourself.

[spoRv]

France, thanks for the answer; worry not about late replies... and again, thanks for your efforts and time!

By the way, full screen white at around 900 nits or so (like in The Matrix) is painfully good! :D Those were good times when colourists DID NOT use OLED TVs as their reference monitors, with their meager 150/200 nits full screen... but I digress.

Just another question: diffuse white should be set at 100 nits for SDR; and at 203 nits in PQ, right? If so, why your LUT puts it around 400 nits?

[FranceBB]

Well, once again, the answer is complicated. In SDR you have a maximum of 0.7V, which correspond to 100 nits and that's absolutely fine. In PQ, you have the reference white at 0.40V, which is indeed 203 nits. Then, of course, you have specular highlights of different things inside the scene that exceed that and can go as high as you want them to be. So far so good. The problem, however, is that here we're using an SDR content as our source and unfortunately in SDR there aren't things like specular highlights, there are just... highlights. If we map our peak brightness (i.e 100 nits) to be the reference white in PQ (i.e 203 nits) then we would technically be correct and that's what a lot of software do, however we wouldn't have any kind of "HDR" at all. In other words, if you were to see such a movie, you would immediately spot that it originated from an SDR master and that it was just a very simple conversion. I know that we're talking about BT709 to BT2020 PQ, but the BBC offers the 5a LUT to go from BT709 to BT2020 HLG in order to make the content "look close to the original SDR when watched in an HDR 1000 nits monitor" and those sure enough go to 400 nits.

BT709 SDR 100 nits (source)
BT2020 HDR HLG 400 nits (BBC LUT 5a)
https://i.imgur.com/vO1AAoh.png

So, not only I've done the same thing in my BT709 SDR to BT2020 HDR HLG LUT, but I've also applied the very same logic in my BT709 SDR to BT2020 HDR PQ LUT as in both cases I'm mapping 100 nits SDR to 400 nits in HDR (it's actually 420 as I did the original math wrong a long time ago, but I left it as is as nobody ever complained).


BT2020 HDR PQ content after my LUT has been applied to the BT709 SDR source:
https://i.imgur.com/ibkcItW.png


As I mentioned last time round, however, for a roundtrip you would need a LUT that brings everything to 1000 nits PQ and then go back to 100 nits BT709, but that's risky as you might end up with very undesirable results, which is why I settled on 400 nits (yes, fine, 420, but whatever). As to why 400 nits and not higher, it's because in SDR you might indeed get nicely graded movies that can pop and look very nice in the HDR conversion, but you can also get clipped out whites. Take a look at this scene:

https://i.imgur.com/x2ovo7H.png

The outside of the window is completely clipped out and that's 100 nits in SDR. If we were to bring it to 1000 nits in HDR PQ, then we would make the viewer feel uncomfortable, especially if he's watching the movie during the evening, after dinner, in a pitch dark living room. At 400 nits, however, it's not gonna make the user uncomfortable.

[spoRv]

Thanks for the explanation, France!

Now for the next release, SDR->PQ 400/420 nits correction! :p

[asarian]

Absolutely brilliant stuff! Got it all to work nicely.

Now, for re-encoding with x265, dgdecodenv always handily gives me this type of info on existing HDR movies:

--colorprim 9 --transfer 16 --colormatrix 9 --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)" --max-cll "203,21" --frames 222217 --chromaloc 2

When I do a SDR2HDR conversion myself, with these LUTs, where can I get this info from? Especially the --master-display parameters, so I can actually write the output correctly to disk, using x265. Thanks.

[FranceBB]

Absolutely brilliant stuff! Got it all to work nicely.

I'm glad to hear that. :)
I started this project back in 2019 'cause lots of companies were offering .cube files to perform various kind of conversions for a pretty penny ($150 or even $300) and I thought it wasn't fair as those are really just matrices that take map some values in an input to some other values in output and were supposed to be free and open source for everyone. Since then, lots of people started using them and they've been included in several projects the likes of FFAStrans and Hybrik to name a few, which actually made me happy. So, the more people use them, the better. :D


When I do a SDR2HDR conversion myself, with these LUTs, where can I get this info from? Especially the --master-display parameters, so I can actually write the output correctly to disk, using x265.
Well, in SDR we can always expect the input to peak at 0.7V i.e 100 nits in Limited TV Range which corresponds to 235 in 8bit and 940 in 10bit.
The conversion takes that and maps it to 400 nits in both HLG and PQ (they correspond to different millivolt levels due to the difference in nature between those two curves), so you can set the following values in your x265 command line.

For HLG:

--min-luma 64 --max-luma 940 --chromaloc 2 --range limited --videoformat component --colorprim bt2020 --transfer arib-std-b67 --colormatrix bt2020nc --atc-sei 18 --overscan show

This is not a mistake, in HLG you don't need to specify the mastering display, nor the MaxCll as they're not mandatory and the TV will adjust automatically anyway. If the TV is BT2020 SDR 100 nits, it will ignore the HLG transfer and it will display it as-is by only interpreting the colormatrix and primaries. Sure, whites will be dimmer compared to an SDR signal, but it will look ok-ish and that's the intended output and the whole reason why HLG was invented (i.e to have one single linear channel which allows people with HDR and BT2020 SDR TVs to see it without having to air two channels for the same content and waste bandwidth on the already overcrowded satellites like Hotbird, Astra etc).

For PQ:


--min-luma 64 --max-luma 940 --chromaloc 2 --range limited --videoformat component --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0.0050)" --max-cll 400,200 --overscan show


In PQ the metadata are mandatory, so you can include them as per the section above given that the conversion from SDR will output 400 nits.


In both cases, I'm assuming that you're encoding in 10bit limited tv range, hence the min-luma max-luma, but you can either change those (if you're targeting 12bit) or remove them if you don't want them there as they're not mandatory anyway. Last but not least, I included --chromaloc 2 as 4:2:0 Type 2 'cause I noticed that you were targeting it, however keep in mind that Cube() will perform all the calculations in RGBPS (i.e RGB 16bit), so when you then go back to YUV 4:2:0 you need to convert the chroma placement yourself.
I know that you're using VapourSynth and not AviSynth, so I'm afraid I can't help you with that. I'm sure that there are plenty of people who can help you in the VapourSynth section with a conversion from RGBPS (i.e RGB 16bit which doesn't have a chroma placement 'cause chroma is the same resolution as luma given that they're one and the same) to YUV 4:2:0 Type 2 (chroma placement top left), but as a safety net if you can't find a way to do that in VapourSynth, you could always output YUV 4:2:0 16bit with the left chroma placement (i.e the old standard MPEG-2 placement) and then perform the conversion to top left (i.e coordinates 0-0) within FFMpeg before piping it to x265 like this:


ffmpeg.exe -i "AVS Script.avs" -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe --y4m - --dither (other encoding options) -o "raw_video.hevc"


(again, it says AVS Script.avs but I would imagine the same applies to VPS Script.vpy).


In this example below (apologies, it's Avisynth again) I've grouped the results of the HLG and PQ conversions starting from the BT709 SDR 100 nits source:

video=LWLibavVideoSource("V:\fs0\clip.dir\UAT11887.mxf")
audio=LWLibavAudioSource("V:\fs0\clip.dir\UAT11887.mxf", stream_index=4)
AudioDub(video, audio)
ConvertBits(16)
ConvertToPlanarRGB()
source=last



Cube(source, "C:\Program Files (x86)\AviSynth+\LUTs\BT709_to_HLG.cube", interp=1, fullrange=1)
Converttoyuv420()
VideoTek(Mode="HLG", Type="nits")
Crop(0, 0, -0, -520)
Subtitle("BT2020 HDR HLG")
my_hlg=last

Cube(source, "C:\Program Files (x86)\AviSynth+\LUTs\BT709_to_PQ.cube", interp=1, fullrange=1)
Converttoyuv420()
VideoTek(Mode="PQ", Type="nits")
Crop(0, 0, -0, -520)
Subtitle("BT2020 HDR PQ")
my_pq=last


Converttoyuv420(source)
VideoTek(Mode="SDR", Type="nits")
Crop(0, 0, -0, -520)
Subtitle("BT709 SDR")
my_bt709=last


StackVertical(my_bt709, my_hlg, my_pq)



and as you can see the conversion is proportional, so if things peak at 100 nits in SDR, they're gonna peak at 400 nits in both HDR HLG and HDR PQ:

https://i.imgur.com/qXIfDh4.png

however if they peak lower in the SDR version, they're also gonna peak lower in the HDR HLG and HDR PQ versions (in this case around 80 nits in SDR correspond to 200 nits in HDR HLG and HDR PQ in the conversion:

https://i.imgur.com/QTRacir.png

[asarian]

I'm glad to hear that. :)

You are a brilliant man, in whatever thread I find you.:goodpost:

Thank you again, profusely for this very extensive info! Can't believe you went out of of your way like this, with so much invaluable information! I shall all eagerly take it to heart! :thanks:

[asarian]

--min-luma 64 --max-luma 940 --chromaloc 2 --range limited --videoformat component --colorprim bt2020 --transfer arib-std-b67 --colormatrix bt2020nc --atc-sei 18 --overscan show

I'm gettimg dangerously close to a valid HDR output. :) I used this line:

VSPipe -c y4m "f:\jobs\hdr.vpy" - | x265-new --y4m --input - --preset medium --input-depth 10 --output-depth 10 --crf 13 --hdr --min-luma 64 --max-luma 940 --chromaloc 2 --range limited --videoformat component --colorprim bt2020 --transfer 16 --colormatrix bt2020nc --atc-sei 18 --overscan show --output "i:\video\hdr.hevc"

And this script:

import vapoursynth as vs

core = vs.core
core.max_cache_size = 65535

vid = core.lsmas.LibavSMASHSource(r"f:\veai\alientest_iris2-00.11.57.773-00.12.46.554.mov")
vid = core.resize.Bicubic(vid, matrix_in_s="709", format=vs.RGBS)
vid = core.timecube.Cube(vid, cube=r"C:\VS\plugins\BT709_to_HLG.cube")
vid = core.resize.Point(vid, matrix = 1, format = vs.YUV422P10)
vid = core.neo_f3kdb.Deband (vid, preset="veryhigh", dither_algo=2)

vid.set_output ()


Not getting an 'HDR10 compatible' notice in MediaInfo, though. I reckon I either import from wrong colorspace, or convert erroneously. Movie is .mov, 422 HQ (the only lossless option TVAI offers). So, probably doing something wrong. But output is 422 BT 2020 (10-bit), so I can't be all that far off.

[FranceBB]

Not getting an 'HDR10 compatible' notice in MediaInfo, though.

Mediainfo is right, HDR10 means PQ 10bit, while you're encoding in HLG 10bit. It's still HDR, but not HDR10, it's a different standard. ;)

[asarian]

Mediainfo is right, HDR10 means PQ 10bit, while you're encoding in HLG 10bit. It's still HDR, but not HDR10, it's a different standard. ;)

And that shows my ignorance. :sly: Thanks for your patience.

N.B. 422 effectively produces an unplayable movie for me (like at 2 fps). I know of no media player that can do this, btw, so 420 it will have to be.

The colors and brightness were excellent, btw! :thanks:

[FranceBB]

N.B. 422 effectively produces an unplayable movie for me (like at 2 fps). I know of no media player that can do this, btw, so 420 it will have to be.


Yeah, that's probably because with 4:2:2 it goes all into software decoding putting all the load on the CPU, while with 4:2:0 it uses hardware decoding and it's therefore smooth during the playback. :)


The colors and brightness were excellent, btw! :thanks:


Nice! I've used it in production for a while so it would have been a problem if it was otherwise eheheheh
On that, if you're going to 4:2:0, remember to either convert to top left the chroma location or remove the --chromaloc 2.
As for the chroma resizing, don't use BilinearResize and PointResize. Especially the latter it's based on nearest neighbours and should never be used in practice. At work I generally use Spline64Resize, but I guess a windowed Sinc resizer like LanczosResize or BlackmanResize would also do.

[Z2697]

--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0.0050)"

That last value, 0.0050, might be wrong?

[asarian]

On that, if you're going to 4:2:0, remember to either convert to top left the chroma location or remove the --chromaloc 2.

Another bit of valuable information!

So, just remove --chromaloc 2 altogether? Good thing I caught your reply in time, as I was aready 10 minutes in, reencoding the movie. :)

Should I perchance remove --hdr too? (as it's not HDR10).

As for the chroma resizing, don't use BilinearResize and PointResize. Especially the latter it's based on nearest neighbours and should never be used in practice. At work I generally use Spline64Resize, but I guess a windowed Sinc resizer like LanczosResize or BlackmanResize would also do.

Awesome! Using core.resize.Spline64 now.

[Z2697]

Another bit of valuable information!

So, just remove --chromaloc 2 altogether? Good thing I caught your reply in time, as I was aready 10 minutes in, reencoding the movie. :)

Should I perchance remove --hdr too? (as it's not HDR10).



Awesome! Using core.resize.Spline64 now.

Remove chromaloc, yes, or since other HDR materials are chromaloc=2, designate the chromaloc when you converting RGBS back to YUV420P10. Use the chromaloc argument of core.resize. Conveniently the same name and same meaning of values.

[Z2697]

You can even do it at playback ;)
mpv --target-colorspace-hint=yes --vf=format=gbrpf32le,lut3d=file=BT709_to_PQ.cube,zscale=p=bt2020:t=smpte2084:pin=bt2020:tin=smpte2084
zscale is for "tagging" the video as PQ + Rec.2020 but perhaps there's filter for the specific job, I'm just more familiar with zscale

[FranceBB]

That last value, 0.0050, might be wrong?

"au contraire", I would say, it's actually correct.

--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0.0050)"

means


Mastering display color primaries: Display P3
Mastering display luminance: min 0.0050 cd/m², max: 1000 cd/m²


You can try yourself by using that in x265 and then checking Mediainfo on the newly produced raw_video.h265 file. ;)

[Z2697]

"au contraire", I would say, it's actually correct.



means



You can try yourself by using that in x265 and then checking Mediainfo on the newly produced raw_video.h265 file. ;)

I thought you mean 0.0050 cd/m^2 which should be 50 in the command.
But the reason of it "means" 0.0000 cd/m^2 is that it is parsed as unsigned integer in x265.
https://bitbucket.org/multicoreware/x265_git/src/7b5332d9df9a26204861009a9d68f28a2898e3ea/source/encoder/sei.h#lines-596:609

Anyway, that will not produce error in practice, and there's no use of the master-display information... that I know of. Do you happen to know some of the use case?

[FranceBB]

I thought you mean 0.0050 cd/m^2 which should be 50 in the command.
But the reason of it "means" 0.0000 cd/m^2 is that it is parsed as unsigned integer in x265.
https://bitbucket.org/multicoreware/x265_git/src/7b5332d9df9a26204861009a9d68f28a2898e3ea/source/encoder/sei.h#lines-596:609


Ah crap, you're absolutely right.


there's no use of the master-display information... that I know of. Do you happen to know some of the use case?


It's ignored by literally every player as it has no real use, so yeah it won't make any difference.
By the way, good catch, but now I'll just put it to 0 to be safe. Something like:

--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0.0000)"

should be just as safe. :)

[ProWo]

Hi FranceBB

I'm using your LinearTransformation.avsi script with Avisynth64+ with this setting:
LinearTransformation(Input="Linear_BT709", Output="BT2100_PQ")

Encoding the resulting avs with FFmpeg gives (as input):
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p(tv, bt2020nc/bt709/smpte2084, progressive)

Should bt2020nc/bt709/smpte2084 not be bt2020nc/bt2020/smpte2084?

The mediainfo from the resulting video shows:

Color primaries : BT.709
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant

Color primaries should be BT.2020

Maybe the error in the script is here:
output_Matrix =
\ : Input=="Linear_BT709" && Output=="BT2100_PQ" ? ("Rec2020")


Thx for your help.

[FranceBB]

Oh crap. I'm correctly overriding the matrix and transfer but I'm not setting the primaries at all.
If you need a quick and dirty fix, add this in your Avisynth script after the LinearTransformation() call:

propset("_Primaries", 9)

Anyway, aside from that, can you please test this new version and let me know if it works?

https://github.com/FranceBB/LinearTransformation/blob/master/LinearTransformation.avsi

If it does, then I'll make a release tomorrow morning. ;)

[asarian]

Oh crap. I'm correctly overriding the matrix and transfer but I'm not setting the primaries at all.

Oh crap, does this go for the VapourSynth 'cube' too?

[ProWo]

Oh crap. I'm correctly overriding the matrix and transfer but I'm not setting the primaries at all.
Anyway, aside from that, can you please test this new version and let me know if it works?

https://github.com/FranceBB/LinearTransformation/blob/master/LinearTransformation.avsi

If it does, then I'll make a release tomorrow morning. ;)
Success, it works fine now. Thanks. :)

[Z2697]

Oh crap, does this go for the VapourSynth 'cube' too?

This is just metadata, if you specified the right one when you use resize to convert RGB back to YUV it should be fine, actually if you don't specify or used wrong one, the actual colors shouln't be altered at all, you can easily fix the metadata in encoding parameters or even encoded bitstream.

[asarian]

This is just metadata, if you specified the right one when you use resize to convert RGB back to YUV it should be fine, actually if you don't specify or used wrong one, the actual colors shouln't be altered at all, you can easily fix the metadata in encoding parameters or even encoded bitstream.

Thank you! You got me worried there for a moment. :D

MediaInfo always reported the right colorspace; juat wanted to be sure.

[Z2697]

Thank you! You got me worried there for a moment. :D

MediaInfo always reported the right colorspace; juat wanted to be sure.

Actually, there's a little caveat: because core.resize read and use colorspace information from frame props if they exist, if your frame is flagged as "bt709" and you specify primaries_s when converting, it might perform bt709 -> bt2020 conversion rather than setting the property only.

I'd suggest clear the related frame properties when using core.resize to perform "colorimetric" conversion.
(What's the collective name for matrix, transfer and primaries conversion?)

[asarian]

Actually, there's a little caveat: because core.resize read and use colorspace information from frame props if they exist, if your frame is flagged as "bt709" and you specify primaries_s when converting, it might perform bt709 -> bt2020 conversion rather than setting the property only.

I'd suggest clear the related frame properties when using core.resize to perform "colorimetric" conversion.
(What's the collective name for matrix, transfer and primaries conversion?)

Well, did a small test:

import vapoursynth as vs
core = vs.core
core.max_cache_size = 65535

import havsfunc as haf

vid = core.dgdecodenv.DGSource (r'c:\jobs\repo-00.01.16.497-00.02.09.085.dgi')
vid = core.resize.Spline64(vid, matrix_in_s="709", format=vs.RGBS)
vid = core.timecube.Cube(vid, cube=r"C:\VS\plugins\BT709_to_HLG.cube")
vid = core.resize.Spline64(vid, matrix=9, format = vs.YUV420P10)

vid.set_output ()

MediaInfo says 'Color prmaries BT.2020' on output.

But that may be because of setting (mandatory) 'matrix' in core.resize.Spline64, so I can't really tell what comes out of the BT709_to_HLG line (though it should be BT.2020).

So, should I change something?

[VoodooFX]

@FranceBB Maybe you would want to add LUts for videos from DJI drones?

Because I looked at your thread first when I needed them. :D

https://forum.videohelp.com/threads/416286-DLog-video