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 7th July 2020, 14:28   #1  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Sin squared kernel for resize (Gaussresize mod)

As numerical modeling shows sinus square function gives a bit narrower single pulse with given comparable outside non-linearity and non-monotonicality (ringing) in compare with gaussian function.

The modeling was done with web-accessible setup - you can check it at http://drakan.ru/FTProot/vid_work/LR...g_rest_en.html

For example at sigma = 0.85 gauss pulse has 0.5-level duration about 2T


and with T=3.7 sin squared pulse has 0.5-level duration 1.9T and significally better form near lower values.


Sinus squared function (pulse/kernel) is f(arg,T) (T as parameter)

for(abs(arg) < PI/2)
{
(cos(arg*T*PI))^2
}
else
0

(To be centered around 0 we replace sin(arg+pi/2) to cos() )/

Currently in avisynth only GaussResize gives acceptable results in attempts to get good anti-alized fonts for example or doing other high-quality anti-alized work. May be because of better pre-filtering.

So I assume using of sinus squared kernel instead of gaussian may gives a bit sharper results with same level of artifacts (ringing) control.

As building todays avisynth (+) is enough difficult for low-skilled programmer it will be nice if anyone with existing anisynth-build enviroment will make an additional resize function almost completely based on current GaussResize function with changed gauss kernel to sinus-squared kernel.
Also with additional parameter similair as GaussianResize have.

Last edited by DTL; 8th July 2020 at 12:47.
DTL is offline   Reply With Quote
Old 7th July 2020, 14:34   #2  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
For example of using GaussResize for getting antialiased video-font (compared with curent simple built-in avisynth font raserizer) the script can be used:
Code:
function Ast(clip c, int isize)
{
 return Subtitle(c, "Font",font="Arial",size=isize,align=6,halo_color=$FF000000, text_color=$00e0e0e0)
}

function Ast2(clip c, int isize)
{
 return Subtitle(c, "Font",font="Arial",size=isize,x=10,y=20,halo_color=$FF000000, text_color=$00e0e0e0)
}

BlankClip(100,480,290,"RGB24",25)

Animate(last, 0,100,"Ast2",  80,  180)

AddBorders(100,100,600,200)
Levels(0, 1, 255, 10, 235)

GaussResize(width/8,height/8,p=15)

Animate(0,100,"Ast",  11,  22)

SincResize(last,width*10,height*10,taps=20) (last resize must be omitted to get 100% size output, it only simulates video control monitor processing)
Looking in the sources of current avisynth+ release (3.6.1) it may looks like (derived from Sinc and Gauss resize existing filters):

Addition to resample_functions.cpp:

Code:
/***********************
 *** SinSquared filter ***
 ***********************/

SinSquaredFilter::SinSquaredFilter(double p) {
  param = clamp(p, 0.1, 100.0);
}

double SinSquaredFilter::f(double value) {
   value = fabs(value);
   double p = param*0.1;
   value *= M_PI*p;

 if (value < M_PI/2) 
{
    return cos(value)*cos(value);
}
else
 return 0;
}

and to resample_functions.h :

class SinSquaredFilter : public ResamplingFunction
{
public:
  SinSquaredFilter(double p = 30.0);
	double f(double x);
	double support() { return 4.0; };

private:
 double param;
};
and may be to other places to 'register' new filter. At first tests may be one can just rewrite existing GaussResize function.

The changes are small enough but to test them it is required to build locally full avisynth build enviroment. Or may be any online way for building avisynth available to get working binary for test ? Ofcourse debugging ability will be lost in compare with full building and debugging local enviroment.

Last edited by DTL; 12th July 2020 at 16:44. Reason: fixed code changes a bit
DTL is offline   Reply With Quote
Old 8th July 2020, 08:50   #3  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
Oh, interesting, i think i can easely add this to my plugin. PM an email i can send you a build test.
__________________
My github.

Last edited by jpsdr; 8th July 2020 at 08:53.
jpsdr is offline   Reply With Quote
Old 9th July 2020, 20:10   #4  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
One more promising kernel around powered-sinus/cosinus:

(for double *Filter::f(double value) function with all the same other lines )
Code:
if (value < M_PI/2)
{
return pow(cos(value), 1.7);
}
else
if (value < M_PI * 0.8)
return (-1)*cos(value) * cos(value)/value;
else
return 0;
While gaussian and limited to +-pi/2 cosine-squared kernels gives both ringing-controlled and halo/peaking(over/undershooting) controlled shape it gives significally lower sharpness. We can try to make kernel with halo/peaking control but with reduced ringing (outside our impulse borders) as possible. So it is my attempt to combine cosine-squared (real ^1.7 looks works better) impulse with inverted cosine-squared (unfortunately pow() functions looks like illegal of powering to 2.0- of negative numbers, but we can possibly replace negative cos(pi/2+) to positive sin/cos shape shifted to pi..pi/2 in the future versions) impulse dividev to argument for better decay.
In the range of T parameter 2.6 to 3.6 it gives sharpened shape with controlled undershoots amplitude and duration with enough control ringing outside undershoots. The lowest possible 0.5-level duration is about 1.4T with T-parameter 2.6. It is significally closer to theoretical 1.2T limit of 0.5-level of sinc base impulse in compare with gaussian and sin/cos suqared kernels.

May this can be called SinPowResize to separate with SinSqResize filter.

Though due to significant negative values this kernel definetly require float processing engine or at least signed integer instead of unsigned integer. I hope in todays avisynth resample in ASM is designed for handling negative coefficients as well as positive.

Updated web-simulator - http://drakan.ru/FTProot/vid_work/LR...g_rest_en.html it has Sin^p button now.



Unfortunately using limits like "value < M_PI * 0.8" looks like dirty hacking that works with simple 5-point simulator and some limited range or T-parameter but may cause bugs with real resample engine because I do not know which values of 'value' parameter actually passes to f(value) kernel function. Still do not have working avisynth-building enviroment for testing.

Last edited by DTL; 12th July 2020 at 16:43.
DTL is offline   Reply With Quote
Old 10th July 2020, 10:03   #5  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Quick tests of the over/under shooted kernel in real processing in avisynth (built-in sincresize to size*4):

T=2.7, downscaled 3 times to fit 0..255 range (without negative values illegal to integer 8-bit coding of typical video/images). Samples put by hand in ms-paint into image array. (16),1,31,89,31,1,(16) (in the right side of image, at the left is sort of sin^2 or gauss pulse without over/undershoots (16),46,89,46,(16). 800% screenshot of ms-paint.

Later loaded in avisynth with imagereader, scaled with sincresize to size*4 with max available taps=20 and displayed in virtualdub as 50% and 100% size. The undershooted pulse shows very good conditioned against ringing with visually sharper view. Ofcourse vertically it is unconditioned against any Nyquist limits becaue it is 1-dimentional test, so it do shows ringing vertically.
Attached Images
   

Last edited by DTL; 10th July 2020 at 10:21.
DTL is offline   Reply With Quote
Old 11th July 2020, 10:51   #6  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Thanks to jpsdr for providing test builds. He makes permission to share results and executable. It is in attach.

Current report on results:

Test script for testing 64x SSAA text with float size (or at least non-integer size) also compared to built-in Subtitle() text engine.
Code:
Loadplugin("ResampleMT.dll")

function Ast(clip c, int isize)
{
 return Subtitle(c, "Font",font="Arial",size=isize,align=6,halo_color=$FF000000, text_color=$00e0e0e0)
}

function Ast2(clip c, int isize)
{
 return Subtitle(c, "Font",font="Arial",size=isize,x=10,y=20,halo_color=$FF000000, text_color=$00e0e0e0)
}

BlankClip(100,480,150,"RGB24",25)

Animate(last, 0,100,"Ast2",  80,  180)

AddBorders(100,100,600,200)
Levels(0, 1, 255, 10, 235)

a=GaussResize(last,width/8,height/8,p=17)
b=SinSqrResizeMT(last,width/8,height/8,p=3.1)
c=SinPowResizeMT(last,width/8,height/8,p=3.4)

a=Animate(a,0,100,"Ast",  11,  22)
b=Animate(b,0,100,"Ast",  11,  22)
c=Animate(c,0,100,"Ast",  11,  22)

StackVertical(a,b,c)

SincResize(width*4,height*4,taps=20)
Levels(0, 1.2, 255, 0, 255)
2 new test functions: SinSqrResizeMT and SinPowResizeMT. Usable range of p-parameter around 2..5 float.

SinSqrResizeMT uses simple cos(arg)^2 kernel. It shows results very close to built-in Gauss resize. In given range of control parameter both ringing and over/undershoots are nicely conditioned. The contrast and sharpen of result is average.

SinPowResizeMT uses more complex kernel of cos(arg)^1.7 at +-pi/2 agrument range and -cos(arg)^2/(arg) in +-pi/2 to +-0.8pi argument range. The results are significally different: It still very good conditioned against ringing but gives more sharp results in both higher contrast and some under/overshooting (half-period non-ringed).

So we can define 2 different classes of kernels:
1. Both anti-ringing and anti-over/undershoots conditioned (gauss and cos^2).
2. Anti-ringing conditioned with (adjustable) over/undershoots that increases visual sharpness.

Unfortunately inside avisynth resampling engine the advanced kernel works in some different way in compare with my modeling and parameter p gives very small or not at all control for amplitude of over/undershooting. It mostly control overall filter frequency response from more blurry to extra sharp and ringy. Also it looks the hack of 0.8pi limiting is too illegal for sin/cos functions and gives discontiniuty. So it is good to adjust kernel function to +-pi limit with more fading members or parameters tuning. Also this class of resampling kernerls definetly needs more than 1 user-defined parameter for control both frequency response and 'sharpening' effect.

May someone can continue this work or may be I will someday get avisynth building enviremont for experiments.
Attached Images
 
Attached Files
File Type: 7z ResampleMT_sinp.7z (170.3 KB, 58 views)

Last edited by DTL; 12th July 2020 at 16:43.
DTL is offline   Reply With Quote
Old 12th July 2020, 08:55   #7  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Oh - I found my error in parameters description, that cause difference between T-values in my simulator and 'param' in avisynth build.

In my simulator the T-param is converted to 'frequency' with reciprocal f=1/T. And I forgot it in function description. So correct relation between simulator T-param and current build avisynth function p-param is p=10/T. 10x because of 0.1 multiplication inside avisynth function.

Now things goes close as they should. The 'SinPow' kernel still has limited enough usable range in current approximation math (from T > 2.55 to T < 3.75 or p < 3.9 and p > 2.66) and I will try to fix it with my simulation work. The limited and mostly interested case is lowest duration side (lowest T-value) and as hand-positioned samples shows it can reach close to theoretical duration of sinc-pulse of 1.2T at 0.5-level limit. With about 35% undershoots of positive pluse amplitude. Keeping outside ringing acceptably controlled (at least for 8-bit SDR video).

Ofcourse it is illegal for 100% amplitide pulses in 16..235 8-bit video coding, but may work in scaled-down for contrast pulses. Like 0.2x scaled - (16),1,17,44,17,1,(16)
DTL is offline   Reply With Quote
Old 12th July 2020, 10:30   #8  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
@DTL: would be nice if you could use 'code'-tags, it would really help making your posts more readable.
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 13th July 2020, 10:32   #9  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Finally I was able to build ResampleMT with VS2013 and made corrections and debug to functions more quickly. The most important was limiting support() member to 2 instead of 4 as in GaussFilter because 4 gives errors in following avisynth resampler. The param processing is now follows web-simulator T-value (no reciprocacity and 0.1 multiplication because todays avisynth good accepts float params values).
Current kernel func:
Code:
double SinPowFilter::f(double value)
{
	value = fabs(value);
	value *= M_PI / param;

	if (value<(M_PI / 2)) return pow(cos(value), 1.8);
	else
	{
		if (value<(M_PI)) return -(cos(value)*cos(value)) / (0.9*value);
		else return 0;
	}
}
In testing with typical videocamera frames with p-parameter = 2.5 it gives comparable sharpness with Lanczos4Resize() but with better conditioned anti-ringing. Parameter p<2.5 gives better sharpness but may cause more artifacts, p>2.5 gives less sharpness. Intendent for using for downsampling at anti-alizing processing and lower frame size rip creation.
Name of function SinPowResizeMT(), parameters are same as GaussResizeMT except for p-param as descriped above. Default p=2.5. Usable range of p-param is about 2..5 float. Internally limited to 1.0..10.0.

Currently only x64 build available because win32 config gives some errors.

As for sin^2 simple kernel: It gives very close to GaussResize results, so may be no any value for most users.
Attached Files
File Type: zip ResampleMT-master-src.zip (127.8 KB, 34 views)
File Type: zip ResampleMT_x64_SinPowReisize.zip (140.4 KB, 44 views)

Last edited by DTL; 13th July 2020 at 11:10. Reason: udpated sample script from p=7 to p=2.5
DTL is offline   Reply With Quote
Old 13th July 2020, 20:43   #10  |  Link
cork_OS
Registered User
 
cork_OS's Avatar
 
Join Date: Mar 2016
Posts: 160
Seems the secret of madshi's non-ringing Lanczos has revealed.
__________________
I'm infected with poor sources.
cork_OS is offline   Reply With Quote
Old 14th July 2020, 02:37   #11  |  Link
patul
Registered User
 
Join Date: Sep 2005
Posts: 130
@DTL, I suggest you put in the samples, source and binary somewhere else (google drive, github) instead of as attachment.. With all due respect to the moderators, attachments will need to get manual approval from the moderators and it could take sometime.
patul is offline   Reply With Quote
Old 14th July 2020, 07:45   #12  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Build (with sample / demo script ) https://drive.google.com/file/d/1AFO...ew?usp=sharing .
Sources https://drive.google.com/file/d/1rhE...ew?usp=sharing .

Last edited by DTL; 14th July 2020 at 14:51. Reason: updated links for public access witout premission request
DTL is offline   Reply With Quote
Old 14th July 2020, 11:42   #13  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Quote:
Originally Posted by cork_OS View Post
Seems the secret of madshi's non-ringing Lanczos has revealed.
I think there was not very the same task. It looks they try to use Lancsoz (sinc-based) resampler on 'non-conditioned' input data for upsample. That definetly will cause ringing effect (even in samples-space without signal/image restoring for viewing as required). Also in that thread users post about requirement of co-operative adjusting 2 or even 3 components of digital (discrete) workflow:
1. Samples source
2. Resampling engine
3. Restoring engine for image viewing

I assume current mature video (broadcasting) processing still based on the classical digital (discreete) processing of continious (analog) (image) data.
So 1. Samples sources (like video cameras, or digital/graphic data sources - CG systems, 3D- and 2D image 'renderers') must provide 'conditioned' samples arrays describing some continious/analog image. 'Conditioned' means if we check this data array on correct monitor (see 3.) it have (minimized or controlled by author/producer) ringing and over/under shooting (may also somewhere called 'peaking') in the state defined by image data authour/producer. As my practic shows different producers has its own opinion how 'sharp' must image looks in terms of over/under-shooting.
2. Resample engine (if we need for some reason change number of samples, spatial density) must keep the 'conditioning' of the output samples array. Or it may adjust 'sharpness' as person making resampling wants with ringing controlled to be as minimum as possible.
3. Restoring engine for image viewing must process input samples as described in Nyquist/Kotelnikov/etc theorem of restoring continious data from its sampled form. In math it is just Sinc-lowpass filtering with large enough taps (to better restore the highest still legal frequencies). I think its spirit still exists in typical documents for good quality video monitors like https://tech.ebu.ch/docs/tech/tech3320.pdf .

Here is a bit different tasks: The filter is designed for getting 'conditioned' samples output arrays for 'non'conditioned' sources (during operation like 'antialiasing', though it is a bit more complex because it is not only spectrum-limiting with simple 'ideal-low-pass filter', but also spectrum-conditioning in the legal low frequencies pass-range). For example buit-in avisynth font rasteriser gives badly conditioned for video samples data of glyphs and using down-resize we can enchance its 'conditioning' and adjust looking in terms of 'sharpness' while keeping aliasing and ringing in low (controlled) state.

And second typical task is down-resize of already formed 'conditioned' sources (2D samples array describing some continious image) because it is limiting-spectrum operation and must be performed with respect to correct math operation to get also 'conditioned' for video output result (2D samples array describing some continious image with lesser number of samples).

For up-sizing of good 'conditioned' video data we can simply use already working SincResize. It is typical operation on geometry video data processing for example for images overlay with float instead of integer coordinates. I hope somedays avisynth will be capable for geometry operations with float instead of integer coordinates. For example for better accuracy image positioning and smoother animations, smoother crawl/zoom effects etc.
DTL is offline   Reply With Quote
Old 20th July 2020, 18:59   #14  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Made some waveform testing on Tektronix WFM7120 signal control equipment.

Production script for 1920x1080 frame
Code:
Loadplugin("ResampleMT.dll")

function Ast2(clip c, int isize)
{
 return Subtitle(c, " Сергей          | председатель комтитета по государственному контролю,",font="Arial",size=isize,x=10,y=20,halo_color=$FF000000, text_color=$00202020)
}

BlankClip(100,1700*4,180*4,"RGB24",25,color=$00e0e0e0)

Animate(last, 0,100,"Ast2",  45,  180)

AddBorders(280,3400,600,200,color=$00202020)

SinPowResizeMT(last,width/4,height/4,p=2.9)
Output data passed 1 time HDCAM 422 MPEG-2 50 Mbit/s compression-decompression I suppose via import and output from broadcast server.

Photos taken with poor-people camera from handheld android (smart)phone.

Control mon frame (near 70..80% of animation length)


Tek line select setup pos in the frame height


Full screen waveform window with p=2.5


Full screen waveform window with p=2.7


Full screen waveform window with p=2.9


Full screen waveform window with p=3.1


4-windows tek screen with p=3.1


For comparison some close for text size output from badly-conditioned CG title station with lots of badly controlled ringing artefacts:




Last edited by DTL; 20th July 2020 at 19:38.
DTL is offline   Reply With Quote
Old 21st July 2020, 14:14   #15  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
It took me a while to look at the math behind it and I gotta say that it's a very good catch.
Well done for finding this out.
I guess it took a Russian to prove us wrong xD

Quote:
Originally Posted by DTL View Post
The 'SinPow' kernel still has limited enough usable range in current approximation math (from T > 2.55 to T < 3.75 or p < 3.9 and p > 2.66) and I will try to fix it with my simulation work. The limited and mostly interested case is lowest duration side (lowest T-value) and as hand-positioned samples shows it can reach close to theoretical duration of sinc-pulse of 1.2T at 0.5-level limit. With about 35% undershoots of positive pluse amplitude. Keeping outside ringing acceptably controlled (at least for 8-bit SDR video).
Ok, I may have got it completely wrong, but isn't that gonna shoot to the roof (i.e give out of range values) on signals that peak at 770mV (0.7V), namely 235 8bit?

Quote:
Originally Posted by DTL View Post
In testing with typical videocamera frames with p-parameter = 2.5 it gives comparable sharpness with Lanczos4Resize() but with better conditioned anti-ringing. Parameter p<2.5 gives better sharpness but may cause more artifacts, p>2.5 gives less sharpness. Intendent for using for downsampling at anti-alizing processing and lower frame size rip creation.
I see... Can it also be used as a brick-wall low-pass filter for antialiasing only, possibly with a cutoff that the user can choose? I'm just asking 'cause now I'm curious.

Quote:
Originally Posted by patul View Post
@DTL, I suggest you put in the samples, source and binary somewhere else (google drive, github) instead of as attachment.. With all due respect to the moderators, attachments will need to get manual approval from the moderators and it could take sometime.
I was actually lurking ResampleMT and now I understand where those commits come from: https://github.com/jpsdr/ResampleMT/...f3bf459bffc87b

In other words, don't worry, they're being merged into the main repository created and maintained by Jean Philippe.

Quote:
Originally Posted by DTL View Post
Photos taken with poor-people camera from handheld android (smart)phone.
We work in broadcast, but we're all broke (me included). It's a common place for people here on Doom9 xD

Quote:
Originally Posted by DTL View Post
Output data passed 1 time HDCAM 422 MPEG-2 50 Mbit/s compression-decompression I suppose via import and output from broadcast server.
XDCAM50 spotted here xD

Quote:
Originally Posted by DTL View Post
Made some waveform testing on Tektronix WFM7120 signal control equipment.
I've been using Waveform Monitors by Tektronix ever since January 2016; very good choice. A part of me is missing whenever I'm not at work with a Waveform Monitor next to me.

Anyway, very well done!

Last edited by FranceBB; 21st July 2020 at 14:21.
FranceBB is offline   Reply With Quote
Old 21st July 2020, 15:56   #16  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
"Can it also be used as a brick-wall low-pass filter for antialiasing only, possibly with a cutoff that the user can choose? I'm just asking 'cause now I'm curious."

If you attempt to do 'anti-alias' work with 'ideal brick wall low-pass' filter you will typically got ringing caused by 'Gibbs-phenomenon' ( https://en.wikipedia.org/wiki/Gibbs_phenomenon ) . So as my practice shows good 'conditioning' filter must AND cut-off illegal frequencies outside Nyquist limit AND control shape of remaining spectrum components inside legal Nyquist frequencies (from zero to Fd/2).

To do filtering with ideal brick-wall low-pass filter I think you can use already existed in avisynth SincResize filter.

'but isn't that gonna shoot to the roof (i.e give out of range values) on signals that peak at 770mV (0.7V), namely 235 8bit?'

Legal values for 8bit video data encoding samples values (for limited transitions) can reach limits from 1 to 254 (0 and 255 are system sync code values). So smart digital encoding of video data in Rec.601 (709, etc) already have some headroom for proper handling (limited) over and under shoots even below system-black 16 level and system-nominal-white 235 level. So it can encode and transfer more sharper image data in compare with 0(system black)..255(system while and max white) encoding with <0 and >255 non-legal and non-possible data values. More (visually) sharper with still good conditioning against ringing.

Example: if we try to encode sharp transition from system-black 16 level to system-nom-white 235 level we can either stuck with 16..235 range (for example using non-ringing/non-over/under-shooting Gauss kernel filter) and got something like:
16,16,70,191,235,235,235,... samples sequence.
But it will give less sharp transition - more time (or actually restored image space dimention) from 0.1 to 0.9 level rise.
Like 1.6T from 0.1 to 0.9 system nominal amplitude.


in compare with over/under shooting like: 16,16,1,92,254,254,235,235,... samples sequence. This samples sequence has 'out-of range' 16..235 encoding samples, but only shortly around transition.
It allows to get about 1.05T rise transition.


So it is legal to encode over/undershoots with 1..15 and 235..254 code values, and also 235..254 code levels may be used to encode super-white 'knee-d' values (with losing more and more ability to encode properly over-shooting for small details and transitions on large detail borders).
More exact you can test in in web-simulator at the link in the first post.

Last edited by DTL; 22nd July 2020 at 09:53. Reason: added images
DTL is offline   Reply With Quote
Old 21st July 2020, 17:21   #17  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
Don't forget my version has the range parameter...
I hope i'll have time to make a build soon.
Check eventualy, as it's possible that i put a build, and post info on doom9 later...
__________________
My github.
jpsdr is offline   Reply With Quote
Old 22nd July 2020, 13:25   #18  |  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 jpsdr View Post
Don't forget my version has the range parameter...
I hope i'll have time to make a build soon.
Check eventualy, as it's possible that i put a build, and post info on doom9 later...
Got it.
I just downloaded the new version and it's testing time!

So, I grabbed one of the spare BetaCAM contents I had available in 720x576 anamorphic 16:9. I picked two random scenes and I upscaled them to HD 1280x720 using different resizing kernels, including the new SinPowResizeMT().
Here are the results:

Original anamorphic 576p

PointResize Upscale

BilinearResize Upscale

BicubicResize Upscale

LanczosResize Upscale

GaussResize Upscale

SincResize Upscale

SinPowResize Upscale

Spline16Resize Upscale

Spline36Resize Upscale

Spline64Resize Upscale

Spline144Resize Upscale

Spline64Resize + NNEDI Upscale
FranceBB is offline   Reply With Quote
Old 22nd July 2020, 14:16   #19  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
And now another scene:

Original anamorphic 576p

PointResize Upscale

BilinearResize Upscale

BicubicResize Upscale

LanczosResize Upscale

GaussResize Upscale

SincResize Upscale

SinPowResize Upscale

Spline16Resize Upscale

Spline36Resize Upscale

Spline64Resize Upscale

Spline144Resize Upscale

Spline64Resize + NNEDI Upscale



As you can see, PointResize is crappy and doesn't really achieve anything usable in the real world, as expected.
BilinearResize is very blurry, just as expected...
BicubicResize is slightly less blurry, but with a bit more ringing...
LanczosResize is sharper than both Bilinear and Bicubic, however aliasing and ringing are now more pronounced...
GaussResize is very blurry; it somewhat hides ringing and aliasing at the expense of sharpness...
SincResize... mother of sharpness...! It's so sharp, that it looks like someone actually used a poor sharpening filter on it... It's way too sharp and it shows every possible problem, from aliasing to ringing and even haloing for that matter! Those issues are so pronounced that it's barely watchable...
SinPowResize... it's actually trying to achieve something better than Sinc, preserving the sharpness of it but getting less artifacts. Indeed, there are less artifacts, but the result still shows very bad aliasing all over the edges. As you can see from the first picture in my former post (I had to split the post in two due to the max number of images allowed), it kinda made it worse 'cause volleyball players are now a blocky mess on the edges. The math is ok, but on real world examples it misbehaved apparently...
Spline16Resize, Spline36Resize, Spline64Resize, Spline144Resize... I gotta be fair, the only reason why I included Spline144 is not to end up in the Katie's blacklist and / or receive complaints about the fact that I didn't include her beloved resizing kernel, so... xD
Anyway, the difference between them is barely noticeable; the result of Spline64Resize is pretty sharp and although it does show some aliasing on the edges, it's not so terrible. When used in combination with NNEDI some of the aliasing around the edges gets smoothed out and the result is actually pretty pleasant to watch. So, again, I'm gonna go with Spline64 + NNEDI as the best solution.
I'm sorry for Sin Squared, it looked promising on the paper, but it doesn't seem suited for real life scenarios, at least on my test. Perhaps it will behave differently on synthetic videos like animations / anime / cartoons etc.
FranceBB is offline   Reply With Quote
Old 22nd July 2020, 14:24   #20  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Quote:
Originally Posted by FranceBB View Post
Got it.
I just downloaded the new version and it's testing time!

So, I grabbed one of the spare BetaCAM contents I had available in 720x576 anamorphic 16:9. I picked two random scenes and I upscaled them to HD 1280x720 using different resizing kernels, including the new SinPowResizeMT().
For upscale it works close to LanczosResize with taps 2..3 with max sharpness with p about 2.5, and may be closer to GaussResize with p > 3.

The whole point of this method is for production any finite-resolution system data (SD,HD,UHDetc), 'conditioned', from for example infinite-res source (3D render or vector-defined image data like TrueType fonts). Or make down-scaled rips from hi-res sources to down-res targets.

I think it will not have any benefits in upscale (because in classic digital processing there defined the one and only one method of 'upscale' i.e. analog data restoration from digital form is Sinc-based filtering).

The good testing scenario is for example creating DVD-sized rip (SD 576 lines) from HD or better UHD source. And ofcourse the testing for output ringing must be performed with syntetic SincResize restoration at 2x..8x size in avisynth or real hardware DVD high quality DAC up to 13.5x8=108 MHz upsampling or broadcast quality waveform monitors like Tektronics/Leader products. Or may be producing subtitling or titling for any resolution system.
Current Subtitle() filter in avisynth produces too badly conditioned output and it is now possible to fix it significally using SSAA workflow:
1. Get Subtitle() output in 2x..8x+ size
2. SinPowResize (or GaussResize) /2../8+ to get conditioned output system size text.
Also if using 10x upsize and /10 down-resize (100x SSAA) it useful for .1 sample precision glyphs or text positioning (and sizing) for example for smooth crawls or other text animations. Same applying to layers composing work with sub-sample output positioning precision etc.

Last edited by DTL; 22nd July 2020 at 14:42.
DTL 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:29.


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