AviSynthShader + SuperRes

[markiemarcus]

Originally Posted by poisondeathray

I can reproduce this; easier to see with colorbars or similar patterns

fulls=true seems to "fix" it (or match the others)

ConvertBits(16, fulls=true)
SuperResXBR(MatrixIn="Rec601")
ConvertBits(8, fulls=true, dither=-1)

Many thanks for this! It does indeed work. I guess the big question is why? I haven't observed this behaviour in KNLMeansCL for example. Just a bug?

I also wonder why it produces very slightly different results (detail-wise) to the LSB method. I was under the impression that despite the different approach to high bit depth processing, the results should be 100% identical.

[ChaosKing]

Originally Posted by ChaosKing

thx, found it later too.

Also found this https://artoriuz.github.io/mpv_upscaling.html
FSRCNNX is an upscaler which seems to be similar to NGU (madvr)

It can be downloaded here in glsl format: https://github.com/igv/FSRCNN-TensorFlow/releases

Maybe Avisynth shader could support glsl in (a not so distant) future

If someone needs it. https://github.com/Lypheo/vs-placebo supports glsl shader files now, it's a VapourSynth plugin.

[markiemarcus]

It seems that there is an incompatibility between AvisynthShader and AVS+ 3.6. I'm getting:

"System exception Access Violation". Shader.avsi, line 218.

Can anybody else confirm?

[goorawin]

Yes it has the same error for me

[markiemarcus]

Damn. TMM2 won't load either. I guess I'll be sticking with 3.5.1 for the foreseeable future!

[Reel.Deel]

These issues have been solved in Avisynth+ v3.6.1. No official release yet, for now download test 8 here: https://forum.doom9.org/showthread.php?t=181351
As for TMM2, download update here: https://github.com/Asd-g/TMM2/releases

[markiemarcus]

Thanks so much for the reply!

TMM2 seems to work fine with test 8. Unfortunately, still no dice with AvisynthShader. I'm getting exactly the same system exception.

Line 218 in Shader.avsi reads:

ExecuteShader(last, Input, Precision=3, Clip1Precision=PrecisionIn, OutputPrecision=PrecisionOut, PlanarOut=PlanarOut, Engines=Engines, Resource=true)
convert ? ConvertFromShader(PrecisionOut, format=sourceFormat, lsb=lsb_out) : last

[MysteryX]

By popular demand, v1.6.6 is released!
- Updated headers to support Avisynth+ 3.6

I didn't do much testing so let me know if you encounter any issues.

[StainlessS]

Cheers MX

[DJATOM]

https://github.com/mysteryx93/AviSyn...0a84bb01acR156
I think you slipped b = in your edits, didn't tested though

[gispos]

Originally Posted by MysteryX

By popular demand, v1.6.6 is released!
- Updated headers to support Avisynth+ 3.6

I didn't do much testing so let me know if you encounter any issues.

Thanks

[markiemarcus]

Originally Posted by MysteryX

By popular demand, v1.6.6 is released!
- Updated headers to support Avisynth+ 3.6

I didn't do much testing so let me know if you encounter any issues.

Legend, thank you!

Edit: Seems to work fine here.

[StvG]

Originally Posted by MysteryX

By popular demand, v1.6.6 is released!
- Updated headers to support Avisynth+ 3.6

I didn't do much testing so let me know if you encounter any issues.

It crashes on non Avisynth+ 3.6 environment.
There is no env->Allocate/env->GetEnvProperty for anything than V8 interface.

[MysteryX]

Originally Posted by StvG

It crashes on non Avisynth+ 3.6 environment.
There is no env->Allocate/env->GetEnvProperty for anything than V8 interface.

dang.... how am I supposed to deal with that!?

Perhaps supporting older versions of AVS+ isn't important; if we consider it to have a more unstable API so far. Those using AVS+ can get the latest version of it. No reason to not upgrade.

[real.finder]

Originally Posted by MysteryX

dang.... how am I supposed to deal with that!?

see how asd and pinterf did it

[StvG]

Originally Posted by MysteryX

dang.... how am I supposed to deal with that!?

Perhaps supporting older versions of AVS+ isn't important; if we consider it to have a more unstable API so far. Those using AVS+ can get the latest version of it. No reason to not upgrade.

Check this post https://forum.doom9.org/showthread.p...74#post1915174

[MysteryX]

Originally Posted by StvG

Check this post https://forum.doom9.org/showthread.p...74#post1915174

Simplest: for previous AVS versions, do the same I was doing for AVS 2.6

[Alexkral]

Hi, I'm not sure what's happening here:

clip = BlankClip(width = 100, height = 100)
W = clip.Width
H = clip.Height
ConvertToShader(clip, Precision = 1)
for (i = 1, 2) {
    W = W * 2
    H = H * 2
    Shader("shader.hlsl", output = 2)
    Shader("shader.hlsl", clip1 = 2, Width = W, Height = H)
}
ExecuteShader(last, clip, Clip1Precision = 1, Precision = 3, OutputPrecision = 1)
ConvertFromShader(Precision = 1, Format = "RGB32")

The result is a 400 x 400 clip as it should be, but if I look at the c0 register of the first shader on the second pass, the width and height are 100 again after they have been doubled on the first pass. If I add "Width = W / 2, Height = H / 2" to the first shader then everything is correct, again suggesting that by not doing so the texture is being downscaled.

[MysteryX]

Originally Posted by Alexkral

Hi, I'm not sure what's happening here:

clip = BlankClip(width = 100, height = 100)
W = clip.Width
H = clip.Height
ConvertToShader(clip, Precision = 1)
for (i = 1, 2) {
    W = W * 2
    H = H * 2
    Shader("shader.hlsl", output = 2)
    Shader("shader.hlsl", clip1 = 2, Width = W, Height = H)
}
ExecuteShader(last, clip, Clip1Precision = 1, Precision = 3, OutputPrecision = 1)
ConvertFromShader(Precision = 1, Format = "RGB32")

The result is a 400 x 400 clip as it should be, but if I look at the c0 register of the first shader on the second pass, the width and height are 100 again after they have been doubled on the first pass. If I add "Width = W / 2, Height = H / 2" to the first shader then everything is correct, again suggesting that by not doing so the texture is being downscaled.

If I remember correctly... each output buffer (Clip1 - Clip9) are initialized at the start and cannot be changed. You're trying to fill Cilp1 with 2 different frames of different sizes. You'll need to use Output = 3 to create a separate buffer.

Output=1 needs to be the final output, so you may have to start with outputs 2, 3 and 4 for processing.

[Alexkral]

Thanks, I tested it and you're right.

EDIT: Well, it works, but I'm not sure if the explanation is correct. This is what I've done:

clip = BlankClip(width = 100, height = 100)
W = clip.Width
H = clip.Height
ConvertToShader(clip, Precision = 1)
for (i = 1, 2) {
    W = W * 2
    H = H * 2
    Shader("shader.hlsl", output = i+1)
    Shader("shader.hlsl", clip1 = i+1, Width = W, Height = H)
}
ExecuteShader(last, clip, Clip1Precision = 1, Precision = 3, OutputPrecision = 1)
ConvertFromShader(Precision = 1, Format = "RGB32")

Now output is 3 on the second pass, and has the correct size, so it's the output which can't change its size, and clip1 is receiving outputs of different sizes. Also I've seen that in SuperXbrMulti you solve this by sending the size to the shader as a parameter, so I'm not sure the best way of doing it:

1 - Setting the size: Shader("shader.hlsl", output = 2, Width = x, Height = y)
2 - Using a parameter: Shader("shader.hlsl", Param2 = size, output = 2)

or doing the above.