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. |
23rd December 2019, 10:46 | #121 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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. |
23rd December 2019, 10:50 | #122 | Link | |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,815
|
Here how frame looks with value=1000
Quote:
UPDATE: Only outputmode=2 fixes this issue.
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper Last edited by Atak_Snajpera; 23rd December 2019 at 10:56. |
|
23rd December 2019, 10:57 | #123 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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. |
23rd December 2019, 13:49 | #124 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,815
|
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
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
23rd December 2019, 15:20 | #125 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,815
|
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
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper Last edited by Atak_Snajpera; 23rd December 2019 at 15:42. |
29th December 2019, 01:21 | #126 | Link |
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 ? |
29th December 2019, 01:39 | #127 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
Quote:
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. |
|
29th December 2019, 12:32 | #128 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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. |
30th December 2019, 02:02 | #129 | Link | |
Registered User
Join Date: Mar 2013
Posts: 6
|
Quote:
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. |
|
8th January 2020, 12:12 | #130 | Link |
QfG Group Germany
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. |
15th May 2020, 00:11 | #132 | Link |
Registered User
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 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. |
15th May 2020, 17:20 | #133 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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. |
24th May 2020, 09:56 | #134 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
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... |
24th May 2020, 10:45 | #135 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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. |
24th May 2020, 11:07 | #136 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
__________________
See My Avisynth Stuff |
|
24th May 2020, 11:17 | #137 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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. |
24th May 2020, 11:24 | #138 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
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 |
|
24th May 2020, 11:41 | #140 | Link | ||
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
Quote:
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 |
||
|
|