I Have Published a HDR10 to HLG Converter

[wswartzendruber]

I've just pushed some updates to Git that change the default tone mapping approach from R'G'B' to maxRGB.

[ErazorTT]

... change the default tone mapping approach from R'G'B' to maxRGB.

I have no idea what any of that means but I guess you know what you're doing..
BTW, I'm still using your tool all the time now for all my encodings.

[wswartzendruber]

I have no idea what any of that means but I guess you know what you're doing..
BTW, I'm still using your tool all the time now for all my encodings.
Are you encoding UHD discs, or some other source?

Has the documentation been helpful?

Are you aware that documentation exists?

[ErazorTT]

Are you encoding UHD discs, or some other source?

Has the documentation been helpful?

Are you aware that documentation exists?

only UHD discs. I have read the github documentation. And yes it was helpful.

For other people to find this software, I would really think you should add a link also to the list of avisynth filters: http://avisynth.nl/index.php/External_filters

[Reel.Deel]

For other people to find this software, I would really think you should add a link also to the list of avisynth filters: http://avisynth.nl/index.php/External_filters

Although technically is not an AviSynth plugin. However, I did added to the external links section of the AVSCube (http://avisynth.nl/index.php/AVSCube#External_Links) plugin a while back.

[wswartzendruber]

https://github.com/wswartzendruber/hlg-tools/releases/tag/release/1.0.0

This concludes active development. Any new releases from here will be in response to community feedback.

[wswartzendruber]

Special thanks to ErazorTT for reporting the bug that lead to this release:

https://github.com/wswartzendruber/hlg-tools/releases/tag/release/1.0.1

[ErazorTT]

I'm currently trying to find a rigorous way to determine the luma scale. Trying to come up with somthing I found this discrepancy and I cannot wrap my head around it.

Here I am plotting the display brightness of the HLG curve and the SDR curve with 100%=203nits.
Since the HLG specifications say that 100% signal value on the SDR picture should represend 75% signal value on the HLG picture, and 75% of the HLG signal are 203nits, I am using these 203nits as maximum for the SDR curve.

https://i.postimg.cc/NLpgjN61/SDR100eq-HLG75.png (https://postimg.cc/NLpgjN61)

But as can be seen, the two curves never match! So I am currently questioning your recommendation to "use a frame with a caucasian face in a well-lit environment, comparing the brightness of that face".

The curves would be matching in the lower half if one would be using the definition of 89%SDR=75%HLG. Since then the curve look like that:

https://i.postimg.cc/Jt1rmwkr/SDR89eq-HLG75.png (https://postimg.cc/Jt1rmwkr)

So in the case of 89%SDR=75%HLG one can directly comare the brightnesses of the darks and the midtones. But this does not follow the assumption that 100%SDR=75%HLG.

In order to be able to compare the brightness using the 100%SDR=75%HLG definition, one needs to first scale the values of the HLG stream before one can compare them to the SDR stream. The factor to increase signal values of the HLG stream would be 1.123. This would produce the following curves:
https://i.postimg.cc/7CGVfQJb/SDR100eq-HLG75-1-123.png (https://postimg.cc/7CGVfQJb)

[wswartzendruber]

This is quite intentional.

BT.2408-4 section 5.1.2.1 does state that SDR displayed within HLG should have 100% SDR mapped to 75% HLG. This is effectively mapping SDR maximum white to HDR reference white.

Elsewhere, BT.2390-9 section 1.3 states the following:

In video, the system white is often referred to as reference white, and is neither the maximum white level of the signal nor that of the display.

And continues on with:

In traditional imaging, the range allocated to these highlights was fairly low and the majority of the image range was allocated to the diffuse reflective regions of objects. For example, in hardcopy print the highlights would be 1.1x higher luminance than the diffuse white maximum. In traditional video, the highlights were generally set to be no higher than 1.25x the diffuse white. Of the various display applications, cinema allocated the highest range to the highlights, up to 2.7x the diffuse white.

(Note that these are display linear values.)

This is why the preview LUTs generated by pq2hlg behave the way they do. We are not trying to map SDR within HLG, we are trying to find the SDR representation of a HLG image. As such, pq2hlg's preview mode linearly maps 0%-75% HLG to 0%-90% SDR, and it compresses 75%-100% HLG within 90%-100% SDR.

SDR does have a small amount of dynamic range for specular detail, just nowhere near as much as HLG.

[ErazorTT]

So then you say that 90% of the SDR signal should map to 75% of the HLG signal?

[wswartzendruber]

So then you say that 90% of the SDR signal should map to 75% of the HLG signal?

That is my present philosophy until someone can argue why it shouldn't be.

[ErazorTT]

That is my present philosophy until someone can argue why it shouldn't be.

I found a sentence in 2408-5 supporting your view. In section 7.7:
The difference in perceived mid-tone contrast arises because of the difference in the diffuse white level of an SDR image (~100 cd/m2) and that of an HDR image (~200 cd/m2).
Thus in order to compare the pixel signal values of SDR and HLG, we have to carry out the comparison under the assumption that SDR and HLG have the same diffuse white level of ~200. Making the 100% signal of SDR going above 200 in that comparison.

PS: i found an even better quote from 2408-5. Table A8.2 states the following numbers:
90%SDR = 75%HLG = 203nits
100%SDR = 79%HLG = 260nits

[wswartzendruber]

Uh, wow. Appendix 8 is new for the fifth revision. And it's all about how the PRC does HDR/SDR simulcasting.

And...we independently came to similar conclusions about mapping HLG to SDR.

[ErazorTT]

You know, I had the impression that HLG not only has more headroom in the highlights but also in blacks ("bottomroom"..? :p). At least when reading through the BBC documentations.
But now our HLG streams have basically the exact same pixel signal values in the darks and midtones as SDR. So how to reconcile this with the BBC statement?

[wswartzendruber]

Wait, what does the BBC say that counters this?

[ErazorTT]

this here for example at around minute 8:
https://www.smpte.org/webcast/dr-pq-and-hlg-presented-bbc
Granted, at this stage he talks about the camera curve (OETF) and not the display curve (EOTF), but I would have thought that there should have been also some repercussions in the display curve if the camera curve is different.

here are the slides for that talk:
https://www.dutchguild.nl/31jan2017/HLG%20Overview%20-%20Dutch%20Guild%20published.pdf
Especially slide 14, where it zooms into the curve, and one sees that the SDR curve does actually not match the HLG curve.

And then there is Figure 18 in 2390-10, again the OETF, the red HLG line is not exactly on top of the blue SDR line in the lower half, but slightly above it. Thus bringing home the same message as the plot on slide 14.

Or to put it differently: Section 5.1 and section 5.2 of 2408-5 do the SDR to HLG conversion differently. 5.1 produces an HLG signal that follows the same curve as SDR and can be matched exactly like we're doing, and 5.2 generates a HLG signal which looks more like the OETF plots I mention above.
:confused:

I am aware however that the PQ to HLG conversion does not have any of these ambiguities and has only the luma-scale as a free parameter. So all this does not contradict your LUT generator, it's a question about the expectation of what curve the birghtness of the resulting HLG will follow. And this is not clear to me. Should I expect to get basically an SDR curve in the lower half, which would match the section 5.1 SDR to HLG conversion, or should I expect to get something looking like the OETF which does not match the SDR curve and would reproduce the section 5.2 SDR to HLG conversion.

[wswartzendruber]

The shape of the HLG curve isn't something I considered at all. Fundamentally, I view PQ with a reference white of 203 nits and MaxCLL of 1,000 nits as being logically equivalent to HLG. Once I realized that, I came to see most of the conversion process in the context of linear display light.

In any event, the HLG curve doesn't mean what it used to. Back when HLG was going to put reference white at 50%, the shadows and midtones were going be on a SDR response curve, while the specular detail above that would be on something closer to PQ. But now, reference white is at 75%. So 1/3 of the shadows+midtones are in the PQ-area of the curve.

[wswartzendruber]

I didn't realize I could upload copyrighted HLG material to YouTube, but WB will apparently let me as long as I don't monetize it.

https://www.youtube.com/watch?v=D-F82b9m3Qo

Can anyone see this in HLG?

[FranceBB]

Can anyone see this in HLG?

Yes I can:
when people are watching with SDR BT709 capable devices, it shows 1080p and google converts the colormatrix only from BT2020 to BT709, so the reference white will still be 75%.
When people are watching with SDR BT2020, google will serve the BT2020 HLG stream (although the monitor will ignore the transfer) and the reference white will still be 75%.
In my case, I'm watching this with an HDR HLG BT2020 capable device (and a 799 nits monitor) and it offers me the right HLG stream: Settings Image (https://i.imgur.com/mNekeoD.png)


I tried to make a few screenshots while the monitor and the OS are in HDR Mode, so hopefully they're gonna give you an idea of how it looks like in HDR HLG:

Img 1 (https://i.imgur.com/neG8RKV.png) - Img 2 (https://i.imgur.com/fkVKuNs.png) - Img 3 (https://i.imgur.com/zRJLTpj.png) - Img 4 (https://i.imgur.com/xj8rD6P.png) - Img 5 (https://i.imgur.com/iK1N3JR.png) - Img 6 (https://i.imgur.com/blGF1Rd.png) - Img 7 (https://i.imgur.com/qmANPsb.png)

On a real monitor it looked really good, though... except for the fact that YouTube bit-starved everything, but that ain't HLG Tools fault.

[wswartzendruber]

Yeah the compression they applied is horrendous. I'm guess my small-time channel doesn't warrant any more bits than that. I would have paid them to do a better job.

[wswartzendruber]

I wonder if Disney will let me get away with the same thing...

[FranceBB]

I wonder if Disney will let me get away with the same thing...

I guess there's only a way to find out xD
Jokes aside, I wouldn't risk it.
When I upload samples they're generally stuff I recorded with my camera myself.

[wswartzendruber]

I've also uploaded an Alita clip.

https://www.youtube.com/watch?v=XMdFweclflY

The BT.709 presentation here looks...kind of red...

https://wswartzendruber.net/images/alita-yt709-vs-sdr.jpg

YouTube's BT.709 mapping is on the left. Native BT.709 is on the right.

[kolak]

Yep, looks quite saturated, but when I play YT and compare this to your grab then they don't match (maybe it's due my screen been P3 gamut and tags accuracy). YT is less saturated, but still more than the one on the right. It's hard to say which one is correct. Update: seeing HLG in native format actually one on the left looks more correct.
There can be HDR version and SDR version and HDR mapped to SDR doesn't really have to look as native SDR version.
If you want to compare you conversion to something else use Resolve which has Dolby mapping built in.
Dolby tools do best SDR from all tools I've seen. Maybe because they work per shot, so each seen is analysed for min/avg/max brightness and then mapped to SDR. This is way more optimal than global conversion.
From my tests Dolby tools preserve saturation better than eg Resolve's internal mapping filter. Overall they tend to create rather more saturated look.

I think YT now puts HDR over Dolby tools for SDR conversion, so it should be quite good. But not sure if they convert HLG to HDR10 and then use Dolby to map to SDR or do some direct HLG to SDR mappings.

[FranceBB]

But not sure if they convert HLG to HDR10 and then use Dolby to map to SDR or do some direct HLG to SDR mappings.

They don't for HLG, no worries about that.


The BT.709 presentation here looks...kind of red...



Speaking of the sample, I see it red-ish in HLG as well to be fair.

Those are the screenshots I grabbed while playing YouTube in HLG and with the OS being HLG aware and outputting in HLG BT 2020 like I did for Aquaman:

Img1 (https://i.imgur.com/o26N2Bt.png) - Img2 (https://i.imgur.com/bXFD2ft.png) - Img3 (https://i.imgur.com/UCFCIx7.png) - Img4 (https://i.imgur.com/OQrpJjd.png) - Img5 (https://i.imgur.com/nbh3m89.png) - Img6 (https://i.imgur.com/z4BfdYr.png)

[kolak]

They don't for HLG, no worries about that.





Speaking of the sample, I see it red-ish in HLG as well to be fair.

Those are the screenshots I grabbed while playing YouTube in HLG and with the OS being HLG aware and outputting in HLG BT 2020 like I did for Aquaman:

Img1 (https://i.imgur.com/o26N2Bt.png) - Img2 (https://i.imgur.com/bXFD2ft.png) - Img3 (https://i.imgur.com/UCFCIx7.png) - Img4 (https://i.imgur.com/OQrpJjd.png) - Img5 (https://i.imgur.com/nbh3m89.png) - Img6 (https://i.imgur.com/z4BfdYr.png)

It can be tested if they use Dolby mapping for HLG input or not.

Your grabs are P3 gamut with sRGB gamma.
Are they really HLG just with sRGB tag or gamma is sRGB (then it's a conversion)?

[wswartzendruber]

I don't know if they're gamma mapping or not...

However, I can generate a test signal for upload this weekend to find out.

[wswartzendruber]

They're not mapping brightness. They're just interpreting HLG as BT.709.

https://www.youtube.com/watch?v=8g0NRk1afYk

[Balling]

Alita is fake HDR, 203 nits everywhere. which is SDR level in 1000 nits. I would say any test with it is invalid. https://www.youtube.com/watch?v=JLmkRyhjzQ8

It mostly does not even exceed 709 primaries, which is ridiculous.

Of course it is still a cool example of blu-ray with both Dolby Vison MEL and HDR10+.

[wswartzendruber]

Alita is fake HDR. I would say any test with it is invalid. https://www.youtube.com/watch?v=JLmkRyhjzQ8
It's not fake HDR, it's cinematic XYZ.

And the test in this case is in color gamut and how YouTube is mapping BT.2020 to BT.709.

[kolak]

Hmmm- this sounds as "easy" way, but far from optimal.
Also YT requires HLG HDR been sent as Rec.2020, so you can't use P3 primaries (has to be P3 within Rec.2020).

[wswartzendruber]

What's a better way to upload HDR to YouTube?

[kolak]

Rec.2020 PQ with proper headers.

https://support.google.com/youtube/answer/7126552?hl=en#zippy=%2Chdr-video-file-encoding%2Chdr-metadata

If encoder doesn't set proper headers then use MOV container and then this tool to inject proper HDR metadata (of course video has to be Rec.2020 with PQ):

http://mogurenko.com/2021/01/29/amcdx-video-patcher-v0-6-7/

If you have small sample I can make you DV SDR mapping.

[wswartzendruber]

No offense, but I really wish PQ would just die when it comes to content distribution.

Its proper place is in the studio.

EDIT: Alternatively, I'm willing to hear arguments on why viewers need more dynamic range than what HLG offers.

[Balling]

Hmmm- this sounds as "easy" way, but far from optimal.
Also YT requires HLG HDR been sent as Rec.2020, so you can't use P3 primaries (has to be P3 within Rec.2020).

Only Netflix masters use pure P3-D65 with PQ. In fact windows does not even support HLG.

>EDIT: Alternatively, I'm willing to hear arguments on why viewers need more dynamic range than what HLG offers.

Black level? 0.0001 is simply achievable and is much more important than difference between 750 nits LG C9 and 1700 nits Galaxy S22 Ultra.

>No offense, but I really wish PQ would just die when it comes to content distribution.

Yes, without 12 bit PQ in Main12 or VP9.2 12 bit it is not perfect.

[kolak]

You can use which you prefer until it hits some delivery spec and then you have to use what is required. All "transmission" needs Rec.2020 as this is in UHD standard.
Netflix delivery spec doesn't mandate P3, it can be Rec.2020 as well. It mandates DV though.

[kolak]

No offense, but I really wish PQ would just die when it comes to content distribution.

Its proper place is in the studio.

EDIT: Alternatively, I'm willing to hear arguments on why viewers need more dynamic range than what HLG offers.

Not my decision :)
You should be happy that at least happy we've passed ancient Rec.709 and 100nits :)

[Balling]

You can use which you prefer until it hits some delivery spec and then you have to use what is required. All "transmission" needs Rec.2020 as this is in UHD standard.
Netflix delivery spec doesn't mandate P3, it can be Rec.2020 as well. It mandates DV though.

Last time I checked DV still mandates P3, which is less than what samsung QD-OLED support, I suppose to preserve some bitrate. Are you sure JPEG 2000 masters do not mandate P3-D65 with PQ?

[kolak]

It's always P3 gamut. No one commercially grades to Rec.2020 as nothing (realistic) can display it.
Just in case of Rec.2020 delivery it's P3 within Rec.2020 container (same a many cinema masters are just Rec.709 within P3).
Netflix delivery spec is public:
https://drive.google.com/file/d/0B9DJydDVOVKKLVdCdlF2cFVDVEE/view?resourcekey=0-GRqfy963JM9jcd-MQcaoBw

[Balling]

I've also uploaded an Alita clip.

https://www.youtube.com/watch?v=XMdFweclflY


YouTube's BT.709 mapping is on the left. Native BT.709 is on the right.

Yes, I do not know what you did but this is absolutely wrong with blu-ray 00688.m2ts, Blu-ray is much darker.
mpv.com --target-colorspace-hint=yes -hwdec=nvdec --gpu-api=vulkan -vo=gpu-next BDMV\STREAM\00688.m2ts

mpv.com --target-colorspace-hint=yes -hwdec=nvdec --gpu-api=vulkan -vo=gpu-next --ytdl-format=335 https://www.youtube.com/watch?v=XMdFweclflY

LG C9 also agrees with the first command if not even slightly darker. Oh and changing vulkan to d3d11 MAKES NO difference at all. It is bitperfect looking.

[Balling]

It's always P3 gamut. No one commercially grades to Rec.2020 as nothing (realistic) can display it.
Just in case of Rec.2020 delivery it's P3 within Rec.2020 container (same a many cinema masters are just Rec.709 within P3).
Netflix delivery spec is public:
https://drive.google.com/file/d/0B9DJydDVOVKKLVdCdlF2cFVDVEE/view?resourcekey=0-GRqfy963JM9jcd-MQcaoBw

Spears & Munsil UHD HDR Benchmark was specifically graded on Laser BT.2020 projector (red tulips scene), even on FEL. Lego Batman and some others were test graded on Blu-ray as BT.2020. Matrix was graded in 2020. Latest Star wars is mostly outside P3...

QD-OLED can go into Bt.2020 no problem. Self-emissive QD will even surpass that.

In fact Ted has a giant list of movies outside P3. Oh, and there is also SDR 10 bit HEVC blu-ray tagged as Bt.2020.

[Balling]

Looks like it is new stuff in Netflix spec.

>Updated colorimetry to include support for ITU-R BT.2020 Dolby VisionTM HDR IMF packages

[kolak]

Spears & Munsil UHD HDR Benchmark was specifically graded on Laser BT.2020 projector (red tulips scene), even on FEL. Lego Batman and some others were test graded on Blu-ray as BT.2020. Matrix was graded in 2020. Latest Star wars is mostly outside P3...

QD-OLED can go into Bt.2020 no problem. Self-emissive QD will even surpass that.

In fact Ted has a giant list of movies outside P3. Oh, and there is also SDR 10 bit HEVC blu-ray tagged as Bt.2020.

As you said- all rather test titles.
If you have Rec.2020 titles then they will look different depending how much of Rec.2020 your TV can cover. Not a desired thing :) Tech has to be there in order to make a use of Rec.2020.
Do you know how much those laser projectors cost?
Also- projection gives totally different viewing experience compared to TVs as it's reflective, not emissive. These projectors are also not very bright as they are for dark rooms. There is still a lot to do.

I just watched some info abut QD and it's more like shy of 90% of Rec.2020, so still not there. We need 95%+ to start doing Rec.2020 grades. Problem is that industry still has no screen for this as pro market is dead and no one is really doing special panels for reference screens.
No idea where you read that QD-OLED can go to Rec.2020 (easily)?

[kolak]

Is there Lego Batman Blu-ray which is Rec.2020 (for sure) or they kept it just for cinema master?
Fact that it was graded to Rec.2020 is 0 guarantee what is on Blu-ray as you create many versions for different releases.
Not that sure big studio would be keen to release Rec.2020 grade when tech is not there ( I worked at those places).
Show me grab from this disc saying Mastering display color primaries = Rec.2020.
Not that it matters much but it is not even a native UHD tile, but 2K upscale.

Almost sure Rec.2020 grade was just for Dolby Cinemas:
https://www.avsforum.com/threads/the-lego-batman-movie-in-dolby-vision-hdr-and-atmos-sound.2747881/page-2

[Balling]

Not that it matters much but it is not even a native UHD tile, but 2K upscale.



Their upscale is many times better than what LG or Nvidia can give, it is not real time. Also, this is animation. And yes, Lego Batman has a lot of colors outside P3. https://www.avsforum.com/threads/christie-eclipse-projector.3018138/page-82#post-59680204

Anyway, latest Star Wars and remaster of Matrix are not P3, they were by design mastered for Bt.2020, even if tagged in MDCV as Display P3. Matrix is tagged 2020 though.
https://mobile.twitter.com/NanosysInc/status/1290434026994577408
>No idea where you read that QD-OLED can go to Rec.2020 (easily)?

This is just first gen of it. I mean it is kinda obvious.

>Also- projection gives totally different viewing experience compared to TVs as it's reflective, not emissive.

They are certainly very different SPD, so are captured on cemaras differently than TVs.

[wswartzendruber]

Yes, I do not know what you did but this is absolutely wrong with blu-ray 00688.m2ts, Blu-ray is much darker.
mpv.com --target-colorspace-hint=yes -hwdec=nvdec --gpu-api=vulkan -vo=gpu-next BDMV\STREAM\00688.m2ts

mpv.com --target-colorspace-hint=yes -hwdec=nvdec --gpu-api=vulkan -vo=gpu-next --ytdl-format=335 https://www.youtube.com/watch?v=XMdFweclflY

LG C9 also agrees with the first command if not even slightly darker. Oh and changing vulkan to d3d11 MAKES NO difference at all. It is bitperfect looking.
pq2hlg takes the input's reference white level into account when performing the conversion.

Alita is a cinematic XYZ transfer. So reference white is going to be 48 nits and MaxCLL is going to be 130 nits. You feed these values into pq2hlg so it can factor them into the LUT it generates. Then you'll get reference white put at 203 nits and MaxCLL tonemapped down to 1,000 nits.

EDIT: Although, since Alita doesn't use all of HLG's dynamic range, no tone mapping will take place.

[kolak]

Their upscale is many times better than what LG or Nvidia can give, it is not real time. Also, this is animation. And yes, Lego Batman has a lot of colors outside P3. https://www.avsforum.com/threads/christie-eclipse-projector.3018138/page-82#post-59680204

Anyway, latest Star Wars and remaster of Matrix are not P3, they were by design mastered for Bt.2020, even if tagged in MDCV as Display P3. Matrix is tagged 2020 though.
.

When you grade you have two ways: P3 settings or you grade in Rec.2020 and then you have gamut limiter. Typically this limiter is set to P3. When you export you get P3 within Rec.2020. If you grade in P3 you then export as Rec.2020 and get same end result.
Blu-ray is always Rec.2020 as there is no such a thing like P3 defined 'transmission' format. Your players sends 2020 to TV.

If you now go to 1st grading method you turn off P3 limiter and grade in full Rec.2020. Here most important is monitor. If you do so but your monitor is capable of about P3 anyway it's all good. Colorist wil see only P3 colors, but master will contain also colors up to Rec.2020 gamut. Colorist doesn't know how exactly scene is going to look with Rec.2020 capable display though as he simply can't see it. This is why standard approach is to limit gamut to P3 today.
If you grade on something close to Rec.2020 then when watched on P3 monitor you will get 'unknown preview'. You won't see what colorist did as your monitor can't display all Rec.2020 colors, so your experience is affected. I’m not sure how 'bad' or not it will manifest as I have not seen monitor which goes much outside of P3. Industry is struggling with any decent HDR screen as Sony stopped making pro OLED panels and Panasonic trashed their dual layer tech as well.
When you watch Rec.709 on poor laptop screen (still probably 50% laptop screen are <Rec.709) you get not a nice experience, so P3 vs Rec.2020 is similar but may be less drastic as P3 is already a 'lot' of colors. I assume if you have properly mastered Rec.2020 disc (so player is aware of it and does proper conversion) then it's not really destructive and you see just P3 without those 'extra' colors. In this case Rec.2020 disc are fine.
Another reason is hidden in $. Now you have P3 experience, but when tech evolves then they will sell you same content again graded to Rec.2020 :p

Matrix may be true Rec.2020 title, but was probably still graded on monitor which doesn't go much beyond that. If it was graded in Rec.2020 on laser projector then home users will not necessarily see good representation (as cinema is very different experience) of director/colorist idea, so it's not all that obvious that having out of P3 colors is a good thing today (this is why Rec.709 is/was used for so long even if studios had P3 monitors for quite a time). We need to wait for tech to catch up to use Rec.2020.

The whole idea in standard is that things are clearly defined and you grade to achievable parameters. There is no place for any mapping, approximation etc. Monitors are calibrated and follow precise math. Once you leave studio it's crazy world with TVs set all over the place, but this is another story :)

Also- any analysis like in case of Sony monitor should not be done with compressed master (or Blu-ray) as you get plenty codec overshoots so if monitor's check is "bit perfect" then many pixels will be outside of 100% P3, but only because they are overshoot. If you could set gamut to eg. 103-105% P3 (or low pass filter signal first) then results would be different. Most discs out there are P3 limited.

[kolak]

pq2hlg takes the input's reference white level into account when performing the conversion.

Alita is a cinematic XYZ transfer. So reference white is going to be 48 nits and MaxCLL is going to be 130 nits. You feed these values into pq2hlg so it can factor them into the LUT it generates. Then you'll get reference white put at 203 nits and MaxCLL tonemapped down to 1,000 nits.

EDIT: Although, since Alita doesn't use all of HLG's dynamic range, no tone mapping will take place.

Yes as HDR in cinema is just bit more than 100nits ( 108 nit is used by Dolby HDR cinema if I remember well). It’s still way superior experience compared to any TV.

[FranceBB]

Yep, exactly, the overwhelming majority is still limited to P3 and grades contents this way and then exports as BT2020. Even our Eizo, Kodac and Sony expensive studio equipment which we've been using to grade HDR stuff from Log since 2018 can't do much better and I can totally relate with what Kolak said: it wouldn't make sense to go beyond Display P3 'cause no one would be able to see and benefit from it anyway (especially users won't be able to see those anyway as far as consumer TVs are concerned), so yeah. About the different TV sets, aside from the different technologies they use, I also noticed that the overwhelming majority of users (excluding the Doom9 population) just puts very exaggerated settings, throwing any creative intent down the drain (I'm talking about stuff like putting contrast up high, colors up high, sharpness 100% etc all together with linear interpolation / optical flow artifacts) which make the final result completely different from what we saw in the studio, but hey, c'est la vie. About the last thing, overshooting, you're absolutely right again: final distribution codecs have overshoots occurring occasionally on different scenes and the more bit-starved the files are, the worse they get. People might think that masterfiles are safe from those, but believe it or not, I saw those occurring in *some* high bitrate ProRes files as well (and I'm sure you saw them too), but anyway that's another story.


:goodpost: Kolak, I'm glad that you're here. :)

[Balling]

Well, all USA based on snapdragon Galaxy devices have natural profile which is color accurate.

So this whole
>excluding the Doom9 population

Is misleading. Of course until device manufactures will not force color accurate profiles... Oh and also Dolby Vision profiles are accurate by default I think. Not that they also do not have Vivid mode.

>Your players sends 2020 to TV.

I am not sure this is the case with MacOS, BTW. It is certianly not the case with some Mastering monitors with P3-D65 modes (ONLY mode sometimes). Atomos Ninja...

>any analysis like in case of Sony monitor should not be done with compressed master (or Blu-ray) as you get plenty codec overshoots

Some of those are 420 overshoots. Thay is why you do not use mastering monitor. You use davinci resolve or ff software. See for example, this uses ff: https://youtu.be/DtyDmnoPVRs