HLG processing for good picture on SDR monitor

[VictorLS]

Due to huhn's "madVR doesn't support HLG" in thread LAV Filters - DirectShow Media Splitter and
Decoders here (http://forum.doom9.org/showthread.php?p=1883593#post1883593) I've known madVR still not support HLG (https://en.wikipedia.org/wiki/Hybrid_Log-Gamma) if it can be correctly done at all (as MPC-BE developer says there's only few HLG content so they don't want support HLG in their MPC-BE well - present their EVR Custom Presenter (EVR-CP)'s auto switching on as minimum with DXVA2 (native and copy-back) Processing: HDR(HLG) to SDR gives overcontrasted and bad saturated video as minimumn on SDR monitors - even worse than without any processing - washed out colors and i.e. red becomes orange w/o processing:
SDR (well):
https://i.postimg.cc/259tTF33/2018-SDR.png (https://postimg.cc/94T1Q9dj)
HLGw/oProcessing (undersaturated and undercontrasted):
https://i.postimg.cc/8CvvnTzW/2019-HLG.png (https://postimg.cc/hJShXWxP)
HLGtoSDRprocessing (oversaturated and overcontrasted):
https://i.postimg.cc/9FzrncxM/2019-HLGto-SDRprocessing.png (https://postimg.cc/JGVryCCV)
I've found with old version of LAV Video Decoder 0.68.1.35 (modified by Aleksoid1978 to accelerate 4K h265 10bit via NVIDIA CUVID in WinXP) Processing: HDR(HLG) to SDR not switching on even in any DXVA2 mode.
Return to huhn's "madVR doesn't support HLG" - I'm not pity very much because my old computer couldn't use madVR in modes showing not worse than EVR or EVR-CP on 4K but I want watch F1 in HLG h265 10bit 4:2:0 4K with colors not worse than before HLG (see SDR picture) in i.e. 2018 - I've recorded many files to compare - here's three of them:
20180729-160530_RTL UHDsdr.ts (73MB) https://yadi.sk/i/nKbwy-6ohkWQxw
20190511-140255_RTL UHDhlg.ts (19MB) https://yadi.sk/d/sVcYR6QgkfcGOw
20190630-183800_RTL UHDhlg.ts (14MB) https://yadi.sk/d/OjMMtl5d6JibQQ
But my GTX750v2 videocard is strong enough to process 4K video with shaders (i.e. Convert HDR to SDR or HDR but they gives wrong colors too) in EVR-CP so my questions are:
1. Does anybody know some another HLG to SDR shader I can try?
2. Can anybody write such shader which can process HLG metadata (repeat - if it can be correctly done at all)?

[videoh]

1. It's not a shader but DGHDRtoSDR 1.13 can now convert HLG to SDR. DGIndexNV can also do it for its display, with parameter sliders compatible with DGHDRtoSDR. The results are very pleasing and expose the issues with just playing HLG directly without conversion. It should be easy to do in a shader but I don't do DirectShow stuff so someone else will have to do it. I'd be happy to provide the algorithm if someone wants it to make a shader. But anyway, it's not rocket science. You just replace the PQ EOTF with the HLG EOTF.

2. AFAIK, HLG does not have any metadata that would guide the presentation. Yes, I know about the preferred transfer function SEI, but it is fixed at 18 for HLG. Lack of metadata is a big plus for HLG.

[VictorLS]

videoh, thanks for reply and your algorithm.
I'm not programmer but I've heard about DGIndexNV (DGDecNV) but never used it so I'm not sure I'll can to convert HLG to SDR correctly.
Tell me, please where can I download DGHDRtoSDR 1.13 to try to convert HLG videos to SDR to see result?
If link is a secret can you convert 20190511-140255_RTL UHDhlg.ts and/or 20190630-183800_RTL UHDhlg.ts and upload it, please?

[videoh]

No secrets from you, VictorLS! You'll find it here (scroll down a bit):

http://rationalqm.us/mine.html

You should be able to tweak parameters to fairly well match the SDR version. DGIndexNV has a GUI tweaker for it that makes finding good parameters really easy. You'll need a decent nVidia card to run DGIndexNV. You can run DGHDRtoSDR without an nVidia card but it can be slow in SW mode. Do you have a decent nVidia card installed?

The gentleman that asked me to implement this said he is very happy with the results (zys4416 at DG forum): "the result is pretty perfect". Sweetie Pie would say "purrfect".

Probably jpsdr's HDR tools can also do this conversion. Always great to hear from jpsdr so maybe he will chime in.

Bullwinkle said: "PQ sucks. People say I don't suck. HLG is the True Way."

[VictorLS]

No secrets from you, VictorLS! You'll find it here (scroll down a bit):
http://rationalqm.us/mine.html
Thanks, I've download DGHDRtoSDR_1.13.rar from there but I haven't seen algorithm there like i.e. for kerneldeint141
Do you have a decent nVidia card installed?
Yes, I have decent enough GTX750v2 on GM206 (as GTX950 and GTX960 but I think ~ two times slower) videocard - it can hardware decoding 4K h265 10bit 4:2:0 even in WinXP.
Always great to hear from jpsdr so maybe he will chime in.
I hope it'll be so.
The gentleman that asked me to implement this said he is very happy with the results (zys4416 at DG forum): "the result is pretty perfect".
I've found at http://rationalqm.us/board/viewtopic.php?f=14&t=617&start=550
I tried so AviSynth+ script in ffdshow:
=================================
loadplugin("C:\dghdrtosdr.dll")
DGHDRtoSDR(impl="sw",mode="hlg",white=1800)
Prefetch(3)
=================================
(impl="sw" because I haven't dgdecodenv.dll) but got error while playing trim_187.ts and my test h265 SD SDR quasi-interlaced file (I've written AviSynth(+)-script to deinterlace it correctly). How can I get YUV420P16?

[videoh]

Thanks, I've download DGHDRtoSDR_1.13.rar from there but I haven't seen algorithm there like i.e. for kerneldeint141 I'm not sure what you mean by "algorithm" here. What exactly are you looking for, source code?

I've found at http://rationalqm.us/board/viewtopic.php?f=14&t=617&start=550
I tried so AviSynth+ script in ffdshow:
=================================
loadplugin("C:\dghdrtosdr.dll")
DGHDRtoSDR(impl="sw",mode="hlg",white=1800)
Prefetch(3)
=================================
(impl="sw" because I haven't dgdecodenv.dll) but got error while playing trim_187.ts and my test h265 SD SDR quasi-interlaced file (I've written AviSynth(+)-script to deinterlace it correctly). How can I get YUV420P16? Your script needs a source filter capable of delivering high-bit depth 10-bit in YUV420P16. That would normally be DGSource(), but I am sure there are others. Send me a PM and I'll gift you a DGDecNV license, as you seem to be a fine chap. You probably want a 10-series card or better for UHD 10-bit HEVC stuff.

[VictorLS]

I'm not sure what you mean by "algorithm" here. What exactly are you looking for, source code?
May be source code - I'm not programmer so all can help to write shader after your
I'd be happy to provide the algorithm if someone wants it to make a shader
will be appreciated.
Your script needs a source filter capable of delivering high-bit depth 10-bit in YUV420P16. That would normally be DGSource(), but I am sure there are others.
I see.
Send me a PM and I'll gift you a DGDecNV license, as you seem to be a fine chap.
I'm from Russian Crimea and you can change your opinion http://forum.doom9.org/search.php?searchid=8484373&pp=200 (read mostly from 27th July 2016, 17:30 to 20th November 2016, 09:56) ;)
In any case many thanks for proposition (in anyway we are in Crimea under sanctions and PayPal not work in Crimea as international cards too) - I've sent you PM.
You probably want a 10-series card or better for UHD 10-bit HEVC stuff.
I want hypotetic 30-series weak (and therefore cheap and silent as mine GTX750v2 - btw I removed fan from at all so it's passive now - just almost noiseless 120mm not too far from that and it still cool while hardware decoding 4K h265 10bit 4:2:0 video with ~ 50% load of VideoEngine) videocard with 4GB VideoRAM and hardware acceleration HEVC 8K 4:2:2 (for some SAT feeds - nVIDIA has promised to think about) and 4:4:4 (20-series can accelerate 4:4:4 already but I haven't seen from SAT yet) and VP10 and AV1 in Windows7x64 ;)

[DJATOM]

Yeah, no 4:2:2 atm for 20 series, but is there are some channels airing in 4:2:2 chroma subsampling format? That's a news for me.

[VictorLS]

DJATOM
Best regards to former and I hope future in Russian World compatriot.
is there are some channels airing in 4:2:2 chroma subsampling format? That's a news for me.
Despite it's offtop here - about 10 years ago was 4:2:2 MPEG2 permanent SD channel MED OFFICE on 39e satellite MED OFFICE.ts (10MB) https://yadi.sk/i/NnRontXRs-xckA - I knew only Elecard could decode it that time.
First race of FormulaE in history was translated from 4:2:2 feed - I've remuxed it with mkvtoolnix 09-13_13-19-15_hy1_-002.mkv (126MB) https://yadi.sk/i/G7KrUACkbUYEU
Eurovision 1920x1080i50 feeds was MPEG2 and now h264 but always 4:2:2
In some years international F1 feed from 10e is transmitted as h264 1920x1080i50 4:2:2 (namely when F1 - other events of weekend are in 4:2:0 chroma subsampling) i.e. 4:2:2 20190414-090034_TATA WIF Main_КвятКитай.ts (19MB) https://yadi.sk/i/XqdkpfKMddC_vA
In some month if I remember correctly from 4e9 was transmitting 3840x2160p25 4KUA channel 20171204-234107_4KUA.ts (55MB) https://yadi.sk/d/bo-0KiV83QKoge - only MainConcept HEVC Video Decoder can decode all 25 frames per second on my old and weak Athlon II x3 460 with ~90% load of each core, LAV Video Decoder stutters with 100% load.
Later I saw just seldom feeds like h264 1920x1080i50 4:2:2 09-16_14-29-23_LEV VS VAL HD50_.ts (62MB) https://yadi.sk/d/2lXjVe2S3MxFXG (my processor is quite enough to decode all 50 fps with ~50% load) or h265 4:2:2 3840x2160p50 20180428-175510_4K ENC 3 RMAD VS LEG.ts (563MB) https://yadi.sk/d/m0s5ztpj3XnUyw - I believe few processors (begining from Intel Core i7 and top AMD Ryzen) can decode all 50 frames per second and keep video and audio synced. I watched it with MainConcept's SkipPB option or with MPC Video Decoder with "Skip non Intra frames" in Properties of MPCVideoDec_skip_non_I-frames.7z (7,2MB) https://yadi.sk/d/ZBA-K2-6UUV4TQ with synced audio and ~1fps ;)

videoh
Thank you very much - I've got well enough (some cool) colors while playing HLG in DGIndexNV:
https://i.postimg.cc/XY99mW3m/DGIndex-NV-HLG.png (https://postimages.org/)

[DJATOM]

VictorLS
И тебе привет (:
(Hope mods will not restrict me for few Russian words)

So there are not so much channels with 4:2:2 color mode, I see. Actually it might be useful for animes, since usually it's done into Apple ProRes 4:2:2 @ 10 bit (I have few friends who worked on such files, but they didn't shared those with me due to NDA). I personally think it's better to use 4:4:4 (with upscaling of old content) for broadcasting, we're not in analogue TV era where interlace and halved chroma saved a lot of channel bandwidth, allowing more channels per allocated analogue TV frequencies and improving overall quality of transmission.

[videoh]

@VictorLS

You are most welcome and I am happy you find DG tools useful. Maybe I would pop the whites a little by backing off on the tm parameter and/or bumping up the white parameter.

@DJATOM

Hello to you too. :)

[VictorLS]

So there are not so much channels with 4:2:2 color mode, I see.
You're right.
Actually it might be useful for animes ... I personally think it's better to use 4:4:4 (with upscaling of old content) for broadcasting
I same think about 4:4:4 for anime and seem nVIDIA too - Turing-core based videocards must support hardware acceleration of 4:4:4 chroma subsampling quite well.
we're not in analogue TV era where interlace and halved chroma saved a lot of channel bandwidth, allowing more channels per allocated analogue TV frequencies and improving overall quality of transmission.
Broadcasters (even German) saves bandwidth as they can so even HD may show worse than high-quality SD channel https://sat-dx.club/viewtopic.php?f=82&t=254&start=190#p29114
In any way I haven't seen 4:4:4 from SATs yet and sure it wouldn't.
Btw my old 1-core Athlon II 3,2GHz couldn't decode 4:2:2 h264 1920x1080i50 ~20Mbit/s international F1 feed so I've bought 3-core CPU (not found 4-core that time in sale) and insert in old 690G mobo and now CPU load about 50% of each core so I need hardware acceleration of 4K, 8K and so on.
Maybe I would pop the whites a little by backing off on the tm parameter and/or bumping up the white parameter.
I'll try to watching on new binaries but it'll be appreciated if you'll once let me somehow know about new version out ;)

[DJATOM]

@videoh
Hi, Don.

@VictorLS
You can subscribe onto "Binaries update thread" and receive notifications onto e-mail. But I'm just personally checking Don's forum for new posts and updates (good reason to do so).

[VictorLS]

Maybe I would pop the whites a little by backing off on the tm parameter and/or bumping up the white parameter.
Btw here's two files to help achieve red (and other) colors while playing 4K HLG such ordinary FullHD SDR
20190511-130113_ARENA HD_flag.ts (38MB) https://yadi.sk/i/HiuZ5Rb2RKkc0g
20190511-152944_RTL UHD_flag.ts (67MB) https://yadi.sk/i/985DVw34OHQrrA

[VictorLS]

I was written about mpv https://mpv.srsfckn.biz/ is well player for HLG and this is so as minimum for last version (and with hardware acceleration in my case with --hwdec=auto in mpv.conf):
https://i.postimg.cc/8CLPVyM8/mpv-rtl-hlg.png
so problem with watching HLG records is solved but for live watching (and play records in my favorite KMPlayer) some HLG->SDR shader with quality not lower than mpv is still appreciated.

[videoh]

Btw here's two files... Thank you for the samples, VictorLS.

[VictorLS]

Thank you for the samples, VictorLS.
You're welcome.

[FranceBB]

is there are some channels airing in 4:2:2 chroma subsampling format? That's a news for me.

Professional feeds are always in 4:2:2 planar 10bit, however they are not for end users, they are for broadcasters everywhere in the world to receive the signal, decode it, do any kind of adjustment / comment then event and the re-encode it and air the event with their specifications.

For instance, the ATP Masters 1000 (https://en.wikipedia.org/wiki/ATP_Tour_Masters_1000) world feed which is shot and distributed across the whole world via Sat to all the licensors is in H.264 4:2:2 planar 10bit 25i, however once we get the signal, we make sure that luma and chroma is in limited tv range and we insert the comment, it gets dithered down to 8bit 4:2:0 planar (yv12) and re-encoded to H.264 25i with a way lower bitrate.

http://www.dtti.it/wp-content/uploads/2015/05/logo-masters-1000.gif


Actually it might be useful for animes, since usually it's done into Apple ProRes 4:2:2 @ 10 bit.


Animations of anime characters and so on are generally produced in RGB but they get exported as AppleProRes HQ 4:2:2 10bit progressive as masterfile which is the one that is generally sent to studios. I've been encoding those files from 2013 to 2015 with my previous job (still as encoder but at a different company) however I can tell you that while some studios work really well and give you a nice clean masterfile without any issues, some others don't and the file provided has any kind of issues I'm looking at you, Sentai!.
As a side note, sometimes old japanese broadcasters living in the stone-age prefer to get an XDCAM-50 file instead which is just a crappy MPEG-2 8bit yv16 telecined which is a shame 'cause if you are a sub-licensor you don't get the original masterfile from the Studio, but the mezzanine file sent to the japanese broadcaster instead.
Anyway, I did like that job, but I prefer to work as encoder in the new company as I've been encoding documentaries, tv series and other more important and exciting things than anime.


(I have few friends who worked on such files, but they didn't share those with me due to NDA).


Of course they didn't, if we ever even dare to upload such a thing and it gets leaked, not only the company we work for loses the licence but it also has to pay a big fee. What happens to the person who shared the file? Well, it gets sacked and he can say goodbye to this job as no one would ever dare to hire him in any other studio.
I can't share their name for privacy reasons, but I know a few people who have been sacked only because someone hacked their account and stole a proxy file (not even the masterfile!!) and shared it publicly on the internet via torrent before it was aired.

[VictorLS]

FranceBB, Thanks for your post.
Here's "new" HLG file 20190831-160457_RTL UHD.mkv (135MB) https://yadi.sk/i/SRloXWrOP-L-xA - mpv.exe plays it with right colors and and mpv.conf with "--hwdec=auto" near it to play with hardware acceleration if it's supported by videocard.

[Cary Knoop]

For instance, the ATP Masters 1000 (https://en.wikipedia.org/wiki/ATP_Tour_Masters_1000) world feed which is shot and distributed across the whole world via Sat to all the licensors is in H.264 4:2:2 planar 10bit 25i
Do they still use cameras that record interlaced signals? :confused:
No wonder to me broadcast is a dying breed!

ATP matches can be viewed over the internet and there are 0.0 reasons to support this idiotic interlaced signal, it's 2019 for crying out loud!
And if "granny's TV" needs it then interlace the original 50p signal over the air to 50i (or 25i if you prefer this semantic)!

[VictorLS]

50i (or 25i if you prefer this semantic)!
I'm not professional but I'm sure not 50i but i50=25i on my own.
May be someone know place where shader-writers are to ask them about writing HLG->BT.709 shader there?

[Cary Knoop]

I'm not professional but I'm sure not 50i but i50=25i on my own.

It's semantics it refers to the same thing. 50 fields per second or 25 frames per second. Personally I prefer the 50i terminology because 2 fields do not actually make a visual frame!

[VictorLS]

It's semantics it refers to the same thing. 50 fields per second or 25 frames per second.
I knew that but I'm about place of letter i (before or after number) is important: 25i means 25 full-height frames are get from 50 interlaced (half-height i50) frames.
2 fields do not actually make a visual frame!
Commonly you're right but in case of static it's equal.
Btw high quality double framerate deinterlacers (i.e. Yadif) gives enough video quality for not too fast moving to say i50=p50=50p - in case of progressive video place of p doesn't important.

[VictorLS]

After mpv I've just found that VLC 3.0.11x64 (in Win7x64) with OpenGL video output gives ~ right colors (incl. red) while playing HLG on SDR monitor.
Who can extract ps_2_0 or ps_3_0 shader from I suppose libplacebo (https://code.videolan.org/videolan/libplacebo/-/blob/master/src/shaders/colorspace.c#L819) (license is LGPLv2.1+) to use in app SmartDVB?

[VictorLS]

I've reuploaded 20190526-164153_RTL UHD.ts (687MB) https://transfiles.ru/gyjv4 for HLG tests.
Here's https://transfiles.ru/2a2f9 two new shaders but still give wrong colors on my own (tested in MPC-HC 1.9.6)
May be someone can adjust parameters to achieve colors like in mpv and VLC?

[VictorLS]

I've made some screenshots from 20190526-164153_RTL UHD.ts on Ryzen 3 3200G under Win10 2004 with Adrenalin20.7.1 (on 50Гц DVI) HLG.7z (19 MB) https://transfiles.ru/gx1mz and had asked people with eyes seeng right colors what png is nearest to real colors?

[VictorLS]

I've reuploaded 20190526-164153_RTL UHD.ts (687MB) https://transfiles.ru/gyjv4 for HLG tests
For comparison I've found same ~4 minutes piece but recorded from SAT feed so SDR H.264 1920x1080i50 4:2:2 (so don't accelerated now - may be Intel Xe will in nearest future - but each core of my Athlon II x3 360 load about 60% and video absolutely fluent) Formula1.2019.Round06.Monaco.Race.Sat.Feed.1080i.H264.Multi.Language.mkv (478 MB) https://transfiles.ru/9vyow

[VictorLS]

For devices not supported 4:2:2 to compare HLG and SDR I've downloaded and did same fragment 4:2:0 F1.Round.06.Grand.Prix.de.Monaco.2019.Race.HDTV.1080i_.ts (312 MB) https://transfiles.ru/aoxe0

[VictorLS]

did same fragment 4:2:0 F1.Round.06.Grand.Prix.de.Monaco.2019.Race.HDTV.1080i_.ts (312 MB) https://transfiles.ru/aoxe0
Modern Ryzen 3 3200G drivers (older not tried) hangs when use hardware acceleration of that file so I reupload new one F1.Round.06.Grand.Prix.de.Monaco.2019.Race.HDTV.1080iDG.ts (313 MB) https://transfiles.ru/oj6st

[VictorLS]

For HLG tests (to achieve ~ right colors while in ordinary DirectShow players like MPC-HC(BE), PotPlayer, KMPlayer etc) I've reuploaded ts files with same piece of F1 race to more permanent place:
1. Original 4K h265 HLG file 20190526-164153_RTL UHD.ts (687 MB) https://yadi.sk/d/6_vZCglWkP1xxw
2. 4:2:2 h264 1920x1080i50 BT.709 file from SAT feed Formula1.2019.Round06.Monaco.Race.Sat.Feed.1080i.H264.Multi.Language_fromMKVtsMuxerNotHDMVcompatible.ts (501 MB) https://yadi.sk/i/X1nPqEAqIAZXoQ
3. 4:2:0 h264 1920x1080i50 BT.709 file from Russian channel F1.Round.06.Grand.Prix.de.Monaco.2019.Race.HDTV.1080iDGSplit.ts (313 MB) https://yadi.sk/d/5NCBNVwWx9rWZQ

[butterw2]

I've made some screenshots from 20190526-164153_RTL UHD.ts on Ryzen 3 3200G under Win10 2004 with Adrenalin20.7.1 (on 50Гц DVI) HLG.7z (19 MB) https://transfiles.ru/gx1mz and had asked people with eyes seeng right colors what png is nearest to real colors?

following our discussion in the thread https://forum.doom9.org/showthread.php?t=181584 I do find it concerning that widely different results are obtained with the same vlc player depending on which api (dx/opengl) is used.

Could the avisynth script DGHDRtoSDR mentionned at the beginning of this thread be used as a reference, on your HLG test files, to determine what the accurate result is ?

[VictorLS]

I do find it concerning that widely different results are obtained with the same vlc player depending on which api (dx/opengl) is used...what the accurate result is ?
http://forum.doom9.org/showthread.php?p=1916215#post1916215
so answer is only OpenGL gives ~ right colors while playing HLG (D3D9 and others gives wrong colors) on SDR (BT.709) monitor in Win7 and after additional research D3D11&OpenGL in Win8-10 but D3D11 usually gives more fluent video such OpenGL in Win7. Versions of mpv before August 2019 gives such as VLC OpenGL colors while playing HLG files without hardware acceleration too.

[butterw2]

test file: RTL_HLG_2160p.mp4 (top of the thread, RTL title screen)
compared vs RTL_SDR
tbc: to be confirmed

no correction: POOR (but shaders are supported for correction)
- mpc-hc (EVR-CP)
- vlc (dx9)

HLG auto-correction: GOOD
- vlc (dx11, default Output mode > Win8)
- vlc (OpenGL for windows), using libplacebo (tbc)
- mpv (tbc)
it is reported that mpv output can be made more similar to vlc through conf file settings.

HDR auto-correction: BAD
- mpc-be
- Convert HDR to SDR.hlsl

[VictorLS]

no correction: POOR (but shaders are supported for correction)
- vlc (dx9)
How to use external shaders in VLC?
PS. I've just seen http://forum.doom9.org/showthread.php?p=1919502#post1919502 (great work, but when 20190526-164153_RTL UHD.ts paused in MPC-HC to see effect after turning shader off must be play next frame (i.e. Astra Ultra HD Demo.ts don't need play next frame) - KMPlayer 4.0.7.1 can fully operate with shaders when 20190526-164153_RTL UHD.ts paused) and found where shader in VLC but haven't tried it yet.

[VictorLS]

HLG auto-correction: GOOD
- vlc (dx11, default Output mode > Win8)
If watch carefully on high-quality monitor (not TN) i.e. red color in VLC (DXVAChecker) D3D11 not really red on my own - with VLC OpenGL much closer to red.

[butterw2]

Good doesn't imply perfect.

Based on this sample (upconverted SDR most likely), my main takeaway is that the HLG backwards compatibility on SDR (HDTVs) is quite underwhelming. However some processing as performed in vlc might improve on this result. A purist however might say that HDR can only be properly displayed on a HDR screen.

I tried out an encoder gui to see what the out of the box tonemapping experience might be like:
-HLG x265 pass-through: worked OK.
-HLG to SDR performed in avisynth with HDRTools: better than nothing, but still not GOOD.

Moreover, implementing the required processing is likely more difficult in a video player vs avisynth because you have to deal with DirectShow, the GPU SW/HW and realtime processing constraints.

[wswartzendruber]

Hi there. Someone brought this thread to my attention after demo'ing some work I did on a HDR10 to HLG converter.

Based on this sample (upconverted SDR most likely), my main takeaway is that the HLG backwards compatibility on SDR (HDTVs) is quite underwhelming.
I think the main issue you guys are running into is 2020 to 709 color mapping. HDTVs do 709. 4K TVs do 2020. Most 4K TVs are HDR, but some are SDR, particularly older ones. HLG was designed to be compatible with these 4K SDR TVs that still did 2020 color. HLG was never really intended to display properly on HDTVs.

However some processing as performed in vlc might improve on this result.
VLC does indeed have excellent algorithms for mapping 2020 to 709. They're actually quite good. I've uploaded some screenshots of Alita: Battle Angel in HLG displayed by VLC. (https://imgur.com/a/IN63ytr)

A purist however might say that HDR can only be properly displayed on a HDR screen.
HDR is a complete and total mess, if I may be frank. But HLG is much better about SDR as long as the HLG picture is balanced correctly, meaning that reference white is calibrated to 75% input signal strength. Again, a purist is going to say that HLG should always be shown on a 2020-capable device.

[VictorLS]

Someone brought this thread to my attention after demo'ing some work I did on a HDR10 to HLG converter.
Good joke - it was me (topicstarter) here (http://forum.doom9.org/showthread.php?p=1919827#post1919827)
VLC does indeed have excellent algorithms for mapping 2020 to 709. They're actually quite good.
You're quiet right - if some shader will give same quality as VLC it'll be appreciated.
Some more exact in case of HLG ARIB STD-B67 instead of yours 2020 on my own.
You can download libplacebo (http://forum.doom9.org/showthread.php?p=1916215#post1916215) from VLC and three sample videos (http://forum.doom9.org/showthread.php?p=1919134#post1919134) from my posts above.
HDR is a complete and total mess, if I may be frank. But HLG is much better about SDR as long as the HLG picture is balanced correctly, meaning that reference white is calibrated to 75% input signal strength. Again, a purist is going to say that HLG should always be shown on a 2020-capable device.
I agree, but again VLC quality of showing HLG (ARIB STD-B67) on BT.709 monitors and TVsets is quiet enough.

[VictorLS]

From wswartzendruber's post (http://forum.doom9.org/showthread.php?p=1919860#post1919860) I've known Kodi is next (after mpv and VLC) player with well HLGtoSDR tonemapping (I tried and confirm that HLG 20190526-164153_RTL UHD.ts (687 MB) https://yadi.sk/d/6_vZCglWkP1xxw is played in Kodi with ~ right colors) but we need HLGtoSDR shader ;)

[VictorLS]

Free-To-Air channel RTL UHD Austria provider ORS begins from 19e2 11214h22000 - it's some strange (same German RTL UHD now too): while adv and studio it's ordinary HLG but when F1 from our Russian Sochi colors are good on SDR monitor without any processing like shader, modern MPC-BE, VLC, mpv or Kodi. Here's sample 20200926-153844_RTL UHD Austria.ts (232 MB) https://yadi.sk/d/_4Oo1_awZEQr4g

[videoh]

it's some strange...
Here's sample 20200926-153844_RTL UHD Austria.ts (232 MB) https://yadi.sk/d/_4Oo1_awZEQr4g What is strange about it? It's HLG and so will play "OK" as SDR.

BTW, sorry to say but your English is borderline understandable. Try full sentences, each expressing a single coherent thought.

[VictorLS]

What is strange about it? It's HLG and so will play "OK" as SDR
You can just compare 20190511-152944_RTL UHD_flag.ts (67MB) https://yadi.sk/i/985DVw34OHQrrA I've uploaded in this thread before (http://forum.doom9.org/showthread.php?p=1886135#post1886135) with present 20200926-153844_RTL UHD Austria.ts (232 MB) https://yadi.sk/d/_4Oo1_awZEQr4g (20190511-130113_ARENA HD_flag.ts (38MB) https://yadi.sk/i/HiuZ5Rb2RKkc0g SDR for control) with EVR (not EVR-CP to avoid any post-processing in renderer) in MPC-HC and if you have good monitor and eyes I believe you'll see difference as minimum in red color in top left corner ;)
Btw today's F1 race translation fully prove I was right - in some seconds before adv someone was switching from non-HLG to HLG and vise versa - I hope to cut and upload an example(s) in days.
BTW, sorry to say but your English is borderline understandable.
You're welcome but i.e. when I gave just link on this thread to a smart Russian guy Iron_Butterfly (I even didn't new he's shader writer that time) he fully understand me and at first correct not working MPC-VR's correction_hlg.hlsl shader (so modern versions of MPC-BE do HLGtoSDR with i.e. EVR-CP but red becomes some rose due to wrong and non-adjustable constants) and then wrote new working shader I successfully use in app SmartDVB or MPC-HC. Here's shader with my constant 1000.0&300.0 Convert HLG to SDR.hlsl (6 КБ) https://yadi.sk/d/4Ugay1550LPg1Q - in original was 1000.0&80.0
Even nevcairiel well understand I ask him but he implement in LAV Video Decoder useful thing (like NVIDIA CUVID h265 10bit decoding or switchable CUVID DXVA processing for playing "broken" streams in Win7x64 with hardware accelerations without artifacts on nVIDIA videocards) in years but not all frame decoding - I agree he calls simpler "skipping" (this function is in ffmpeg) he don't want to implement despite of it's very easy to do, proved by Aleksoid1978 and MPC Video Decoder.
Try full sentences, each expressing a single coherent thought.
It's hard to write hard enough things with simple sentences ;)
If you or someone can't understand whole sentence try to read without () and then in () and summarize them in your brains because I believe each word I write is important ;)

[videoh]

I believe each word I write is important. That's reassuring. Thank you.

[VictorLS]

Here's a sample I promised to upload (http://forum.doom9.org/showthread.php?p=1924517#post1924517) 20200927-141013_RTL UHD Austria_.ts (108 MB) https://yadi.sk/i/FInnqG3BbHt5SQ - when watching with EVR (so without processing) between 5 and 6 seconds red Ferrari becomes some orange (so video beginning from 6th second becomes ordinary HLG so shader and i.e. EVR-CP become necessary to watch Ferrari in ~ normal color on SDR - so non-BT.2020 - monitor).
One more thing - rectangle STRECKENINFO GP VON RUSSLAND without shader is some orange too but see letters carefully - with EVR and in VLC they are looking well but with shader+EVR-CP and in mpv letters with visible artifacts.
PS. On my PC EVR-CP some times stutters while playing RTL UHD but VLC with OpenGL always fluent - can someone confirm that?

[VictorLS]

Here's a sample I promised to upload
Here's one more vise versa sample 20200927-151917_RTL UHD Austria_.ts (58 MB) https://yadi.sk/i/n2vgJY5IZGg_Fg
without HLG processing at 8th second i.e. orange adv banner "Emirates FLY BETTER" becomes red.

[VictorLS]

I've watched 20200927-141013_RTL UHD Austria_.ts and 20200927-151917_RTL UHD Austria_.ts on Samsung QLED 43" supported even AV1 4K 60fps playing and it shows wrong overcontrasted and oversaturated video while non-HLG in that files and normal video when HLG in same videos.
PS. Letters on STRECKENINFO GP VON RUSSLAND looks like in VLC so good enough (but not ideal).
Here's two shaders with my constants 1000.0&300.0 and 150.0&0.5 https://transfiles.ru/l99ql - in original was 1000.0&80.0 and 100.0&0.5
Btw I've reupload that two shaders to more permanent place Shaders.7z (2 KB) https://yadi.sk/d/-DUfaqlY6LfxtA

[VictorLS]

MPC Video Renderer (MPC-VR) v0.4.10.1542 https://yadi.sk/d/X0EVMKP4TcmnHQ/Old/0.4.10 (0.4.10.1542 is last version let turn HLG processing off in MPC-VR and well use HLGtoSDR shader instead) shows HLG on SDR even better than shaders on my own.
With MPC Video Renderer colors are less saturated but nearer to SDR.

[VictorLS]

New shader from smart Russian guy Iron_Butterfly HLG-BT2100toSRGB.hlsl (3 KB) https://yadi.sk/d/ExnEkJR-sgms1g

[VictorLS]

Just tried Daum PotPlayer 210127 https://daumpotplayer.com/download/ and it can show HLG such as HLG-BT2100toSRGB.hlsl in MPC-HC with internal in PotPlayer Direct3D9 Video Renderer
With Default.dsf skin HLG processing can be easily switched on/off by pressing HDR in a bottom while playing HLG file like 20190526-164153_RTL UHD.ts (687 MB) https://yadi.sk/d/6_vZCglWkP1xxw

[kasper93]

Due to huhn's "madVR doesn't support HLG"
HLGw/oProcessing (undersaturated and undercontrasted):
https://i.postimg.cc/8CvvnTzW/2019-HLG.png (https://postimg.cc/hJShXWxP)

Regardless of HLG it looks like you are using madVR wrong. Desaturation comes form BT.2020, not HLG. I figured I will clear one thing for all of you guys.

madVR does not convert gamut to your display if you do not ask it to. You have to specify you display "calibration" parameters. Even if it is not calibrated, BT.709@2.2 is probably very close to your display :) Or better use 3DLUT...

And this apply to all non bt.709 content, not only HLG. Here is comparison with correct and incorrect configuration.

https://thumbs2.imgbox.com/97/d4/pHCRcx2e_t.png (https://images2.imgbox.com/97/d4/pHCRcx2e_o.png) https://thumbs2.imgbox.com/fa/a5/bQUlPpwH_t.png (https://images2.imgbox.com/fa/a5/bQUlPpwH_o.png)

This board is not a best example, but you can clearly see the difference when BT.2020 is converted to BT.709... With EURO2020 HLG content looks ok, as it was designed to looks reasonably well on SDR devices.

[VictorLS]

madVR does not convert gamut to your display if you do not ask it to. You have to specify you display "calibration" parameters. Even if it is not calibrated, BT.709@2.2 is probably very close to your display :) Or better use 3DLUT...
Because I haven't alternative of madVR (it permanently some stutters on my old and slow computer, EVR and MPC-VR shows same files fluently) I began to search 3DLUT for ~ correct HLGtoSDR conversion but didn't find it that time - your research is great.
This board is not a best example, but you can clearly see the difference when BT.2020 is converted to BT.709... With EURO2020 HLG content looks ok, as it was designed to looks reasonably well on SDR devices.
If you read (you can translate if don't understand Russian language) and download files I've uploaded from there https://forum.ixbt.com/topic.cgi?id=73:5256:3663#3663 until now you'll see 20210611-232433_TRT 4K.ts isn't HLG and don't need any color conversion (but it's 25 Hz, so SVP is appreciated), 20210612-164807_TRT 4K.ts without HLGtoSDR conversion (in i.e. MPC-VR 0.4.10.1542) looks washed out on SDR monitor, 20210613-161108_TRT 4K.ts without HLGtoSDR conversion looks better than 20210612-164807_TRT 4K.ts but with HLGtoSDR conversion looks better than without one - then I've done some screenshots madVRvsMPC-VRcomparison.7z (18 MB) https://disk.yandex.ru/d/ur54NnTmgdFzKA where MPC-VR's HLGtoSDR conversion is much more accurate than madVR and latest MPC-VR5 without conversion (~ the same result) I guess mean showing SDR layer of HLG video on SDR monitor.

[Balling]

>Desaturation comes form BT.2020, not HLG.

No. Neither BT.2020 ncl matrix, nor BT.2020 primaries can really do that. It is the PQ or HLG transfer (which is what HDR is) that affects the picture. That can be very simply checked in mpv that can override matrix, transfer, range and primaries.

>EURO2020 HLG content looks ok, as it was designed to looks reasonably well on SDR devices.

Actually HLG was designed to look well on SDR devices.

[VictorLS]

Actually HLG was designed to look well on SDR devices.
Theretically so but long time HLG was with ugly colors (especially red was looked as orange) on i.e. my SDR monitor.

[kasper93]

No. Neither BT.2020 ncl matrix, nor BT.2020 primaries can really do that. It is the PQ or HLG transfer (which is what HDR is) that affects the picture.

It is actually pretty simple concept. If you have wide-gammut video and map it to RGB as is and display it on narrow-gammut display it will be under saturated. The same when you display narrow-gammut content on wide-gammut display, it will be overstarated. That's why wide-gammut monitors have sRGB clamping/emulation (whatever you want to call it) mode.


That can be very simply checked in mpv that can override matrix, transfer, range and primaries.

Of course you can! Try `mvp --target-prim=bt.2020` on sRGB display, with any video. Result will be understated.

This is exactly what happens with madVR if you don't tell it display parameters explicitly it will expect display to be "compatible" with source content and push it "as-is". Hence you need to tell madVR that your display is for example BT.709 (close to sRGB) so that other gammuts are converted accordingly.

For example mpv does that automatically, as it expect most people to have sRGB displays.
(auto mode) Disable any adaptation, except for atypical color spaces. Specifically, wide/unusual gamuts get automatically adapted to BT.709, while standard gamut (i.e. BT.601 and BT.709) content is not touched.
Actually HLG was designed to look well on SDR devices.

Yes, this is what I said.

[huhn]

actually you have bug at your hands here.

by design madVR is supposed to do bt 709 gamma 2.2 output with "disable calibration controls for this display" outside of HDR output mode.
so this should be an automated case.
a bt2020 gamma or a bt601 gamma file should be automatically converted to bt 709 with gamma 2.2 for some reason it's not doing this for HLG files.

i will report that to him.

[kasper93]

actually you have bug at your hands here.

by design madVR is supposed to do bt 709 gamma 2.2 output with "disable calibration controls for this display" outside of HDR output mode.

Where did you get this information? I'm almost certain madshi said (at one point) that there is no gamut conversion unless you request madVR to do so. And it checks out with my observation.

bt.709 2.2 output is expected after HDR pixel shader tone mapping. But since HLG is not supported it is treated like normal BT.2020

so this should be an automated case.
a bt2020 gamma or a bt601 gamma file should be automatically converted to bt 709 with gamma 2.2 for some reason it's not doing this for HLG files.

I will say it third time. HLG is not a factor here... I have SDR bt.2020 file and it behaves exactly the same.

i will report that to him.

Please let me know where. Because this change is not that obvious and I'd like to be in loop :)

[huhn]

he talk about it years ago it still kinda here as information: https://forum.doom9.org/showthread.php?t=171787
disable calibration controls for this display: The display is assumed to have a BT.709 gamut with a pure power gamma of 2.2 (probably).

and we also got the information that some correction are not done.

the new beta version can detect HLG that was a necessary change after i reported that it is treated as HDR10+ (or something like that) with the internal MPC-BE decoder lav filter at the time didn't send the HLG meta data to madVR

what so ever with a new beta (133 or 134) with HLG it totally ignored the setting could be bt 2020, bt 709 or "no calibration" i get the same image with every source. actually all calibrations setting with my current build are totally ignored so i can't do a proper test for now and i can't report it.
bugs are reported here: http://bugs.madshi.net/my_view_page.php?refresh=true

i will soon try the release version and the newest beta.

[kasper93]

he talk about it years ago it still kinda here as information: https://forum.doom9.org/showthread.php?t=171787
disable calibration controls for this display: The display is assumed to have a BT.709 gamut with a pure power gamma of 2.2 (probably).

and we also got the information that some correction are not done.

Asmodian is not madshi, is he? madshi has proven himself over the years to be very strict and organized about those things. I would never expect "disable calibration controls" to do hidden assumptions and do implicit conversions when there is explicit option "this display is calibrated" to set properties of the display.

Also to not make empty assumptions I found the posts that I remembered.

And, if we use "disable calibration controls for this display" [...] the source gamut is used without correction ?Yes.
And about conversion itself.
With SDR BT.2020 content and "this display is already calibrated to BT.709", madVR converts the gamut from BT.2020 to BT.709, but colors are simply clipped in the most simple way to BT.709, which is not optimal. With SDR content and "this display is already calibrated to BT.2020", no processing is necessary/done.

With HDR BT.2020 content, it's almost the same. However, the BT.2020 -> BT.709 gamut mapping is performed in much higher quality.

It's on my to do list to perform the higher quality processing also for SDR gamut down-conversions.

Optimal or not it is still better than trying to display bt.2020 without adaptation. Also if you have a 3DLUT for your monitor you will get best result :)

the new beta version can detect HLG that was a necessary change after i reported that it is treated as HDR10+ (or something like that) with the internal MPC-BE decoder lav filter at the time didn't send the HLG meta data to madVR

what so ever with a new beta (133 or 134) with HLG it totally ignored the setting could be bt 2020, bt 709 or "no calibration" i get the same image with every source. actually all calibrations setting with my current build are totally ignored so i can't do a proper test for now and i can't report it.

I can't comment on that, I don't see any of your issues. I'm using latest LAV and madVR b135, HLG content is processed as SDR one. As I would expect if it is not supported.

[huhn]

Asmodian is not madshi, is he? madshi has proven himself over the years to be very strict and organized about those things. I would never expect "disable calibration controls" to do hidden assumptions and do implicit conversions when there is explicit option "this display is calibrated" to set properties of the display.

Also to not make empty assumptions I found the posts that I remembered.
this is not based on empty assumption it'S more based on tests and Asmodian don't writes these parts down if he didn't test them.
and i just tested live version 0.92.17 and it clearly behaviours as usual it assumes BT 709. madVR has to work out of the box the far majority of user doesn't know what either bt 709 nor bt 2020 are and that'S absolutely ok.
Optimal or not it is still better than trying to display bt.2020 without adaptation. Also if you have a 3DLUT for your monitor you will get best result :)
been using 3D LUT for years now hell my meter get's so old i think about replacing it just because it could drift to far.


I can't comment on that, I don't see any of your issues. I'm using latest LAV and madVR b135, HLG content is processed as SDR one. As I would expect if it is not supported.
it's only one system and clearly needs more testing but i have to setup and calibrate a new Tv and it's taking a long time so i can't do a proper test right now.

as sad before my other system with the live none beta version behaviours like the past and assumes BT 709 test with HDR 10 and proper BT 2020 flag test file i just found. https://drive.google.com/file/d/1Ic9DZXMSo07EJMqCFaQRKSSrSw6y1mYv/edit
HLG is not assumed to output bt709 this is inconsistent behaviour if tone mapped or not the displays output characteristic hasn't changed when both output SDR.

the new BETA version have a change for HLG because madVR got nuts when HLG meta was send to it which lav filter doesn't do "yet" with madVR.
was great fun: https://forum.doom9.org/showthread.php?p=1930343#post1930343

[kasper93]

this is not based on empty assumption it'S more based on tests and Asmodian don't writes these parts down if he didn't test them.
and i just tested live version 0.92.17 and it clearly behaviours as usual it assumes BT 709. madVR has to work out of the box the far majority of user doesn't know what either bt 709 nor bt 2020 are and that'S absolutely ok.

I get that, but I'm trying to prove to you that it is wrong. madshi said that and it is consistent with my observations.
SDR BT.2020 with stable 0.92.17 (same behavior as with beta)
https://thumbs2.imgbox.com/66/d1/SomlKBFU_t.png (https://images2.imgbox.com/66/d1/SomlKBFU_o.png) https://thumbs2.imgbox.com/21/b8/bCoPz6PT_t.png (https://images2.imgbox.com/21/b8/bCoPz6PT_o.png)

What you might be referring to is how HDR pipeline works in madVR. If content is detected as HDR it goes through "hdr" tone-mapping settings. And if it goes through "pixel shader" tone map the internal output is indeed bt.709 2.2 which then goes to "calibration" settings and gamma settings. Note that if you use other option in "hdr" settings it will not go through calibration.

But for SDR and currently HLG it doesn't go through HDR pipeline, hence there is no BT.709 conversion unless selected in "calibration" settings.

Bottom line is, if you want madVR to ouptut proper colorspace for your display, set display parameters in "calibration" page, else it will not do that in some cases.

Also madVR 3DLUT selection after HDR pixel shader tone mapping is slightly broken, around 2017 there was discussion about that, but it gone nowhere https://www.avsforum.com/threads/madvr-argyllcms.1471169/ but I digress, not related to our current discussion. But if you use HDR tone-mapping and SDR 3DLUT it has to be 2.2 gamma instead rec.1886... it is little bit mess currently.

as sad before my other system with the live none beta version behaviours like the past and assumes BT 709 test with HDR 10 and proper BT 2020 flag test file i just found. https://drive.google.com/file/d/1Ic9DZXMSo07EJMqCFaQRKSSrSw6y1mYv/edit
HLG is not assumed to output bt709 this is inconsistent behaviour if tone mapped or not the displays output characteristic hasn't changed when both output SDR.

Sorry, I don't understand. This file have PQ transfer function, not HLG. It is detected as HDR by madVR with "unknown properties" (in fact in both stable and beta), but it is completely different case than we are discussing in this thread. This file is treated as HDR.

[huhn]

first of my calibration setting on the new Tv where ignored because of 2 possible reasons windows 11 been a windows OS or this TV is so broken that it creates new identifies that the current available one in the settings is an old one so it never applies. maybe both.

Sorry, I don't understand. This file have PQ transfer function, not HLG. It is detected as HDR by madVR with "unknown properties" (in fact in both stable and beta), but it is completely different case than we are discussing in this thread. This file is treated as HDR.

the point is both output SDR. HDR10 with pixelshader and HLG with no special treatment. but in one case madVR assumes BT709 and does a conversation and in the other it doesn't even through the display characteristics didn't change both are SDR to a unknown display one time it's bt 709 and one type is just doesn't touch the image.
just because on has a HDR pipeline does not excuse the different behaviour. the HDR10 file is just to proof that it assumes in this case bt709.

Also madVR 3DLUT selection after HDR pixel shader tone mapping is slightly broken, around 2017 there was discussion about that, but it gone nowhere https://www.avsforum.com/threads/mad...llcms.1471169/ but I digress, not related to our current discussion. But if you use HDR tone-mapping and SDR 3DLUT it has to be 2.2 gamma instead rec.1886... it is little bit mess currently.
well the gamma was supposed to be added to the 3D LUT so madVR can read it and act accordingly. but well same for clipping btb and wtw... argyll CMS 3D LUT don't support the input of these values because of timing "reasons" that don't apply to a PC and want them clipped and madshi wanted them to just not read them or something what so ever still buggy.

bt 1886 is generally messy :-)

[kasper93]

the point is both output SDR. HDR10 with pixelshader and HLG with no special treatment. but in one case madVR assumes BT709 and does a conversation and in the other it doesn't even through the display characteristics didn't change both are SDR to a unknown display one time it's bt 709 and one type is just doesn't touch the image.
just because on has a HDR pipeline does not excuse the different behaviour. the HDR10 file is just to proof that it assumes in this case bt709.

Ok, I get what you mean. But it is the other way around. madVR still doesn't "assume" anything about target display if you have "disable calibration control". Just happens to be that output of "pixel shader" tone mapping is BT.709 internally (by default/design) after tone mapping, which happens to much output display. You can still correct this by changing "display calibration" settings.

I can actually see why this is confusing from high level point of view. HDR processing is not consistent with SDR one, mostly because HDR is a big bulk of processing, which is not really compatible fully with "calibraton" tab currently.

Nevertheless my original point was that in order to properly watch SDR BT.2020 (or HLG) you need to set calibration for a display. I get that HDR processing overwrites some os the original SDR pipeline logic, but in pure SDR mode it has to be done.

well the gamma was supposed to be added to the 3D LUT so madVR can read it and act accordingly.

This is off topic here, we could move to https://www.avsforum.com/threads/madvr-argyllcms.1471169 if you would like to continue discussion. I even have posted there not long ago about my issues with current setup. Indeed expected input gamma could be embedded in 3dlut so madVR could convert before. We could also have a more complex list of 3dluts to support common transfer functions. Currently when selecting 3dlut transfer function is ignored and essentially this means you need to manual change 3dlut file when needed.