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 > Capturing and Editing Video > VapourSynth

Reply
 
Thread Tools Search this Thread Display Modes
Old 5th January 2018, 05:47   #21  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
@ifb: Thanks for that!
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 19th January 2018, 21:38   #22  |  Link
melp
Registered User
 
Join Date: Dec 2017
Posts: 8
Is HLG-based content easier to tone-map? It's built to be compatible with SDR displays, which makes me think tone-mapping it would be trivial and yield higher-quality results. If this is the case, PQ-based HDR content can be transcoded to HLG for higher-quality tone-mapping.
melp is offline   Reply With Quote
Old 20th January 2018, 13:27   #23  |  Link
Gser
Registered User
 
Join Date: Apr 2008
Posts: 418
Quote:
Originally Posted by melp View Post
Is HLG-based content easier to tone-map? It's built to be compatible with SDR displays, which makes me think tone-mapping it would be trivial and yield higher-quality results. If this is the case, PQ-based HDR content can be transcoded to HLG for higher-quality tone-mapping.
The only reason tone mapping is done is to make HDR footage look "normal" on SDR screens, we can't make SDR screens show any more than what the technology is limited to. HLG content is designed to look normal on both types of screens already hence tone mapping it would be pointless.

On a side note HLG technology is really limited, it only shows more detail in highlights. You might not even notice you are looking at HLG footage. I tried some demo HLG footage on my tv and I wasn't really convinced of its benefits. The real benefit of next generation tv is the use of HEVC, only progressive video and higher framerates. I've seen trial broadcasts and it looks amazing.
Gser is offline   Reply With Quote
Old 20th January 2018, 15:56   #24  |  Link
ifb
Registered User
 
Join Date: Dec 2009
Posts: 72
Quote:
Originally Posted by Gser View Post
HLG content is designed to look normal on both types of screens already hence tone mapping it would be pointless.
HLG certainly does not look "normal" on a reference monitor in SDR mode (BVM-X300). You can however crank the brightness and contrast and get an acceptable picture. That's what the "backwards-compatibility" of HLG gets you. That is not the case with S-Log3 and PQ.

Now, once you add 2020 to the mix, the backwards compatibility claims gets a little more dubious. 2020 on a 709 monitor is quite desaturated.

And HLG certainly will blow out an SDR display when you push the iris. It's HDR. You still need to do some sort of knee/tonemapping/clipping to convert to SDR.

Whether HLG or PQ is easier to convert to SDR, I guess it's about the same. The problem is fundamentally the same in both cases (squeezing HDR into SDR).
ifb is offline   Reply With Quote
Old 20th January 2018, 17:58   #25  |  Link
melp
Registered User
 
Join Date: Dec 2017
Posts: 8
Good info, thanks. It sounds like the methods in the OP and other posts on page 1 produce a better picture than just playing HLG on an SDR display.
melp is offline   Reply With Quote
Old 20th January 2018, 18:27   #26  |  Link
Gser
Registered User
 
Join Date: Apr 2008
Posts: 418
Quote:
Originally Posted by ifb View Post
HLG certainly does not look "normal" on a reference monitor in SDR mode (BVM-X300). You can however crank the brightness and contrast and get an acceptable picture. That's what the "backwards-compatibility" of HLG gets you. That is not the case with S-Log3 and PQ.

Now, once you add 2020 to the mix, the backwards compatibility claims gets a little more dubious. 2020 on a 709 monitor is quite desaturated.

And HLG certainly will blow out an SDR display when you push the iris. It's HDR. You still need to do some sort of knee/tonemapping/clipping to convert to SDR.

Whether HLG or PQ is easier to convert to SDR, I guess it's about the same. The problem is fundamentally the same in both cases (squeezing HDR into SDR).
Actually HLG is supported in Rec. 2100, not 2020 and definitely not 709. A simple clipping of highlights is enough to produce a usable picture if not a perfect one but for millionaires with access to reference monitors like yourself BBC licenses 3D LUTs http://downloads.bbc.co.uk/rd/pubs/p...censing_v2.pdf

One of the reasons why HLG was selected was because of its unreliance on meta-data supposedly, but the more I read the more bullshit I see spread across my screen. HLG makes so many compromises that it's not good for anything. I have a feeling PQ will become more popular if broadcasters have any sense left in them. For example the amount of meta data used in HDR10 is tiny and could be broadcasted for example once per second. It could be left up to the device manufacturer to decide whether to show an incorrect picture for the remainder of that second or to wait for the HDR meta data and in case of a mid broadcast dropout to use the previous meta data until new meta data has been received.

Last edited by Gser; 20th January 2018 at 18:46.
Gser is offline   Reply With Quote
Old 22nd January 2018, 01:21   #27  |  Link
melp
Registered User
 
Join Date: Dec 2017
Posts: 8
Quote:
Originally Posted by Gser View Post
Actually HLG is supported in Rec. 2100, not 2020 and definitely not 709. A simple clipping of highlights is enough to produce a usable picture if not a perfect one but for millionaires with access to reference monitors like yourself BBC licenses 3D LUTs http://downloads.bbc.co.uk/rd/pubs/p...censing_v2.pdf

One of the reasons why HLG was selected was because of its unreliance on meta-data supposedly, but the more I read the more bullshit I see spread across my screen. HLG makes so many compromises that it's not good for anything. I have a feeling PQ will become more popular if broadcasters have any sense left in them. For example the amount of meta data used in HDR10 is tiny and could be broadcasted for example once per second. It could be left up to the device manufacturer to decide whether to show an incorrect picture for the remainder of that second or to wait for the HDR meta data and in case of a mid broadcast dropout to use the previous meta data until new meta data has been received.
I don't believe the motivating factor for broadcasters in deciding between PQ and HLG is bandwidth-related (i.e., can we squeeze one frame per second with HDR metadata into our stream?), but rather it's driven by a desire for backwards compatibility with older set-top boxes and displays.
melp is offline   Reply With Quote
Old 22nd January 2018, 17:18   #28  |  Link
age
Registered User
 
Join Date: Oct 2015
Posts: 54
I've recently done a new script based always on the hale tone mapping , it works mainly in linear rgb with bt2020 primaries and the luma channel, it has an option for the desaturation of the super bright colors and for linearize the first part of the tonemapper curve.


There's only few parameters:
source_peak = max brightness expressed in nits
desat = how much desaturate the bright regions, it goes from 0 to 100, with 0 there isn't any desaturation and with 100 it desaturate totally the bright colors, default is 50
lin= True or False, with True it linearize the first part of the curve
show_satmask=True or False, with true it show the mask used for the reduction of the saturation
show_clipped=True or False, show the image with clipped highlights

hable only in rgb
(sorry for the horrible compression)

new script

show_satmask=True

show_clipped=True





HLG with rec709 primaries

HLG tonemapped



example of usage with HLG content(convert always to linear with 2020 primaries)
Code:
import vapoursynth as vs
import tmap

core = vs.get_core()
c = core.ffms2.Source(source  = 'C:/..../TravelXP 4K HDR HLG Demo.ts')

c=core.resize.Bicubic(clip=c, format=vs.RGBS,filter_param_a=0.0,filter_param_b=0.75, range_in_s="limited", matrix_in_s="2020ncl", primaries_in_s="2020", primaries_s="2020", transfer_in_s="std-b67", transfer_s="linear",dither_type="none", nominal_luminance=1000)

c=tmap.tm(c,source_peak=1000,desat=50,show_satmask=False,lin=True,show_clipped=False)

c=core.resize.Bicubic(clip=c, format=vs.YUV422P10, filter_param_a=0.0, filter_param_b=0.75, matrix_s="709", primaries_in_s="2020", primaries_s="709", transfer_in_s="linear", transfer_s="709",dither_type="none")


c.set_output()

I don't have tested it much but I think sometimes it gives acceptable results :-)
Here's the script
Attached Files
File Type: zip tmap.zip (1.2 KB, 217 views)
age is offline   Reply With Quote
Old 24th January 2018, 14:06   #29  |  Link
MonoS
Registered User
 
Join Date: Aug 2012
Posts: 203
Hi age, you provided an example to convert an hlg source, what if i want to tonemap a standard hdr bt2020 to bt709 sdr result?
Also, what is the rationale with using the lin parameter?

If i need to downscale the tonemapped clip in linear light can i just do it before the second resize call or do i need some other steps?
MonoS is offline   Reply With Quote
Old 24th January 2018, 19:14   #30  |  Link
age
Registered User
 
Join Date: Oct 2015
Posts: 54
With frameprops and clipinfo you should get all the needed metadata

Code:
import vapoursynth as vs
import tmap

core = vs.get_core()

c = core.ffms2.Source(source  = 'C:/../Videos/test.mkv')

#c=core.text.FrameProps(c)
#c=core.text.ClipInfo(c)
c=core.resize.Bicubic(clip=c, format=vs.RGBS,filter_param_a=0.0,filter_param_b=0.75, range_in_s="limited", matrix_in_s="2020ncl", primaries_in_s="2020", primaries_s="2020", transfer_in_s="st2084", transfer_s="linear",dither_type="none", nominal_luminance=1000)

c=tmap.tm(c,source_peak=1000,desat=50,show_satmask=False,lin=True,show_clipped=False)

c=core.resize.Bicubic(clip=c, format=vs.YUV420P8, filter_param_a=0.0, filter_param_b=0.75, matrix_s="709", primaries_in_s="2020", primaries_s="709", transfer_in_s="linear", transfer_s="709",dither_type="ordered")


c.set_output()

The original tonemapper curve is s-shaped, with lin=true the first part of the curve is linear.
It's a bit more contrasted in the shadows
age is offline   Reply With Quote
Old 24th January 2018, 19:24   #31  |  Link
age
Registered User
 
Join Date: Oct 2015
Posts: 54
Quote:
Originally Posted by MonoS View Post
If i need to downscale the tonemapped clip in linear light can i just do it before the second resize call or do i need some other steps?
Yes, you can do it before the second resize call
age is offline   Reply With Quote
Old 24th January 2018, 20:04   #32  |  Link
ZMachine95
Registered User
 
Join Date: Feb 2015
Posts: 6
Hi, I would like to download your attachment (here), but it says "Attachments Pending Approval". Can you please provide another link or just tell the staff to approve it? Wonderful job by the way!
ZMachine95 is offline   Reply With Quote
Old 24th January 2018, 20:37   #33  |  Link
age
Registered User
 
Join Date: Oct 2015
Posts: 54
Quote:
Originally Posted by ZMachine95 View Post
Hi, I would like to download your attachment (here), but it says "Attachments Pending Approval". Can you please provide another link or just tell the staff to approve it? Wonderful job by the way!
Thanks!!
Here it is
https://filebin.net/uvi8bgwe76hmc5ft
Edit V2
https://filebin.net/qkzfw0kssfxfipst

Last edited by age; 25th January 2018 at 18:25.
age is offline   Reply With Quote
Old 24th January 2018, 23:04   #34  |  Link
MonoS
Registered User
 
Join Date: Aug 2012
Posts: 203
Thank you for your response, i'm trying the script right now and i have a question about the source_peak parameter.
When i examine the original file with mediainfo it reports me two value for the source peak
Code:
Mastering display luminance              : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
Maximum Content Light Level              : 500 cd/m2
Which of the two should i use? If i understood correctly i should use the MCLL parameter, am i right?
Also does the source_peak and nominal_luminance needs to be the same?

Sorry for the amount of question but i fucked up quite a lot of time all those colors conversion
MonoS is offline   Reply With Quote
Old 25th January 2018, 04:35   #35  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Here's how I understood it so far:

1. Luminance
Code:
Mastering display luminance              : min: 0.0001 cd/m2, max: 1000.0000 cd/m2
translates to:
Code:
L(max/0.0001,min/0.0001)=L(1000000/1)
2. Color Primaries
Code:
Mastering display color primaries        : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
translates to:
Code:
G(Gx/0.00002,Gy/0.00002)B(Bx/0.00002,By/0.00002)R(R/0.00002x,Ry/0.00002)WP(Wx/0.00002,Wy/0.00002)=G(13250,34499)B(7499,2999)R(34000,15999)WP(15634,16450)
ColorPrimaries and Luminance combined give:
Code:
G(13250,34499)B(7499,2999)R(34000,15999)WP(15634,16450)L(10000000,1)
which you set under "--master-display"

3. Max CLL
Code:
Maximum Content Light Level              : 1000 cd/m2
Maximum Frame-Average Light Level        : 400 cd/m2
translates to:
Code:
--max-cll "1000,400"
Cu Selur

Ps.: Does someone know how to translate:
Code:
Transfer characteristics                 : PQ
to x265? My problem is that x265 --transfer doesn't have 'PQ'.
__________________
Hybrid here in the forum, homepage

Last edited by Selur; 25th January 2018 at 05:04.
Selur is offline   Reply With Quote
Old 25th January 2018, 11:00   #36  |  Link
age
Registered User
 
Join Date: Oct 2015
Posts: 54
Quote:
Originally Posted by MonoS View Post
Thank you for your response, i'm trying the script right now and i have a question about the source_peak parameter.
When i examine the original file with mediainfo it reports me two value for the source peak
Code:
Mastering display luminance              : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
Maximum Content Light Level              : 500 cd/m2
Which of the two should i use? If i understood correctly i should use the MCLL parameter, am i right?
Also does the source_peak and nominal_luminance needs to be the same?

Sorry for the amount of question but i fucked up quite a lot of time all those colors conversion

Both source_peak and nominal_luminance have the same value
yes, it's the Maximum Content Light Level
age is offline   Reply With Quote
Old 25th January 2018, 11:11   #37  |  Link
age
Registered User
 
Join Date: Oct 2015
Posts: 54
Quote:
Originally Posted by Selur View Post
Ps.: Does someone know how to translate:
Code:
Transfer characteristics                 : PQ
to x265? My problem is that x265 --transfer doesn't have 'PQ'.
smpte2084 in x265=st2084 in vapoursynth resize=pq
age is offline   Reply With Quote
Old 25th January 2018, 11:19   #38  |  Link
ZMachine95
Registered User
 
Join Date: Feb 2015
Posts: 6
Quote:
Originally Posted by age View Post
Great!
ZMachine95 is offline   Reply With Quote
Old 25th January 2018, 15:59   #39  |  Link
age
Registered User
 
Join Date: Oct 2015
Posts: 54
v2 with hopefully (slighty) better general saturation

https://filebin.net/qkzfw0kssfxfipst

Same usage as before
age is offline   Reply With Quote
Old 25th January 2018, 16:33   #40  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
@age or also someone else...
Interesting, but as i'm not used to all this expressions syntax.
Is it possible to have the mathematical formulas (even is there is several steps) ?

Could be something like this :
[Y0 U0 V0] direct ffxxx or anything HDR output.
R= fr(Y0,U0,V0) Give fr formula
G=Fg(Y0,U0,V0) etc...

R1=f1(R) Give f1 mathematical formula with "A","B","C","exposure_bias", etc...
R2=f2(R1) etc...

Y1=fy(Rn,Gn,Bn) Give fy formula.
Etc...

So, if this could be possible, it would be a great help.
jpsdr is offline   Reply With Quote
Reply

Tags
hdr, sdr

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 15:39.


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