real.finder's Avisynth Stuff

[real.finder]

Originally Posted by hello_hello

real.finder,

ResizeX seems to have issues. Try this with any source and you'll see what I mean.

ResizeX(width(),height(), 100,100,0,0)

Cheers.

original ResizeX by Desbreko is same, resize8 is ok

[real.finder]

Originally Posted by hello_hello

real.finder,

ResizeX seems to have issues. Try this with any source and you'll see what I mean.

ResizeX(width(),height(), 100,100,0,0)

Cheers.

try ResizeX(width(),height(), 100,100,0,0,resize8=true) with https://github.com/realfinder/AVS-St...p/ResizeX.avsi

[hello_hello]

Is the Resize8 argument for testing purposes?

It seems to be okay when Resize8=true (the output appears to be the same as Resize8 with it's noring arguments false and Spline36 used for luma and chroma).
When it's false it's the same as before. I'm not sure why you'd want it to behave the old way though.

Can you tell me if I'm missing something here?
Edit: Don't worry, I worked it out and explained it to myself in the next post.
I haven't tried very hard to work out why yet, but something doesn't seem quite right, and I'm not seeing anything obvious in the functions.

ColorBars()
KillAudio()
ConvertToYV12()
A = last

OutW = 1280
OutH = 960
RXCropC = 0.25 * (1.0 - (float(width(A) / 2.0) / float(OutW / 2.0)))
RXCrop  = RXCropC * 2.0
R8CropC = 0.25 - ((width(A) / 2) * 0.25 / float(OutW / 2))
R8Crop  = R8CropC * 2.0

Yp = ExtractY(A).BilinearResize(OutW,OutH, 0,0,0,0)
Up = ExtractU(A).BilinearResize(OutW/2,OutH/2, RXCropC,0,0,0)
Vp = ExtractV(A).BilinearResize(OutW/2,OutH/2, RXCropC,0,0,0)

CP = CombinePlanes(Yp, Up, Vp, planes="YUV", source_planes="YYY", pixel_type=PixelType(A))
MC = MergeChroma(A.BilinearResize(OutW,OutH, 0,0,0,0), A.BilinearResize(OutW,OutH, RXCrop,0,0,0))
RX = A.ResizeX(OutW,OutH, kernel="Bilinear", Resize8=true)
R8 = A.Resize8(OutW,OutH, noring=false, noring_c=false, kernel="Bilinear", kernel_c="Bilinear")

# Subtract(CP, MC) # Same
# Subtract(RX, R8) # Same
# Subtract(CP, RX) # Different
# Subtract(MC, R8) # Different

subtitle(string(RXCropC, "%.20f"), align=8)\
.subtitle(string(R8CropC, "%.20f"), align=2)

While I'm here, in case you know.
Any idea why ResizeX excludes PointResize from the chroma shift fix?

Cheers.

[hello_hello]

I think I know what the difference is. It's due to the way Avisynth interprets "src_right" according to whether it's >0 or <=0, and both scripts are converting a src_right cropping of zero to a positive number, changing the way it's interpreted.

Using my MergeChroma example above, the way I thought it was done in one of the original threads where this issue first came to light was like this:

MergeChroma(A.BilinearResize(OutW,OutH, 0,0,0,0), A.BilinearResize(OutW,OutH, RXCrop,0,0,0))

But it was actually this:
https://forum.doom9.org/showthread.p...97#post1543797

SW = width(A)
SH = height(A)
MergeChroma(A.BilinearResize(OutW,OutH, 0,0,SW,SH), A.BilinearResize(OutW,OutH, RXCrop,0,SW,SH))

That makes more sense, as it effectively increases the chroma width and keeps the same luma to chroma ratio.

Sorry to interrupt the thread while I worked that out.

[tuqc]

when I use "notSMDegrain(Contrasharp=true)" I get "I dont know what 'cb1' means".anyone help me out,thx

tested。1080P works fine with 'Contrasharp=true'。 480p get error 。anyone same promble?

[real.finder]

Originally Posted by hello_hello

Is the Resize8 argument for testing purposes?

It seems to be okay when Resize8=true (the output appears to be the same as Resize8 with it's noring arguments false and Spline36 used for luma and chroma).
When it's false it's the same as before. I'm not sure why you'd want it to behave the old way though.

kinda of, I don't want to change filter behavior I didn't made in first place, keep in mind that edi_rpow2 use resizex, I didn't test if this break it, also I can't do much test/works these days so contributions are welcome

Originally Posted by tuqc

when I use "notSMDegrain(Contrasharp=true)" I get "I dont know what 'cb1' means".anyone help me out,thx

tested。1080P works fine with 'Contrasharp=true'。 480p get error 。anyone same promble?

try https://github.com/realfinder/AVS-St...SMDegrain.avsi

[hello_hello]

Originally Posted by real.finder

kinda of, I don't want to change filter behavior I didn't made in first place, keep in mind that edi_rpow2 use resizex, I didn't test if this break it, also I can't do much test/works these days so contributions are welcome

I'm not familiar with edi_rpow2 and I haven't studied avisynth variable shorthand, so it's not always easy to work out what variables/functions represent. "sisphbd", "nrb", "nrf", "tmm2_ortmm1"... I'm learning them slowly though.
Why are so many functions written as though there's a need for DOS 8.3 vrbnames.

Anyway, as ResizeX effectively adds the left and top cropping to the source width and height (or doesn't subtract it... I've forgotten already) it seems specifying those prevents it misbehaving. With the new Resize8 argument false there's an obvious difference between these two.

ColorBars()

ResizeX(640,480, 20,20,620,460)
and
ResizeX(640,480, 20,20,0,0)

These are in complete agreement though, so I can only assume ResizeX has been broken for a while (I used a wrapper function to disable anti-ringing etc for Resize8).

Spline36Resize(640,480, 20,20,0,0)
WResize8(640,480, 20,20,0,0, cplace="mpeg1")

I had a quick skim through edi_rpow2, and most of the calls to ResizeX don't specify any right or bottom cropping. Bummer..... For the record, these two are the same, so I assume eedi3 does.

eedi3_rpow2(rfactor=4, cshift="ResizeX", fwidth=1280, fheight=960)
eedi3_rpow2(rfactor=4, cshift="WResize8", fwidth=1280, fheight=960)

[hello_hello]

Originally Posted by real.finder

kinda of, I don't want to change filter behavior I didn't made in first place....

Well it turns out ResizeX's behaviour isn't that far removed from the norm. Obviously I've spent too much time with my head up my backside to notice.

The Avisynth resizer page says the defaults for src_width and src_height are... well... the source width and height.

http://avisynth.nl/index.php/Resize
float src_left, src_top = 0, 0
float src_width, src_height = (source width, height)

That's followed by cropping rules that are just plain wrong for resizer cropping, but ResizeX isn't quite following them anyway, because.....

float src_width/height =
If > zero, these set the width and height of the clip before resizing.
If <= zero, they set the cropping of the right and bottom edges respectively, before resizing.

BilinearResize(640,480, 100) behaves like ResizeX.
BilinearResize(640,480, 100, 0, 0,0) ends the madness.

For ResizeX though, zero for the right/bottom cropping doesn't get it done.

Well... I'm off to contemplate living in a world where those defaults aren't considered mental...

[real.finder]

yes, I also think ResizeX behaviour is worng, but maybe edi_rpow2 not eedi3_rpow2 need this

[StainlessS]

R.F.,
Any idea whats happening here,

ColorBars(Pixel_type="YV12").KillAudio.Assumetff
Stab3(use_Feedback=true)    # Stab3(use_Feedback=false)  OK

PotPlayer and VDub2 both just disappear like magic [on play/load], similar symptoms to recursive stack exhaustion and Avisynth total crash [without error message].

[kedautinh12]

Yeah, i crash with Stab3() too, use normally with Stab3(use_Feedback=true)

[StainlessS]

Further, W10 Windows Logs

Exception code: 0xc0000409
Fault offset: 0x000000000006db8e
Faulting process ID: 0x740
Faulting application start time: 0x01d7893d29ee940e
Faulting application path: C:\NON-INSTALL\VDUB\VDUB2\VirtualDub64.exe
Faulting module path: C:\Windows\System32\ucrtbase.dll
Report ID: ab0d1965-784d-4b6d-aa1a-5f61d73dfdef
Faulting package full name:
Faulting package-relative application ID:

EDIT:
Above error code seem to be related to Windows Update Error, [I have Windows Update disabled on W10],
dont see why that can be related.

W7, I'm gettin'

The named argument 'mask' to InpaintDelogo had the wrong type.
StabilizationToolsPack.avsi, Line 482.

Line 482

bfix > 1 ? stabclip.FillBorders_stabi(pad=subsampl && mirror!=15 ? 1 : 0,subsample=subsampl,FixFalPos=defined(FalPosclip) ||
  \ FixFalPos ? last : Undefined, mirror=mirror==15,PAR=PAR, FillBordersc=u_ExIn ? preclip.ExInpaint(bfixc.mt_lut(u=-255,v=-255)) 
  \ : u_InDe ? preclip.InpaintDelogo(mask=bfixc, Loc="0,0,0,0",dPP=0,dPPm=1,diPP=1,diPPm=0,oPP=1,oPPm=0,Inflate=0) 
  \ : preclip.InpaintLogo(bfixc)) : bfixc

EDIT: Just before above line bfixc = type YV12, presume InpaintDelogo requires RGB.
EDIT: Says "wrong type", not "wrong colorspace type", But is showing for me type clip YV12. [so I'm confused]

[StainlessS]

Originally Posted by StainlessS

PotPlayer and VDub2 both just disappear like magic [on play/load], similar symptoms to recursive stack exhaustion and Avisynth total crash [without error message].

From Stack Overflow

The clue to the problem is in the exception code: 0xc0000409

0xc0000409 means STATUS_STACK_BUFFER_OVERRUN.

In other words, something in your program is writing past the current stack frame, corrupting data on the stack. The program has detected this and rather than let it continue, has thrown an exception.

https://stackoverflow.com/questions/...ode-0xc0000409
Dont know why some post on Microsoft.com thought it were to do with Windows Update.

EDIT: So, AVS error message on W7, and Stack exhaustion/corruption on W10.

EDIT: Anybody confirm error results on both W7 and W10 ? [with current StabilizationToolsPack.avsi and Zs_RF_Shared.avsi]

[real.finder]

did you have last https://forum.doom9.org/showthread.php?t=176860 ?

[StainlessS]

I had v1.2 [5th July 2019] which seems to be last in Pinterf suppository ,
but posted by VoodooFX as v1.24 [28 Nov 2020] at your linked post [post attachment].

Thanks, I'll give it a try [maybe later, gotta get to pub before it runs out of beer].

EDIT: Damn it, I think I was confusing InpaintDelogo[v1.24] and AvsInpaint[v1.2].

[StainlessS]

Originally Posted by StainlessS

R.F.,
Any idea whats happening here,

ColorBars(Pixel_type="YV12").KillAudio.Assumetff
Stab3(use_Feedback=true)    # Stab3(use_Feedback=false)  OK

PotPlayer and VDub2 both just disappear like magic [on play/load], similar symptoms to recursive stack exhaustion and Avisynth total crash [without error message].

OK, I finally updated InPaintDeLogo.avsi [v1.24] and problem disappears [on W10 (stack exhaustion gone), not tried yet on W7 but anticipate no probs], Thanks R.F.

[real.finder]

test update https://github.com/realfinder/AVS-St..._resize16.avsi to use fmtconv

note: it's not work with noring yet, it's need porting Dither_resize16nr to fmtc_resamplenr, which use array in way like this https://forum.doom9.org/showthread.p...89#post1949689 so I will wait for now

fmtconv update for nnedi3_resize16 should fix many old problems, like this https://forum.doom9.org/showthread.p...94#post1924894

something old now (nothing to do with last update) but also if you want the old default hybrid LBD and lsb you can set FastNnediHBD to true (to use nnedi3 with 8bit whatever the HBD input is used, just like the old "lsb_in=true, lsb=true" but it using HBD in other places so it's not 100% same output or even speed as lsb (it's a bit slower than lsb because slimit_dif vs Dither_limit_dif16))

also aside from that, keep in mind that nnedi3_resize16 still use dithertools if you use 8bit even without lsb, in short it's still use hacks

[tormento]

Originally Posted by real.finder

also AKA A.SONY's Avisynth Stuff

Could you please adapt SPresso and STpresso to ExTools from DogWay? We could get rid of masktools, RGTools and perhaps something else.

P.S: Do they support HBD?

[real.finder]

I plan to update crt-display (CRT display emulator) by cretindesalpes but it need Dither_box_filter16 and Dither_resize16nr (already plan to port it to fmtc_resamplenr)

Originally Posted by tormento

Could you please adapt SPresso and STpresso to ExTools from DogWay? We could get rid of masktools, RGTools and perhaps something else.

Currently very unlikely

[Dogway]

Originally Posted by tormento

Could you please adapt SPresso and STpresso to ExTools from DogWay? We could get rid of masktools, RGTools and perhaps something else.

I ported SPresso.

Anyway I'm not entirely replacing RGTools with ExTools (except for EX mods) because RGTools is insanely fast (AVX2 helps), blurs are ok within 10% of removegrain() but medians are slower. Anyway removegrain(4) is very very basic and thickens lines so I will replacing it with a smarter median on the long run.