FranceBB LUT Collection

[quietvoid]

There shouldn't be a need for the "dvhe0509" LUT anymore for AVS users: https://github.com/Asd-g/avslibplacebo
At least if you have a GPU. It also gives correct results, contrary to the LUT.

[StvG]

You should set the correct matrix for rgb->yuv here otherwise 601 is used. Can be verified by putting propshow() after LinearTransformation.

[FranceBB]

Originally Posted by StvG

You should set the correct matrix for rgb->yuv here otherwise 601 is used. Can be verified by putting propshow() after LinearTransformation.

Nicely spotted.
Fixed and I mentioned your suggestion in the release notes.


Linear Transformation v2.1 Released!

Changelog:

- Improved conversion back to input sampling by correctly setting the output matrix as per StvG suggestion

[Balling]

Originally Posted by 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.

You know, you are saing it like there may be no bugs that lead to e.g. using simplied Little CMS mode that is only 49^3 max. See https://github.com/mpv-player/mpv/issues/10400

After this fix you can finally do even 512^3.

[frank]

Hello Francesco,
there is a problem with your 3D 65 lut BT709_to_HLG.cube.

# BT709 SDR to BT2020 HLG with reference white 75% (Full Range in - Full Range out)

You'll get limited spikes with color errors (black/blue) on bright reflections. After many tests I found it is not working on full range. I know you work with limited range in the studio. May be you mismatched something?
This Avisynth+ script worked on this lut and the resulting colors are good.

# (dgDecodeNV)
dgSource("movie.dgi") # SDR AVC

# (avsresize.dll) 
z_ConvertFormat(pixel_type="RGBP16", \
  colorspace_op="709:709:709:l=>rgb:709:709:l", \
  chromaloc_op="left=>top_left")

# Apply LUT (vscube.dll) RGBP16
Cube("BT709_to_HLG.cube")

# (avsresize.dll)
z_ConvertFormat(pixel_type="YUV420P10", \
  colorspace_op="rgb:std-b67:2020:l=>2020:std-b67:2020:l", \
  chromaloc_op="top_left=>top_left")

Usually the red marked l shoud be f (full) for full range lut.
The movie was Those Magnificient Men in their Flying Machines.

You can also try STUDIOCANAL's AVC intro. The white text is inverted to black.
-------------
Dell XPS 15, Win10 Pro

[frank]

New test without Avisynth+.
I used NVEncC64 from rigaya. Best and fastest converter for NVIDIA.
You only can use size 65 LUTs in this program.
The importent cmd lines:

-i "movie.mkv" ^
--vpp-colorspace matrix=bt709:bt2020nc,lut3d=BT709_to_HLG.cube,range=limited:limited ^
-c hevc --profile main10 -u p5 --qvbr 25 ^
...
--chromaloc 2 --colorprim bt2020 --colormatrix bt2020nc ^
--transfer bt2020-10 --atc-sei arib-std-b67 ^

The program log shows:

Vpp Filters colorspace: cspconv(nv12 -> yuv444(16bit))
matrix:bt709->GBR
lut3d: table=BT709_to_HLG.cube
size=65, interp=tetrahedral
matrix:GBR->bt2020nc
cspconv(yuv444(16bit) -> yv12(16bit))
cspconv(yv12(16bit) -> p010)

Working perfect with your LUT. And faster, 240 fps on my notebook.
No more limited spikes, nice colors.
So I think there must be a problem with Avisynth+ and the plugins, and levels.

EDIT
Possible cause.
Depends how the 3dLUT is integrated. I think Avisynth cube reads elements as integer and not float, or has issues. So some elements for high levels destroy the colors. NVEncC64 correctly reads and converts elements as float.
All LUTs from wswartzendruber are working well with my script, but PQ to HLG only.

[spoRv]

Bravo Francesco, ottimo lavoro!

I'm thinking if you can make two further LUTs:
XYZ to 2020 HLG
XYZ to 2020 PQ
- unless double conversion XYZ->SDR 709 then SDR-709->HDR (HLG or PQ) is equivalent, without too much loss.

OT: how is possible to open a DCP (and other sources like HEVC 10 bit for example) and NOT getting only 8 bit?
I tried ffvideosource, directshowsource, DSS2, but always only 8 bit...

[FranceBB]

Originally Posted by frank

Hello Francesco,
there is a problem with your 3D 65 lut BT709_to_HLG.cube.

You'll get limited spikes with color errors (black/blue) on bright reflections. After many tests I found it is not working on full range. I know you work with limited range in the studio. May be you mismatched something?

I cannot reproduce.
It works just fine in full range here.

This is from the movie Lucy, a BT709 XDCAM-50 SDR 100 nits masterfile:

FFVideoSource("D:\Masterfiles\Lucy MPEG-2 FULL HD SDR BT709 YUV422 25i TFF 8bit.mxf")
propClearAll()

VideoTek(Mode="SDR")

As you can see, it peaks at around 700mV, so 235 in Limited TV range.

This is what happens when I go to HLG using my LUT which closely follows the BBC specification of their white paper as I've been reviewing it over and over and over again:

FFVideoSource("D:\Masterfiles\Lucy MPEG-2 FULL HD SDR BT709 YUV422 25i TFF 8bit.mxf")
propClearAll()

#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")

#From BT709 SDR to BT2020 HDR HLG with 16bit precision
Cube("C:\Program Files (x86)\AviSynth+\LUTs\BT709_to_HLG.cube", fullrange=true)

#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")

VideoTek(Mode="HLG")

As you can see, the value which was previously at 700mV (so 235, so 100% of the Limited TV Range SDR signal which corresponds to 100 nits in the BT709 SDR version) is now at 520mV, so we now have the reference white at 75% of the Limited TV Range HDR HLG signal.

In my view, there's nothing wrong with this.

Originally Posted by spoRv

I'm thinking if you can make two further LUTs:
XYZ to 2020 HLG
XYZ to 2020 PQ

No problem, but I'll need someone to test them too.
I'll put them on my "to do" list.

Originally Posted by spoRv

OT: how is possible to open a DCP (and other sources like HEVC 10 bit for example) and NOT getting only 8 bit?
I tried ffvideosource, directshowsource, DSS2, but always only 8 bit...

That is actually really weird.
Are you sure you're using the latest ffms2 and Avisynth+?
This is because on the old, legacy Avisynth 2.6, you would get 8bit planar all the time OR 16bit stacked or interleaved.
On the new Avisynth+, however, it will index high bit depth sources at their native bit depth, so if you have a 10bit planar source it will be 10bit etc.
There's one notable exception, though, and that is DCP.
If you have a DCP, it means that it's a MJPEG2000 4:4:4 XYZ 12bit, however XYZ isn't natively supported in Avisynth (despite my desperate requests to support it dating back to 2017 and which I included in my meme collection https://forum.doom9.org/showthread.php?p=1953469).
There are some people like Jean Philippe who had to work in XYZ, so what they did was to create a fake RGB64 output on his ConvertYUVtoXYZ() function with XYZ inside. Some other people like Hydra/HolyWu/Asd just recognized that XYZ isn't supported in Avisynth and therefore indexers like LWLibavVideoSource() won't output anything and report an error:





Other people like Myrsloyk instead added automatic conversion, which is the case for ffms2, which brings me to the final reply of your question: if you index an XYZ 12bit file with FFVideoSource(), it will automatically bring it to 16bit, convert it to YUV and output a YUV 16bit stream.

As you can see here, my input was a MJPEG2000 in UHD XYZ 4:4:4 12bit and after indexing with FFVideoSource() it has become a YUV 4:4:4 16bit planar:




This is the Mediainfo of the original file:

Video 
ID : 2 
Format : JPEG 2000 
Format profile : D-Cinema 4k 
Format settings, wrapping mode : Frame 
Codec ID : 0D010301020C0100-0401020203010104 
Duration : 1 h 15 min 
Bit rate : 248 Mb/s 
Width : 3 996 pixels 
Height : 2 160 pixels 
Display aspect ratio : 1.85:1 
Frame rate : 25.000 FPS 
Color space : XYZ 
Chroma subsampling : 4:4:4 
Bit depth : 12 bits 
Scan type : Progressive 
Bits/(Pixel*Frame) : 1.147 
Stream size : 130 GiB (100%) 
Title : Picture Track 
Color range : Full

XYZ seen as is through MPV: https://i.imgur.com/46XuSBi.jpg
XYZ indexed by FFVideoSource() in Avisynth which automatically converts to YUV 16bit: https://i.imgur.com/xi8pHH4.jpg

[wswartzendruber]

Originally Posted by FranceBB

I cannot reproduce.

As you can see, the value which was previously at 700mV (so 235, so 100% of the Limited TV Range SDR signal which corresponds to 100 nits in the BT709 SDR version) is now at 520mV, so we now have the reference white at 75% of the Limited TV Range HDR HLG signal.

In my view, there's nothing wrong with this.

This is in agreement with BT.2408, so long as you are including SDR in a larger HLG presentation. If you are converting SDR to HLG outright, that is covered in BT.2446, which offers three methods.

[frank]

I used hardware decoding. I'll test again when I return from my trip. Weekend.

[FranceBB]

Originally Posted by frank

when I return from my trip. Weekend.

Vacation? Where are you chillaxing?
As to me, right now I wanna go nowhere. I've had enough of travelling after Amsterdam to attend IBC. Not just 'cause it was all over-expensive, but also 'cause I got caught in the Schipol airport strike and lost my flight after a 4h queue...
I had to get back and book another flight (with no refund) and it costed me 400€... Madness.

I've had enough.

Originally Posted by wswartzendruber

This is in agreement with BT.2408, so long as you are including SDR in a larger HLG presentation. If you are converting SDR to HLG outright, that is covered in BT.2446, which offers three methods.

Yep, that's exactly right. The original BBC White Paper from 2017 specified mapping in which BT.709 SDR is "mapped" to HLG by making HLG act as its container. In other words, there's no "creative" intent whatsoever and it's not using any of the methods specified in ITU BT.2446 which will inevitably "try to be smart" to try to give an authentic HLG feel and will change the overall perceived contrast. In the original White Paper, in fact, the BBC suggested to use the hybrid nature of HLG to make it act as a container for BT709. In other words

"Conversions whereby SDR content is placed into an HDR container without changing the dynamic range"

in accordance with ITU BT.2390.
The reason for this method is strictly related to rights.
While when we're both producers and broadcaster we can do what we want (like with sports in which we can use scene-referred HLG conversion if we have some non HLG camera, like the small ones for replays inside the net in football games), for movies and tv series whose rights are not ours, we gotta use display-referred mapping with the method I mentioned above 'cause otherwise if we apply the methods highlighted in ITU BT.2446 the content provider might reject the conversion as it will inevitably change the content. (We had a few occasions in the past where this happened and our contents got rejected, which is why I reviewed this LUT several times in the past).

[spoRv]

So, I finally found a way to load >8bit sources with:

ffvideosource("filename.extension",enable10bithack=true)

it correctly see DCPs as 12 bit; it automatically converts XYZ color space, though.

[FranceBB]

I'll ask you again: which version of Avisynth are you on? Is it Avisynth 2.6.1 from 2016 or 3.7.2 from 2022?
If you're not on 3.7.2, you might wanna update https://github.com/AviSynth/AviSynthPlus/releases

And don't worry, the only OS that were dropped in the meantime are Windows 98SE and Windows 2000, so given that it's highly unlikely that you're dealing with MJPEG2000 12bit using any of them, you should really update.

The reason why I'm saying this is the line you wrote right here:

"enable10bithack=true"

This parameter here doesn't exist any longer in ffms2.
As a matter of fact it has been deprecated years ago.
The reason is that back in the days of 2.6.1, Avisynth was only working in 8bit planar, while the only high bit depth supported were 16bit stacked (Dither Tools) and interleaved (HDR Core).

Back in the days, FFVideoSource() outputted 10bit+ sources as 16bit stacked, while LWLibavVideoSource () outputted 10+ sources as 16bit interleaved.
Nowadays, they both output in planar, so 10bit planar sources are kept as 10bit planar etc.
Although there's nothing wrong in working in 16bit stacked as you're doing, you need to be careful about MSB and LSB and which filters support it etc.
Let me be very clear: when you work in stacked, you must tell each and every function you're gonna call later that you're working with that.

This is an updated build of ffms2

Originally Posted by StvG

ffms2_6ad7738 (pass: u7Uezbh3fTHM):
- ffms2@90975ec;
- ffmpeg n5.1@1764a6887b;
- zlib 1.2.12;
- dav1d 1.0.0;
- AviSynth: set Dolby Vision RPU data in frame props.

I'm gonna quote myself:

Originally Posted by FranceBB

HBD stands for "High Bit Depth" and it refers to the bit depth in which you're working with.
There are 3 possible ways to work with high bit depth in Avisynth:

- Planar
- Stacked
- Interleaved

Planar means regular high bit depth, namely you can work in 8bit, 10bit, 12bit, 14bit, 16bit planar and 32bit float. The picture is the way it is and has regular high bit depth.
In other words, 1920x1080 16bit planar is 1920x1080.



Stacked means that MSB (most significant bit) and LSB (less significant bit) are "stacked" one on top of the other, so you end up with a picture which has double its height.
In other words, 1920x1080 16bit stacked becomes 1920x2160 as it has 8bit MSB + 8bit LSB stacked one on top of the other.



Interleaved means that MSB and LSB are "interleaved" together one next to the other, so you end up with a picture which has twice its Width.
In other words, 1920x1080 16bit interleaved becomes 3840x1080 as it has 8bit MSB + 8bit LSB interleaved one next to the other.

[spoRv]

Originally Posted by FranceBB

I'll ask you again: which version of Avisynth are you on? Is it Avisynth 2.6.1 from 2016 or 3.7.2 from 2022?
If you're not on 3.7.2, you might wanna update https://github.com/AviSynth/AviSynthPlus/releases

...

This is an updated build of ffms2
...

I run Avisynth+ 3.7.0 - by the way, "enable10bithack=true" works ONLY inside MP_Pipeline.

So, I've downloaded the updated ffms2 build: still 8 bit only, both with 10bit HEVC and 12bit DCP.

Then I've downloaded 3.7.2; the same; but now ffvideosource doesn't work inside MP_Pipeline anymore; dss2 doesn't work at all, directshowsource load everything at 640x480...

Reverting to 3.7.0 everything works as previously!

Back on topic:
shouldn't "BT2020_HLG" be "BT2100_HLG"?
And, if so, couldn't "BT2100_PQ" be "BT2084_PQ" to differentiate it more from "BT2100_HLG"?

[FranceBB]

Originally Posted by spoRv

I run Avisynth+ 3.7.0 - by the way, "enable10bithack=true" works ONLY inside MP_Pipeline.

Are you using Ferenc's version of MPPipeline()?

https://github.com/pinterf/MP_Pipeline/releases

Originally Posted by spoRv

So, I've downloaded the updated ffms2 build: still 8 bit only, both with 10bit HEVC and 12bit DCP.

But how...? O_O
I clearly get 4:4:4 16bit planar converted to YUV when using an updated build of ffms2 and Avisynth+...

Originally Posted by spoRv

Then I've downloaded 3.7.2; the same; but now ffvideosource doesn't work inside MP_Pipeline anymore; dss2 doesn't work at all, directshowsource load everything at 640x480...

Reverting to 3.7.0 everything works as previously!

Wait, so... changing Avisynth version affects the indexing? O_O
Are you using propclearall() right after indexing in modern version of Avisynth? (that's needed 'cause otherwise other plugins will misbehave)
This is a really really really strange behavior.
I'll test tomorrow again with MPPipeline()

Originally Posted by spoRv

shouldn't "BT2020_HLG" be "BT2100_HLG"?
And, if so, couldn't "BT2100_PQ" be "BT2084_PQ" to differentiate it more from "BT2100_HLG"?

Nah, with BT2020 I mean the SDR version of the BT2020 which is signalled in HLG streams.
Given that HLG is hybrid and backwards compatible with BT2020 SDR TVs, that is signalled as BT2020 and arib-std-b67, hence TVs which can read HLG will interpret the color curve in the transfer characteristics and will reproduce accordingly, while the ones that can't will ignore the color curve and just interpret it as BT2020 SDR, hence showing everything a bit dimmed (as the reference white is 75% instead of 100%) but still making use of the BT2020. When it comes to SMPTE2084, so PQ, on the other hand, such a color curve isn't backwards compatible with BT2020 SDR TVs 'cause it's totally logarithmic, therefore blacks are pushed higher and the waveform stays in the middle, which is why it's identified by the "BT2100" which is used for HDR.

Anyway, none of this affects anything, it's just a naming convention to make some rationale around those LUTs and inside the parameters of the function I made, but yeah, they can be changed eventually, so I'll stay open to suggestions.

[wswartzendruber]

I would offer that the BT.2020 SDR fallback capability of BT.2100 HLG is largely a mechanic of HEVC signaling. With AV1, for example, I can find no way to specify a fallback transfer function. Ergo, with AV1, BT.2100 HLG streams are signaled as that and only that.

After reviewing these specifications and how they're organized, I would have expected three different naming patterns to occur:

1. BT2020_SDR
2. BT2100_HLG
3. BT2100_PQ

[frank]

Vacation? Where are you chillaxing?

I was driving to visit relatives in Leipzig.

You did the lut3d test with a file from your office.

Lucy MPEG-2 FULL HD SDR BT709 YUV422 25i TFF 8bit.mxf

Eh, you should use a normal Blu-ray with AVC YUV420.

The two known cube filters avsCube and dgCube have in Avisynth+ different issues with BT709_to_HLG.cube. The cause was the black level! If the source goes to black (0) or lower then avsCube inverts borders to white, and dgCube destroys colors, makes spikes. Also clearly visible in the vectorscope of VideoTek.

avsCube with BT709 to HLG

I was able to eliminate it by limiting the levels of the source.

Levels(16,1,235,17,235,coring=false)

This line eliminates black 16 (0) in limited YUV space. So I think your test source .mxf never reached real black or super black.

Then I looked at your BT709_to_HLG.cube and dada...
the first filter line has small negative values. It corresponds to black 0. This generates errors in Avisynth+ in the multiplication. It must be a filter problem with floating/integer conversion. In ffmpeg and NVEncC the lut3D filter is working without issues.

I replaced this filter line with three zeroes and BT709_to_HLG.cube is working perfectly.
I don't know where the negative shift is coming from. First line must be zero, we don't want super blacks.
Please recalculate this LUT.
_________________________________________
Dell XPS 15 9510, Win10 Pro, Avisynth+ 3.7.2 (64)

[FranceBB]

Originally Posted by frank

You did the lut3d test with a file from your office.

Guilty :P

Originally Posted by frank

Eh, you should use a normal Blu-ray with AVC YUV420.
The two known cube filters avsCube and dgCube have in Avisynth+ different issues with BT709_to_HLG.cube. The cause was the black level! If the source goes to black (0) or lower then avsCube inverts borders to white, and dgCube destroys colors, makes spikes. Also clearly visible in the vectorscope of VideoTek.

Ouch.
I know what this is about: compression artifacts lead to overshooting.
Essentially, in consumer-tier stuff, you have values outside the limited tv range which were "created" from scratch. I.e they shouldn't be there, but they are as a result of compression.
In other words, once those values are taken into account, unexpected things can happen.
Generally in professional master files and TX Masters, we try to avoid those as much as possible 'cause having them would result in QC Fail as operators always play the files with a Tektronix Hardware Waveform Monitor at their left hand side, taking the input signal from the hardware playback port (carried via SDI).

Originally Posted by frank

I was able to eliminate it by limiting the levels of the source.

Levels(16,1,235,17,235,coring=false)

This line eliminates black 16 (0) in limited YUV space. So I think your test source .mxf never reached real black or super black.

That's exactly right. By making sure all values are within the legal region, you basically created the exact same environment we work on as you got rid of compression overshooting.

p.s just FYI, what you did is really good and should be done all the time as illegal values won't be displayed anyway as all monitors are RGB Full Range and therefore if you feed a monitor with a 16-235 YUV limited signal, it will expand it to 0-255, therefore anything lower than 16 will be negative, thus not displayed (same goes for out of range whites).

Originally Posted by frank

Then I looked at your BT709_to_HLG.cube and dada...
the first filter line has small negative values. It corresponds to black 0. This generates errors in Avisynth+ in the multiplication. It must be a filter problem with floating/integer conversion. In ffmpeg and NVEncC the lut3D filter is working without issues.

I think the best thing to do would be to inform Donald Graft about this.
Since he rarely visits Doom9 any longer and he's staying on his own solitary ice castle ehm I mean his forum, I hope my fellow compatriot @Tormento will point him to this topic here.

[frank]

The best way is to zero out that first line.

You know a lut3d is mathematically a linear matrix, or table:

input vector x matrix = output vector

Input is full range 0..max, and output is is full 0... max.
All vector elements are greater or equal zero.
The filter works internally with a fast integer format. So negative table elements can generate overflow, depending on word length. You'll get overshuts that don't exist in the input, epecially around point 0.

[FranceBB]

Originally Posted by frank

The best way is to zero out that first line.

I finally had a bit of spare time to look at this and I can't believe what I found...

The values from the first three rows are:

-0.00086043 -0.00046653 -0.00063309
0.00905835 0.00289278 0.00107100
0.01858871 0.00607219 0.00265007

And you're absolutely right, the first row is negative.
How did it happen?
Easy.
I always create the LUTs at work in Studio RGB due to our requirements, then I perform a direct trilinear interpolation to convert the values to Full Range RGB and then post here publicly so that they can be used everywhere.

Simply put: trilinear interpolation got it wrong and mapped the Studio RGB values to non existing values in Full Range RGB.
This led to negative coefficients which mean absolutely nothing in this case and are wrong.
By zeroing the first line you've done the right thing 'cause you've removed the negative mapping. With a simple calculation, the actual value of the first row should be:

0.00819792 0.00242625 0.00043791

in other words, the first three rows are supposed to be:

0.00819792 0.00242625 0.00043791
0.00905835 0.00289278 0.00107100
0.01858871 0.00607219 0.00265007

You can replace them safely and make some tests, but they're gonna be right.
I will update the LUT on GitHub too and credit you in the pull request.

EDIT: Done - https://github.com/FranceBB/LinearTr...fece62b7ea4c23


Thank you for pointing this out, very very very well done as I completely overlooked it.