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 > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 23rd December 2019, 10:46   #121  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
In that case, i think it's with others parameters you should first play/adjust (crosstalk,whiteshift, pct values), instead of putting a parameter totaly out of range/spec, but... Afterall, if it produces results you like.

I've edited my other post.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 23rd December 2019, 10:50   #122  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Here how frame looks with value=1000


Quote:
Before adding OutputMode=2, for experiment, add Convertbits(16)
No difference. Btw. I'm using l-smash as decoder + latest avisynth+ and video is detected as YUV420p10.

UPDATE: Only outputmode=2 fixes this issue.

Last edited by Atak_Snajpera; 23rd December 2019 at 10:56.
Atak_Snajpera is offline   Reply With Quote
Old 23rd December 2019, 10:57   #123  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
If no difference, at least, it means there is "no error". I didn't expect resolution loss at 16 bits...
In that case, add OutputMode=2 to ConvertYUVtoZXY().
You shouldn't have resolution loss in that case.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 23rd December 2019, 13:49   #124  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Has anybode managed to emulate madvr look using this plugin?

sample -> https://4kmedia.org/sony-camping-in-nature-4k-demo/
No matter which method I use I get either opaque white or oversaturated 4k logo

reference from madvr


BT2446 30000 (BTW. WhiteShift does nothing)


Reinhard exposure=12


Mobius exposure=15
Atak_Snajpera is offline   Reply With Quote
Old 23rd December 2019, 15:20   #125  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Ok. Mission accomplished! I've managed to emulate madvr tonemapping almost perfectly. Logo however is still slightly oversaturated. Sky gradient is also slightly different.

Emulated using Bt2446
Code:
video=ConvertYUVtoXYZ(video,Color=0,HDRMode=0,OOTF=false,OutputMode=2,Crosstalk=0.0,threads=1)
video=ConverXYZ_BT2446_C_HDRtoSDR(video,PQMode=true,Lhdr=50000.0,Lsdr=100.0,pColor=0,pct_ref=0.6,pct_ip=0.6,pct_wp=1.0,pct_sdr_skin=1.0,pct_hdr_skin=0.44,threads=1)
video=ConvertXYZtoYUV(video,Color=2,pColor=0,OOTF=false,Crosstalk=0.0,threads=1)


MadVR



I have also noticed that emulated method gives more realistic sky color than madvr's tonemapping
emulated


Madvr

Last edited by Atak_Snajpera; 23rd December 2019 at 15:42.
Atak_Snajpera is offline   Reply With Quote
Old 29th December 2019, 01:21   #126  |  Link
r4dius
Registered User
 
Join Date: Mar 2013
Posts: 6
Hi, I've looking for ways to get hdr to sdr done right but still can't find how .. I'd like to get the hdr converted footage to match the existing sdr version but there's always a mismatch,
when bright colors look ok then dark stuff looks way darker and vice versa, madvr and mpv tonemapping look good but there's no method to export their tonemapped output as I understand it,
the only way I found is to exporting frame by frame (with command line options) with mpv but this thing will take ages, so I was wandering would there be a way to use the hdrtools tools to match the mpv output ?
I mean a reproducible way that would always produce the same result (or close to it) as mpv ?
r4dius is offline   Reply With Quote
Old 29th December 2019, 01:39   #127  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by r4dius View Post
Hi, I've looking for ways to get hdr to sdr done right but still can't find how .. I'd like to get the hdr converted footage to match the existing sdr version but there's always a mismatch
Of course there is! Movies are shot in log and then graded from the raw masterfile to either SDR BT709 or HDR PQ BT2100, so there's always going to be a mismatch as you will be starting from the graded HDR version whereas the SDR bluray disk were made from the original log footage. Anyway, with HDRTools you can use tonemapping algorithms which can give you pretty good results. The one that has always been working for me as a good compromise is Reinhard so you may wanna check it out from my previous posts.
Also please read the documentation and the PDF wrote by Jean-Philippe included in the plugin download which are gonna explain how this plugin works and what it does.




Totally unrelated:

Question for Jean-Philippe: is it different from the last build you sent me via email? 'cause if it isn't, I'm gonna share the images of the last test results, otherwise I'm gonna repeat those tests.
FranceBB is offline   Reply With Quote
Old 29th December 2019, 12:32   #128  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
The difference is the implementation of the whiteshift, which wasn't in the version i've send you for pre-test. So, it's different in this way, but, in what was allready implemented, as far i remember there is no change.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 30th December 2019, 02:02   #129  |  Link
r4dius
Registered User
 
Join Date: Mar 2013
Posts: 6
Quote:
Originally Posted by FranceBB View Post
Of course there is! Movies are shot in log and then graded from the raw masterfile to either SDR BT709 or HDR PQ BT2100, so there's always going to be a mismatch as you will be starting from the graded HDR version whereas the SDR bluray disk were made from the original log footage. Anyway, with HDRTools you can use tonemapping algorithms which can give you pretty good results. The one that has always been working for me as a good compromise is Reinhard so you may wanna check it out from my previous posts.
Also please read the documentation and the PDF wrote by Jean-Philippe included in the plugin download which are gonna explain how this plugin works and what it does.




Totally unrelated:

Question for Jean-Philippe: is it different from the last build you sent me via email? 'cause if it isn't, I'm gonna share the images of the last test results, otherwise I'm gonna repeat those tests.
Merci, I've been testing a bit with your examples on this post, it's getting better but cant seem to find a perfect match yet, I'll be testing some more,
still I wonder is it not possible to extract the required values used from let's say mpv, as its result looks really good for me, and reuse them on the hdrtools ?
I mean such thing would allow more than easy conversion rather than hand picking values for each movie.
r4dius is offline   Reply With Quote
Old 8th January 2020, 12:12   #130  |  Link
-QfG-
QfG Group Germany
 
-QfG-'s Avatar
 
Join Date: Oct 2018
Location: Germany
Posts: 245
A little Test of Tonemapping from me. HDRTools is better then DGTonemap (both curves), the new ripbot x264 have good standard settings in the script. A few pictures from me, but i think DGHDRtoSDR is still the best tonemapper of Avisynth base (the best choice for me is Blackmagic DaVinci Resolve for tonemapping, via ACES). Also you con minimize the "Black Crush" Problems, if you set "fullrange=true" in the ConvertYUVtoXYZ Line.

madVR 100 Nits:


madVR 150 Nits:


madVR 200 Nits:


HDRTools Ripbot Settings:


HDRTools (QfG Settings ~100 Nits):


DGHDRtoSDR (QfG Setting ~100 Nits)


DGTonemap (Hable Curve Untouched ~ 100 Nits)


*The pictures are from a 4K HDR Upscale from me from Star Wars VII

** I Miss the spoiler function here

Last edited by -QfG-; 8th January 2020 at 13:34.
-QfG- is offline   Reply With Quote
Old 29th April 2020, 00:07   #131  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
New version, see first post.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 15th May 2020, 00:11   #132  |  Link
hellgauss
Registered User
 
hellgauss's Avatar
 
Join Date: Sep 2002
Location: Italy
Posts: 90
Thank you for this tool, I used your first example to convert BT.2020 to BT.709, with nice results.

I have some questions

Consider a video with these parameters from mediainfo

Code:
Color range                 : Limited
Color primaries             : BT.2020
Transfer characteristics    : PQ
Matrix coefficients         : BT.2020 non-constant
Mastering display color pri : 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
Mastering display luminance : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
From what I understand, when using ConvertYUVto***, I should set Color=1, HDRMode=0. Mastering d. color is the default one.

1) How matrix coefficients enters in the conversion? Is it important?

2) How mastering display luminance is handled in HDRmode=PQ? It seems that these value can be set only in HLG. According to https://www.itu.int/dms_pub/itu-r/op...2017-PDF-E.pdf the EETF function should enter in the process?

3) I'm trying to understand how the maxcll and maxfall parameters can be calculated. In https://www.smpte.org/sites/default/...-Ecosystem.pdf , pag 44, the "linear values (R,G,B)calibrated to cd/m2" are the values from ConvertYUVToLinearRGB() without OOTF-1 (i.e. linear displayed data)? Has EETF any role here?

Thanks
HG

Last edited by hellgauss; 15th May 2020 at 00:18.
hellgauss is offline   Reply With Quote
Old 15th May 2020, 17:20   #133  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
No, you're PQ => HDR => BT.2100 => color=0. In the doc, it's said that HDRMode has effect only if color=0.
From what i've understood, you have BT2020, which is SDR, and you have BT2100, which is HDR version of BT2020.
So if "Transfer characteristics" is PQ or HLG => HDR => BT2100.
I suggest you to read the ColorConversion.pdf i've provided, which explain the path and what formulas/computation this plugin uses.

1)
Matrix coefficients are the one used to convert RGB to XYZ, they are more than important, it's them which defined the convertion matrix. Any change will change the output result.

2)
In PQ, mastering display luminance is not used, as it's always 1=10000.
I didn't implement any EETF function. This is very specific and used only for a display device when it wants to display a value wich is out of his range, from what i've understood. It's not a processing step i've implemented, and for now, didn't intend to.
If i implement it one day, it will be more in an external function (and not in an inside step of a ConvertXXXtoYYY) like the HDRtoSDR functions, because in a way, it's doing something similar.

3)
As there is not the keyword displayed (it says "linear values" and not "linear displayed values"), so from my point of view, they are the (Rs,Gs,Bs) i talk in my pdf, and not (Rd,Gd,Bb), but honestly, i'm not 100% sure.
But it's a value in cd/mē, so if it's PQ, just multiply by 10000, but if it's HLG, you have to know the mastering level.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 24th May 2020, 09:56   #134  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
I'm currently experimenting with downscaling HDR sources, otherwise keeping the HDR characteristics intact. I've understood from the x265 thread that processing should be done in linear light if possible.

Is this the proper way of doing things?
ConvertYUVtoLinearRGB(color=0, outputmode=0)
xxxxResize(xxxx, yyyy)
ConvertLinearRGBtoYUV(color=0, outputmode=2)

Is the difference between outputmode=0 and 2 in the first conversion just accuracy (and speed)? I tested a short encode with both values and outputmode=0 produces a slightly larger file. I cannot tell a difference in VDub2 when interleaving the two choices.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 24th May 2020, 10:45   #135  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
AS said in the ReadMe :
OutputMode -
Set the output data mode.
0: No change : Input 8 Bits -> Output : RGB32, Input > 8 Bits -> Output : RGB64
1: The ouput will be RGB64
2: The ouput will be RGBPS (Planar RGB float)

So, if your input is >8bits, outputmode=2 will force output to RGPBS instead of RGB64, better accuracy but slower (didn't make speed test, so can't tell "how much" slower).
There is no other difference.
Some people said that they have banding introduced even in 16 bits when converting from/back in PQ mode (especialy in dark area), but not in float mode. So, i'll suggest outputmode=2 in the first convertion.
__________________
My github.

Last edited by jpsdr; 24th May 2020 at 11:01.
jpsdr is offline   Reply With Quote
Old 24th May 2020, 11:07   #136  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by jpsdr View Post
AS said in the ReadMe :
OutputMode -
Set the output data mode.
0: No change : Input 8 Bits -> Output : RGB32, Input > 8 Bits -> Output : RGB64
1: The ouput will be RGB64
2: The ouput will be RGBPS (Planar RGB float)

So, if your input is >8bits, outputmode=2 will force output to RGPBS instead of RGB64, better accuracy but slower (didn't make speed test, so can't tell "how much" slower).
There is no other difference.
Some people said that they have banding introduced even in 16 bits when converting from/back in PQ mode (especialy in dark area), but not in float mode. So, i'll suggest outputmode=2 in the first convertion.
btw why not accept RGBP! or even RGB48!
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 24th May 2020, 11:17   #137  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
I don't see the need of others RGB outputmode, you can add a convertion after if you want something else, it will be lossles if you keep the same bit depth.
Also, it means i have to add input support of these formats in ConvertRGBtoXXX, i don't see the point to ouput something i don't support in input in the reverse convert. Don't want to.
From my point of view, supporting RGB, RGB64 and RGPS is enough to cover all the others cases, which can be easely be done by a simple convertion from the avs core.
__________________
My github.

Last edited by jpsdr; 24th May 2020 at 11:27.
jpsdr is offline   Reply With Quote
Old 24th May 2020, 11:24   #138  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by jpsdr View Post
It's called ConvertYUVtoLinearRGB, so, i only acced YUV input.
As far as i know, there is no source material as float, we are for now, at maximum 12 bits. So, as i'm lazzy, i don't intend for now to add float YUV input support.
I mean ConvertXYZtorgb https://forum.doom9.org/showpost.php...89&postcount=2

also as the output, RGBP should be faster than RGB48, RGB64

and RGB48 (with no alpha) should be faster than RGB64
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 24th May 2020, 11:30   #139  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
Ah...
You answered during my post change/edit, after correcting my misunderstanding of your question.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 24th May 2020, 11:41   #140  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by jpsdr View Post
Ah...
You answered during my post change/edit, after correcting my misunderstanding of your question.
Quote:
Originally Posted by jpsdr View Post
I don't see the need of others RGB outputmode, you can add a convertion after if you want something else, it will be lossles if you keep the same bit depth.
Also, it means i have to add input support of these formats in ConvertRGBtoXXX, i don't see the point to ouput something i don't support in input in the reverse convert. Don't want to.
From my point of view, supporting RGB, RGB64 and RGPS is enough to cover all the others cases, which can be easely be done by a simple convertion from the avs core.
what about make it just RGBP, since RGB64 is slower

0: No change : Input 8 Bits -> Output : RGBPx, Input > 8 Bits -> Output : RGBPx
1: The ouput will be RGBP16
2: The ouput will be RGBPS (Planar RGB float)
__________________
See My Avisynth Stuff
real.finder 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 11:14.


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