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

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

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

[Marsu42]

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]

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




the output of "PQ_to_BT709" looks ok-ish


Good. :)


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





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

If you want, feel free. :)

[Marsu42]

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.

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?

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.

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]

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



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



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


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.


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


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.



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



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]

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/Sample-SamsungS20-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]

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

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


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


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


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:

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

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

to this:

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

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


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:

https://i.imgur.com/u9BaFyJ.png
https://i.imgur.com/JlsJrbE.png

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



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



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


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




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!



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

Your result also looks pretty good, William! ;)

[Marsu42]

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.

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]

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)


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 (https://camo.githubusercontent.com/7882b1eec263c3ed010e792b4d2c122e6831672d9e7fdc7e53f3f4ce36ee0ebb/68747470733a2f2f692e696d6775722e636f6d2f774f4f644962342e706e67) (i.e slightly larger in the frame would be better)



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


Welcome to HDR PQ XD


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]

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.


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]

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! :D

[wswartzendruber]

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

Can I get a sample somewhere?

[FranceBB]

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

[wswartzendruber]

Psst! Remember that Apple sample...

[FranceBB]

Psst! Remember that Apple sample...

Damn, I knew I was gonna forget!
Check your PM

[wswartzendruber]

Cool! I'll grab it when I get home.

[wswartzendruber]

That's BT.709 with HLG being falsely signaled in the bitstream.

[FranceBB]

That's BT.709 with HLG being falsely signaled in the bitstream.

hahahahahahaha
Apple iPhone Pro? More like Apple screw up pro then!

But no, seriously, that cannot be.
It is indeed BT2020 with HLG in it in fact:

(disclaimer: the picture shows one of our F1 journalists doing a speech)

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

The problem is that the camera sensor of the iPhone has really just a bunch of stops, so the resulting HLG will be bad and with really bad overshooting over the 0.52V (i.e 75% reference).


So... although it actually really is BT2020 HLG, it really doesn't introduce any improvement over a standard BT709 SDR recording as I'm pretty sure iPhone sensors barely have 6 stops (which is what you need for 100 nits...)



Now, I clearly cannot share the """master""" of the speech, but here's a more public sample I can share about a landscape: Link (https://bit.ly/3pld586)

The same goes for this sample depicting Christmas Lights, which is indeed BT2020 HLG with overshooting ('cause lights would require many more stops than the ones currently available in the iPhone):

https://i.imgur.com/02X0591.png
https://i.imgur.com/1cQT6xC.png


On the left hand side, there's the displayed version assuming it as BT2020 HLG (correct) and on the right hand side there's the displayed version assuming it as BT709 SDR (not correct):

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


Still, does it make sense to have HLG on such a puny sensor? Probably not...
But you know, it's Apple, if they have like 7 stops and can turn the BT709 SDR 100 nits into a 175 nits BT2020 HLG, they'll call it HDR and scream to the whole world that they're great... :P

[Balling]

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! :D

Samsung still uses PQ. My galaxy s22. Apple uses HLG with dolby vision meta to derive PQ.

[Balling]

>But you know, it's Apple, if they have like 7 stops and can turn the

iPhone 13 has 12 stops.

[FranceBB]

iPhone 13 has 12 stops.

For real or is it what they declared on paper like when they were fined for misleading info about their monitors?

It would be nice to see a sample.
The reason why I'm skeptical is that big sensors like the full frame one of the Sony A7 III have 15 stops, so it would really surprise me if Apple had 12 on their tiny sensors in their phones...

[Majorlag]

FranceBB,
I noticed that a few people where trying to get your wonderful LUT's to work better for them. I wanted to share the script I use to get HDR to SDR to work for me with PQ to SDR. This worked for Marsu42's sample clip without a custom LUT. This uses LaTo's SmoothAdjust 3.20 Avisynth plugin to change gamma, since HDR and SDR have different gamma levels. No need to figure out brightness levels of source. Tested on several clips with great results. Thanks again for your hard work in create those LUT's

#Bringing everything to 16bit
ConvertBits(16)

#Stack when working in 16bit precision for SmoothLevels
#HDR and SDR have different Levels, then unstack
#Lmode 3 to keep blacks from crushing, and white from greying
ConvertToStacked()
SmoothLevels16(HQ=true,preset="fullrange",gamma=0.8,Lmode=3)
ConvertFromStacked()

#Converting YUV to RGB with 16bit precision
ConvertToPlanarRGB()

#Tone-mapping HDR PQ to SDR LUT
Cube("C:\Program Files (x86)\AviSynth+\LUTs\PQ_to_BT709_v1.cube")

#Converting RGB to YUV 4:2:0 planar with 16bit precision
ConvertToYUV420()

[Balling]

Latest Davinci added profile 5 Dolby Vision decoder. Only MacOS.

[FranceBB]

Only MacOS.

bummer

[wswartzendruber]

This uses LaTo's SmoothAdjust 3.20 Avisynth plugin to change gamma, since HDR and SDR have different gamma levels.
If this is true, then my hlg-tools converter is doing things wrong. Ultimately, I can't figure out how to scale brightness.

1. BT.1886 implies that SDR->HDR brightness scaling requires no gamma adjustment.

2. BT.2100 implies that gamma adjustment is absolutely necessary, and the HLG EOTF handles this.

3. BT.2446 states that it's optional.

:confused:

[Majorlag]

I have not tested any HLG content. All the videos that I have dealt with are all PQ.

I could be wrong, I thought I read that HDR used a different gamma. Without changing the gamma, it looks a bit washed out, especially the sun and clouds in scenes using the LUTs. The gamma shift and LUTs are also much closer to SDR blu-ray of of the same UHD HDR clips that other plugins never seem to get close to.

I was mostly posting my script because I saw one of the previous posters wished it was a bit darker. I have never been a fan of the other scripts out there, so hopefully someone else finds it useful to them, or maybe have a starting point to run with it and improve. Again, never tested HDR HLG, at least with HDR PQ I get the results that is most pleasing to me after spending countless days trying to get HDR PQ sources to convert nicely

[Majorlag]

If this is true, then my hlg-tools converter is doing things wrong. Ultimately, I can't figure out how to scale brightness.

1. BT.1886 implies that SDR->HDR brightness scaling requires no gamma adjustment.

2. BT.2100 implies that gamma adjustment is absolutely necessary, and the HLG EOTF handles this.

3. BT.2446 states that it's optional.

:confused:

I found a recent article talking about different gamma at https://www.igorslab.de/en/all-around-the-topic-colors-part-2-monitor-basics/2/. With Rec.709 at 2.4 and Rec.2020 at 2.2. This is the same that I have read from several sources for the last few years. Interesting BT.1886 I thought was 2.35 for gamma and is mentioned in that article as being between 2.2 and 2.4.

Maybe my method of madness is way off, but the end result was close, but changing it by 0.2 by changing the plugin's gamma value 1.0 (do nothing) to 0.8 resulted in satisfactory results for me and my setup. Not sure why I have to shift the gamma before the LUT, but it worked better before then after the 3d colour volume change.

[Balling]

"Interesting BT.1886 I thought was 2.35 for gamma and is mentioned in that article as being between 2.2 and 2.4."

It is 2.35, as in CRT true curve. Sony just moved to 2.4 after their reference LCD got better black point. And anyway, 2.4 is correct rounding for 2.35.

https://mixinglight.com/color-grading-tutorials/gamma-2-2-vs-gamma-2-4-davinci-resolve/
https://referencehometheater.com/2014/commentary/gamma-correct/

The article is garbage. sRGB does not use pure gamma, in fact nothing uses pure gamma nowadays (only Adobe RGB 1998).

From the article "I use C1 BT.1886 at home with my LG OLED, I personally like it better than Gamma 2.4 (matter of taste)."

What is the difference? Is BT.1886 using the light sensor as it should per BT.1886?

"and Rec.2020 at 2.2."

It does not say that. BT.1886 is used for it too.

[Majorlag]

I should clarify. The metadata of PQ HDR files that I deal with has "Color primaries:BT.2020" "Mastering display color primaries:Display P3" While Display P3 (comes from Apple) uses D65 (6500 K as in sRGB and Adobe RGB) and Gamma 2.2 (like sRGB). The D65 white point is now used internationally as a standard

The opinion of the quality of the article can be debated, however this is not the only site that has the same information referencing gamma 2.2 for HDR and 2.4 for SDR. That was just the most recent article I could find. Not sure what all claims the rest of the article talks about, it was more of a simplified explanation of why I find reducing gamma seems to work for my needs in converting HDR to SDR.

[Balling]

"referencing gamma 2.2 for HDR and 2.4 for SDR"

The article only talks about SDR. What??

"Mastering display color primaries Display P3"

You do understand that still means color primaries are BT.2020? Also, this is typo in Mediainfo. Display P3 is sRGB transfer. It actually means P3-D65.

[FranceBB]

Bravo Francesco, ottimo lavoro!

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


Hey Sporv, I'm getting closer to satisfy your request.
I've added:

BT2020 HLG to DCI P3 D63 XYZ γ 2.6
BT2020 PQ to DCI P3 D63 XYZ γ 2.6

https://i.imgur.com/UFnVxN5.png
https://i.imgur.com/rW9gvoJ.png

also check this out: https://forum.doom9.org/showthread.php?p=1979435

[FranceBB]

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


Changelog:

- Introduced support to DCI P3 D63 XYZ conversion to/from BT2020 HLG & PQ as requested by Sporv.


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

LinearTransformation(Input="BT2020_HLG", Output="DCI_XYZ")

LinearTransformation(Input="DCI_XYZ", Output="BT2020_HLG")

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



https://github.com/FranceBB/LinearTransformation/releases/


Note:
Please note that going back from DCI P3 D63 XYZ to PQ RGB is particularly hard and although I tweaked it on a few titles, the end result is supposed to be manually checked, especially 'cause this is all based on "static" MaxCLL assumptions which may not fit each and every case and for this very reason I wouldn't trust the conversion in a totally automatic process.
As far as HLG is concerned, however, you can safely "turn the autopilot on" and trust the conversion.

[Balling]

Adobe just released Camera Raw 15.1, that properly supports PQ surface on windows 11 for 48 megapixel DNGs from iPhone 14. It has insane HDR. My Galaxy S22 Ultra Expert RAW has NO HDR. Not even a pixel. WTF. Fake RAW, bad Samsung.

See some samples: crazy HDR https://www.dropbox.com/s/kl764411n9jxr5c/iPhone14Pro_ProRAW48MP.DNG?dl=1

Simple HDR: https://www.dropbox.com/s/ormope1xmzysdwq/IMG_1138.DNG?dl=0

Almost no HDR: https://www.dropbox.com/s/rqyasvk2hwqhfc1/IMG_1151.DNG?dl=0

[Dragon1981]

Guys,
I like dolby vision profile v5 output converted through davinci resolve of the HDR (HLG) videos shot on my iPhone 12. Is it possible to have same kind of color output in SDR through some LUT?
Used FranceBB LUT for iPhone SDR export but it doesn't quite go near to DV v5 color matching.

[FranceBB]

Used FranceBB LUT for iPhone SDR export but it doesn't quite go near to DV v5 color matching.

Have you tried the standard HLG to BT709 LUTs too?
The thing is that a lut doesn't understand Dolby Vision metadata, it's just a matrix: numbers in, numbers out, so the results can change.
Post a sample and I'll see what I can do.

Oh, almost forgot: Merry Christmas! ;)

[Dragon1981]

Have you tried the standard HLG to BT709 LUTs too?
The thing is that a lut doesn't understand Dolby Vision metadata, it's just a matrix: numbers in, numbers out, so the results can change.
Post a sample and I'll see what I can do.

Oh, almost forgot: Merry Christmas! ;)

Merry Christmas!

Whenever I import "HLG_BT2020_to_Linear_BT709.cube " LUT in my resolve, it gives error". Attached is the screenshot.
Other LUTs import worked fine from your collection.

Below, I am giving original sample and processed videos as you asked.

Original HLG video from iPhone 12:
https://drive.google.com/file/d/1M_O50P0Rv0zzzB5ndSPxSx4IJ1kLj-8U/view?usp=share_link

Processed SDR video in resolve with your "HLG_A_to_LinearBT709" LUT:
https://drive.google.com/file/d/1RaNOOWqm7CvdSJUcSvB3I8hgYwq-1fC2/view?usp=share_link

Processed Dolby Vision Profile v5 video in Resolve:
https://drive.google.com/file/d/1L4z6VUNI6AQg8muxv5WBa9wcyd3kJgBh/view?usp=share_link

I am attaching project settings and export video settings of Resolve here for dolby vision export and SDR export for your information.

[FranceBB]

Happy New Year! :)

So... let's first take a look at what we have here.
The reference white of 75% has overshooting over 0.52V in what is supposed to be specular highlights like the reflections in the tiara and the other pieces of jewelry that the girl is wearing. Far from being an ideal shot, but I guess we can't expect much from a tiny sensor like the one we have in mobile phones (iPhones included):

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

Although there's a great deal of motion blur at 29,970p, at least the real reference white is correctly positioned at 0.52V as we can see on the left hand side of the waveform monitor, so looks like Apple didn't screw this up completely after all:

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


This is the conversion with the non public BBC LUT:


video=LWLibavVideoSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\Sample.mov")
audio=LWLibavAudioSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\Sample.mov")
AudioDub(video, audio)

ConvertBits(16)
ConvertToPlanarRGB(matrix="Rec2020")
Cube("C:\Program Files (x86)\AviSynth+\LUTs\8a_HLG_bt709_AC_mode-nar_in-nar_out-nar_nocomp.cube", fullrange=true)
ConverttoYUV420(matrix="Rec709")


https://i.imgur.com/4EZ2pfO.png
https://i.imgur.com/FSXMXKb.png

Now, I know that the BBC LUT is correct, which means that there's something deeply wrong in the way Apple's logic saved the BT.2020 colours as there's a huge shift towards the magenta and red.
As always, my HLG_A_to_LinearBT709 LUT was done in 2021 to address that and in fact the result is quite pleasing:

video=LWLibavVideoSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\Sample.mov")
audio=LWLibavAudioSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\Sample.mov")
AudioDub(video, audio)

ConvertBits(16)
ConvertToPlanarRGB(matrix="Rec2020")
Cube("C:\Program Files (x86)\AviSynth+\LUTs\HLG_A_to_LinearBT709.cube", fullrange=true)
ConverttoYUV420(matrix="Rec709")

https://i.imgur.com/xy37zdB.png
https://i.imgur.com/NYJJHrm.png


The magenta shift is still quite noticeable, though, in your case, so I would still consider color shifting a bit more or reduce the saturation in the magenta part only altogether.
I think something like this looks much more natural:

video=LWLibavVideoSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\Sample.mov")
audio=LWLibavAudioSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\Sample.mov")
AudioDub(video, audio)

ConvertBits(16)
ConvertToPlanarRGB(matrix="Rec2020")
Cube("C:\Program Files (x86)\AviSynth+\LUTs\HLG_A_to_LinearBT709.cube", fullrange=true)
ConverttoYUV420(matrix="Rec709")
tweak(StartHue=75, EndHue=135, sat=0.70, dither=true)

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

[Dragon1981]

Happy New Year! :)


Happy New Year. That's one hell of analysis which is certainly above my understanding and requirement. Thanks for the detailed reply though.
I shoot lots of home videos of my daughter. I normally convert them in Dolby Vision (for my TV) and Rec709 (for sharing).
Just wanted to have quick LUT which can give me Rec709 video in color grades like Dolby Vision.
I guess I will just use your LUT which gives decent colours in Rec709.
:thanks:

[FranceBB]

I shoot lots of home videos of my daughter.

Oh, I didn't know that she was your daughter.
It's nice that you get to spend some time with your family. :)


I guess I will just use your LUT which gives decent colours in Rec709.

Yeah, for home videos sharing is more than enough.
The "official" use we have of that LUT is for our News channel.
Essentially we get people/viewers sending us videos from all over the world 'cause everyone has a smartphone around these days and people started sending us videos in HLG shot with the iPhone in early 2021, so we needed to cope with those, especially given that the news channel is still in FULL HD BT709, hence the LUT. ;)
The other use we had for this LUT was during the America's Cup 'cause we couldn't send cameramen physically on the boats as they would slow them down, so we had the crew recording videos on their iPhone in HLG and sending those over (I talked about this early on in this topic if you're curious (https://forum.doom9.org/showthread.php?p=1934075#post1934075) :) )

[Balling]

There are now HDR10+ EETFs in libplacebo and in ffmpeg. https://github.com/FFmpeg/FFmpeg/commit/eabc304d123bb4193ae8dc7a602530c2e0d86450

So initial support for the base of Dolby Vision curves too, another part of ST2094

[FranceBB]

Any chance of having a CPU only version of libplacebo in FFMpeg as well as the current GPU one?
I mean, currently it requires GPU acceleration, which is fine for on prem, but not very cloud friendly given the limits of most AWS EC2...
Ideally, if a GPU isn't available, it should be able to have a CPU only fallback instead of failing.

[quietvoid]

Any chance of having a CPU only version of libplacebo in FFMpeg as well as the current GPU one?
I mean, currently it requires GPU acceleration, which is fine for on prem, but not very cloud friendly given the limits of most AWS EC2...
Ideally, if a GPU isn't available, it should be able to have a CPU only fallback instead of failing.

I've had no problem running it with "lavapipe" on Linux. Of course it comes from mesa.
https://archlinux.org/packages/extra/x86_64/vulkan-swrast/

Following the Arch Wiki example for "Software Vulkan: lavapipe" at: https://wiki.archlinux.org/title/Vulkan.

Environment vars: LIBGL_ALWAYS_SOFTWARE=1 __GLX_VENDOR_LIBRARY_NAME=mesa VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.i686.json:/usr/share/vulkan/icd.d/lvp_icd.x86_64.json
Command: ffmpeg -i video.mkv -init_hw_device vulkan -vf hwupload,libplacebo=format=yuv420p,hwdownload,format=yuv420p test.mkv

[libplacebo @ 0x563979c887c0] Device Name: llvmpipe (LLVM 15.0.7, 256 bits)

I don't know if this method would work for your environment.
In FFmpeg, vf_libplacebo is currently only supported for Vulkan frames. It's a GPU library, after all.

[OrangeColaJuice]

... my ancient iGPU lacks Vulkan support, so sad that I can't make short videos of my favorite HDR movies to share on Mongolian basket waving forums/imageboards.

[wswartzendruber]

... my ancient iGPU lacks Vulkan support, so sad that I can't make short videos of my favorite HDR movies to share on Mongolian basket waving forums/imageboards.
I lived in Ulaanbaatar, Mongolia from 1995 to 2000.

I don't remember anything about basket weaving.