Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Programming and Hacking > Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th April 2020, 05:44   #1  |  Link
wswartzendruber
Registered User
 
Join Date: Feb 2008
Posts: 47
I Made a PQ to HLG Converter

I wrote a small utility for converting raw video streams from PQ to HLG. It's available on GitHub.

Code:
USAGE: pq2hlg [format] [nits] [width] [height] [input] [output]
  format - The raw pixel format to use. Supported options are:
           rgb48
  nits   - Luminance value of the brightest pixel in the input.
  width  - Width of the video stream in pixels.
  height - Height of the video stream in pixels.
  input  - Raw RGB48 input file; use - for STDIN.
  output - Raw RGB48 output file; use - for STDOUT.
My motivation was that I wanted to rip my 4K UltraHD library, but wanted to do so in a viewing format that is as universal as possible, even if that entails some amount of compromise. I quickly settled on HLG after reading about it, but couldn't find a conversion utility to do this. I learned that ffmpeg supports the use of lookup tables, but couldn't find any such thing for cheaper than a couple hundred dollars. Others were available from the BBC under license.

All in all, I got quite fed up with the situation and started researching PQ, HLG, metadata, gamma curves, etc. until I got nauseated and started work. Then I studied some more and then went back to coding. Wash, rinse, and repeat a few times. I'm at the point where I'm comfortable with releasing my work to the public. Principally, it uses, to the best of my understanding, the algorithm published by BBC Research & Development.

Future improvements may include passing dynamic metadata in for variable PQ->HLG tone mapping. I definitely want to add YUV10 support as soon as I can figure out how the U and V components are encoded.

This is also the first thing I've written in Rust, so it's probably not going to be as idiomatic or as proper as it could be.

EDIT: Attached a screenshot from Alita: Battle Angel using this utility, taken from a nightly build of VLC 3.0.9 on a SDR monitor. The video codec in use is VP9 Profile 2.

EDIT: I also forgot to mention: This isn't really suitable for any brightness value aside from 1,000 nits. If a PQ video has a peak brightness of less than 1,000 nits, pass 1,000 nits in as the second argument anyway. If any pixel ever exceeds 1,000 nits, then external tone mapping really needs to be applied to the PQ source before passing it into this utility. A peak brightness of other than 1,000 nits can be specified, but this will cause reference white to be pushed up or down. This addendum is in accordance with ITU-R BT.2390-8 Section 7.2.
Attached Images
 

Last edited by wswartzendruber; 13th April 2020 at 07:05. Reason: Clarifying brightness setting.
wswartzendruber is offline   Reply With Quote
Old 13th April 2020, 20:17   #2  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,696
Fun project!

Here's one thing I've been trying to wrap my mind around regarding HLG: I get that one of the big appeals is "backwards compatibility", and I totally see how, from an EOTF standpoint it's somewhat backwards compatible with SDR. In other words, you could feed an HLG signal to a dumb SDR display and the luminance would look mostly correct.

However, I don't understand how (without some other component) it can be backwards compatible from a color gamut standpoint. If you're doing HLG with Rec2020 or P3, from what I understand that will NOT look correct on a non wide-gamut display. Gamut conversion is not trivial.

So... how does that work?

Your screenshot looks at least mostly correct to me, so I'm wondering how you / VLC converted the gamut from Rec2020 to Rec709.
Blue_MiSfit is offline   Reply With Quote
Old 13th April 2020, 21:36   #3  |  Link
wswartzendruber
Registered User
 
Join Date: Feb 2008
Posts: 47
Quote:
Originally Posted by Blue_MiSfit View Post
Fun project!

Here's one thing I've been trying to wrap my mind around regarding HLG: I get that one of the big appeals is "backwards compatibility", and I totally see how, from an EOTF standpoint it's somewhat backwards compatible with SDR. In other words, you could feed an HLG signal to a dumb SDR display and the luminance would look mostly correct.

However, I don't understand how (without some other component) it can be backwards compatible from a color gamut standpoint. If you're doing HLG with Rec2020 or P3, from what I understand that will NOT look correct on a non wide-gamut display. Gamut conversion is not trivial.

So... how does that work?

Your screenshot looks at least mostly correct to me, so I'm wondering how you / VLC converted the gamut from Rec2020 to Rec709.
It's entirely on the player to do that, as you have surmised. VLC does an outstanding job of it while Kodi doesn't even seem to try (everything looks washed out).

My assumption with VLC is that it is using some kind of logarithmic roll-off to compress the color dynamics. However they do it, the results are outstanding.

EDIT: I have to take that back. I put Alita through Kodi and Rec.2020->Rec.709 mapping was indeed happening. That other clip I played must not have had the right colorspace signaled.

Last edited by wswartzendruber; 14th April 2020 at 07:34.
wswartzendruber is offline   Reply With Quote
Old 15th April 2020, 20:40   #4  |  Link
scharfis_brain
brainless
 
scharfis_brain's Avatar
 
Join Date: Mar 2003
Location: Germany
Posts: 3,632
Quote:
Originally Posted by Blue_MiSfit View Post
Fun project!

Here's one thing I've been trying to wrap my mind around regarding HLG: I get that one of the big appeals is "backwards compatibility", and I totally see how, from an EOTF standpoint it's somewhat backwards compatible with SDR. In other words, you could feed an HLG signal to a dumb SDR display and the luminance would look mostly correct.

Interestingly enough, I do it the other way around:
Watching most SDR content with HLG.
This works quite well for most movie-like content
and b0rks most of the time with video-like content.

It seems that gradual luminance saturation (and chrominance desaturation) of the SDR film-curve in bright areas of the image fits the HLG-curve quite well.

On the other hand SDR with video-content peaking colors will look terrible with HLG applied.

My Sony OLED-TV allows to force the use of HLG on any type of input signal.
__________________
Don't forget the 'c'!

Don't PM me for technical support, please.
scharfis_brain is offline   Reply With Quote
Old 17th April 2020, 05:33   #5  |  Link
wswartzendruber
Registered User
 
Join Date: Feb 2008
Posts: 47
I've attached some more screenshots for demonstration. All in all, the HLG-on-SDR picture is somewhat dim, but I find that this leads to a more pleasant viewing experience, especially with the lights turned out. Reference white comes in on my monitor somewhere around 100 nits and bright whites come in around 200. So the specular highlights are noticeable as the director intends. In contrast, the SDR grading of the film looks washed out and loud.
Attached Images
   
wswartzendruber is offline   Reply With Quote
Old 17th April 2020, 13:23   #6  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 914
Quote:
Originally Posted by wswartzendruber View Post
My motivation was that I wanted to rip my 4K UltraHD library, but wanted to do so in a viewing format that is as universal as possible, even if that entails some amount of compromise. I quickly settled on HLG after reading about it, but couldn't find a conversion utility to do this. I learned that ffmpeg supports the use of lookup tables, but couldn't find any such thing for cheaper than a couple hundred dollars. Others were available from the BBC under license.
Oh, really...? *coff coff* Link *coff coff*

By the way, the fact that people were charging a lot of money for those matrices of linear transformation is exactly what made me want to share them for free...
Of course, as I always said, the ones made by AVID, BlackMagic, BBC and so on have had a lot of engineers working on them, while I made mine together with my boss in a studio room and they have been tested against a single professional monitor by Sony and not a wide range of them, but still...

Quote:
Originally Posted by wswartzendruber View Post
All in all, I got quite fed up with the situation and started researching PQ, HLG, metadata, gamma curves, etc. until I got nauseated and started work. Then I studied some more and then went back to coding. Wash, rinse, and repeat a few times. I'm at the point where I'm comfortable with releasing my work to the public. Principally, it uses, to the best of my understanding, the algorithm published by BBC Research & Development.
Yep, starting with the BBC Whitepaper is always a good starting point as it basically explains how the conversion should be done.


Quote:
Originally Posted by wswartzendruber View Post
This is also the first thing I've written in Rust, so it's probably not going to be as idiomatic or as proper as it could be.
I don't actually know rust as programming language as I never studied it, but still hats off for researching and implementing your own converter.

Quote:
Originally Posted by Blue_MiSfit View Post
Fun project!

Here's one thing I've been trying to wrap my mind around regarding HLG: I get that one of the big appeals is "backwards compatibility", and I totally see how, from an EOTF standpoint it's somewhat backwards compatible with SDR. In other words, you could feed an HLG signal to a dumb SDR display and the luminance would look mostly correct.
Correct.

Quote:
Originally Posted by Blue_MiSfit View Post
However, I don't understand how (without some other component) it can be backwards compatible from a color gamut standpoint.
In fact, it isn't.

Quote:
Originally Posted by Blue_MiSfit View Post
If you're doing HLG with Rec2020 or P3, from what I understand that will NOT look correct on a non wide-gamut display. Gamut conversion is not trivial.

So... how does that work?
It's not converted. Let me clarify that.
The whole reason why we want to air with HLG, as broadcasters, is that we wanna have both HDR and SDR on the same channel, BUT (and here's the catch) most people tend to think that when we say "SDR" we're actually referring to Linear BT709 100 nits, but we are not.

When we air a 4K UHD stream via satellite it has two things mainly: the colormatrix and the color curve.
If you have a new 4K UHD TV, it's gonna read the stream, understand the BT2020nc, understand the HLG curve and display the color curve correctly, thus showing you the right amount of nits (up to 1000) that the content has. You're definitely watching an HDR content.
If you have an old 4K UHD TV, however, when it's gonna read the stream, it's gonna correctly interpret the BT2020nc, but it's just gonna ignore any information relative to the color curve, thus displaying the content as BT2020nc SDR 100 nits. The more a content is graded towards HDR, the worse it's gonna look on BT2020nc SDR panels, the more is graded towards SDR, the less you're gonna have dynamic range on HDR monitors, hence the compromise and the 1000 nits limit.
For quite some time I had to grade live sports events to 400 nits maximum 'cause many people didn't have HDR panels at the very beginning.

For the records, the reason why you can't do that with something like PQ is that if you ignore the color curve information on a PQ stream, then everything is gonna look very dull, as PQ is a proper logarithmic curve, while HLG is indeed Hybrid and compromises details in the shadows to make it SDR compatible but still has room for the peak brightness to be way higher than 100 nits.

Out of curiosity, this is how you're gonna see the very same HDR HLG signal on two different monitors: one BT2020nc SDR which ignores the color curve and the other that reads and interprets the color curve:




As you can clearly see, it's a compromise and it's never gonna look exactly as we intended it to look, which is something that kinda pisses us all off (broadcast encoders), but hey, we barely have the bandwidth to have 25 Mbit/s H.265 on all our 4K channels, so it would be madness to have two 4K channels for everything...

Last edited by FranceBB; 17th April 2020 at 13:30.
FranceBB is offline   Reply With Quote
Old 17th April 2020, 13:31   #7  |  Link
videoh
Useful n00b
 
Join Date: Jul 2014
Posts: 1,390
Quote:
I quickly settled on HLG after reading about it, but couldn't find a conversion utility to do this.
I cough like FranceBB too (no, not the virus!):

http://rationalqm.us/hdr/DGPQtoHLG_1.0.rar

It's an Avisynth filter that supports both SW mode and CUDA mode.

Last edited by videoh; 17th April 2020 at 13:37.
videoh is offline   Reply With Quote
Old 17th April 2020, 21:44   #8  |  Link
wswartzendruber
Registered User
 
Join Date: Feb 2008
Posts: 47
Quote:
Originally Posted by FranceBB View Post
Yep, starting with the BBC Whitepaper is always a good starting point as it basically explains how the conversion should be done.
Am I crazy for wanting to add scene-specific tone mapping to compress anything over 1,000 nits via dynamic PQ metadata? This was a goal from the beginning, otherwise, I would have written this thing to just output a static LUT.

And what's this color curve you speak of? I don't remember reading anything about that. I know that I have to weigh R, G, and B by differing factors to determine the overall luminance of a PQ pixel, but that's about it. Everything else seems to treat R, G, and B independently of each other.

Oh, and here are some more screenshots.
Attached Images
    
wswartzendruber is offline   Reply With Quote
Reply

Tags
hdr, hlg, pq2hlg

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 05:21.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.