I Have Published a HDR10 to HLG Converter

[FranceBB]

Well, left you have 4000 nits, right you have 1000 nits:



The script is:

video=FFVideoSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\GraySteps All.mkv")
audio=BlankClip(length=719, fps=24000, fps_denominator=1001, audio_rate=48000, channels=1)
AudioDub(video, audio)

propClearAll()

z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:full", resample_filter_uv="spline64", dither_type="error_diffusion")

bbc4000=Cube("C:\Program Files (x86)\AviSynth+\LUTs\2a_PQ4000_HLG_mode-nar_in-nar_out-nar_nocomp.cube", fullrange=true)
bbc1000=Cube("C:\Program Files (x86)\AviSynth+\LUTs\1a_PQ1000_HLG_mode-nar_in-nar_out-nar_nocomp.cube", fullrange=true)

StackHorizontal(bbc4000, bbc1000)

z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

and indeed you can see more steps in the 4000 nits one, just take a look at the whites.

[wswartzendruber]

I'll mess with all this once I get off work.

[ErazorTT]

Originally Posted by FranceBB

and indeed you can see more steps in the 4000 nits one, just take a look at the whites.

Yes there are more steps in the 4000nits. But actually its too many steps. The BBC lut looks to be wrong, as I wrote in my previous post:

Originally Posted by ErazorTT

Hm that is weird. The BBC lut produces two steps at almost exactly the same non-white brightness (red arrows in the grayBBC.png picture). These steps are apart 5% of the signal, which for PQ is really a lot in absolute terms. So that must be wrong!

Addionally, I took out my colorspace calculation sheet and found that a 4000nits white is at a 8bit value of 198 for a limited range signal. So actually in the picture the step with an orange arrow should already have been completly white, since that is at a value of 202.

Also look at the files I posted there.

[ErazorTT]

Originally Posted by wswartzendruber

I'll mess with all this once I get off work.

Currently I don't think you should do any changes to your code. Your result appears to be on point for me. (In contrast to the BBC lut, which appears to be somehow messed up)
At least for a luma-scale of 1.0. For Factors above I'm not so sure, I still think there is something fishy.

[wswartzendruber]

Originally Posted by ErazorTT

At least for a luma-scale of 1.0. For Factors above I'm not so sure, I still think there is something fishy.

From a theoretical standpoint, the PQ to HLG conversion process fundamentally has one parameter: Lw. This controls the reference peak luminance.

Now, I could have pq2hlg alter this value according to MaxCLL after any --lum-scale adjustment, but as BT.2408-4 page 23 explains, "the signal level for diffuse white will vary." I made a decision early on that Lw would always be fixed to 1,000 nits, which is what BT.2408 calls for.

Ergo, the pq2hlg process consists of three fundamental steps:

1. Scale luminosity to get reference white where it should be (if specified).
2. Tone map everything from the working maximum down to 1,000 nits.
3. Perform the PQ-to-HLG conversion process.

[FranceBB]

Tomorrow I'll repeat the test with the Warner Bros approved one and I'll compare it to the BBC one and we're gonna see the differences. Ironically, Warner didn't approve the BBC one, which probably means that there must be something odd indeed.

[ErazorTT]

@wswartzendruber: I rechecked what I was doing in 16bits, and as it appears everything is fine just as you said. It's doing exactly the right thing for lum-scale!
Doing things in 10bits made it appear that the "point of max whiteness" was moving to the dark side on a greyscale ramp when lum-scale was increased. But that was only due to rounding errors on 10 bits. Interesting, I would have thought that 10bits would be enough precision for anything I'm doing.

@FranceBB: yes, that would be interesting as well

[wswartzendruber]

Looks like I'm at odds with the BBC on what a 4,000 nit LUT should do:

http://wswartzendruber.net/images/bb...-4000-nits.png

Telling pq2hlg that the MaxCLL is 10,000 nits produces a much closer result to the BBC's LUT:

http://wswartzendruber.net/images/bb...10000-nits.png

[FranceBB]

Ok, looks like the BBC 4000 nits LUT is doing something particular indeed, but if anything the WB approved one is even... more peculiar, let's put it this way.
This is the Warner 4000 nits LUT:

video=FFVideoSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\GraySteps All.mkv")
audio=BlankClip(length=719, fps=24000, fps_denominator=1001, audio_rate=48000, channels=1)
AudioDub(video, audio)

propClearAll()

#From 4:2:2 16bit planar Narrow Range to RGB Planar 16bit Narrow Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

#From PQ to HLG with 16bit precision
Cube("C:\Program Files (x86)\AviSynth+\LUTs\WarnerBros_PQToHLG_MaxCLL_4000.cube", fullrange=true)

#From RGB 16bit planar Narrow Range to YUV422 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:std-b67:2020:limited=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

Warner 4000 nits left, BBC 4000 nits right:




Color Saturation Steps Warner Bros approved LUT 4000 nits encode: https://we.tl/t-JezXgoCRzm

Grey Steps All Warner Bros approved LUT 4000 nits encode: https://we.tl/t-QZ5iX3gvOI


@wswartzendruber... can you check if this one checks out with your output?

[ErazorTT]

Originally Posted by FranceBB

z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

#From PQ to HLG with 16bit precision
Cube("C:\Program Files (x86)\AviSynth+\LUTs\WarnerBros_PQToHLG_MaxCLL_4000.cube", fullrange=true)

#From RGB 16bit planar Narrow Range to YUV422 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:std-b67:2020:limited=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

Why the heck are you converting to limied range rgb and then have the lut run on full range?

[FranceBB]

Originally Posted by ErazorTT

Why the heck are you converting to limied range rgb and then have the lut run on full range?

the full range thick there doesn't matter, that particular LUT is Narrow Range in - Narrow Range Out, so basically Limited TV Range in, Limited TV Range Out.

If you set it to false, it's not gonna work correctly, 'cause every time you convert to RGB with something like Convertto etc it will expand levels to Full Range and at that point it's too late.

[FranceBB]

This is a 1000 nits movie.

FFVideoSource("\\Mibcpmcs011.avid.mi.bc.sky.it\raid0\MASTERFILES\Godzilla vs Kong H.265 UHD HDR PQ BT2020 YUV422 23,976p 10bit.ts")

propClearAll()

#From 4:2:2 16bit planar Narrow Range to RGB Planar 16bit Narrow Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

#From PQ to HLG with 16bit precision
Cube("C:\Program Files (x86)\AviSynth+\LUTs\WarnerBros_PQToHLG_MaxCLL_1000.cube", fullrange=true)

#From RGB 16bit planar Narrow Range to YUV422 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:std-b67:2020:limited=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

As you can see black sits perfectly at 4096 ('cause we're working in 16bits) and everything is nice and dandy.
Same goes for frame 1382:



Now, here's what happens with this other script:

FFVideoSource("\\Mibcpmcs011.avid.mi.bc.sky.it\raid0\MASTERFILES\Godzilla vs Kong H.265 UHD HDR PQ BT2020 YUV422 23,976p 10bit.ts")

propClearAll()

ConvertBits(16)
ConvertToPlanarRGB()
Cube("C:\Program Files (x86)\AviSynth+\LUTs\WarnerBros_PQToHLG_MaxCLL_1000.cube", fullrange=false)
ConverttoYUV422()

The result is CLEARLY wrong:



and indeed you can see the black sitting far too high:




and this is ALSO WRONG:

FFVideoSource("\\Mibcpmcs011.avid.mi.bc.sky.it\raid0\MASTERFILES\Godzilla vs Kong H.265 UHD HDR PQ BT2020 YUV422 23,976p 10bit.ts")

propClearAll()


z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

Cube("C:\Program Files (x86)\AviSynth+\LUTs\WarnerBros_PQToHLG_MaxCLL_1000.cube", fullrange=false)

z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:std-b67:2020:limited=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

as you can clearly see that the black is far too high.

So, in a nutshell, to recap the officially used LUTs:

-> The BBC one works in Full PC Range RGB
-> The WB approved one works in Studio RGB (i.e Limited TV Range)

therefore, for the Warner Bros approved one, you need to first bring everything to Studio RGB 16bit planar and THEN apply the LUT, then go back to Limited TV Range YUV without touching the levels. This is pretty common in the industry and honestly the only reason why the BBC one works in full range is that they made two version of the same LUT one that works in Full Range RGB and the other that works in Limited TV Range RGB.
I've been encoding plenty of movies this way and never had any problems as they all passed QC before going on air, so no worries, I know what I'm doing ehehehehehe
Besides, this is the main reason why I've been using avsresize in all my workflows here at work.

[ErazorTT]

Originally Posted by FranceBB

that particular LUT is Narrow Range in - Narrow Range Out

ok that's the answer. So in contrast to the lut generator these are for the narrow range. I wasn't aware of that.

[SeeMoreDigital]

Originally Posted by FranceBB

Color Saturation Steps Warner Bros approved LUT 4000 nits encode: https://we.tl/t-JezXgoCRzm

Grey Steps All Warner Bros approved LUT 4000 nits encode: https://we.tl/t-QZ5iX3gvOI

Newbie question...

Is there any particular reason why these samples have been encoded in 10-bit AVC instead of 10-bit HEVC?

There's very little hardware SoC playback support for 10-bit AVC.


Cheers

[wswartzendruber]

Is anyone using SoC devices to compare these clips?

[SeeMoreDigital]

Originally Posted by wswartzendruber

Is anyone using SoC devices to compare these clips?

The media players on loads of 'smart' televisions support HLG HDR encoded using HEVC in either .mkv, .mp4 or .m2ts...

[ErazorTT]

I wasn't even aware that these were AVC's that FranceBB was sharing. I would think that for actual encoding HEVC would be his prefered format as well, but here we're just sharing test clips for quick assessment.

Me at least, I'm encoding anyhting 8bits in AVC and anything 10bits in HEVC.

[FranceBB]

Originally Posted by SeeMoreDigital

Newbie question...

Is there any particular reason why these samples have been encoded in 10-bit AVC instead of 10-bit HEVC?

There's very little hardware SoC playback support for 10-bit AVC.

Every file I encode is not intended for consumers SoC but for professional SoC.

What professional SoC like Versio want is an XAVC Intra Class 300 with PCM audio muxed in MXF.

In a nutshell, it's a file in which all frames are intra and their weight is exactly the same, it's level 5.2, 4:2:2, 10bit H.264.





Just FYI if you're a consumer, those kind of files are the ones which are re-encoded live in H.265 4:2:0 25Mbit/s 10bit with AC3 audio, muxed in .TS

[SeeMoreDigital]

Originally Posted by FranceBB

Every file I encode is not intended for consumers SoC but for professional SoC.

What professional SoC like Versio want is an XAVC Intra Class 300 with PCM audio muxed in MXF.

I don't think the 'professional' end of the market was the spec wswartzendruber was originally aiming for...

[wswartzendruber]

Originally Posted by SeeMoreDigital

I don't think the 'professional' end of the market was the spec wswartzendruber was originally aiming for...

They're just expendable test clips that show us output signal level for a given signal input and LUT transform. They're not at all intended for end user viewing.

My personal HLG library is encoded as 10-bit HEVC.

What these test clips are encoded as is irrelevent so long as they convey the information correctly and thread participants can see them. These aren't meant for viewing, but for study with dedicated equipment.