FranceBB LUT Collection

[frank]

For transcoding you only need ffmpeg. It works faster and accurately. Here an example for conversion PQ HDR to SDR BT709 in Windows 10.

ffmpeg64.exe -i input.uhd.mkv ^
-vf scale=1920x1080:flags=bicubic,lut3d='D\:/INSTALL/LUT/PQ_to_BT709_v1.cube',format=yuv420p ^
-c:v libx264 -preset fast -crf 20 ^
-g 48 -bufsize 15M -maxrate 15M ^
-force_key_frames chapters -forced-idr 1 ^
-color_primaries bt709 -colorspace bt709 -color_trc bt709 ^
-c:a copy ^
movie.mkv

The lut3d filter reads the 10 bit input into rgb48 and applies the matrix. You get about 12 fps speed on a notebook.
lut3d needs the absolute path to the LUT with slashes like in Linux. Path variables don't work.
No Avisynth 16 bit is needed. You can apply filters from ffmpeg.

Thanks for your great work, Frank!

[FranceBB]

Well, you're welcome.
As a side note: last time I tried, ffmpeg wasn't able to read large matrices like 64x64x64 but was working fine with 32x32x32 ones and 16x16x16 ones as well. As result, some of the most accurate LUTs were not applied and resulted in an error. I don't know whether someone updated the lut3dfilter or not, but in case they didn't, just keep in mind that it might not work. If you wanna try, try to use the PQ to HLG matrix (which is definitely a 64x64x64) and check whether ffmpeg complains about it being too large or not: if it does, then they didn't update it, if it doesn't, then they updated it and I'm gonna add it as an example of how to use my LUTs.

[wswartzendruber]

I need to remember to compare your hand-tuned LUTs to my CLI utility.

EDIT: Actually, that would be stupid. I need to get a HLG display of some kind first.

[frank]

Test with Jaws (HDR10+) and PQ_to_HLG.cube - it works.
I used NVIDIA hevc_cuvid decoder to get rid of the annoying messages "hevc: Skipping NAL unit 62" and for quick resizing.

ffmpeg64.exe -v verbose ^
-c:v hevc_cuvid -resize 1920x1080 -r 24000/1001 -i "input.uhd.mkv" ^
-vf lut3d='D\:/INSTALL/ffmpeg/PQ_to_HLG.cube',format=yuv420p10le ^
-c:v libx265 -profile:v main10 -preset fast -crf 18 ^

[hevc_cuvid @ 000002ac571c6100] Formats: Original: nv12 | HW: p010le | SW: p010le
[graph 0 input from stream 0:0 @ 000002ac57402c80] w:1920 h:1080 pixfmt:p010le tb:1001/24000 fr:24000/1001 sar:1/1
[auto_scaler_0 @ 000002ac57403f80] w:iw h:ih flags:'bicubic' interl:0
[Parsed_lut3d_0 @ 000002ac57403e80] auto-inserting filter 'auto_scaler_0' between the filter 'graph 0 input from stream 0:0' and the filter 'Parsed_lut3d_0'
[auto_scaler_1 @ 000002ac57403780] w:iw h:ih flags:'bicubic' interl:0
[Parsed_format_1 @ 000002ac57403680] auto-inserting filter 'auto_scaler_1' between the filter 'Parsed_lut3d_0' and the filter 'Parsed_format_1'
[auto_scaler_0 @ 000002ac57403f80] w:1920 h:1080 fmt:p010le sar:1/1 -> w:1920 h:1080 fmt:rgb48le sar:1/1 flags:0x4
[auto_scaler_1 @ 000002ac57403780] w:1920 h:1080 fmt:rgb48le sar:1/1 -> w:1920 h:1080 fmt:yuv420p10le sar:1/1 flags:0x4
x265 [info]: HEVC encoder version 3.4+15-g45f1d01f8
x265 [info]: build info [Windows][GCC 10.2.0][64 bit] 10bit

Latest ffmpeg self compiled (Zeranoe emulating) with media-autobuild suite. No errors but contrast is too high on SDR display. I have no HLG capable device.

[FranceBB]

Great, then they updated ffmpeg!
Good to know, the more the merrier.
I added the ffmpeg example in the first post.

[shph]

Not sure why this info is so hidden by FranceBB, but looking to screenshots these LUTs are generated in well known LUTCalc https://cameramanben.github.io/LUTCa...alc/index.html

[FranceBB]

Originally Posted by shph

Not sure why this info is so hidden by FranceBB, but looking to screenshots these LUTs are generated in well known LUTCalc https://cameramanben.github.io/LUTCalc/

Not hidden at all, LUT Calc is a great tool made by Ben Turley and I would recommend it to everyone, however it's not the only thing I use of course, as I manually make calculations and I check and modify them in Davinci Resolve with a Decklink card outputting the SDI to a broadcast 4K Sony reference monitor, its scope, Davinci's scope and a Tektronix. In other words, there's a lot of manual work involved 'till I get things right. If you feel like using LUT Calc yourself, feel free and I invite everyone who wants to try any LUT Calculation software to try it out, but again you gotta make sure to understand what you're doing and to make correct calculations as you can't really select an input curve and an output curve and expect a software to do its magic. Also 'cause it may or may not have some parameters or other things; for instance, when I made the Z-Log to Linear BT709 SDR matrix, it was completely from scratch as there was only the official documentation; after all it was a brand new color curve and many software haven't been updated for quite some time; for instance LUT Calc hasn't been updated since 2017 and has no clue about Z-log. That's why I said that there's a lot of manual work involved. I personally love Linear Algebra, it's literally my favorite subject and what I find fascinating is how a matrix gives you the feeling to almost morph the space you're working on and it can be applied to pretty much everything, from geometry to computer science. In this very case, a matrix basically maps points from an input space to some other points to the output and could actually be identified as a function; looking at it as a function, it indeed can be either an Homomorphism or not (in fact we can talk about surjective and bijective, also known as 1-1 and onto). So, depending on the input and output points you have different "mapping functions", i.e matrices with different properties. Of course, nobody writes each and every own value of a matrix individually in real life scenarios (unless they're very small matrices like the one you write in your class which generally don't go beyond 5x5 while in the real world we have thousands of coeffs.) as we all use models and this is where something to calculate LUTs can come in handy, either working in Matlab, Julia, LUT Calc will do.



To everyone who wants to try it out (if you didn't attend at least a linear algebra class), I definitely suggest MIT Lectures by Gilbert Strang on Julia and Linear Algebra, he's probably the best in his field. If you don't wanna take such a course and you wanna have only a "vague" idea of how these things work, then I suggest you to watch the "Essence of Linear Algebra" series by Grant Sanderson (3blue1brown). As to my personal YT channel, unlike what I did with Electrical Engineering and Digital Electronics, I've posted things about Linear Algebra but not as a course, but instead as solution to several exercises out of fun and 'cause I thought they might be useful for other engineering students, but I didn't really make it as a course with lectures, so it's NOT something a beginner should be watching.

By the way, if it pleases more people, Shph, I can write a more detailed process about how these things work (or at least, about what my understanding of these things is) and what I do, including all the tools I use to make my matrices, it's not a big deal.
The only reason I opened this topic a while ago was 'cause I had to make matrices myself for things I had to do (I work in broadcast) and I was amazed by how many companies were ripping off people by selling their matrices for a lot of money and I wanted to do something for other people by making all my matrices free. Again, while a company hires several engineers to make calculations and test matrices over and over again, the ones I make are only made by myself, so they may not be as accurate and studied as the ones done by Avid or Blackmagic or Adobe or the BBC etc, but I try to keep everything mathematically correct and most importantly free and open. I didn't even expect other people to use them, actually, this topic kinda had much more success than I expected which means that there's a genuine willingness by people to use them and, as long as other people or my company will ask me to make them or work at something, I'll keep making them and posting them here. So, all in all, I think it's an happy ending. In the meantime, I'll share some useful links.


Useful Links:

Matlab: https://uk.mathworks.com/downloads/
Julia: https://julialang.org/
BBC White Papers 283: https://www.bbc.co.uk/rd/publications/whitepaper283
BBC White Paper: http://downloads.bbc.co.uk/rd/pubs/p...tion_Guide.pdf
LUT Calc: https://cameramanben.github.io/LUTCalc/
MIT Lectures by Gilbert Strang about Linear Algebra: https://www.youtube.com/playlist?lis...1E2BBF13BECF6C
MIT Lectures about Julia: https://www.youtube.com/playlist?lis...PY-wt2mEouZgaZ
Essence of Linear Algebra by Grant Sanderson: https://www.youtube.com/watch?v=fNk_...2xVFitgF8hE_ab


Other free alternatives to my LUTs:

HDRTools by Jean Philippe Scotto di Rinaldi: https://forum.doom9.org/showthread.php?t=175488
DGHDRtoSDR by Donald Graft: http://avisynth.nl/index.php/DGHDRtoSDR

[shph]

Yes, LUTCalc is not a simple one click tool and may need some solid technical background especially when it goes to LUTs with custom options. Development was stopped in 2017, but In 2020 seems it back to life and hope we may see new options there. There are some discussions on GitHub and link to beta version was always here http://cameramanben.github.io/LUTCalc/testing/

By the way, your LUTs pack included in Hybrid.app, so i came to this thread to see if it may be further details.

[FranceBB]

Originally Posted by shph

Yes, LUTCalc is not a simple one click tool and may need some solid technical background especially when it goes to LUTs with custom options. Development was stopped in 2017, but In 2020 seems it back to life and hope we may see new options there. There are some discussions on GitHub and link to beta version was always here http://cameramanben.github.io/LUTCalc/testing/

Ah, I didn't know about the beta version. It's good to know. It would be great to have an updated version up and running.

Originally Posted by shph

By the way, your LUTs pack included in Hybrid.app, so i came to this thread to see if it may be further details.

Hybrid? You mean the one developed by Selur? I didn't know 'cause I've never used it and I basically never go to the GUI dedicated section of Doom9, but I'm glad he found them worth to be included.

[shph]

Yes, it is Hybrid developed by Selur.
Small question. I notice BT709_to_HLG_400.cube and BT709_to_HLG_800.cube inside Hybrid, but seems those LUTs are excluded from your current Github package. Are those some sort of legacy outdated non recommended LUTs?
Also seems Hybrid use legacy naming for few LUTs probably taken from some early packages. I will notice Selur and ask to update those names.

[FranceBB]

Originally Posted by shph

Yes, it is Hybrid developed by Selur.
Small question. I notice BT709_to_HLG_400.cube and BT709_to_HLG_800.cube inside Hybrid, but seems those LUTs are excluded from your current Github package. Are those some sort of legacy outdated non recommended LUTs?
Also seems Hybrid use legacy naming for few LUTs probably taken from some early packages. I will notice Selur and ask to update those names.

Oh boy, they were experimental, targeting two different nits level within the BBC specification. In other words, I was trying to see the result by remapping the peak white in the SDR luma to 400 nits and to 800 nits. You can keep them inside the program, but I would of course advise anyone to use the updated version. As a matter of fact, I kinda opted out for 100 nits SDR to 400 nits HDR HLG as re-mapping it to 1000 nits or so was causing some unwanted effect, especially when I was watching it on a 1000 nits reference monitor. I mean, nobody wants a completely clipped out sky (due to the 100 nits limitation of the original content) to peak at 1000 nits 'cause while in SDR you wouldn't notice, in HDR it would be annoying as there would be too much light all caused by averaged out values that were originally 235 in the 100 nits version. This happened many times, especially when "backpacks" cameraman are sent to record interviews on live sports events, like on a football pitch or near the F1 track and so on. I've also used the "new" matrix to re-encode some old footages so that I was able to insert them inside a documentary I was making (which was clearly shot in Clog3 to get enough stops / nits to produce it in HDR): About Max (2019)
You can actually try to download the "new" version of the matrix and see the differences yourself.
Anyway, by uploading them on GitHub, it should allow people to be aware of each and every changes so that these kind of things don't happen, which is one of the reason why I wanted to ditch Megaupload.


Side note: I'm pretty busy with the remastering thing at work, but when I'm gonna have time, I wanna try to make two HLG and PQ to Linear BT601 matrices as they can actually be useful when downscaling to SD without making the intermediate step of going through Linear BT709. It's actually something I wanted to make long time ago, but I never had time...

[FranceBB]

A friend of mine asked me what I was thinking about his camera, a Canon EOS R.
I tried it and unfortunately for him my review wasn't flattering... heck, it was rather a more sweetened version of "it's ok for FULL HD, it sucks for UHD".

If you're curios, here's a sample (re-encoded by YT sadly 'cause I wouldn't know where to upload it to make it last as WeTransfer lasts for a week only) brought to BT709 SDR 100 nits with my LUT (it's a video, not an image, you have to click on it to see it as I can't embed it):



Sample:

Canon EOS R 4K UHD 25p Sample in CLog1 brought to Linear BT709 4:2:0 (yv12) planar 8bit 100 nits using a matrix of linear transformation 65x65x65 with 16bit planar precision. The result has then been dithered down to 8bit planar with the Floyd Steinberg Error Diffusion using Avisynth.


MediaInfo of the original file:

General 
Complete name : U:\temp\Raw Canon EOS R\1220_001.MP4 
Format : MPEG-4 
Format profile : Base Media / Version 2 
Codec ID : mp42 (mp42/avc1/CAEP) 
File size : 415 MiB 
Duration : 7 s 600 ms 
Overall bit rate mode : Variable 
Overall bit rate : 458 Mb/s 

Video 
ID : 1 
Format : AVC 
Format/Info : Advanced Video Codec 
Format profile : High@L6.1 
Format settings : 1 Ref Frames 
Format settings, CABAC : No 
Format settings, Reference frames : 1 frame 
Format settings, GOP : N=1 
Codec ID : avc1 
Codec ID/Info : Advanced Video Coding 
Duration : 7 s 600 ms 
Bit rate mode : Variable 
Bit rate : 456 Mb/s 
Width : 3 840 pixels 
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:0 
Bit depth : 8 bits 
Scan type : Progressive 
Bits/(Pixel*Frame) : 2.201 
Stream size : 413 MiB (100%) 
Language : English 
Color range : Full 
Color primaries : BT.709 
Transfer characteristics : BT.709 
Matrix coefficients : BT.709 
Codec configuration box : avcC 

Audio 
ID : 2 
Format : PCM 
Format settings : Big / Signed 
Codec ID : twos 
Duration : 7 s 600 ms 
Bit rate mode : Constant 
Bit rate : 1 536 kb/s 
Channel(s) : 2 channels 
Sampling rate : 48.0 kHz 
Bit depth : 16 bits 
Stream size : 1.39 MiB (0%) 
Language : English 

Other 
ID : 3 
Type : Time code 
Format : QuickTime TC 
Duration : 7 s 600 ms 
Bit rate mode : Constant 
Frame rate : 25.000 FPS 
Time code of first frame : 00:43:38:13 
Time code, striped : Yes 
Language : English

Camera Review:

As to the Camera itself, it's limited to 25p or 29.970p in 4K and its sensor isn't really great, especially in UHD. Although this camera is capable of recording in UHD (3840x2160), it cannot record in 50p or 60p and on top of that it's limited to 8bit. As to HDR, its dynamic range is pretty much zero; this is because although it's capable of recording in CLog1, its sensor can record as little as 120 nits, of which 20 nits are just noise. Blacks are full of noise and they don't really benefit for the additional "range" (if we can call it that, considering that it's as little as 20 nits) and it's very hard not to clip out whites. If you close too much to save high frequencies (like the sky), then you're gonna get everything averaged out / crashed in the blacks. My review is simple: this is not a camera for UHD nor HDR and it can only work for FULL HD BT709 SDR 50p/60p as it's meant for these things. The fact that Canon added the ability to record in UHD and in CLog1 doesn't really mean that it should be used that way. One final remark goes to the autofocus which tries to get the objects in focus all the time making the stuttering of recording in 25p even more noticeable...
Codec: H.264, 3840x2160, 4:2:0 yv12 25p, 500 Mbit/s Linear BT709 8bit planar (--ref 1, all frames are encoded as Intra).

[FranceBB]

Greetings, everyone!
This year has hardly been a "year" as there were restrictions in place, mandatory face coverings, lockdowns, all due to this global pandemic.
Anyway, there's now an approved vaccine and there might be another one soon, so there's light at the end of the tunnel.
This is gonna be my last release of 2020 and it's gonna be with a 2020-related thing.

Linear Transformation v1.1 Released!!

- Added Linear BT2020 SDR 100 nits to HLG BT2020 HDR 200 nits support

Download Link (GitHub)

The reason for it is that, according to the ITU specifications, HLG defines graphics white as being 75% of code values and the common mapping of the original SDR 100 nits signal to fit as white for HLG is 3.18 of Y relative value, which leads to the magical number of 200 nits. I've cross-checked it with different sources, the math is correct and it also pleases the viewer (i.e me xD).






Disclaimer: screenshot are taken in HDR on an HDR monitor on Windows 10, the picture on the right has the HLG color curve applied and thus needs an HDR monitor to be displayed correctly, you won't see it displayed correctly on an SDR one.

[FranceBB]

As you probably are aware, Iphone 12 can shoot in HDR HLG BT2020 Dolby Vision H.265 10bit planar.
The problem is that because of the tiny sensor, it doesn't have many stops, which in turns doesn't have many nits, however what Apple seems to be doing is very peculiar and requires a very dedicated matrix of linear transformation, hence this LUT.

This is the original picture shot by the Iphone 12: https://i.imgur.com/ubIAcsl.png

The reason why I had to make yet another matrix is that I wasn't really pleased with what the tonemapping algorithms were producing: on the left hand side, Reinhard, in the middle, Hable, on the right hand side the proper HDR HLG BT2020 interpreting both the color curve and color matrix correctly: https://i.imgur.com/nBNE3q5.png

they came straight from zscale of FFMpeg but similar results can be achieve in Avisynth with HDRTools.
After spending lots of time tweaking the parameters, I decided to make the LUT myself and this is what I've got:



It seems that Apple's interpretation of the HLG curve is not exactly based on the BBC specs as it has a black point that starts very high, way higher than it should. HLG is known to be an Hybrid curve which starts like a Linear BT2020 curve, so like SDR, but then changes and approaches its HDR nature, which is why it can be viewed both on SDR and HDR monitors. In Apple's implementation, however, this is NOT the case as the black starts way higher, as if it was a proper logarithmic curve. This creates problems as it's supposed to start lower and "confuses" tonemapping algorithms.
Not only that, it's also gonna look bad on SDR BT2020 displays! This is how it would look on SDR BT2020 displays if you interpret the color matrix correctly as BT2020 but you ignore the info about the color curve: https://i.imgur.com/3GoGKeM.png
See? It's wrong, it's really wrong, blacks are supposed to be displayed properly on SDR displays due to the nature of the curve which starts normally and THEN becomes logarithmic, but here it's not the case and the black point is far too high. What I think tried to achieve with this is to squeeze as much as they could from this curve by making it as logarithmic as possible and I could understand that if it wasn't for the fact that with such a tiny sensor it's not justified.
I mean, honestly, even cameras that shoot HLG don't do that, so why should Apple?
I have no words...

Anyway:

Updated Linear Transformation v1.2
- Added HLG BT2020 Apple to Linear BT709 SDR

Link: https://github.com/FranceBB/LinearTr...ation/releases

[frank]

I have tested the BT709 to HLG conversion and got a dark result.
After some research in Avisynth+ and FFmpeg I found that the RGB input to BT709_to_HLG.cube must be limited 16-235 (TV). Then the output of Cube() will be full RGB with right black level 0. Maybe you tested with a TV RGB from your office?

Because the RGB range in ffmpeg and Avisynth is 0-255/2023 (PC) the LUT has to work with full range.

[FranceBB]

Originally Posted by frank

I found that the RGB input to BT709_to_HLG.cube must be limited 16-235 (TV).

Crap, you're right, I just checked.
It was outputting this:



instead of this:

Originally Posted by frank

Maybe you tested with a TV RGB from your office?

Yes, it goes through a Blackmagic Decklink and then on to a Canon Broadcast Monitor via SDI.
Good catch.

Unfortunately I'm at Sky but I'm not in a 4K room to test right now, so I might have got it wrong but I tried to fix it.
Left (HLG) - Right (BT709): Img1 - Img2 - Img3

Can you please test this and come back to me?

https://we.tl/t-GTfJ7q9P6n

p.s If I got it wrong, I'll book a 4K editing room for late this afternoon.

[frank]

My test is very simple. I only use VirtualDub to check the avs.

My Avisynth+ script:

# (LSMASHSource.dll)
LWLibavVideoSource("movie.mkv",cachefile="movie.lwi",format="",decoder="",prefer_hw=1) # cuvid

# Converting format (avsresize.dll)
z_ConvertFormat(pixel_type="RGBP16",colorspace_op="709:709:709:l=>rgb:709:709:f",dither_type="none")

# Apply LUT (vscube.dll)
Cube("BT709_to_HLG.cube",fullrange=true) # max-cll 1000

# Converting format (avsresize.dll)
z_ConvertFormat(pixel_type="YUV420P10",dither_type="error_diffusion")

# Enable MT
Prefetch(2)

This script is very fast! With ffmpeg x265 I get 36 fps (1080p) encoding speed on my notebook.

Your new cube works as far I can see.

[FranceBB]

Ah ok, a very simple yet effective test.
I'm glad it's working ok, I'll test it in a proper broadcast monitor tomorrow morning and if everything is alright, I'll swap it on GitHub and in the next version of FFAStrans.

[frank]

I tested a short sample of Das Boot (The Boat) with the cube. Encoded in HLG BT2020-10, not BT709.
Sorry, not good! Black level is good, but then colors get brighter too soon. So medium brightness of mid tones gets higher.
Looking on my LG CX (HDR HLG ready) I can compare with the original movie.
The original (BT709) looks much better.

[FranceBB]

Ok, I see. I tried to knee it down a bit, how about this one: https://we.tl/t-Drj48BMhpy



Red is BT709 SDR, Blue is BT2020 HLG HDR