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 27th July 2021, 17:50   #181  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Small size over and undershoots can be removed with low-pass filtering or blurring. Like gauss-blur with enough radius. And the medium and large size details levels can be analyzed for min/max/average .
DTL is offline   Reply With Quote
Old 12th August 2021, 22:01   #182  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 447
avsresize_r10 (pass: 7fgQwBn9zreN): do not set matrix frame property when source matrix frame property is undef and color family is not changed;
- zimg@bf73dbe.
StvG is offline   Reply With Quote
Old 13th August 2021, 12:53   #183  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Thanks for the new build and most importantly thanks for making the plugin in the first place.
I wouldn't have been able to encode some Studio RGB 12bit PQ masterfiles by reliably applying my non-public LUTs without messing up with the levels without this one.
You saved me in a certain sense.

Last edited by FranceBB; 13th August 2021 at 13:00.
FranceBB is offline   Reply With Quote
Old 18th November 2021, 01:35   #184  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 447
avsresize_r11 (pass: 2bzWmpDAZbk8): added parameter use_props (whether to read and set frame properties);
- zimg 3.0.3.
StvG is offline   Reply With Quote
Old 18th November 2021, 06:26   #185  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Thank you for the new version

Would it be possible to add an option to use properties from a different clip than the source for the colorspace_op (and maybe chromaloc_op)? My use case is a simple "original clip" -> "convert to linear RGB and downscale" -> "convert back to original colorspace".
__________________
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 18th November 2021, 08:27   #186  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
use case is a simple "original clip" -> "convert to linear RGB and downscale" -> "convert back to original colorspace".'

If you use typical chroma subsampled input and output to this 'simple' - it is really very complex. Because chroma subsampling introduce distortions that can not be completely fixed in 'linear processing'. To better fix the both luma and chroma distortions of nonlinear systems the 'non-linear' that is content-adaptive processing required. Also to build the better processing the standartization of chroma antialiasing filter in display device required (or standartization of other display subsampled-decompressor if it finally going out of 'linear processing' at all).
So the playing 'simple' games around chroma-loc and 'going to linear' that is not perfectly possible from chroma-subsampled ugly old lossy compression still not allow to get best possible results. The distortions raises with saturation of colours and sharpness of colour transients.
So if the developer of z.lib reads here - may be try to add some content-adaptive non-linear resizer methods too to this library of functions.
DTL is offline   Reply With Quote
Old 18th November 2021, 22:55   #187  |  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 StvG View Post
avsresize_r11 (pass: 2bzWmpDAZbk8): added parameter use_props (whether to read and set frame properties);
- zimg 3.0.3.
It's always nice to see developers beginning to use the new Avisynth+ 3.7.1 frame properties. Well done and thanks!
FranceBB is offline   Reply With Quote
Old 19th November 2021, 07:37   #188  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 447
Quote:
Originally Posted by Boulder View Post
Thank you for the new version

Would it be possible to add an option to use properties from a different clip than the source for the colorspace_op (and maybe chromaloc_op)? My use case is a simple "original clip" -> "convert to linear RGB and downscale" -> "convert back to original colorspace".
Can you elaborate why would you use different frame properties than ones of the source clip?

Quote:
Originally Posted by FranceBB View Post
It's always nice to see developers beginning to use the new Avisynth+ 3.7.1 frame properties. Well done and thanks!
After r3 frame properties are always read and set when the avs+ version supports them.
When every option of colorspace_op is specified (matrix, transfer, primaries, range) and different than "auto", use_props=false can be used for higher fps.
But now I'm seeing that use_props=false doesn't pass frame properties (removes the frame properties). Another version is needed to fix that.
StvG is offline   Reply With Quote
Old 19th November 2021, 08:34   #189  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by StvG View Post
Can you elaborate why would you use different frame properties than ones of the source clip?
In that phase, the source clip is in RGB. It's basically YUV420P16 (BT709 or BT2020) -> linear RGB, downscale -> YUV420P16 (original format) -> feed to x265 for encoding.
__________________
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 19th November 2021, 09:22   #190  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 447
Quote:
Originally Posted by Boulder View Post
In that phase, the source clip is in RGB. It's basically YUV420P16 (BT709 or BT2020) -> linear RGB, downscale -> YUV420P16 (original format) -> feed to x265 for encoding.
You want to use the frame properties of "YUV420P16 (BT709 or BT2020)" as target matrix/transfer/primaries... when doing "linear RGB, downscale -> YUV420P16" ?
StvG is offline   Reply With Quote
Old 19th November 2021, 09:33   #191  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by StvG View Post
You want to use the frame properties of "YUV420P16 (BT709 or BT2020)" as target matrix/transfer/primaries... when doing "linear RGB, downscale -> YUV420P16" ?
Yes, that's the idea.
__________________
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 21st November 2021, 11:06   #192  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 447
avsresize_r12 (pass: oPrkZ7IH132A): changed use_props type from bool to int.
Code:
use_props (default -1) - whether to read and set frame properties:
-1: If frame properties are supported - if every option of colorspace_op and chromaloc_op are specified and different than "auto", 0, otherwise 1.
If frame properties are not supported - 0.
0: If frame properties are supported - only set frame properties.
1: Read and set frame properties.
2: Save properties of the source clip as frame properties: z_ChromaLocation, z_ColorRange, z_Matrix, z_Transfer, z_Primaries.
Every option of colorspace_op and chromaloc_op must be specified and different than "auto".
3: Save properties of the source clip as frame properties: z_ChromaLocation, z_ColorRange, z_Matrix, z_Transfer, z_Primaries.
Frame properties _ChromaLocation, _ColorRange, _Matrix, _Transfer, _Primaries must exist.
Frame properties _Matrix, _Transfer, _Primaries must have values different than 2 (unspec).
4: Use z_xxx frame properties as target values.
z_xxx frame propeties are removed after the colorspace conversion.
use_props=0 is faster than use_props=1
use_props=2 is faster than use_props=3

Example use_props=2 and use_props=4
Code:
z_ConvertFormat(pixel_type="rgbp", colorspace_op="709:709:709:l=>rgb:linear:709:f", chromaloc_op="left=>left", use_props=2)
z_ConvertFormat(pixel_type="yv12", use_props=4) # convert rgb to yuv with the yuv initial properties
Example use_props=3 and use_props=4
Code:
z_ConvertFormat(pixel_type="rgbp", colorspace_op="709:709=>rgb:linear", use_props=3)
z_ConvertFormat(pixel_type="yv12", use_props=4) # convert rgb to yuv with the yuv initial properties
StvG is offline   Reply With Quote
Old 22nd November 2021, 10:29   #193  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Well, looks like it works!

Quote:
#Indexing the HDR10 PQ BT2100 4:2:2 10bit planar source
video=FFVideoSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov")
ch1=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=1)
ch2=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=2)
ch3=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=3)
ch4=FFAudioSource("\\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=4)
ch5=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=5)
ch6=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=6)
ch7=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=7)
ch8=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=8)
ch9=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=9)
ch10=FFAudioSource("\\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=10)
ch11=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=11)
ch12=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=12)
ch13=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=13)
ch14=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=14)
ch15=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=15)
ch16=FFAudioSource("\\mibcisilonsc\avisynth\Scambio\FILM\Harry Potter and The Chamber of Secrets\HARRYPOTTERANDTHECHAMBEROFSECRETS_FEA_HDR_REC2020PQ_444F_PR444_2160P23-20211024145222.mov", track=16)
audio=MergeChannels(ch1, ch2, ch3, ch4, ch5, ch6, ch7, ch8, ch9, ch10, ch11, ch12, ch13, ch14, ch15, ch16)
AudioDub(video, audio)

#From 4:2:2 10bit to 4:2:2 16bit planar
ConvertBits(16)

#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("\\mibcisilonsc\avisynth\Server\encoder\encoder\Processors\avs_plugins\LUTs\WarnerBros_PQToHLG_MaxCLL_2508.cube", fullrange=true)

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

#Clipping
Limiter(min_luma=64, max_luma=940, min_chroma=64, max_chroma=960)

Prefetch(8)
correctly reports std-b67 which stands for arib-std-b67 which is HLG in the frame properties!


Last edited by FranceBB; 22nd November 2021 at 10:32.
FranceBB is offline   Reply With Quote
Old 7th January 2022, 01:12   #194  |  Link
ErazorTT
Registered User
 
Join Date: Mar 2003
Location: Germany
Posts: 215
ditehring methods returning different averages

I would like to report that the dithering methods ordered, random, error_diffusion of the z_ConvertFormat function return slightly different averaged values.
So when having big single color patches like in test patterns, the averages over all pixels are slightly different for the methods.

I admit that the difference is small (9 in the full range of 0-32768 which equals 0.07 for the range of 0-255). But still for 16 bit clips this would be measurable.

I put all the screenshots in the folder and also the saved pictures from the clip, which can be opened an checked:

https://drive.google.com/drive/folde...pn?usp=sharing

If this is expected, then which method is nearer to the true average?
ErazorTT is offline   Reply With Quote
Old 7th January 2022, 03:00   #195  |  Link
kedautinh12
Registered User
 
Join Date: Jan 2018
Posts: 2,153
Quote:
Originally Posted by ErazorTT View Post
I would like to report that the dithering methods ordered, random, error_diffusion of the z_ConvertFormat function return slightly different averaged values.
So when having big single color patches like in test patterns, the averages over all pixels are slightly different for the methods.

I admit that the difference is small (9 in the full range of 0-32768 which equals 0.07 for the range of 0-255). But still for 16 bit clips this would be measurable.

I put all the screenshots in the folder and also the saved pictures from the clip, which can be opened an checked:

https://drive.google.com/drive/folde...pn?usp=sharing

If this is expected, then which method is nearer to the true average?
I think it's faster than convertbits. Maybe can replace convertbits in TemporalDegrain2???
kedautinh12 is offline   Reply With Quote
Old 8th January 2022, 01:12   #196  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 447
Quote:
Originally Posted by ErazorTT View Post
I would like to report that the dithering methods ordered, random, error_diffusion of the z_ConvertFormat function return slightly different averaged values.
So when having big single color patches like in test patterns, the averages over all pixels are slightly different for the methods.

I admit that the difference is small (9 in the full range of 0-32768 which equals 0.07 for the range of 0-255). But still for 16 bit clips this would be measurable.

I put all the screenshots in the folder and also the saved pictures from the clip, which can be opened an checked:

https://drive.google.com/drive/folde...pn?usp=sharing

If this is expected, then which method is nearer to the true average?
It's expected. About the choice of the dither algorithm - you can check this thread.
For info:
- colorspace_op conversions are done in float and then dither to the target bit depth (if different than float);
- resize operations are done in 16-bit (if source/target are not float) and then dither to the target bit depth (if target lower than source and lower than 16/32-bit).
StvG is offline   Reply With Quote
Old 10th January 2022, 01:21   #197  |  Link
ErazorTT
Registered User
 
Join Date: Mar 2003
Location: Germany
Posts: 215
Quote:
Originally Posted by kedautinh12 View Post
I think it's faster than convertbits. Maybe can replace convertbits in TemporalDegrain2???
Really? I’ve never benchmarked that. I would assume that both are orders of magnitudes faster than anything TemporalDegrain2 is doing.
ErazorTT is offline   Reply With Quote
Old 11th January 2022, 10:56   #198  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
Quote:
Originally Posted by ErazorTT View Post
Really? I’ve never benchmarked that. I would assume that both are orders of magnitudes faster than anything TemporalDegrain2 is doing.
fmtc_bitdepth works really fine too.
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 25th January 2022, 06:08   #199  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by StvG View Post
It's expected. About the choice of the dither algorithm - you can check this thread.
For info:
- colorspace_op conversions are done in float and then dither to the target bit depth (if different than float);
- resize operations are done in 16-bit (if source/target are not float) and then dither to the target bit depth (if target lower than source and lower than 16/32-bit).
If the process chain is denoise -> downscale -> deband, is it better to leave dithering out of the downscaling phase, since debanding also does some sort of dithering (f.ex. f3kdb)?
__________________
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 25th January 2022, 23:31   #200  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 447
Quote:
Originally Posted by Boulder View Post
If the process chain is denoise -> downscale -> deband, is it better to leave dithering out of the downscaling phase, since debanding also does some sort of dithering (f.ex. f3kdb)?
It depends. If your source is 10-bit (it will be valid for any bit depth < 16-bit):
a) if denoise in source bit depth (10-bit), downscale w/o bit depth change (10-bit->16-bit->10-bit - how internally avsresize will scale), deband w/o bit depth change (assume f3kdb: 10->16-bit->10-bit - how internally f3kdb will deband)
b) convert to 16-bit, denoise, downscale, deband, convert to source bit depth (10-bit)

For a) it's better to apply dither after the downscaling.
For b) 16-bit->10-bit is done only once at the end - dither.

If the speed penalty of b) isn't the bottleneck, it should be always the preferred option imo.
StvG 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 20:46.


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