FranceBB LUT Collection

[frank]

Ok, thanks as always.

But I found another wrong LUT: PQ_to_HLG.cube
There the first 4290 rows have wrong negative elements.

Well we can generate the LUT with William's generator but you shoult correct it. This LUT is very important.
And please update your github releases. I only found v2.1.

[FranceBB]

Linear Transformation v2.2 Released!!

Changelog:

Re-interpolated and removed illegal negative values to avoid overflow in Avisynth Cube() and DGCube() implementation in both BT709 to BT2020 HLG and BT2100 PQ to BT2020 HLG. Credits to frank from Germany.

Tested on the .ts version of Army of the Dead (which is the closest thing I have to a low bitrate consumer version):

[Marsu42]

Originally Posted by FranceBB

Hi,
LUTs are generally used to grade contents, but they can be useful to do quick and dirt color space conversions, especially in this day and age.

Can I use any of these to to convert my Samsung HDR10+ phone vidoes to SDR for my regular PC montior? The mediainfo output of the source mp4 file is:

Color range: Limited
Color primaries:  BT.2020
Transfer characteristics: PQ
Matrix coefficients: BT.2020 non-constant
Mastering display color primaries: Display P3
Mastering display luminance: min: 0.0050 cd/m2, max: 1000 cd/m2

The FFMpeg tonemap filter is very slow. I've been trying to use some of these .cube files, but now have to ask because I this is simply too confusing for me - the output of "PQ_to_BT709" looks ok-ish, and I've tried combination of others - but I'm really not understanding what I'm doing I'm afraid to say. Plus I don't know what set for the encoder output --color-primaries --matrix-coefficients --transfer-characteristics settings.

Edit: I could upload a short source file clip to some sharehoster.

[FranceBB]

Originally Posted by Marsu42

Can I use any of these to to convert my Samsung HDR10+ phone vidoes to SDR for my regular PC montior?

Absolutely, however given that they're static LUTs, they won't benefit from the dynamic metadata of HDR10+ (i.e the transformation will be static).
If it's just to watch them, I strongly suggest you MPV as a player, which is open source, cross platform and it will perform dynamic tonemapping to BT709 automatically in a scene-by-scene fashion.

Anyway, if you want to re-encode them to BT709 SDR instead, then you're in the right place.

Originally Posted by Marsu42

the output of "PQ_to_BT709" looks ok-ish

Good.

Originally Posted by Marsu42

I don't know what set for the encoder output --color-primaries --matrix-coefficients --transfer-characteristics settings.

it's pretty easy, for x262, x264 and x265 it's just

--colormatrix bt709 --transfer bt709 --colorprim bt709

while for FFMpeg it's:

-color_primaries 1 -color_trc 1 -colorspace 1

Originally Posted by Marsu42

I could upload a short source file clip to some sharehoster.

If you want, feel free.

[Marsu42]

Originally Posted by FranceBB

Absolutely, however given that they're static LUTs, they won't benefit from the dynamic metadata of HDR10+ (i.e the transformation will be static).

Um, how bad is this?

Sorry, usually I'm not _that_ clueless, but this whole hdr stuff is news to me, I'm usually all about images (including color spaces like Adobe RGB or Photo Pro) and regular (sdr) video transcoding. However, now I've just got this fancy new phone and discovered the HDR10+ switch...

Use case: My desktop hardware (connected to the large monitor) is simply too slow to decode the 4k hevc clip, so I need to transcode. Plus I'd like to carry around my favorite clips with reduced bitrate and resolution.

Originally Posted by FranceBB

If it's just to watch them, I strongly suggest you MPV as a player, which is open source, cross platform and it will perform dynamic tonemapping to BT709 automatically in a scene-by-scene fashion.

Thanks, I didn't realize mpv has that many options!

The --target-prim=bt.709 --tone-mapping=mobius combination seems to do what I've achieved with ffmpeg, but since even regular playback ls lagging...

MPV even has an option to use the .cube files, but the video playback is... very colorful :-) using --image-lut=PQ_to_BT709_v2.cube --vo=gpu-next. I've tried all options for --image-lut-type= so I'm probably missing something, or my GPU isn't "next" enough?

Originally Posted by FranceBB

it's pretty easy, for x262, x264 and x265 it's just --colormatrix bt709 --transfer bt709 --colorprim bt709.

Right, thanks, I was wondering if all these three get changed to bt709 with the lut3d.

Originally Posted by FranceBB

If you want, feel free.

Sample-SamsungS20-BT2020-HDR10+.mp4: https://www119.zippyshare.com/v/1xzay9yv/file.html

As you can see, it's a contrasty scene, and I'm really struggling to finde the "correct" .cube file (and/or ffmpeg/mpv video filter options). Even the difference between v1 and v2 PQ_to_BT709 seems tricky, and both look a bit washed-out and not colorful enough to me. However, while being inside in the winter I don't quite remember how it was like in the summer.

The exiftool output (mediainfo see above) says it's BT2100, too... which accordung to Wikipedia is same-ish as BT2020. Right, I'm really new to this, so any help is appreciated.

ColorProfiles: nclx
ColorPrimaries: BT.2020, BT.2100
TransferCharacteristics: SMPTE ST 2084, ITU BT.2100 PQ
MatrixCoefficients: BT.2020 non-constant luminance, BT.2100 YCbCr

[wswartzendruber]

BT.2100 (both PQ and HLG) use BT.2020 color values. "Transfer characteristics" is where BT.2100 emerges with its own take on things (either PQ or HLG).

To refer to BT.2100 color...is...strange...

[FranceBB]

Originally Posted by Marsu42

Um, how bad is this?

Not too bad, but let's just say that dynamic tonemapping would be better, however given that it's not a movie but rather a video shot by your mobile phone, it's gonna be fine. I'm actually surprised to see mobile phones shooting in PQ out there, I thought smartphones were all gonna implement HLG...

Originally Posted by Marsu42

Sorry, usually I'm not _that_ clueless, but this whole hdr stuff is news to me,

no worries, we can't be expert in everything. I myself don't know lots of things. For instance, when people like Ferenc, Jean Philippe, Donald, ifb, DTL etc make use of intrinsics and write long complicated assembly stuff (or inline assembly code back in the days) I always have a big surprised face ('cause I can't).

Originally Posted by Marsu42

now I've just got this fancy new phone and discovered the HDR10+ switch...

Eh, at least you've got PQ, I'm pretty angry at Google 'cause both my Google Pixel 5 and my Google Pixel 6 Pro got only LogV2 for HDR or the normal BT709 SDR 100 nits, but rumors say that Google engineers decided to introduce HLG with the new 7 (which I actually didn't want to buy straight away to be fair, but if rumors are true, then I guess I don't have any other choice)...

p.s for those wondering, I turn all my LogV2 into HLG

Originally Posted by Marsu42

Use case: My desktop hardware (connected to the large monitor) is simply too slow to decode the 4k hevc clip, so I need to transcode. Plus I'd like to carry around my favorite clips with reduced bitrate and resolution.

Gotcha. No problem.

Originally Posted by Marsu42

Thanks, I didn't realize mpv has that many options!

Yeah, it's one of the best players ever and for HDR I think it's the de facto best in terms of output results (but it's really really heavy in terms of processing).

Originally Posted by Marsu42

MPV even has an option to use the .cube files, but the video playback is... very colorful :-)

Yeah, it's probably an internal planar RGB conversion screw-up, don't worry.

Originally Posted by Marsu42

Sample-SamsungS20-BT2020-HDR10+.mp4: https://www119.zippyshare.com/v/1xzay9yv/file.html

Well, turns out ZippyShare is blocked everywhere. I even tried 3 different British VPN servers, but nothing, then I remembered that StainlessS (who actually lives in the UK) said that it was blocked over there, so switched to a US server and I've been finally able to access the file.


Unlocked in the US: https://i.imgur.com/JTnjr5N.png
Blocked in the UK: https://i.imgur.com/eRCXXrr.png

Originally Posted by Marsu42

As you can see, it's a contrasty scene, and I'm really struggling to finde the "correct" .cube file (and/or ffmpeg/mpv video filter options). Even the difference between v1 and v2 PQ_to_BT709 seems tricky, and both look a bit washed-out and not colorful enough to me. However, while being inside in the winter I don't quite remember how it was like in the summer.

Well, the BT709 should look something like this (which is MPV with my settings): https://i.imgur.com/5GdDipi.jpg

For reference, VLC got it completely wrong (but still watchable): https://i.imgur.com/dwz9gaC.png


and this is the original image for comparison: https://i.imgur.com/Lt7ZyeT.jpg



Anyway, tomorrow I'll fire up Avisynth and I'll give it a shot. Right now it's late in the evening and I don't feel like booting Windows up as I'm on Linux and I'm about to brush my teeth and go to bed.

[Marsu42]

Originally Posted by FranceBB

Well, the BT709 should look something like this (which is MPV with my settings): https://i.imgur.com/5GdDipi.jpg

Thanks for your help so far! This is really bugging me, so I had another go at it.

I've found another software with built-in hdr to sdr mode: MPC Video Renderer is a dx filter and thus is usuable in about every video player. It's not as configurable as MPV, but it does have a GUI :-) ... the last release includes "Optimized PQ to SDR conversion using D3D11 video processor on Windows 10." (which doesn't help with my ancient desktop computer hardware, but still sounds useful). https://github.com/Aleksoid1978/VideoRenderer/releases

This is a reference screenshot of the original HDR10+ mp4 in hdr mode: https://i.imgur.com/oOvAPIN.jpg
This is with MPCVR sdr conversion enabled - I suppose this is about what it should look like: https://i.imgur.com/1nQI34y.jpg

Your screnshot from MPV is too dark imho - it was a glazing summer day, with harsh shadows but overall high brightness. I don't have a tv, but a computer monitor, so I suppose ymmv how it looks. For another reference, this is ffmpeg with "zscale=transfer=linear:npl=100,format=gbrpf32le,zscale=primaries=bt709,tonemap=tonemap=hable:desat=1.5,zscale=transfer=bt709:matrix=bt709:range=limited" which is still not as dark: https://i.imgur.com/X9qKLWE.jpg

It've tried to replicate the MPCVR result with your .cube files, and only succeeded by chaining lut3d='lut/PQ_to_HLG.cube',lut3d='HLG_BT2020_to_Linear_BT709.cube': https://i.imgur.com/kj7jh0t.jpg
The encoding time is a little longer with doing lut3d twice.

The 'PQ_to_BT709' .cube files sound about right, and the result looks nice, but it's a little too bright and/or the colours are a bit washed out:
PQ_to_BT709_v1.cube: https://i.imgur.com/eLRn35g.jpg
PQ_to_BT709_v2.cube: https://i.imgur.com/JQHV0bF.jpg

All screenshots from the ffmpeg trancodes are 8-bit (x264), thus the banding, but it's the only format my ancient desktop computer can decode in hardware.

[Marsu42]

After using avisynth after all, I've found a better solution, because my ancient desktop computer happens to have an external nNvidia gpu - the CUDA plugin DGHDRtoSDR is ~100% faster than ffmpeg lut3d, ~50% faster than avs Cube and ~25% faster than avs DGCube.

z_ConvertFormat(width=2560, height=1440, resample_filter="bilinear", pixel_type="YUV420P16")
DGHDRtoSDR(mode="pq", fulldepth=true, white=1500)

http://avisynth.nl/index.php/Avsresize
http://avisynth.nl/index.php/DGHDRtoSDR

Plus DGHDRtoSDR configurable, solving any color or brightness issues I had with the PQ to SDR cube files.

I tried to use purely ffmpeg with lut3d because I can simply put the -vf filter comands in the av1an command line for the encoding stage - so a single .cube file delivering a MPCVR-ish output would still be welcome.

[richardpl]

lut3d is CPU only, if you could get ffmpeg with libplacebo filter you could use GPU with .cube files.

[wswartzendruber]

Here's the thing with going from PQ to either HLG or SDR: You have to know where reference white sits in the PQ source. So if your source content isn't specifically graded to a standard level, your results can appear either too bright or too dark when going to a relative brightness transfer function. This is true of converting to SDR, and when converting to HLG and viewing on SDR. As your phone is not controlling reference white, we need to determine this value.

First, let's get something else out of the way. The HDR10 metadata in your clip puts MaxCLL at 1,000 nits, but when fishing around for bright pixels, I'm finding them as high as 1,500 nits.

So then, what's the reference white level of your clip? Well, we don't really have any good way to determine this using things that are already white. There are the bird feathers, but they're not ever lit ideally. They're either under direct sunlight (overshoot), or in non-direct light (undershoot). So we have to use an alternative method. Like some of the grass that's visible. When in sunlight, grass should have a nominal luminance of 30 to 65 nits. We'll just use 48 nits as an average.

When blurring a grayscale of your image, some grass comes out to 35% signal strength. That comes out to just 18 nits. And we need to get it to 48 nits. 48 / 18 = 2.67. This is our luminosity scaling factor.

pq2hlg -s 65 -m 1500 -l 2.67 pq2hlg.cube

Here is the result: https://wswartzendruber.net/videos/S...BT2020-HLG.mp4

And that HLG file has reference white much, much closer to where it should be. This should also let you take one of FranceBB's HLG to BT.709 LUTs and get a really good SDR result.

EDIT: And you won't need mpv to dynamically adjust brightness for you.

[FranceBB]

Originally Posted by wswartzendruber

Here's the thing with going from PQ to either HLG or SDR: You have to know where reference white sits in the PQ source. So if your source content isn't specifically graded to a standard level, your results can appear either too bright or too dark when going to a relative brightness transfer function.

William is exactly right, you must know the reference white, otherwise you have to calculate it yourself.

In your case, the clip says absolutely nothing, it puts the default values for the mastering display in as 1000 nits, but it doesn't give us MaxCLL nor MaxFALL which is of course a problem 'cause it means that we gotta calculate it ourselves.

Here are the results of the calculation:

MinCLL: 0
MaxCLL: 1854
MaxFALL: 150




Before we say anything, here's a comparison by using my original PQ_to_BT709_v1.cube

#Indexing
FFMpegSource2("D:\Sample-SamsungS20-BT2020-HDR10+.mp4", atrack=-1)

#Screw frame properties
propClearAll()

#Going to RGB 16bit planar full range
ConvertBits(16)
ConvertToPlanarRGB(matrix="Rec2020")

#Bringing everything to BT709 with 16bit precision
Cube("C:\Programmi\AviSynth+\LUTs\PQ_to_BT709_v1.cube")

#Going back to YUV 4:2:0 Limited TV Range
ConverttoYUV420(matrix="Rec709")

Now, taking 1854 nits into account as our peak, we're gonna use it to perform the right transformation.
Now, since I don't totally trust automatic detection tools ('cause there can be compression overshoots created by the consumer-bitrate encode of H.265) I generally like to take it a bit lower and/or adjust it myself rather than blindly trust the data. As a wild guess, taking outliers out, I think that it's probably gonna be around the 1600 nits region. In this case, we're going from this:





to this:






however we don't really have anything which is totally white as our reference, so it's hard to say what the real value is (and for those wondering, no, we can't take seagulls as white 'cause otherwise we clip the rocks and we can't take the rocks as white 'cause... well... everyone knows they're not!).

Now, if I received such a picture at work and I had to bring it to BT709 myself, I would do something like:




here is your LUT (quick, it lasts 7 days only!): https://we.tl/t-9EyHeoZpC1

and you can apply it like so:

#Indexing
FFMpegSource2("D:\Sample-SamsungS20-BT2020-HDR10+.mp4", atrack=-1)

#Screw frame properties
propClearAll()

ConvertBits(16)
ConvertToPlanarRGB(matrix="Rec2020")
Cube("D:\Test.cube")
ConverttoYUV420(matrix="Rec709")

Originally Posted by wswartzendruber

when fishing around for bright pixels, I'm finding them as high as 1,500 nits.

ehehehe it's nice to see that your calculations and mine sort of check out.

Originally Posted by wswartzendruber

what's the reference white level? Well, we don't really have any good way to determine this using things that are already white. There are the bird feathers, but they're not ever lit ideally. They're either under direct sunlight (overshoot), or in non-direct light (undershoot).

I know the struggle. We generally have someone there holding a thing we use as reference with both white, black and colours. This is also why I'm pretty against mobile phones recording in PQ. I mean, with HLG none of this would have happened, so it would make much much much more sense for mobile phones to record in HLG. I mean, why Samsung, why...?! DX

Originally Posted by wswartzendruber

So we have to use an alternative method. Like some of the grass that's visible. When in sunlight, grass should have a nominal luminance of 30 to 65 nits. We'll just use 48 nits as an average.

Oh, you used grass! That's a very interesting method!

Originally Posted by wswartzendruber

Here is the result: https://wswartzendruber.net/videos/S...BT2020-HLG.mp4

Your result also looks pretty good, William!

[Marsu42]

Originally Posted by FranceBB

I know the struggle. We generally have someone there holding a thing we use as reference with both white, black and colours.

Amazing, thanks to both of you, I really have to digest all this information - but I've saved the custom .cube :-)

Concerning a PQ reference: I faintly remember that I've got a small color card lying around somewhere, I've used it for photography.

If I ever should get to a level when I handle this PQ-HLG and HDR-SDR issues: How large/... would a reference card have to be in the frame in the start of a video to fulfill its purpose?

Up until now I've just turned on the "HDR10+" switch and suspeced that the more data I record, the more I have to work with in postprocessing. I didn't think it would be this tricky without a reference.

Originally Posted by FranceBB

This is also why I'm pretty against mobile phones recording in PQ. I mean, with HLG none of this would have happened, so it would make much much much more sense for mobile phones to record in HLG. I mean, why Samsung, why...?! DX

I'm using the older Galaxy S20, which uses PQ just like the S21. From what I googling the newer S22 has HLG...

[FranceBB]

Originally Posted by Marsu42

Amazing, thanks to both of you, I really have to digest all this information - but I've saved the custom .cube :-)

No problem. You'll always be in safe hands when William replies, you're lucky he's here and active and I'm glad he is given that we're friends. (Well, virtual friends, but friends nevertheless. :P)

Originally Posted by Marsu42

Concerning a PQ reference: I faintly remember that I've got a small color card lying around somewhere, I've used it for photography.

If I ever should get to a level when I handle this PQ-HLG and HDR-SDR issues: How large/... would a reference card have to be in the frame in the start of a video to fulfill its purpose?

Not much, really, but not smaller than this Link (i.e slightly larger in the frame would be better)

Originally Posted by Marsu42

I didn't think it would be this tricky without a reference.

Welcome to HDR PQ XD

Originally Posted by Marsu42

I'm using the older Galaxy S20, which uses PQ just like the S21. From what I googling the newer S22 has HLG...

Good to know, but this means that Samsung went in bold with PQ, realized its mistakes and eventually moved "back" to HLG instead of implementing HLG from the very beginning (which would have been the right thing to do)...

[wswartzendruber]

Originally Posted by FranceBB

No problem. You'll always be in safe hands when William replies, you're lucky he's here and active and I'm glad he is given that we're friends. (Well, virtual friends, but friends nevertheless. :P)

You honor me, despite my stumbling and falling down. And there was much of that to get here.

Some things I still haven't solved. I continue to slowly evolve how I can reliably determine reference white.

Originally Posted by FranceBB

Good to know, but this means that Samsung went in bold with PQ, realized its mistakes and eventually moved "back" to HLG instead of implementing HLG from the very beginning (which would have been the right thing to do)...

Is recording HLG a trend we're going to see with smart phones?

[FranceBB]

Originally Posted by wswartzendruber

Is recording HLG a trend we're going to see with smart phones?

I really hope so!
Google is getting there from Pixel 7 onwards, Samsung now moved to HLG, Apple uses a Dolby Vision profile but with HLG inside (although with arbitrarily set values), I think we're gonna see more and more of it in the next couple of years and that's a very good thing!

[wswartzendruber]

Apple is using HLG?! That surprises me. And in a good way.

Can I get a sample somewhere?

[FranceBB]

Originally Posted by wswartzendruber

Apple is using HLG?! That surprises me. And in a good way.

Can I get a sample somewhere?

Yeah, I'm not a big fan of Apple as you can imagine. Anyway, don't get too excited, as far as I'm concerned, they made a mess out of it and I had to make a very special conditional in my workflows that checks for the Apple made videos and uses the particular "HLG_A" cube which adapts to their recordings (I couldn't call it "Apple" 'cause they would have sued me).


I'll check whether I saved some samples on Monday (so tomorrow) and I'll send them over via PM or maybe via FTP. (If I forget, remind me xD)

[wswartzendruber]

Then call it HLG_Crapple.cube

[wswartzendruber]

Psst! Remember that Apple sample...