FranceBB LUT Collection

[DavidK_]

A feedback is always welcome 'cause other people will always test more scenarios than I do on my own. I gotta say that I did notice a light dominance in red but that probably was because of my test source, so although the intent was to match it as much as possible, I think I "fixed" it when I was creating it so that the output was going to be ok, however that probably ended up with me matching the wrong points; the blue makes sense as it's the one that got compensated in favor of red. Anyway, I'll try to make another one but it would help to have a very short sample if you can provide one so that I can send you multiple outputs.

Did you see my note below? (I have a sample for us to share and settings to match etc)

[FranceBB]

Did you see my note below? (I have a sample for us to share and settings to match etc)

I did, but it's been 18 days since I left the office due to coronavirus and it seems like there's no plan for me to get back there AT LEAST 'till April. Right now I'm sitting at home waiting for this whole mess to calm down. Making a LUT with a crappy commercial 4K TV and monitor wouldn't be wise when I have a 50'000$ Sony monitor at work. Anyway, since this whole think is like a surreal situation, if you want me to try on my commercial TV and monitor, I will, it's just that I don't know how good the output will be.

[PatchWorKs]

#Indexing
FFMpegSource2("whatever.mts", atrack=-1)

#Clipping
Limiter(min_luma=16, max_luma=235, min_chroma=16, max_chroma=240)


OR


#Indexing
FFMpegSource2("whatever.mts", atrack=-1)

#Canon Levels to Limited TV Range
Levels(0, 16, 255, 16, 235, coring=false)



Ok, how to translate into FFMPEG ?
ffmpeg -i whatever.mts -vf "colorlevels=rimin=##/255:gimin=##/255:bimin=#/255:rimax=###/255:gimax=###/255:bimax=###/255, eq=gamma=#.##" -y out.mov

[FranceBB]

@PatchWorks... Clipping in ffmpeg is fairly easy:

ffmpeg -i "sample.mov" -vf lut=y=clipval:u=clipval:v=clipval

[frank]

There are only 3 BT... cubes in your download.
You have 6 BT... cubes at the first page.

I'm very missing the BT2100 HDR PQ to BT709 SDR cube.

[FranceBB]

There are only 3 BT... cubes in your download.
You have 6 BT... cubes at the first page.

I'm very missing the BT2100 HDR PQ to BT709 SDR cube.

Because it's called "PQ_to_BT709.cube" as file and there are two versions of it because one is the one I made at the very beginning when I first began to make matrices of this kind and the other one is my second attempt. The unusual name comes from the fact that at the very beginning I thought that nobody was ever going to be so mad to put a PQ curve into something else other than BT2100 with 10 or 12bit precision, so I just specified the curve and not the matrix in the name of the file only to find out later on that unfortunately there have been people doing weird thing so I changed the name of the post but I didn't change the name of the file (yet).
At the time of the creation whenever I wrote PQ I clearly meant a BT2100 with a PQ curve applied and when I wrote BT709 I clearly meant Linear BT709 with the plain old standard gamma. I hope this clarifies your doubts. Please try the two matrices and let me know.

[frank]

Thank you.

I have tested in Avisynth+ using avscube. The source was an UHD movie mkv:

LWLibavVideoSource(...)
z_ConvertFormat(pixel_type="RGBP16",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:f",dither_type="none")
Cube("C:\Program Files (x86)\AviSynth+\LUT\PQ_to_BT709_v2.cube", cpu=2, fullrange=true)
z_ConvertFormat(pixel_type="YV12",colorspace_op="rgb:linear:709:f=>709:709:709:l",dither_type="ordered")
Sorry, results have too much contrast and clipping from midtones upward.
There must be a problem with the level. It's not usable.

The Cube function only works in RGBP16, maybe floating point like RGBPS is needed.

edit: linear is wrong.

[PatchWorKs]

@PatchWorks... Clipping in ffmpeg is fairly easy:

ffmpeg -i "sample.mov" -vf lut=y=clipval:u=clipval:v=clipval
I just found this interesting repository that explain how to generate a "measurement gif" of a clip with FFMPEG: https://github.com/dericed/ffmpeg-mpeg2video-clipping

This is the (33Mb !) GIF for 10s of my shooting:

http://www.forart.it/_priv/cultura/HF100_measurement.gif

As clearly viewable, the "Video editing for scientific analysis" was right: the Canon HF100 generates a "shifted" range files.

The "recalibration" of it with the clipval parameter generates this instead:

http://www.forart.it/_priv/cultura/recal_clipval.gif

So the next question is: is possible to "shift down" everything (and constrain inside broadcast range, of course) in order to preserve the maximum possible color quality ?

Thanks again and sorry if I'm too nagging.

[frank]

IFAIK Canon has a converter software for the HF100. Maybe they use 16-255.
You have to ask Canon.

[FranceBB]

So the next question is: is possible to "shift down" everything (and constrain inside broadcast range, of course) in order to preserve the maximum possible color quality ?

Thanks again and sorry if I'm too nagging.

Yes, absolutely. Since you're actually producing a non standard file with 16-255 you can also avoid clipping and just remap the highlights to 235 with levels in Avisynth as I pasted the code before

Levels(0, 16, 255, 16, 235, coring=false)

As it says that the input is 16-255 and the output is going to be 16-235. I'm pretty sure other thing that soft-clipping instead of hard-clipping can be done in ffmpeg as well, but I don't use it that much to post you a command line for that as well. Are you sure you don't wanna give Avisynth a try?

Sorry, results have too much contrast and clipping from midtones upward.
There must be a problem with the level. It's not usable.

The Cube function only works in RGBP16, maybe floating point like RGBPS is needed.

Did you try both the two .cube files for PQ to BT709? Do they have the same problem? 'cause that's really weird...

[DavidK_]

I did, but it's been 18 days since I left the office due to coronavirus and it seems like there's no plan for me to get back there AT LEAST 'till April. Right now I'm sitting at home waiting for this whole mess to calm down. Making a LUT with a crappy commercial 4K TV and monitor wouldn't be wise when I have a 50'000$ Sony monitor at work. Anyway, since this whole think is like a surreal situation, if you want me to try on my commercial TV and monitor, I will, it's just that I don't know how good the output will be.

WOW! Glad you are well but wow. I'm in US and we're still figuring out how to react but having some closures and cancellations too.

If you could go ahead and try from home if you can. It would be helpful and much appreciated. :) And it would give you something to occupy your time - ha ha? :) No matter what stay well.

[frank]

Did you try both the two .cube files for PQ to BT709? Do they have the same problem? 'cause that's really weird... Yes, I tested both. But the v2 works better.
Is there another Cube plugin available?

[frank]

Ok, I've got it!! :)

The color must not be linearized. The example in Donald's Cube plugin is wrong.
Here the correct Avisynth+ script:

LWLibavVideoSource(...)
z_ConvertFormat(pixel_type="RGBP16",colorspace_op="2020ncl:st2084:2020:l=>rgb:st2084:2020:f",dither_type="none")
Cube("C:\Program Files (x86)\AviSynth+\LUT\PQ_to_BT709_v1.cube", cpu=2, fullrange=true)
z_ConvertFormat(pixel_type="YV12",colorspace_op="rgb:709:709:f=>709:709:709:l",dither_type="ordered")
v1 has the right contrast.
v2 has lower contrast.

[FranceBB]

I'm glad it finally worked out for you.

WOW! Glad you are well but wow. I'm in US and we're still figuring out how to react but having some closures and cancellations too.

It's gonna be a mess, mark my word. People have been underestimating this so have some governments and they won't realize that until it's too late.
Look what happened in Italy! They are on their knees! And it's not even one of the worse European Health Service, on the contrary, it's kinda "ok" but it's been overwhelmed...
In the UK the government pushed 50 million pound in the research of a vaccine and their plan seems to be to contain and then delay the epidemic 'till this summer when hopefully there will be a cure (the vaccine) and hospitals will be slightly less busy because of the end of seasonal flu. Yet, it's March, it's a long way 'till June, so I truly hope they'll find the vaccine way sooner.
Please, please please, people, don't underestimate this, don't go out if it's not necessary.

[DavidK_]

I'm glad it finally worked out for you.



It's gonna be a mess, mark my word. People have been underestimating this so have some governments and they won't realize that until it's too late.
Look what happened in Italy! They are on their knees! And it's not even one of the worse European Health Service, on the contrary, it's kinda "ok" but it's been overwhelmed...
In the UK the government pushed 50 million pound in the research of a vaccine and their plan seems to be to contain and then delay the epidemic 'till this summer when hopefully there will be a cure (the vaccine) and hospitals will be slightly less busy because of the end of seasonal flu. Yet, it's March, it's a long way 'till June, so I truly hope they'll find the vaccine way sooner.
Please, please please, people, don't underestimate this, don't go out if it's not necessary.


Did you have a chance to make the adjustments to the LUT? I didn't see a new link but I'm still not use to this forum fully.




As for Corona - we are now on partial lockdown here in the US! Store shelfs are bare with everyone hoarding food - especially toilet paper.

But if you had a chance to do that last small adjustment on the LUT let me know and send me a link here!

[wonkey_monkey]

with everyone hoarding food - especially toilet paper.

You eat weird stuff.

[Andouille]

You eat weird stuff.

Fibers are good for digestive system.

[DavidK_]

Fibers are good for digestive system.

And really tasty with a little hot sauce.

[masterkivat]

Hey FranceBB, thank you very much for your LUT collection! I'll give a try someday later on these :D
I wanna ask you something: while I understand the current situation with HDR and such, do you by any change know where to download or have plans to make an LUT file that converts BT.601 to BT.709? I didn't find anything related to this kind of conversion using an LUT file...

[FranceBB]

Well, to be fair I've been thinking about it for a while 'cause if I introduce linear BT601 and I get that right I could potentially get all the matrices that already have linear BT709 as either input or output and modify them to make them BT601 compatible.
The only "bad" thing with Linear BT601 is that there are actually two of them: one for PAL and one for NTSC which would double the work.
I would also like to cross check my results since I don't really trust myself getting the calculations right all the time...
I know that I can't use color matrix 'cause it only converts the matrix and not the primaries... Perhaps I can compare it with the one from "plugin_JPSDR" made by Jean Philippe as he probably got it right.

I might try in the next few days...

[masterkivat]

Well, to be fair I've been thinking about it for a while 'cause if I introduce linear BT601 and I get that right I could potentially get all the matrices that already have linear BT709 as either input or output and modify them to make them BT601 compatible.
The only "bad" thing with Linear BT601 is that there are actually two of them: one for PAL and one for NTSC which would double the work.
I would also like to cross check my results since I don't really trust myself getting the calculations right all the time...
I know that I can't use color matrix 'cause it only converts the matrix and not the primaries... Perhaps I can compare it with the one from "plugin_JPSDR" made by Jean Philippe as he probably got it right.

I might try in the next few days...

hmmm I see... But yeah, man... Take your time on these, I really hope you could provide these LUT files in the future, this kind of conversion would help me a lot with some personal projects that require such conversions :)
Thanks for answering me!

[FranceBB]

Ok, so I made a few tests.
I started with the PAL version of BT601 as you can see:
https://i.imgur.com/QdI7D4p.png

The curve is exactly the same and there's a reason: the difference between those two is so subtle that it can't really be noticed on this scale...

To test this, I indexed a BT709 file and I converted it to BT601 in three different ways:

1st Indexing only (my source file):

FFVideoSource("I:\temp\sample.ts")
Spline64Resize(848, 480)

2nd my LUT:

FFVideoSource("I:\temp\sample.ts")
Spline64Resize(848, 480)
ConvertBits(16)
ConvertToPlanarRGB()
Cube("C:\Programmi\AviSynth+\LUTs\test.cube", fullrange=true)


3rd the old good colormatrix:

FFVideoSource("I:\temp\sample.ts")
Spline64Resize(848, 480)
ColorMatrix(mode="Rec.709->Rec.601", interlaced=false, threads=0, thrdmthd=0)


4th Matrix from HDR Core:

FFVideoSource("I:\temp\sample.ts")
Spline64Resize(848, 480)
ConvertBits(16)
ConvertToDoubleWidth()
Matrix(from=709, to=601, rg=1.0, gg=1.0, bg=1.0, a=16, b=235, ao=16, bo=235, bitdepth=16)
ConvertFromDoubleWidth()


This is the original frame in Linear BT709:
https://i.imgur.com/5yXvUM2.png

This is the result of my linear Transformation:
https://i.imgur.com/6hO1JjQ.png

This is ColorMatrix:
https://i.imgur.com/CAjq1B6.png

This is Matrix from HDR Core:
https://i.imgur.com/cJyP0lg.png

A few frame-comparison, but honestly the difference is so small that it's barely noticeable:

https://i.imgur.com/9oLPtfJ.png
https://i.imgur.com/5kwNGCh.jpg
https://i.imgur.com/LzPRMqH.jpg
https://i.imgur.com/IUzo2aY.jpg
https://i.imgur.com/7RduBS2.jpg
https://i.imgur.com/PDRkzoJ.jpg
https://i.imgur.com/tVffwHp.jpg
https://i.imgur.com/qp8JVfE.jpg
https://i.imgur.com/CPFKXd4.jpg


Could you test it, please, and let me know?


Link: FranceBB LUT (https://mega.nz/file/yVVgDSAB#IFZhR6KfLCHQ9aoeFo56A6htrewYJKoKZ9JI1_zccnM)


This one instead is made by Adam Stanislav and his results are pretty much the same as mine with very little difference. Can you check this one as well, please?
Link: Stanislav LUT (http://www.pantarheon.org/601vs709luts.zip)

[masterkivat]

Your conversions looks pretty damn good! :)
But for my purpose, it would look "technically" wrong... My source file is listed as:

Color range : Limited
Color primaries : BT.601 NTSC
Transfer characteristics : BT.601
Matrix coefficients : BT.601

And since I'm working in this project (upscaling SD content to HD with the proper color conversion), my goal is to do a proper color conversion from BT.601 NTSC to BT.709.
I know this is just the beginning of your work on LUT files, so I'll be patiently waiting your LUT.
As for Adam Stanislav LUT files, I think his "conversion" looks way stronger... Check out this comparison chart (https://slow.pics/c/X9DRGTW2).

[FranceBB]

Ok, so I've done it.
This is the BT601 PAL to BT709:

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

And this is the NTSC one:

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

I then used the CIECAT02 module and its equations for calculating mathematical correlates for the six technically defined dimensions of color appearance: brightness (luminance), lightness, colorfulness, chroma, saturation, and hue.
I've got two matrices 274628 X 3, which are way too precise for such a simple calculation.
Nonetheless, here they are.
Take a look at them and let me know.

p.s of course I made the inverse as well.

Updated link in the 1st post.

[FranceBB]

Introducing LinearTransformation.

With the increasing number of matrices to do any kind of linear transformations, I kinda felt the need to make something more accessible for users, which is why I'm introducing now "LinearTransformation".
This plugin performs Linear Transformations based on a matrix conversion. Matrices are made by me and can be used independently from Avisynth as well.
The function has two parameters: Input and Output.
Currently, only those linear transformations are supported:

From "Linear_BT601_NTSC" to "Linear_BT709"
From "Linear_BT601_PAL" to "Linear_BT709"
From "Linear_BT709" to "Linear_BT601_NTSC"
From "Linear_BT709" to "Linear_BT601_PAL"
From "Linear_BT709" to "BT2020_HLG"
From "Linear_BT709" to "BT2100_PQ"
From "Linear_BT709" to "DCI_XYZ"
From "Linear_BT709" to "ZLog"
From "BT2100_PQ" to "Linear_BT2020"
From "BT2100_PQ" to "Linear_BT709"
From "BT2100_PQ" to "BT2020_HLG"
From "CLog3" to "Linear_BT709"
From "CLog3" to "BT2020_HLG"
From "CLog3" to "BT2100_PQ"
From "SLog2" to "Linear_BT709"
From "SLog3" to "Linear_BT709"
From "BT2020_HLG" to "Linear_BT709"
From "BT2020_HLG" to "BT2100_PQ"
From "DCI_XYZ" to "Linear_BT709"
From "LogC" to "Linear_BT709"
From "VLog" to "Linear_BT709"

A Linear Transformation is essentially a matrix that maps all points of a certain space to another, which includes of course points belonging to a certain curve to other in order to get a different curve.
Of course, a linear transformation can be used in encoding to map some values to some other values and therefore have conversions from curves like PQ to HLG and so on.

The transformation is performed with 16bit precision, which means that if your input source is lower, let's say, 8bit planar yv12, it will be brought to 16bit planar RGB internally, the linear transformation will be applied with 16bit planar precision and then the result will be brought down to 8bit planar yv12.

Planar RGB 16bit is strongly suggested as your source as it's gonna be faster, in fact 4:2:0, 4:2:2, 4:4:4 planar up to 16bit will be converted back and forth internally.

Inside the plugin, the path specified for the matrices is "mypath" and by default is: mypath = "C:\Program Files (x86)\AviSynth+\LUTs" which means that it's gonna look for my LUTs in a folder in such a location. It's not mandatory to have my LUTs there, you can have them in any location you want, provided that you do update that string.

A huge thanks to StainlessS and to the whole community for greatly improving the script and helping me writing it.

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

Usage Example:

Example 1: From Slog3 to Linear BT709


FFVideoSource("mySlog3source.mxf")
LinearTransformation(Input="SLog3", Output="Linear_BT709")


Example 2: From PQ to HLG


FFVideoSource("myPQsource.mxf")
LinearTransformation(Input="BT2100_PQ", Output="BT2020_HLG")

[Dogway]

I'm curious about your LUTs, the reds are deeper using yours for matrix conversion, is this expected for the CIECAT chromatic adaptation? Can you choose Bradford or any other for comparison?
EDIT: Nevermind, you were comparing PAL. I got confused because those coefficients (https://forum.doom9.org/showthread.php?p=1915272#post1915272) are more in line with SMPTE

Also I think that adding an option for the chroma resample kernel should be a good idea, I always switch to spline36 since bicubic is a bit soft, not that I can't do myself but as a suggestion.

[FranceBB]

I'm curious about your LUTs, the reds are deeper using yours for matrix conversion, is this expected for the CIECAT chromatic adaptation? Can you choose Bradford or any other for comparison?
EDIT: Nevermind, you were comparing PAL. I got confused


Yeah, I was indeed comparing with BT601 PAL; anyway, technically I could switch and use the Bradford Chromatic Adaptation

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

but unless there's a real need, I would personally stick with CIE 'cause the CAT02 provided is the international one that is expected to be used everywhere by everyone, which uses the following matrix:

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


Also I think that adding an option for the chroma resample kernel should be a good idea, I always switch to spline36 since bicubic is a bit soft, not that I can't do myself but as a suggestion.

You mean in LinearTransformation() (https://github.com/FranceBB/LinearTransformation/blob/master/LinearTransformation.avsi)? Sure, I can do that, no problem, but in the meantime, if you want you can use the matrices manually like this:

ConvertBits(16)

ConvertToPlanarRGB()

Cube("C:\Programmi\AviSynth+\LUTs\whatever.cube")

Converttoyuv420(chromaresample="Spline64")

so this way you can specify the chroma resample yourself. Since all calculations are done in RGB 16bit Planar and then brought back to whatever you had in input. :)

That would be the same as:


ConvertBits(16)

ConvertToPlanarRGB()

LinearTransformation(Input="something", Output="something_else")

Converttoyuv420(chromaresample="Spline64")


as you're feeding it with RGBP16 and it will output RGBP16 thus allowing you to resize the chroma with your favorite kernel. :)

[Dogway]

Yes, CAT02 is meant to be an improved version but I was curious about why the red is so much deeper. I wanted to test this but couldn't find Linear_BT709 and 601 in your repo(?). I'm missing these LUTs:

BT601_NTSC_to_BT709
BT601_PAL_to_BT709
BT709_to_BT601_NTSC
BT709_to_BT601_PAL


I don't know how it behaves currently but the example in that post is wrong I think. Rec709 and Rec601_PAL only differ 0.010 in red. This is a test I did in Nuke.

Rec709/sRGB
0.640, 0.330, 0.030
0.300, 0.600, 0.100
0.150, 0.060, 0.790

Rec.601 PAL
0.640, 0.330, 0.030
0.290, 0.600, 0.110
0.150, 0.060, 0.790

P22-EBU - ColorMatch RGB (D50) (Radius PressView Monitors)
0.630, 0.340, 0.030
0.295, 0.605, 0.100
0.150, 0.075, 0.775

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

Now when I inverted the matrices M-1 (which is wrong) I get a match of your example.


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

[FranceBB]

Yes, CAT02 is meant to be an improved version but I was curious about why the red is so much deeper. I wanted to test this but couldn't find Linear_BT709 and 601 in your repo(?). I'm missing these LUTs:

BT601_NTSC_to_BT709
BT601_PAL_to_BT709
BT709_to_BT601_NTSC
BT709_to_BT601_PAL


Oh, dang... I forgot to upload them, now they're there.




Now when I inverted the matrices M-1 (which is wrong) I get a match of your example.


I see! I made a boo boo, but it's my fault, it's not the CAT02. I'll make a new one for PAL. NTSC should be ok I think, but now that they're uploaded, feel free to test it as well.

[Dogway]

Thanks, just tested also with SMPTE coefficients and it's working fine : D

[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] 10bitLatest 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! :D
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/LUTCalc/LUTCalc/index.html

[FranceBB]

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 (https://uk.mathworks.com/downloads/), Julia (https://julialang.org/), LUT Calc (https://cameramanben.github.io/LUTCalc/) 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 (https://www.youtube.com/playlist?list=PL221E2BBF13BECF6C) on Julia (https://www.youtube.com/playlist?list=PLP8iPy9hna6Si2sjMkrPY-wt2mEouZgaZ) and Linear Algebra (https://www.youtube.com/playlist?list=PL221E2BBF13BECF6C), 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 (https://www.youtube.com/watch?v=fNk_zzaMoSs&list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab)" series by Grant Sanderson (3blue1brown) (https://www.youtube.com/channel/UCYO_jab_esuFRV4b17AJtAw). As to my personal YT channel (https://www.youtube.com/channel/UCzhj_LmbAAm4bJfCWSeQ9bA/videos), unlike what I did with Electrical Engineering and Digital Electronics, I've posted things about Linear Algebra (https://www.youtube.com/playlist?list=PL7dD-bUWOf-qHymw_jHn9SusEf-H57QzF) 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/papers/HDR/BBC_HDRTV_HLG_LUT_Implementation_Guide.pdf
LUT Calc: https://cameramanben.github.io/LUTCalc/
MIT Lectures by Gilbert Strang about Linear Algebra: https://www.youtube.com/playlist?list=PL221E2BBF13BECF6C
MIT Lectures about Julia: https://www.youtube.com/playlist?list=PLP8iPy9hna6Si2sjMkrPY-wt2mEouZgaZ
Essence of Linear Algebra by Grant Sanderson: https://www.youtube.com/watch?v=fNk_zzaMoSs&list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_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]

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


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]

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) (https://www.imdb.com/title/tt11462526/)
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):

https://i.ytimg.com/vi/XL8kkeEfQuk/hqdefault.jpg (https://www.youtube.com/watch?v=XL8kkeEfQuk&t=1s)

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

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

https://i.imgur.com/AUbkgG0.png
https://i.imgur.com/YqG7Xao.png
https://i.imgur.com/2zELI0v.png
https://i.imgur.com/wnPLunU.png

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:

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

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/LinearTransformation/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]

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:

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

instead of this:

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





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 (https://i.imgur.com/oehCJIA.png) - Img2 (https://i.imgur.com/xEez643.png) - Img3 (https://i.imgur.com/ilndR9X.png)

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

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

Red is BT709 SDR, Blue is BT2020 HLG HDR