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 > Announcements and Chat > General Discussion

Reply
 
Thread Tools Search this Thread Display Modes
Old 19th February 2024, 20:44   #421  |  Link
ErazorTT
Registered User
 
Join Date: Mar 2003
Location: Germany
Posts: 215
@wswartzendruber, yeah sorry I was all over the place with my thoughts.

In the meantime I have sorted my thoughts and came to the following conclusion: Having one LUT for the process of tonemapping the PQ down to 1000 nits AND converting to HLG is proably not the most optimal way of doing it.
The main argument here is that all the different maxcll and lumascales are part of the tonemapping, which can be done with a 1D-LUT (one for each combination of maxcll and lumascale) while the conversion to HLG can be done with a static 3D-LUT, which absolutely never changes.
Since that 1D-LUT can be generated extremenly fast for each combination of maxcll and lumascale, this opens the possibility for dynamic tonemapping.

So I went and implemented exactly that in DoViBaker. It now provides the possibility to have dynamic tonemapping, based on a 1D-LUT generated in memory on the fly. And then on top of that the user can apply the conversion to HLG with a static 3D-LUT. Of course there is also the possibility to have static tonemapping in case the input is just PQ without DolbyVision.

I think that this is an impoved workflow since on top of the addition of dynamic tonemapping, I can also circument the issue with the maximal output brightness of the HLG conversion, by allowing the intermediate output after the tonemapping to be scaled such that it fills the whole singal range. The then adjusted HLG conversion 3D-LUT uses the whole input range, which solves that problem. And also that adjusted 3D-LUT can be much smaller since now all LUT-points are used, and not only those below maxcll.
So instead of having a 65x65x65 LUT where only the lower 50x50x50 points are used, I can now directly use an adjusted 50x50x50 LUT, which has the same fidelity as the usual 65x65x65 LUT but now also hits the absolute max output brightness perfectly, while being less than half the file size (and CPU cache size).

Last edited by ErazorTT; 19th February 2024 at 21:10.
ErazorTT is offline   Reply With Quote
Old 20th February 2024, 00:25   #422  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 413
hlg-tools inherently can't handle dynamic metedata because it generates static LUTs. If something else comes along and is a better way to do things, that won't bother me none.
wswartzendruber is offline   Reply With Quote
Old 20th February 2024, 15:27   #423  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by ErazorTT View Post
@wswartzendruber, yeah sorry I was all over the place with my thoughts.

In the meantime I have sorted my thoughts and came to the following conclusion: Having one LUT for the process of tonemapping the PQ down to 1000 nits AND converting to HLG is proably not the most optimal way of doing it.
The main argument here is that all the different maxcll and lumascales are part of the tonemapping, which can be done with a 1D-LUT (one for each combination of maxcll and lumascale) while the conversion to HLG can be done with a static 3D-LUT, which absolutely never changes.
Since that 1D-LUT can be generated extremenly fast for each combination of maxcll and lumascale, this opens the possibility for dynamic tonemapping.
.
This is an idea behind Dolby tone mapping. It's done per shot or even per frame (eg. for live content) with some 'smoothing'.
2 pass mapping sounds like most optimal.

Last edited by kolak; 20th February 2024 at 15:30.
kolak is offline   Reply With Quote
Old 27th February 2024, 22:47   #424  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 413
I actually don't know that I'm as done with this as I thought I was...

If can I figure out how to efficiently calculate a device-dependent color space's maximum C value in OKLCH, I can quickly do gamut reduction without impacting perceptual brightness. This would let me efficiently:

1. Perform Y-based tonemapping which is not commonly done as it can produce out-of-gamut results.
2. Deal with maximum saturation on a single color channel which causes HLG to clip on that channel.
wswartzendruber is offline   Reply With Quote
Old 28th February 2024, 11:35   #425  |  Link
ErazorTT
Registered User
 
Join Date: Mar 2003
Location: Germany
Posts: 215
Quote:
Originally Posted by kolak View Post
This is an idea behind Dolby tone mapping. It's done per shot or even per frame (eg. for live content) with some 'smoothing'.
2 pass mapping sounds like most optimal.
This is exactly what DoViBaker does. If a DolbyVision substream is available it reads it and steers the tonemapping accordingly. And if no DolbyVision substream is available, the stream can be scanned which creates the necessary information which is then again used for the tonemapping.
ErazorTT is offline   Reply With Quote
Old 28th February 2024, 11:40   #426  |  Link
ErazorTT
Registered User
 
Join Date: Mar 2003
Location: Germany
Posts: 215
Quote:
Originally Posted by wswartzendruber View Post
I actually don't know that I'm as done with this as I thought I was...

If can I figure out how to efficiently calculate a device-dependent color space's maximum C value in OKLCH, I can quickly do gamut reduction without impacting perceptual brightness.
That sound interesting, however looking at https://oklch.com/ it appears to me that the numerical range of the C varialbe has a complicated functional form depeding on the other two variables (this "mountain range" on the top right of the page). How do you plan to use this for gamut reduction?

Last edited by ErazorTT; 28th February 2024 at 12:12.
ErazorTT is offline   Reply With Quote
Old 28th February 2024, 17:31   #427  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 413
Quote:
Originally Posted by ErazorTT View Post
That sound interesting, however looking at https://oklch.com/ it appears to me that the numerical range of the C varialbe has a complicated functional form depeding on the other two variables (this "mountain range" on the top right of the page). How do you plan to use this for gamut reduction?
Right now, I am using brute force to reduce C by an incredibly small amount until converting to RGB has everything in the 0.0-1.0 range. I have generated an experimental BT.2020-to-BT.709 LUT with this method and sent that off to FranceBB for evaluation.

Example Screenshot of Joker HLG

The OKLAB author mentions elsewhere a far more efficient method that I may implement. It relies on color gamut being the shape of a triangle.
wswartzendruber is offline   Reply With Quote
Old 29th February 2024, 16:00   #428  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
Quote:
Originally Posted by wswartzendruber View Post
Right now, I am using brute force to reduce C by an incredibly small amount until converting to RGB has everything in the 0.0-1.0 range. I have generated an experimental BT.2020-to-BT.709 LUT with this method and sent that off to FranceBB for evaluation.
Yes and I'm really really really sorry, but I'm still "having fun" with generating DolbyE 5.1 20bit big endian muxed in aiff...
Once that one is sorted, I'll take a very close look at it.
Apologies for the delay...
FranceBB is offline   Reply With Quote
Old 29th February 2024, 18:29   #429  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 413
Well, I threw the LUT your direction without speaking to you about it prior. You have every right to simply ignore it.

With that said, I am quite thankful that you are willing to review it.
wswartzendruber is offline   Reply With Quote
Old 29th February 2024, 22:37   #430  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
I would never do that, I consider you my friend, we even did a video call together, I would never ignore you.
Unfortunately spare time project thingies are piling up. I also still have to review a pull request by frank for videotek which is still there pending...
It's not easy when you clock in at 08.30AM and you leave your desk at 09.37PM...
FranceBB is offline   Reply With Quote
Old 1st March 2024, 03:32   #431  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 413
Quote:
Originally Posted by FranceBB View Post
I would never do that, I consider you my friend, we even did a video call together, I would never ignore you.
Unfortunately spare time project thingies are piling up. I also still have to review a pull request by frank for videotek which is still there pending...
It's not easy when you clock in at 08.30AM and you leave your desk at 09.37PM...
The priority for you might be some rest and relaxation before looking at the LUT.
wswartzendruber is offline   Reply With Quote
Old 15th March 2024, 21:28   #432  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
Ok, I finally had time to review the LUT.
The LUT has been tested against BT2020 SDR 100 nits contents.
Those contents were way more common in early 2013-2015 when the very first UHD H.265 50p 10bit broadcasting began and streams were just WCG (i.e Wide Color Gamut) but there was no standardization around using actual different logarithmic transfer characteristics.
It goes without saying that the world in 2013 was a very different place. Back then, we didn't expect things to end up the way they are now with logarithmic transfers, because the change in standard was already pretty massive without it!
We were effectively moving from H.264 FULL HD 25i TFF BT709 8bit to H.265 UHD 50p BT2020 10bit, so aside from the resolution and the codec, the very big swing was finally going progressive by saying goodbye to interlacing and finally going to 10bit.
As to the BT2020, given that the overwhelming majority of native BT2020 SDR 100 nits contents were coming from sport events (especially football), everything else was mostly still BT709 SDR 100 nits.
This meant that back then the supply chains around the BT2020/BT709 conversions were made to provide an easy roundtrip by effectively allowing to map BT709 points to BT2020 and remap those down to BT709 almost perfectly in a similar way of what was done for BT709/BT601. This meant it was possible to convert a native BT709 content without "inventing" anything but rather by just remapping the points to the right BT2020 coefficients so that those could then be mapped back (eventually) to BT709 if it was needed.
Back then little did we know that we would end up broadcasting different transfer characteristics, in fact working with logarithmic curves was common but not standardized and it was only an intermediate step in the production process and given that there was no standard everyone came up with its own implementation, the likes of Sony with Slog, Canon with Clog, Arri with LogC, ImagineVision with ZLog for their ZCam etc. What was worse was that each manufacturer included this info either as proprietary metadata in the file (Sony) or by writing the metadata as additional info, so in the "wrong" place in the file (Arri, ImagineVision) or even by blatantly lying and saying BT709 and then including the actual info in a sidecar XML (Canon).
This is still relevant today 'cause if we have HLG is thanks to the development and efforts done in those early days to standardize the whole thing and with the concept that people who still own a BT2020 SDR TV can still watch the stream.
As for the BT709 SDR -> BT2020 SDR -> BT709 SDR roundtrip, it was due to the fact that it was commonly thought back then that we would have been having a single master for everything in BT2020 SDR from which everything else needed to be obtained, a bit like what happened for BT709 (in fact I'd say that 100% of the BT601 SDR versions in 2013 were obtained automatically from the BT709 master). I made several tests with Jean Philippe Scotto di Rinaldi back then and in fact it's possible to apply a perfectly valid roundtrip in his HDR Tools like so:

#BT709 to BT2020
ConvertYUVtoXYZ()
ConvertXYZtoYUV(Color=1, pColor=2)

#BT2020 to BT709
ConvertYUVtoXYZ(Color=1)
ConvertXYZtoYUV(pColor=1)



This can be shown as follows (roundtrip BT709-2020-709):

BT709
BT2020
BT709






As you can see, the roundtrip is performed correctly.
Now, enough of that, on with the tests:










Note that I've just labelled the results obtained with William's LUT "HLG Tools" although he said that it's still experimental and he hasn't included it yet.
Here we can see that OKLAB (the algorithm he based his LUT on) seems to be producing a darker output, thus producing a slight shift in chroma. In some scenes it's much more noticeable, while in some others it's harder to spot. For instance, in the blue of the ambulance it's pretty noticeable. The overall result, however, is not bad and if someone didn't have something to compare it against, he would never be able to notice the difference.

If I have time, I'll try with some sport footage next time.
FranceBB is offline   Reply With Quote
Old 16th March 2024, 00:07   #433  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 413
EDIT: Whoops, nevermind.
wswartzendruber is offline   Reply With Quote
Old 18th March 2024, 10:15   #434  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
New test, this time on Sports, which is actually a true representation of BT2020 SDR 100 nits and I have to say that the results are actually pretty good there.
Both HDR Tools and William's new LUT achieve a very good result. The game was totally watchable and the results were incredibly close. I guess William's new idea of reducing the chroma to make it fall within valid BT709 SDR values works, so... well done.












FranceBB is offline   Reply With Quote
Old 19th March 2024, 05:53   #435  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 413
Yeah so it really does just hard-clip the color gamut. This is typically hard to do because finding a LAB/LCH-based color model than can do this can be a bit difficult. If a color model doesn't cause perceived brightness changes from lowering the chroma, then it will probably cause a hue shift from doing so.

Anyway, here's the OKLAB/OKLCH-based LUT:

https://wswartzendruber.net/uploads/bt2020to709.cube

I find this also works quite well for watching my HLG conversions on my 709 devices:

https://wswartzendruber.net/images/bt2020to709-1

Last edited by wswartzendruber; 19th March 2024 at 05:56.
wswartzendruber is offline   Reply With Quote
Old 20th March 2024, 16:46   #436  |  Link
ErazorTT
Registered User
 
Join Date: Mar 2003
Location: Germany
Posts: 215
Since my last replay in here, I also have been working on a LUT generator from PQ down to HLG, 2020 SDR and 709 SDR (DoViLutGen which is now part of DoViBaker). Including a LAB based mapping to prevent hard clipping for 2020 to 709. And there, what transfere function would you guys think is the proper one to take for going to and from linear, the one from BT709 (scene-referred) or the one from BT1886 (display-referred)? wswartzendruber has apparently used BT1886, which after some back and forth I now also think it probably the right one. But what do you think FranceBB?

Last edited by ErazorTT; 20th March 2024 at 17:24.
ErazorTT is offline   Reply With Quote
Old 20th March 2024, 21:18   #437  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
Quote:
Originally Posted by ErazorTT View Post
And there, what transfer function would you guys think is the proper one to take for going to and from linear, the one from BT709 (scene-referred) or the one from BT1886 (display-referred)?
I'm using display-referred.
FranceBB is offline   Reply With Quote
Old 20th March 2024, 23:18   #438  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 413
I've had good results using the same LUT to convert both BT.2100 HLG and BT.2020 SDR into BT.709 SDR.
wswartzendruber is offline   Reply With Quote
Old 21st March 2024, 07:32   #439  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
Quote:
Originally Posted by wswartzendruber View Post
I've had good results using the same LUT to convert both BT.2100 HLG and BT.2020 SDR into BT.709 SDR.
Yes of course, that's the whole point about HLG.
On a BT709 classic monitor by just converting the matrix/primaries and leaving the transfer alone, you're essentially seeing the same results a person with a BT2020 SDR TV would see when its TV doesn't interpret the transfer. And with HLG the idea is that you're still gonna be able to enjoy a valid result, albeit dimmer.

In the future, hopefully, SD and FULL HD channels will be tossed in favour of one single UHD BT2020 HLG stream per channel, but that future ain't here yet and we still have SD channels...

Last edited by FranceBB; 21st March 2024 at 07:35.
FranceBB is offline   Reply With Quote
Old 26th March 2024, 13:40   #440  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
Same test but this time with an HDR HLG source.
The same concept applies, but this time round I included the waveform to make things more clear.
Effectively, by just converting the matrix and primaries the luma is left untouched, which means that the result will be dimmer compared to tonemapping, but it will be very close to what someone with a BT2020 SDR TV would see.
In this example we have the BT2020 HLG source on the left, Reinhard tonemapping to BT709 SDR (HDR Tools) in the middle and then a simple colormatrix and primaries conversion with William's LUT (HLG Tools) on the right:







as we can see from the luma, this is left untouched by William's LUT and therefore it will peak at the same level as the original HLG source, thus making the white look a bit dimmer. This is exactly what HLG was created for and it's basically the same result someone with a BT2020 SDR TV at home would see. The idea behind HLG is to make it watchable without having to convert the transfer for the BT2020 SDR TVs, so the very same concept can be applied to convert from WCG BT2020 to BT709 leaving the original transfer alone.

Last edited by FranceBB; 26th March 2024 at 13:44.
FranceBB is offline   Reply With Quote
Reply

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


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