FranceBB LUT Collection

[FranceBB]

Originally Posted by asarian

MediaInfo says 'Color prmaries BT.2020' on output.

But that may be because of setting (mandatory) 'matrix' in core.resize.Spline64

Yes, that's exactly right, it is because you're setting the right matrix on the RGB to YUV conversion which isn't optional in VapourSynth. That will also set the frame properties.

Originally Posted by asarian

I can't really tell what comes out of the BT709_to_HLG line (though it should be BT.2020).

It is absolutely and positively BT2020 in terms of the mapped points in the output after the transformation, but in terms of frame properties the answer is: nothing. The frame properties values are just not set in the RGB roundtrip.
The "good news" however is that VapourSynth - unlike Avisynth - expects the user to set them in the function so that they can also be set in the frame properties.
This means that up until this point as long as you set them correctly in the YUV->RGB->YUV roundtrip, then you're good to go.

Originally Posted by asarian

So, should I change something?

Nope, you're doing everything right already, the "issue" is limited to Avisynth in which we have to use PropSet().
In general, we can use this rule of thumb after going back to YUV.

For BT601 PAL outputs:

propSet("_ColorRange", 1) #Limited TV Range
propSet("_Matrix", 5) #BT601 PAL
propSet("_Transfer", 6) #BT601 PAL
propSet("_Primaries", 5) #BT601 PAL

For BT601 NTSC outputs:

propSet("_ColorRange", 1) #Limited TV Range
propSet("_Matrix", 6) #BT601 NTSC
propSet("_Transfer", 6) #BT601 NTSC
propSet("_Primaries", 6) #BT601 NTSC

For BT709 outputs:

propSet("_ColorRange", 1) #Limited TV Range
propSet("_Matrix", 1) #BT709
propSet("_Transfer", 1) #BT709
propSet("_Primaries", 1) #BT709

For BT2020 outputs:

propSet("_ColorRange", 1) #Limited TV Range
propSet("_Matrix", 9) #BT2020
propSet("_Transfer", 14) #BT2020
propSet("_Primaries", 9) #BT2020

For BT2020 HLG outputs:

propSet("_ColorRange", 1) #Limited TV Range
propSet("_Matrix", 9) #BT2020
propSet("_Transfer", 18) #HLG
propSet("_Primaries", 9) #BT2020

For BT2020 PQ outputs:

propSet("_ColorRange", 1) #Limited TV Range
propSet("_Matrix", 9) #BT2020
propSet("_Transfer", 16) #PQ
propSet("_Primaries", 9) #BT2020

For DCI P3 outputs:

propSet("_ColorRange", 1) #Limited TV Range
propSet("_Matrix", 2)
propSet("_Transfer", 17) #DCI P3
propSet("_Primaries", 11) #DCI P3

Tested and working as expected in AVSPmod mod:

Originally Posted by VoodooFX

Maybe you would want to add LUts for videos from DJI drones?

Yeah, that's actually something I wanted to do for quite some time now. I did actually make a first implementation of D-Log to BT709, however I didn't particularly like the results that came out of it. On that note, most of the log conversions I made were targeting BT709, however nowadays log is mostly used to produce BT2020 HLG outputs, at least internally, so I should really start updating those. Anyway, I have a few samples of D-Log footage, so perhaps if I get enough samples of D-Log M footage as well I can make both D-Log to BT709 and D-Log M to BT709.

Hopefully come next year I'll have a bit more time to make things like Slog3 to HLG and to PQ which is kinda important right now as more and more productions shot in Slog3 are then graded and converted in either HLG or PQ for the final release (in our case, it's always HLG but we're a broadcasting company, so we're biased).

[asarian]

Originally Posted by FranceBB

Nope, you're doing everything right already, the "issue" is limited to Avisynth in which we have to use PropSet().
In general, we can use this rule of thumb after going back to YUV.

I cannot thank you enough for your, once again, very extensive and helpful post!

[FranceBB]

Linear Transformation v2.7 Released!

Changelog:

- Added Frame Properties support for Primaries
- BT601 transfer frame properties are now correctly signaled as smpte170m
- Introduced correct signalling of smpte432 primaries and smpte428 transfer for the DCI P3 XYZ Gamma 2.6 conversion

Merry Christmas!

[FranceBB]

In the next release we're gonna have two new conversions that are gonna be added:

- BT2020 SDR to BT709 SDR
- BT709 SDR to BT2020 SDR

Let's start from the first one and let's start by saying that other people have been working on this before me, in fact William (the creator and maintainer of HLG Tools) released a version based on Oklab here: Link. There's absolutely nothing wrong with his LUTs and you can go ahead and use them. What I'm doing is something much more simplistic, in fact the BT2020 SDR to BT709 SDR conversion is actually based on the most simple calculation illustrated in the ITU recommendation 2407.

The conversion is performed as follows:

[0.4124  0.3576  0.1805]^-1     [0.6370  0.1446 0.1689]
[0.2126  0.7152  0.0722]        [0.2627  0.6780  0.0593] =
[0.0193  0.1192  0.9505]        [0.0000  0.0281  1.0610]

Let's take the matrix for which we have to calculate the inverse and let's create the augmented matrix

[0.4124  0.3576  0.1805   1.0000   0.0000  0.0000]
[0.2126  0.7152  0.0722   0.0000   1.0000  0.0000]
[0.0193  0.1192  0.9505   0.0000   0.0000  1.0000]

Now that we have the identity matrix on the right, we have to perform the operations to "bring it to the left" so that what we're gonna be left with is gonna be the inverse.

We make the pivot in the 1° column by dividing the first row by 0.4124

[1.0000  0.8671  0.4376  2.4248  0.0000  0.0000]
[0.2126  0.7152  0.0722  0.0000  1.0000  0.0000]
[0.0193  0.1192  0.9505  0.0000  0.0000  1.0000]

we can eliminate the first column

[1.0000  0.8671  0.4376  2.4248  0.0000  0.0000]
[0.0000  0.5308 -0.0208 -0.5155 1.0000  0.0000]
[0.0000  0.1024  0.9420 -0.0467  0.0000  1.0000]

we can make the pivot in the 2° column by dividing the second row by 0.5308

[1.0000  0.8671  0.4376  2.4248  0.0000  0.0000]
[0.0000  1.0000 -0.0392 -0.9711 1.8837  0.0000]
[0.0000  0.1024  0.9420 -0.0467  0.0000  1.0000]

we can eliminate the second column:

[1.0000  0.0000  0.4717  3.2669  -1.6334  0.0000]
[0.0000  1.0000 -0.0392 -0.9711   1.8837  0.0000]
[0.0000  0.0000  0.9460  0.0527  -0.1930  1.0000]

at this point, we're almost there, we make the pivot in the 3° column by dividing the third row by 0.9460

[1.0000  0.0000  0.4717  3.2669 -1.6334  0.0000]
[0.0000  1.0000 -0.0392 -0.9711  1.8837  0.0000]
[0.0000  0.0000  1.0000  0.0557 -0.2040  1.0569]

we can therefore eliminate third column and we're gonna be left with the inverse matrix on the right as we brought the identity to the left:

[1.0000  0.0000  0.0000  3.2408  -1.5372  -0.4986]
[0.0000  1.0000  0.0000 -0.9689  1.8757    0.0415]
[0.0000  0.0000  1.0000  0.0557 -0.2040    1.0569]

so the inverse is:

[3.2408  -1.5372  -0.4986]
[-0.9689  1.8757    0.0415]
[0.0557 -0.2040    1.0569]

we still have to multiply it with the other matrix, though:

[3.2408  -1.5372  -0.4986]   [0.6370  0.1446  0.1689]
[-0.9689  1.8757   0.0415]   [0.2627  0.6780  0.0593] =
[0.0557 -0.2040    1.0569]   [0.0000  0.0281  1.0610]

we can label the output as:

[A     B      C]
[D     E      F]
[G     H      I]

and they're calculated as:

A= 3.2408 x 0.637 + (-1.5372) x 0.2627 + (-0.4986) x 0 = 1.6605

B= 3.2408 x 0.1446 + (-1.5372) x 0.678 + (-0.4986) x 0.0281 = -0.5876

C= 3.2408 x 0.1689 + (-1.5372) x 0.0593 + (-0.4986) x 1.061 = -0.0727

D= -0.9689 x 0.637 + 1.8757 x 0.2627 + 0.0415 x 0 = -0.1244

E= -0.9689 x 0.1446 + 1.8757 x 0.678 + 0.0415 x 0.0281 = 1.1327

F= -0.9689 x 0.1689 + 1.8757 x 0.0593 + 0.0415 x 1.061 = -0.0083

G= 0.0557 x 0.637 + (-0.204) x 0.2627 + 1.0569 x 0 = -0.0181

H= 0.0557 x 0.1446 + (-0.204) x 0.678 + 1.0569 x 0.0281 = -0.1005

I= 0.0557 x 0.1689 + (-0.204) x 0.0593 + 1.0569 x 1.061 = 1.1186

so our final matrix is:

[ 1.6605 -0.5876 -0.0727]
[-0.1244  1.1327 -0.0083]
[-0.0181 -0.1005  1.1186]

Let's put this theory to the test and compare it against HDRTools:

test1=LWLibavVideoSource("Source1.mxf")
test2=LWLibavVideoSource("Source2.mxf")
test3=LWLibavVideoSource("Source3.mxf")
test4=LWLibavVideoSource("Source4.mxf")

test1++test2++test3++test4

propClearAll()

ConvertBits(16)
bt2020=Subtitle("BT2020 SDR")
bt2020_sdr=last

ConvertToPlanarRGB(bt2020_sdr)
Cube("A:\Ingest\MEDIA\temp\BT2020_to_BT709.cube", interp=1, fullrange=1)
ConverttoYUV444(matrix="Rec709")
Subtitle("BT709 SDR LUT")
bt709_cube=last

ConvertYUVtoXYZ(bt2020_sdr, Color=1)
ConvertXYZtoYUV(pColor=1)
Subtitle("BT709 SDR HDRTools")
bt709_hdrtools=last

StackHorizontal(bt2020, bt709_cube, bt709_hdrtools)

Looks fine.
To spot the actual differences between this method and the XYZ roundtrip made by HDRTools we have to check solid colors like in those commercials in which the clipping of values outside the BT709 realm done by the LUT becomes very apparent:




The difference is pretty clear and it can be seen in both the Colgate and EE backgrounds, with HDRTools actually performing a much better approximation, while the LUT is clipping several values out as it's a simple onto conversion (as every element in the range has at least one corresponding element in the domain) but clearly not one to one (because more elements map to the same destinations). This is also due to the normalizations of value above 1 and below 0. Speaking of values below 0, inside the LUT you're gonna be able to see a bunch of zeroes, that's to avoid issues with non legal values, in fact everything negative has been normalized to 0 to avoid a repetition of frank's issue and more specifically the lut3d implementation.

When we test with real life examples, however, the difference becomes much more slim:









For those who wanna start testing:

BT2020_to_BT709.cube

[wswartzendruber]

Regarding my BT.2020-to-BT.709 conversion LUT he mentioned, I have a new one I just generated:

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

It should be very similar, but the math is a little tighter. It still uses Oklab/Oklch, so it's as perceptually accurate as that is.

EDIT: I mainly use it for viewing HLG on BT.709 SDR. I may as well include screenshots and peddle my wares!

[wswartzendruber]

And now I learn that Google has a colorspace called HCT which is supposed to be even better than Oklab. It's based on CAM16, though, so it may be a bit of a doozie to compute.

[FranceBB]

It feels like a good time to make a release, so... here we are.

Linear Transformation v2.8 Released!

Changelog:

- Implemented a new BT2020 SDR to BT709 SDR conversion.
- Implemented a new BT709 SDR to BT2020 SDR conversion.

To apply those, simply use:

LinearTransformation(Input="Linear_BT2020", Output="Linear_BT709", Interpolation="Tetrahedral")

and

LinearTransformation(Input="Linear_BT709", Output="Linear_BT2020", Interpolation="Tetrahedral")

Or just apply the individual LUTs as always.
The roundtrip was also tested and it should work.

Oh and before anyone says anything, yes, I did actually check to make sure we're populating frame properties correctly eheheheh

LWLibavVideoSource("test.mxf")

LinearTransformation(Input="Linear_BT2020", Output="Linear_BT709", Interpolation="Tetrahedral"))

(and I've just realized that I screwed up the screenshot but whatever).

[FranceBB]

wh0phd pointed out some less than optimal results when performing the conversions to and from BT601 (both PAL and NTSC). Being little used nowadays, the original conversions from 4 years ago didn't quite achieve the expected results, especially for the conversions to and from BT2020 as well as the HLG (arib-std-b67) and PQ (smpte2084) conversions. A review of those was long overdue and as I'm trying to tidy things up I decided to finally spend time on those.

I recreated the matrices by inserting the BT601 PAL, BT601 NTSC, BT709 and BT2020 SDR primaries:






The white point stays the same for all of them, so BT601 PAL and BT601 NTSC as well as BT709 and BT2020 SDR, namely
x white = 0.3127
y white = 0.3290

The values for red, green and blue however change.

BT601 PAL has
x red = 0.640
y red = 0.330
x green = 0.290
y green = 0.600
x blue = 0.150
y blue = 0.060

BT601 NTSC has
x red = 0.630
y red = 0.340
x green = 0.310
y green = 0.595
x blue = 0.155
y blue = 0.070

BT709 has
x red = 0.640
y red = 0.330
x green = 0.300
y green = 0.600
x blue = 0.150
y blue = 0.060

BT2020 has
x red = 0.708
y red = 0.292
x green = 0.170
y green = 0.797
x blue = 0.131
y blue = 0.046


The idea here is to repurpose the BT709 conversions that have been created a long time ago and that have been tested over and over again by the community to produce the BT601 ones by just changing the primaries. Let's take for instance the old BT2020 HLG to BT601 PAL conversion: it was remapping the 75% reference white in the luma to 100% and clipping the rest. As to the chroma, it was converting the primaries from the BT2020 ones to the BT601 PAL ones. Now, this is NOT what we're doing in the BT2020 HLG to BT709 SDR conversion as we're keeping the luma in place and only converting the primaries (which is the whole purpose behind HLG given that it would be what a user would see if he bought a BT2020 UHD TV that can't interpret the transfer). So, in the new BT2020 HLG to BT601 PAL conversion we're using the same logic as the BT2020 HLG to BT709 SDR conversion, namely keeping the luma in place and converting the primaries.

This is the old BT2020 HLG to BT601 PAL conversion:


and this is the new one:


Using the same logic, I could now fill the gap and add the missing BT601 conversions for Slog3, Vlog, LogC and Clog3 as well.

LWLibavVideoSource("C9128.MP4")

ConvertBits(16)
ConvertToPlanarRGB()
Cube("A:\MEDIA\temp\Slog3_to_BT601_PAL", interp=1, fullrange=1)
ConverttoYUV444(matrix="Rec601")

VideoTek()

LWLibavVideoSource("A002C001_200527_RNMK.mxf")

ConvertBits(16)
ConvertToPlanarRGB()
Cube("A:\MEDIA\temp\LogC_to_BT601_PAL.cube", interp=1, fullrange=1)
ConverttoYUV444(matrix="Rec601")

VideoTek()

LWLibavVideoSource("A006C002_191214R7_CANON.MXF")

ConvertBits(16)
ConvertToPlanarRGB()
Cube("A:\MEDIA\temp\Clog3_to_BT601_PAL.cube", interp=1, fullrange=1)
ConverttoYUV444(matrix="Rec601")

VideoTek()

I also fixed an issue in the old BT601 NTSC to BT601 PAL conversion as well as BT601 PAL to BT601 NTSC. Both LUTs have been regenerated using CIECAT02 instead of the Bradford Chromatic Adaptation. Taking z_ConvertFormat() as a safe reference point (i.e avsresize), I started testing the two conversions.

#BT601 PAL to BT601 NTSC
ColorBars(848, 480, pixel_type="YUV444P16")

SinPowerResize(848, 480)
bt601_pal=z_ConvertFormat(colorspace_op="709:709:709=>470bg:601:470bg", resample_filter_uv="spline64", dither_type="error_diffusion")
bt601_ntsc=z_ConvertFormat(colorspace_op="709:709:709=>170m:240m:240m", resample_filter_uv="spline64", dither_type="error_diffusion")

ConvertBits(bt601_pal, 16)
ConvertToPlanarRGB()
Cube("A:\MEDIA\temp\BT601_PAL_to_BT601_NTSC.cube", interp=1, fullrange=1)
ConverttoYUV444(matrix="Rec601")
Histogram("color2")
ntsc_cube=last

ConvertBits(bt601_pal, 16)
z_ConvertFormat(colorspace_op="470bg:601:470bg=>170m:240m:240m", resample_filter_uv="spline64", dither_type="error_diffusion")
ConverttoYUV444(matrix="Rec601")
Histogram("color2")
ntsc_avsresize=last


StackVertical(ntsc_cube, ntsc_avsresize)

and the other way round as well

#BT601 NTSC to BT601 PAL
ColorBars(848, 480, pixel_type="YUV444P16")

SinPowerResize(848, 480)
bt601_pal=z_ConvertFormat(colorspace_op="709:709:709=>470bg:601:470bg", resample_filter_uv="spline64", dither_type="error_diffusion")
bt601_ntsc=z_ConvertFormat(colorspace_op="709:709:709=>170m:240m:240m", resample_filter_uv="spline64", dither_type="error_diffusion")

ConvertBits(bt601_ntsc, 16)
ConvertToPlanarRGB()
Cube("A:\MEDIA\temp\BT601_NTSC_to_BT601_PAL.cube", interp=1, fullrange=1)
ConverttoYUV444(matrix="Rec601")
Histogram("color2")
pal_cube=last

ConvertBits(bt601_ntsc, 16)
z_ConvertFormat(colorspace_op="170m:240m:240m=>470bg:601:470bg", resample_filter_uv="spline64", dither_type="error_diffusion")
ConverttoYUV444(matrix="Rec601")
Histogram("color2")
pal_avsresize=last


StackVertical(pal_cube, pal_avsresize)

You can already test the new versions on Github, but I'm planning to make a new release next week.

[FranceBB]

Linear Transformation v2.9 Released!

Changelog:

- Introduced the new conversions

#Slog3 to BT601 PAL
LinearTransformation(Input="SLog3", Output="Linear_BT601_PAL")

#Slog3 to BT601 NTSC
LinearTransformation(Input="SLog3", Output="Linear_BT601_NTSC")



#Vlog to BT601 PAL
LinearTransformation(Input="VLog", Output="Linear_BT601_PAL")

#Vlog to BT601 NTSC
LinearTransformation(Input="VLog", Output="Linear_BT601_NTSC")



#LogC to BT601 PAL
LinearTransformation(Input="LogC", Output="Linear_BT601_PAL")

#LogC to BT601 NTSC
LinearTransformation(Input="LogC", Output="Linear_BT601_NTSC")



#Clog3 to BT601 PAL
LinearTransformation(Input="CLog3", Output="Linear_BT601_PAL")

#Clog3 to BT601 NTSC
LinearTransformation(Input="CLog3", Output="Linear_BT601_NTSC")

- Improved the existing BT601 conversions (both PAL and NTSC).
- Fixed an issue in the old BT601 NTSC to BT601 PAL conversion as well as BT601 PAL to BT601 NTSC. Both have been regenerated using CIECAT02 instead of the Bradford Chromatic Adaptation.

[FranceBB]

Linear Transformation v3.0 Released!!


Changelog:

- Added new conversions between the normal BT601 NTSC SMPTE C (1987, smpte170m) and the old BT601 NTSC Japan (1953, bt470m)

#BT601 NTSC SMPTE C (1987) to BT601 NTSC Japan (1953)
LinearTransformation(Input="Linear_BT601_NTSC", Output="Linear_BT601_NTSC-J", Interpolation="Tetrahedral")

#BT601 NTSC Japan (1953) to BT601 NTSC SMPTE C (1987)
LinearTransformation(Input="Linear_BT601_NTSC-J", Output="Linear_BT601_NTSC", Interpolation="Tetrahedral")

- Primaries are now correctly updated in the Avisynth frame properties even for inputs that have an Alpha Channel

This feature was requested by ossnorry.
As a bit of history, in 1953 the NTSC version of BT601 was born, however the tube phosphors originally used by the TVs of the time had issues displaying those values and the standard was later changed (reduced) in 1987 to make life easier for the hardware of the time, however one country never stopped using the original NTSC version and that country is Japan, which is why the original NTSC version has become known as "NTSC-J" which stands for "Japan".

Anyway, the old BT601 NTSC Japan (1953) is based on the following values:

x white = 0.3100
y white = 0.3160
x red = 0.670
y red = 0.330
x green = 0.210
y green = 0.710
x blue = 0.140
y blue = 0.080

and is indicated with
--colormatrix smpte170m --transfer bt470m --colorprim bt470m

while the normal BT601 NTSC SMPTE C (1987) that all other NTSC countries adopted has the following values:

x white = 0.3127
y white = 0.3290
x red = 0.630
y red = 0.340
x green = 0.310
y green = 0.595
x blue = 0.155
y blue = 0.070

and is indicated with:
--colormatrix smpte170m --transfer smpte170m --colorprim smpte170m


As you can see, all values are different, including the white point.

All the LUTs created up until this point that referred to BT601 NTSC were targeting the normal BT601 NTSC SMPTE C (1987), namely smpte170m.

This release allows the conversion between the two BT601 NTSC standards: the old BT601 NTSC Japan (1953), namely bt470m, and the normal BT601 NTSC SMPTE C (1987), namely smpte170m.




Left is BT601 NTSC SMPTE C (1987) - Right is BT601 NTSC-Japan (1953):

[mojie126]

May I ask why there is no conversion from SDR (BT709) to Dolby Vision (DV)?

[huhn]

that's simple what even is DV?

it's just PQ bt 2020.

DV is the same as HDR10+ just encoded with licensing stuff and custom meta data representing the same stuff.

[FranceBB]

Originally Posted by huhn

it's just PQ bt 2020.

The one you're referring to is the dual layer, the most common version of Dolby Vision. You're right, in the dual layer you have the first layer as a normal H.265 3840x2160 4:2:0 HDR PQ 10bit planar track and the second layer as a fake H.265 1920x1080 4:2:0 10bit which is actually carrying metadata (it would look green if you tried to decode it on its own). Normal players ignore the second layer and just play the first one as a normal HDR10. Dolby Vision players can read the metadata track and combine it with the first to output 12bit HDR PQ with dynamically changing metadata.


Now, obviously making a LUT for such a thing wouldn't make sense, which is why I'm pretty sure that mojie126 is actually referring to dvhe0509. You see, dvhe0509 is actually a proprietary Dolby space (IPTc2) and the videos encoded with it are not supposed to be played back by normal devices. If you were to playback such a file, you would see the luma resemble a pseudo SDR curve and the chroma being with totally different values.

See here: https://forum.doom9.org/showthread.php?p=1964646

And here in this thread: https://forum.doom9.org/showthread.p...42#post1964642

Originally Posted by mojie126

May I ask why there is no conversion from SDR (BT709) to Dolby Vision (DV)?

I should actually give you a bit more context over how we made the dvhe0509 to BT709 LUT. Essentially, that dates back to February 2022 when algia (Livio Aloja, one of my colleagues, now retired) and I worked on it. Essentially, given that there was no documentation whatsoever, we couldn't really properly revert it and get an appropriate output in BT709. I mean, sure, we knew how things like the grass or the sky should roughly look like but it was really mostly guesswork and we were not really going anywhere. That changed when we got our hands on the Harmonic samples. You see, Harmonic published a few videos encoded in both dvhe0509 and BT709 so, with a lot of patience, armed with a lot of dedication and good will, we went through those one by one and we essentially mapped each and every value found in the dvhe0509 IPTc2 samples to the corresponding value in the BT709 SDR samples and from there we got the LUT. As to the luma, given that it resembled an SDR curve, we left it alone. The results were actually pretty decent even if we were ignoring the Dolby metadata alongside that.

LinearTransformation(Input="dvhe0509", Output="Linear_BT709")



Now, surely we could just reverse it so that we could potentially use the same logic to go from BT709 to a "fake" dvhe0509 IPTc2 and we could probably even get the values somewhat right but we would have no way of writing the correct metadata as we still wouldn't be able to generate the appropriate RPU. I'm pretty sure that no Dolby Vision decoder would accept a stream without the relevant metadata, so I guess we're stuck with this...

[Z2697]

The essential part is dynamic metadata and the colormatrix. (the latter is less essential)
Both are not under the charge of this LUT collection.

[Z2697]

Originally Posted by FranceBB

The one you're referring to is the dual layer, the most common version of Dolby Vision. You're right, in the dual layer you have the first layer as a normal H.265 3840x2160 4:2:0 HDR PQ 10bit planar track and the second layer as a fake H.265 1920x1080 4:2:0 10bit which is actually carrying metadata (it would look green if you tried to decode it on its own). Normal players ignore the second layer and just play the first one as a normal HDR10. Dolby Vision players can read the metadata track and combine it with the first to output 12bit HDR PQ with dynamically changing metadata.


Now, obviously making a LUT for such a thing wouldn't make sense, which is why I'm pretty sure that mojie126 is actually referring to dvhe0509. You see, dvhe0509 is actually a proprietary Dolby space (IPTc2) and the videos encoded with it are not supposed to be played back by normal devices. If you were to playback such a file, you would see the luma resemble a pseudo SDR curve and the chroma being with totally different values.

See here: https://forum.doom9.org/showthread.php?p=1964646

And here in this thread: https://forum.doom9.org/showthread.p...42#post1964642



I should actually give you a bit more context over how we made the dvhe0509 to BT709 LUT. Essentially, that dates back to February 2022 when algia (Livio Aloja, one of my colleagues, now retired) and I worked on it. Essentially, given that there was no documentation whatsoever, we couldn't really properly revert it and get an appropriate output in BT709. I mean, sure, we knew how things like the grass or the sky should roughly look like but it was really mostly guesswork and we were not really going anywhere. That changed when we got our hands on the Harmonic samples. You see, Harmonic published a few videos encoded in both dvhe0509 and BT709 so, with a lot of patience, armed with a lot of dedication and good will, we went through those one by one and we essentially mapped each and every value found in the dvhe0509 IPTc2 samples to the corresponding value in the BT709 SDR samples and from there we got the LUT. As to the luma, given that it resembled an SDR curve, we left it alone. The results were actually pretty decent even if we were ignoring the Dolby metadata alongside that.

LinearTransformation(Input="dvhe0509", Output="Linear_BT709")

Now, surely we could just reverse it so that we could potentially use the same logic to go from BT709 to a "fake" dvhe0509 IPTc2 and we could probably even get the values somewhat right but we would have no way of writing the correct metadata as we still wouldn't be able to generate the appropriate RPU. I'm pretty sure that no Dolby Vision decoder would accept a stream without the relevant metadata, so I guess we're stuck with this...

Some discs have full enhance layer and the track contain some kind of diff of I guess 12bit to the 10bit of main track.
Which probably look like some noise. The track has low bitrate still, so it will look terrible, but at least it still does something I guess...

Is that dvhe0506 conversion works as converting it to RGB using Rec.709 matrix then "correct" the wrong RGB?

[FranceBB]

Originally Posted by Z2697

Is that dvhe0506 conversion works as converting it to RGB using Rec.709 matrix then "correct" the wrong RGB?

Pretty much, yes. Far from ideal, but it gets the job done.

[huhn]

Originally Posted by FranceBB

The one you're referring to is the dual layer, the most common version of Dolby Vision. You're right, in the dual layer you have the first layer as a normal H.265 3840x2160 4:2:0 HDR PQ 10bit planar track and the second layer as a fake H.265 1920x1080 4:2:0 10bit which is actually carrying metadata (it would look green if you tried to decode it on its own). Normal players ignore the second layer and just play the first one as a normal HDR10. Dolby Vision players can read the metadata track and combine it with the first to output 12bit HDR PQ with dynamically changing metadata.

glad to say we are past that and on the fly none LUT DV to HDR10 is a pretty default feature now. pretty much LLDV or what the name was DV handling at the source. this was done with a 3D LUT ion the past

the DV encoder got bt 2020 PQ to eat and the display is presenting bt 2020 PQ at the end.
itp instead of ycbcr a meta data lever or what ever does not change that. how many types of DV are there 12?

Originally Posted by Z2697

Some discs have full enhance layer and the track contain some kind of diff of I guess 12bit to the 10bit of main track.
Which probably look like some noise. The track has low bitrate still, so it will look terrible, but at least it still does something I guess...

Is that dvhe0506 conversion works as converting it to RGB using Rec.709 matrix then "correct" the wrong RGB?

there was a DV level that had highlights encoded in a 2 bit level that is 1080p it's so insanely useless it is still 10000 nits PQ bt 2020 just in a different container and yes a DV file can look quite different from a normal HDR10+ because it was mastered differently.

[rwill]

Originally Posted by huhn

there was a DV level that had highlights encoded in a 2 bit level that is 1080p it's so insanely useless it is still 10000 nits PQ bt 2020 just in a different container and yes a DV file can look quite different from a normal HDR10+ because it was mastered differently.

So which TV's panel supports 10000nits so that you can watch that 10000 nits PQ10 without having to downmap it to the display guided by metadata?

[huhn]

Originally Posted by rwill

So which TV's panel supports 10000nits so that you can watch that 10000 nits PQ10 without having to downmap it to the display guided by metadata?

none and you don't use meta data to do so. any device is measuring peak nit by a frame by frame basin meta data is really just there.

even SDR screen are doing that for decades.