Limited YouTube HLG support vs HDR10 - any success?

[2Bdecided]

I am uploading HDR videos to YouTube. The source is HLG (https://en.wikipedia.org/wiki/Hybrid_log%E2%80%93gamma) from a Panasonic camera.

What I would like is for YouTube to stream HDR to HDR capable devices, and a good SDR conversion to SDR-only devices.

There's lots of old talk about HLG HDR being backwards compatible with SDR, but that's not really true. It uses Rec2020 colour whereas SDR is Rec709, but just as importantly HLG videos viewed on SDR displays just aren't as bright or "contrasty" as normal SDR videos. They still need conversion to look their best in SDR.

The YouTube help pages (https://support.google.com/youtube/answer/7126552?hl=en-GB) suggest that their default HDR>SDR conversion is OK, but you can tweak it by attaching a custom 3D LUT to your video using mkvmerge (https://github.com/youtubehdr/hdr_metadata).

In reality, this is what seems to happen...
HLG source, no LUT:
* HDR device: HLG is streamed as-is to compatible devices
* SDR device: Rec2020>Rec709 colour conversion but no "gamma" conversion takes place so the picture looks low contrast

HLG source, with LUT:
Same as above. The LUT is ignored.

HDR10 source, no LUT:
* HDR device: HDR10 is streamed as-is to compatible devices
* SDR device: Rec2020>Rec709 colour conversion and "gamma" conversion takes place, so the picture looks OK

HDR10 source, with LUT:
As above, but the LUT is used in the HDR>SDR conversion, so you can make the SDR version look exactly as you wish.


My question is: has anyone managed to upload HLG HDR to YouTube and have it convert nicely to SDR, or use an attached 3D LUT correctly?

There are plenty of HLG videos on YouTube that look OK on SDR displays, but I'm not sure if they have been converted properly by YouTube, or if the uploaders just tweaked the brightness and contrast to make the images look acceptable in SDR without conversion (which you can do with HLG, at the expense of compromising the experience on HDR displays).

Cheers,
David.

[FranceBB]

I modified your quote with one important addition, SDR UHD devices that understand the matrix but not the transfer:


In reality, this is what seems to happen...
HLG source, no LUT:
* HDR device: HLG is streamed as-is to compatible devices
* SDR UHD devices: HLG is streamed as is to SDR devices that can read BT2020 as colormatrix but ignore the arib-std-b67 transfer (i.e HLG colour curve)
* SDR FULL HD devices: colormatrix is converted from BT2020 to BT709, but the colour curve stays the same


This kind of conversion is expected and it's how it's supposed to be. Sure, since HLG is hybrid, the white won't peak at 0.7V, so it will look dimmer on BT2020 SDR 100 nits displays, but this is the whole thing about it being backwards compatible with SDR UHD TVs: it will look ok.
The same concept is applied for FULL HD SDR BT709 displays: the matrix is converted but not the transfer, so it will look just as dim as if you were watching the HLG BT2020 stream on a TV that understands the colour matrix but not the colour curve.

- Can a better job be done since it's offline encoding and streaming and not realtime broadcasting?

Absolutely.

- Will YouTube do it?

Who knows.
It used to apply a lut for HLG streams too however they changed this halfway through and I don't see them going back unless something changes their minds.



There are plenty of HLG videos on YouTube that look OK on SDR displays, but I'm not sure if they have been converted properly by YouTube


They were not.


or if the uploaders just tweaked the brightness and contrast to make the images look acceptable in SDR without conversion (which you can do with HLG, at the expense of compromising the experience on HDR displays).


If you're a content creator and you're going to air in HLG, then you must check your content on an HDR HLG BT2020 monitor in both the HDR HLG mode and in the SDR BT2020 mode to make sure that the experience of the viewer at home who owns an UHD SDR TV won't be total garbage, otherwise if you only work in HDR and you only check the HDR result, any benefit of the backwards compatibility of HLG is lost and you might be better off shooting in Slog, Clog, LogC, Zlog or whatever and then go to PQ and air in PQ, hence having a workflow that relies only on truly logarithmic curves. Your blacks will be higher and you'll get many more stops / nits, provided that the sensor is good enough otherwise you'll just get more noise.

P.s Doom9 is full of examples about this, including several of my posts about HLG ;)


Cheers,
Frank

[wswartzendruber]

In order for HLG to look right on any SDR, reference white must be at 75% signal level. If it is lower than this, the picture will look dark. If it is higher than this, the picture will look blown out.

This is independent of gamut conversion.

The old (deprecated) HLG standard put reference white at 50%. This approach is not current.

[2Bdecided]

Thank you both for taking the time to reply and offering helpful information. I have already read many of your posts and threads thanks to Google and the forum search. I used to use be here a lot.

Regarding YouTube's (lack of) conversion...
- Will YouTube do it?

Who knows.
It used to apply a lut for HLG streams too however they changed this halfway through and I don't see them going back unless something changes their minds.
Thank you, that's interesting.

I can kind of understand their decision to not "gamma" convert HLG by default, but their HDR page (https://support.google.com/youtube/answer/7126552?hl=en-GB) is misleading. It talks about "HDR", but lots of the text only applies to "HDR10". It would solve the problem if what the page said was true, i.e. that for HDR (including HLG) you could supply a 3D LUT and they would use it for the SDR conversion.


If you're a content creator and you're going to air in HLG, then you must check your content on an HDR HLG BT2020 monitor in both the HDR HLG mode and in the SDR BT2020 mode to make sure that the experience of the viewer at home who owns an UHD SDR TV won't be total garbage, otherwise if you only work in HDR and you only check the HDR result, any benefit of the backwards compatibility of HLG is lost and you might be better off shooting in Slog, Clog, LogC, Zlog or whatever and then go to PQ and air in PQ, hence having a workflow that relies only on truly logarithmic curves. Your blacks will be higher and you'll get many more stops / nits, provided that the sensor is good enough otherwise you'll just get more noise.

I think the SDR UHD Rec2020 display discussion is a red herring, because there aren't many of them. The usefulness somes elsewhere... There are more HDR "HDR10-only" displays though (i.e. older HDR displays which don't recognise HLG) and they will also display HLG as SDR Rec2020. Like any SDR viewed on an HDR TV, they will use proprietary processing to try make the pictures more HDR-like, which can look quite nice, but HLG can still look worse than actual SDR on these TVs.

I know there's a genuine benefit that, while not perfect, at least it looks more like normal video than unconverted PQ or log, so that's useful at a pinch. Also most PC SW players seem to cope with Rec2020 conversion fine by default, whereas for gamma conversion (HLG or PQ) you need to pick the right player and/or set it up correctly. But if you're going to shoot 4K HDR, it would be nice to think everyone sees a really good picture, rather than just an "OK" or "not awful" one. I don't want it to look worse than native SDR.


The BBC doesn't pretend that you should drive an SDR display with an HLG signal. They don't think just fixing Rec2020-vs-Rec709 is enough.

They convert HLG properly for live SDR broadcasts:
https://www.bbc.co.uk/rd/blog/2018-05-ultra-high-definition-dynamic-range-royal-wedding-uhd-hdr
They will sell you their own LUTs to do the job:
http://downloads.bbc.co.uk/rd/pubs/papers/HDR/BBC_HDRTV_HLG_LUT_Production_Guide.pdf


Anyway, it seems that, today, HDR10/PQ is the best thing to upload to YouTube. Wider compatibility. Decent automatic downconversion. Custom (though static) downconversion if you want it.

You mentioned slog etc which I know can be better and more flexible. The point of shooting HLG for me is that I can just watch it straight away on my TV without processing. You can't do that with Slog. Not everything justifies editing and post processing. Shoot. Share. Watch. Move on. If YouTube supported HLG conversion, it would be great, because the one file would look great everywhere. As it doesn't, I guess there's no easy way.


In order for HLG to look right on any SDR, reference white must be at 75% signal level. If it is lower than this, the picture will look dark. If it is higher than this, the picture will look blown out.

This is independent of gamut conversion.

The old (deprecated) HLG standard put reference white at 50%. This approach is not current.
Thank you. Yes, I see that you are right. It seems that NHK proposed 50% at one point, but the BBC was always 75% or 70%, and the standard is 75%
https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-2017-PDF-E.pdf
(Table 1)


I don't have any desire to watch HLG as SDR because it seems a needless compromise, but I am wondering if maybe my camera is shooting HLG "too dark" compared to the 75% reference. I've played around with other conversions and watching other HLG content "as SDR" and it's always has something of the same disappointing lack of contrast/brightness, though not usually as bad as I'm seeing from my own camera. Sometimes it looks just as bad though. I get the feeling people just over exposure a bit to make the SDR view more acceptable, which makes the HDR over bright but fun.

Cheers,
David.

[wswartzendruber]

EDIT: Nevermind.

[wswartzendruber]

Okay try this and see how it looks:

http://wswartzendruber.net/videos/lg-new-york-hlg.mkv

The old one was a little blown out. This one should have much more correct levels.

[kolak]

You can always convert HLG to HDR10 (which is "lossless" when done properly) and then upload HDR10 with LUT.

[Blue_MiSfit]

Is it really lossless to go from HLG to linear light to PQ? By lossless do you mean HLG -> Linear -> PQ -> Linear -> HLG would be lossless?

[wswartzendruber]

Is it really lossless to go from HLG to linear light to PQ? By lossless do you mean HLG -> Linear -> PQ -> Linear -> HLG would be lossless?
Well, not really.

HLG allocates 75% of the 10-bit space for sub-HDR brightness levels. PQ only allocates 58% (ITU) or 50% (SMPTE). While this gives PQ more dynamic range overall, you could theoretically start to see some banding round-tripping between HLG, PQ, and then back to HLG.

It's better to work with 12-bit sources.

Also, once something is in HLG, I'd honestly just leave it, if I could. Properly mastered HLG signals can be played back at rather arbitrary brightness levels as a part of HLG's core design.

PQ was designed for fixed viewing environments. Most TVs ignore this, though. I'm not sure what happens to artistic intent here.

[FranceBB]

Is it really lossless to go from HLG to linear light to PQ?

I guess he means the fact that it's a sort of one to one (injective) but not onto transformation and you get away with it 'cause you map "less" input points into "more" output points. The same isn't true the other way round, from PQ to HLG which is onto (surjective) but not one to one, so you have to map "more" input points into "fewer" output points.
For something to be mathematically lossless it should be one to one and onto 'cause then you would have an isomorphism and you could always find the inverse of the transformation and losslessly go back between one and the other. Now, before someone jumps in and scream "noooooooo!!" 'cause it's not exactly correct, I will specify this time that I know that topologically speaking an isomorphism is a structure preserving transformation and that you can have lossless operations in our case that are not structure preserving and as such not isomorphism and that I shouldn't loosely use that term, but I do for the sake of the argument and everyone involved as long as we're all on the same page and accept it.

Anyway, after this detour, technically speaking, as long as you're going into something "bigger" you shouldn't have any issues, that's Kolak argument about this.

Is it truly mathematically lossless if we want to be pedantic? No.
But we get the idea...

P.s all the above is assumed to be in 16bit RGB terms, of course in 10bit YUV what wswartzendruber also comes into play.

[kolak]

Is it really lossless to go from HLG to linear light to PQ? By lossless do you mean HLG -> Linear -> PQ -> Linear -> HLG would be lossless?

This is what wise people say. There is an official formula for it I think (I don't think it's mathematically lossless though).
I've tested it and no way I could see any difference when swapping between 2 on Mac HDR screen. It looks "lossless" at least for the eye (Apple+Vimeo use this to pass iPhones HLG recordings to Vimeo).
I've also tested Dolby's PQ to SDR conversion and it's very good compared to anything else I've seen. Maybe because it works per shot and uses analysis before conversion, opposite to some fixed global math.
I also assume (as always) you want to do any conversion on best possible assets, not heavily compressed end deliveries. There are "problems" with final HDR h265s due to codecs overshoots etc. You may get such a wrong eg. max light, so metadata should always be calculated on original assets at grading stage and passed through (wise people will also say this).

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-8-2020-PDF-E.pdf