AviSynthShader + SuperRes [Archive] - Page 10

MysteryX

19th October 2016, 07:44

Sorry for the delays. I have been focusing on other projects (like publishing a book on a topic that would make most people here cringe)

Version 1.5.6 is ready! (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.5.6)

What's new:
- Changed planar format back to D3DFMT_L8
- PlanarIn default value is now false for all methods
- Detect whether graphic card supports planar output and gracefully disable PlanarOut if it doesn't

If you're still experiencing bugs or green screens, please provide more feedback as to what works and what doesn't work for you. Already this version should work a lot better.

Alex-Kid

21st October 2016, 00:01

@MysteryX

Your last posts resolved the issue, thank you!

Flux

21st October 2016, 12:14

I use ResizeShader to downsize high resolution images. Last working version is v1.4.6 (June 6th 2016) and later versions produce brightened images. This happens with both SSIM and Bicubic shaders.

R9 280 3GB (Crimson 16.8.2 drivers), Windows 7 64-bit, Avisynth 2.60, build Mar 31 2015 (16:38:54) Virtualdub 1.10.4 build 35491

I used this AVS script

ImageSource("image.png", end = 0, use_DevIL=true)

Bicubicresize(1920,1080,b=0.0,c=0.75)
#ResizeShader(1920,1080,kernel="SSIM",b=0.5,c=0)
#ResizeShader(1920,1080,kernel="Bicubic",b=0.0,c=0.75)

There seems to be noticeable differences when downsizing with bicubic shader or bicubicresize and with v1.4.6 SSIM and latest SSIM. This happens with my computer:

Original image (3840x2160)
http://i.cubeupload.com/CofSSm.png

Bicubicresize (1920x1080)
http://i.cubeupload.com/FPMQYM.png

Bicubic shader v1.4.6
http://i.cubeupload.com/vQXTG3.png

Bicubic shader latest
http://i.cubeupload.com/9T7nDy.png

SSIM v1.4.6
http://i.cubeupload.com/nwb5OE.png

SSIM latest
http://i.cubeupload.com/8FlM2W.png

burfadel

21st October 2016, 15:31

That's all over the place! Have you considered it might be because you are using Avisynth v2.60 from early 2015, and not the latest Avisynth+ build ( currently 2290, http://forum.doom9.org/showthread.php?p=1783382#post1783382 )?

I have a R9 280X currently (soon a RX 480), running Windows 10 x64 mind you, and don't have the same issue. This includes with the driver version you are using, but I am currently using the just released 16.10.2.

I would suggest trying the latest Avisynth+, use the installer here: http://www.dropbox.com/s/aqlcgzdsh76akki/AviSynth%2B%20r2172.7z?dl=0 made by Groucho2004 from the Avisynth+ thread. THEN copy the avisynth.dll file from the x64 2290 download to windows\system32 and the files in the plugins folder to c:\program files\avisynth+\plugins64+ folder, overwriting the existing files.

Download the currently latest AMD driver, 16.10.2, from, here:
http://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-Crimson-Edition-16-10-2-Release-Notes.aspx

Flux

21st October 2016, 23:43

I'm now using Avisynth+ 2290 and 16.10.2 drivers.

I still get the same images with the latest ResizeShader, but with v1.4.6 I get "Avisynth open failure: System exception - Access Violation (test.avs, line 2)" which is ImageSource("3840x2160.png", end = 0, use_DevIL=true)

burfadel

22nd October 2016, 04:09

I did a test using AvsPmod r452 using your settings above, and yes it does make the image much brighter! In fact, the result is identical to yours.

When I said I hadn't had any problems, I was only referring to normal video use, and by using it slightly differently! I also run a couple of other very subtle shaders, if I remove those you are left with:
ImageSource("n:\Test\CofSSm.png", end = 0, use_DevIL=true).converttoyv12()
ConvertToShader()
Resizeshader(1920,1080,kernel="ssim",b=0.5,convert=false)
ConvertFromShader(format="yv12")

So try that, changing the source name appropriately of course. It comes out properly!

It appears when you use resizeshader as a single function the colour conversion is broken, however when you do it separately using the above method (so you can run multiple shaders if desired with a single memory copy) it works perfectly.

Flux

22nd October 2016, 10:45

musicvideos4k

23rd October 2016, 03:25

As i appreciate MysteryX work, here's my work:

https://www.youtube.com/watch?v=hwFOmAj-AMM

Real Transfer Bt. 2020 and 10-bit HDR.

That's of course YT 709/8 , native hevc gets you BT. 2020 and 10.

Still you can watch it.

burfadel

23rd October 2016, 06:35

I got this

YV12

http://i.cubeupload.com/3beelb.png

YV24 (usually I want to preserve full chroma, so tested this too)

http://i.cubeupload.com/TgoQ0z.png

They look closer to original colors and brightness, but still wrong.

My mistake, I had a look back at the images and get the same result myself. In my haste I think I compared two of the same images! I do think it's a conversion issue though, maybe between linear light, gamma light, sigmoidal light, colourspaces, or whatever else!

MysteryX

23rd October 2016, 15:41

It does look like a conversion issue in the AVSI file, so that will be a lot easier to fix than if the code itself was broken.

Gser

9th November 2016, 22:53

I am now trying to figure out how I could convert some 4:2:2 to YV12 with this, using SSim as a chroma downscaler. Anybody have any ideas if this is possible?

MysteryX

18th November 2016, 12:14

I am now trying to figure out how I could convert some 4:2:2 to YV12 with this, using SSim as a chroma downscaler. Anybody have any ideas if this is possible?
AviSynthShader doesn't support working on single planes (I was about to add support for that but NVidia graphic cards don't support output on single plane textures).

It works only with full RGB data. Optionally, you could interpret the RGB fields as being YUV and processing them accordingly -- which works for some shaders and causes distortions for other shaders; and then keeping only the chroma channel.

However, considering the textures in and out of the shader are 4:4:4, it won't be ideal for your situation.

Mystery Keeper

19th November 2016, 16:28

AviSynthShader doesn't support working on single planes (I was about to add support for that but NVidia graphic cards don't support output on single plane textures).

It works only with full RGB data. Optionally, you could interpret the RGB fields as being YUV and processing them accordingly -- which works for some shaders and causes distortions for other shaders; and then keeping only the chroma channel.

However, considering the textures in and out of the shader are 4:4:4, it won't be ideal for your situation.
What a pile of bullshit. All cards can work with a single component textures.

dipje

22nd November 2016, 11:19

I'm trying this for the first time and I'm getting a "System Exception - Illegal Instruction" when I'm just trying a ConvertToShader(). The supplied SuperRes (and other) functions in Shader.avsi also give this on the ConvertToShader lines.

Windows 10 x64, Avisynth+ r2294 MT x64., AviSynthShader 1.5.6

Edit after trying some more:

Got it working on my x86 Avisynth. I actually don't know which one it is exactly, it seems to be an 'official' 2.6 (2.6.0.6?) build with no MT.
With that one I got the 'ProcessImage' error. Adding 'PlanarIn = false, PlanarOut = false' made it work.

NNedi3 + superres. NNedi3 is the software version, so my gpu usage (for superres and downscaling afterwards) is only about 13% so it must be possible to optimize a bit more, let's try to find some shaders that work with this.
Awesome to play with this, now only if it would work on (my) x64 :).

sacd

27th November 2016, 11:43

Not getting this to run using this script (x64)
LoadPlugin("C:\apps\AvisynthSwitcher\AVSPlugins\x64\Shader-x64")
LoadPlugin("C:\apps\AvisynthSwitcher\AVSPlugins\x64\nnedi3")
colorbars(width = 720, height = 576, pixel_type = "yv12").killaudio().assumefps("pal_double")
SuperRes(2, .43, 0, """nnedi3_rpow2(2, nns=4, cshift="Spline16Resize")""")

in current Avisynth+, avsmeter says:
AVSMeter 2.4.4 (x64) - Copyright (c) 2012-2016, Groucho2004
AviSynth+ 0.1 (r2294, MT, x86_64) (0.1.0.0)

ExecuteShader: ProcessFrame failed.
(C:/apps/AvisynthSwitcher/AVSPlugins/AutoLoad64/Shader.avsi, line 144)
(C:\Projekte\Test\Test_SuperRes.avs, line 4)

dipje

27th November 2016, 19:52

@sacd One post above yours is a possible solution. Searching for 'processframe' in this thread will yield more information.

@others: can it be that avisynthshader is compiled with AVX2 or something ? Or any other reason why I get 'illegal instruction' only with the x64 version ?

sacd

29th November 2016, 16:03

Oh boy, I really did not search before posting, what a no no, sorry that, geez.

@dipje Thanks, got it running now by adding those two

sacd

30th November 2016, 20:47

@others: can it be that avisynthshader is compiled with AVX2 or something ? Or any other reason why I get 'illegal instruction' only with the x64 version ?

I can confirm this to a degree, as on my old i7 980 I'm having illegal instruction too, while on i5 6600 it runs fine.

dipje

1st December 2016, 11:52

well that's a bummer. Would mean my i7-860 is out of luck and any AMD users are out of luck?

MysteryX

21st January 2017, 01:54

For CPU instructions, as per doc:
ConvertToShader, Opt: Optimization path. 0 for only C++, 1 for SSE2, 2 for AVX(only used with Precision=3), -1 to auto-detect. Default=-1

The AVX version is compiled separately, and in the latest version, I think I wasn't even compiling the AVX version because that code path wasn't even used by default. For those having troubles, does your CPU support SSE2? Does it work with Opt=0?

For those having trouble with x64, does it work with x86? I would need more precise details. Please make some tests with both x86 and x64 and tell me exactly which versions work and don't work, as well as the exact script you're using. From there, I can debug with these Avisynth versions.

What a pile of bullshit. All cards can work with a single component textures.
All cards (or most) can take single component textures as input, but NVIDIA cards can't use single component textures as the render target. Thus, single-component input is fine, but single-component output breaks on NVIDIA cards.

MysteryX

21st January 2017, 02:13

I just saw there is some SSSE3 code as well. This might be the issue.

dipje

21st January 2017, 11:31

I'll play around with the opt parameter . My script was a simple ffms2() with a converttoshader() with yv12 source IIRC.

Avisynth+ build at that time, the same revision of avisynth+ for x86 and x64.
The x64 gave 'illegal instruction' and the x86 worked fine.
CPU with sse4.2 level (so no AVX, but it does have Sse3).

Like I said, I will redo some testing (recently reinstalled os so everything is pretty clean ) to give you exact build numbers and versions and such.

MysteryX

21st January 2017, 16:20

I have to admit I did very little testing on x64 (and the memory usage is WAY higher which I found no way to fix -- at least on my graphic card, perhaps on other systems the driver handles memory differently -- can you test this?). If you tell me with more precision what works and what doesn't, that will help me correct the issue.

dipje

21st January 2017, 22:47

Well can't test memory usage for x64 since I didn't manage to get it working at all yet.

So, I didn't had any Avisynth at all installed on this system.
I installed Avisynth+R2294-MT, both x86 and x64. (You have to install it by first using the installer from R2172, then overwriting DLLs from R2294-MT..which is what I did).

Then copied 1.5.6 AvisynthShader package x86 and x64 to the corresponding plugin folders.
I used FFMS2 2.23.1 as source plugin, so my Avisynth script looks like this:
ffms2(source = "P9170146.MOV")
ResizeShader(Width = 1280, Height = 720, Kernel = "SSim", PlanarIn = True, PlanarOut = False)

The source file is a H264 1920x1080 p30 file, YV12 8bpp, progressive, no alpha. Nothing weird with it as far as I know.

I open the AVS file in x64 Virtualdub FilterMod (r38544) and I get 'Illegal Instruction':
https://snag.gy/94lJ7Z.jpg

I open the AVS file in x86 Virtualdub Filter Mod (r38543) and it works just fine.

The error is on line 339 in the Shader.avsi file, which is the 'ConvertToShader' call. I tried adding 'opt = 0', 'opt = 1', 'opt = 2', 'opt = 3' or 'opt = -1' to the parameters, but they all gave the same error.

I then tried setting PlanarIn to True in the 'ResizeShader' call. I get the same error message, but now on line 341 of Shader.avsi, on the Shader("LinearToYuv") call pretty much directly under it. Once again, the x86 version works fine.

I tried setting PlanarOut = True but that doesn't work at all, and gives the error 'ExecuteShader: ProcessFrame failed' which is to be expected on my nvidia card if I see the whole discussion about planar in/out.

If I convert the video to RGB first (ConvertToRGB24 / ConvertToRGB32. Is that still the way to do things with the new avs+ color format support? My Avisynth-syntax is a bit rusty) I can't get past the ConvertToShader call at all (I keep getting the 'System Error - Illegal instruction' at line 339 of Shader.avsi). No matter if I set PlanarIn to true or to false.

So, haven't got a single frame out of X64 yet. Can't say anything about performance or memory usage. But since all of my scripting pipeline is in x64 it's kinda of a bummer that I can't use the stuff in here.

Completely different question: Is there a shader variant of NNEDI3 that can be used in this easily / efficiently? I could only find the nnedi opencl port or the software versions.

MysteryX

22nd January 2017, 00:09

There is a NNEDI3 version here but I hadn't been successful at getting it to work. Have to confirm... what HLSL version is it using?
https://github.com/zachsaw/MPDN_Extensions/tree/master/Extensions/RenderScripts/NNEDI3

MysteryX

30th January 2017, 23:13

x64 works here so I can't test it, furthermore it seems to be coming from the code from Chikuzen and he hasn't posted on this forum for 6 months now. It takes someone with knowledge of assembly to look into it; I can't.

As for the conversion bug with ResizeShader with RGB clip, here's the fix.
Shader.avsi, line 341, replace
ConvertYuv ? Shader((PlanarIn ? "YV" : "Yuv") + "ToLinear" + MatrixIn + ".cso") : last
with
ConvertYuv ? Shader((PlanarIn ? "YV" : "Yuv") + "ToLinear" + MatrixIn + ".cso") : Shader("GammaToLinear.cso")

It performs the resize in Linear Light but wasn't converting from Gamma to Linear before resizing RGB clips.

MysteryX

30th January 2017, 23:34

I just saw there were changes from Chikuzen that I hadn't downloaded locally and thus weren't in the latest builds. I doubt it will fix the issue, but you can try. I just made a new compilation of the x64 library with his commit. Let me know whether that helps.
https://mega.nz/#!fdATyQRT!8Q_dYE1BHTpQMEayQIoO89cvAZUO4Zxk-S5lgm2eUm0

MysteryX

13th February 2017, 23:13

AviSynthShader v1.6 is ready! (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.6)

What's new:
- Added support for all new Avisynth+ clip formats
- Added support for native high-bit-depth clip formats
- ConvertToShader and ConvertFromShader now use native Avisynth+ functions for conversion, which results in better performance in several cases
- AviSynth 2.6 is still supported. ConvertToShader and ConvertFromShader have 2 code paths. Set Opt=2 to use the legacy code path. Opt=-1 will use Avisynth+ functions.
- Updated SSIM downscaler: more advanced XYZ processing

Known issues:
- RGB32 input with RGB64 output, or RGB64 input with RGB32, results in a color shift.
- PlanarIn works only with YUV input, and isn't supported on NVIDIA graphic cards. Leave it to false.
- 32-bit float formats are not currently supported

You might want to test the new vs old code paths with ConvertToShader and ConvertFromShader to detect any differences or subtle color shifts. To do so, edit shader.avsi and add Opt=2 to ConvertToShader and ConvertFromShader to use the legacy code path. This is a way of testing Avisynth+'s conversion functions to detect any rounding errors. I tested the old functions extensively, but haven't done this testing on the new functions.

The new code path shouldn't crash on Avisynth+ x64 anymore!

amayra

14th February 2017, 02:03

thank you for make AviSynthShader great again i will test 1.6 and comeback if i find issues

MysteryX

21st March 2017, 19:59

AviSynthShader v1.6.1 is ready! (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.6.1)

What's new:
- Fixed color shift with RGB32 input and RGB48 output
- Compiled with Visual Studio 2017

CkJ

7th April 2017, 21:29

Hi @MysteryX
I update the latest version and get this error https://i.imgbox.com/ISPA6GoC.png
My script:
loadplugin("AviSynthShader-1.6.1\Shader.dll")
import("AviSynthShader-1.6.1\Shader.avsi")
import("ResizeX_v1.0.1.avsi")
import("edi_rpow2_v1.0.avsi")
loadplugin("nnedi3.dll")
ImageSource("Lighthouse.png").ConvertToRGB24
SuperRes(2, .4, 0, """edi_rpow2(2, edi="nnedi3", cshift="spline36resize")""")

MysteryX

17th April 2017, 17:30

CkJ, your script works here. What version of Avisynth are you using? x86 or x64? Anyone else have this issue?

CkJ

17th April 2017, 21:36

I'm using Avisynth 2.6 x86.
https://i.imgbox.com/Ei7GXHMY.png

bxyhxyh

6th August 2017, 08:49

Ok. Can you make it support Y8?
If i need to use it only on luma that would speed up things.

No, HLSL shaders work on RGB data. Any other data format first needs to be converted into 16-bit RGB. Plus, the necessary colorspace conversions (Gamma to Linear RGB) wouldn't be possible with Y8 data.

Then what about this idea?
Adding boolean value called grayscaled or something.
If grayscaled is false, it works normally.
If grayscaled is true then after video is converted to RGB, it upscales only one channel of RGB clip and duplicate it and merge them together as R, G, and B channels since black and white video has all same value of R, G, B channels right?
By black and white, I mean YUV video converted to Y8 or YUV video that grayscale() function is called.

MysteryX

6th August 2017, 17:03

Instead, how about you simply convert your Y8 clip to RGB before calling it? Or to YV24 to do more precise color conversion on the GPU.

It would be good to process a single plane for performance reasons; but this idea gives no gain.

bxyhxyh

6th August 2017, 18:52

Instead, how about you simply convert your Y8 clip to RGB before calling it? Or to YV24 to do more precise color conversion on the GPU.

What's the point of doing that if SuperRes upscales all three channels of RGB clip?

It seems you didn't get the point, or I didn't explain it clear.

For example you would need to upscale only luma channel. Then upscale chroma with standard resizer and merge them together.
Something like

source=anysource()

luma = source.ConvertToY8()
lumabig = luma.superres()

u = source.utoY8().FasterAndSimplerResizer()
v = source.vtoY8().FasterAndSimplerResizer()

YtoUV(u,v,lumabig)

You said that's not possible because shader converts it to RGB clip anyway even if you make it to support Y8 clip. Therefore there is no gain.

So I'm telling if shader converts it to RGB then what about make it upscaling only one channel from THAT intermediate RGB clip internally? (since grayscaled clip has all same value for all three channels of RGB clip)

like this.

source=anysource()

luma = source.grayscale() # or luma = source.ConvertToY8()
lumabig = luma.superres(grayscaled=true) # this would upscale only one channel of RGB clip that's converted from 'luma' clip. Then duplicate it and merge them together in the process.

u = source.utoY8().FasterAndSimplerResizer()
v = source.vtoY8().FasterAndSimplerResizer()

YtoUV(u,v,lumabig)

MysteryX

6th August 2017, 19:40

Processing only 1 channel on the GPU and treating it as Luma is definitely possible. However, the bottleneck is memory transfer from the GPU, so you most likely won't see any performance gain. Also, SuperRes is designed to work with 3 planes of RGB data -- but different shaders can be designed to work with 1 Luma plane.

MysteryX

9th August 2017, 21:38

Version 1.6.2 is ready! (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.6.2)

What's new:
- Added Factor parameter to SuperXBR and SuperResXBR to upscale by a factor of 2, 4, 8 or 16 in one call

gmail123

19th August 2017, 13:34

gmail123

23rd August 2017, 05:45

my English is poor.
how to use full 16bit processing queue,get highest quality for video upscale.
sample:
LWLibavVideoSource("D:\film\12.mkv")
Dither_convert_8_to_16()
?
SuperRes(?)
?
DitherPost()

how to use "ConvertToShader(Precision=3)" 。

please help me.thanks.

MysteryX

23rd August 2017, 17:03

If using AVS 2.6 and Stack16 format, set lsb_in=true and lsb_out=true

If using AVS+, use ConvertBits(16) and ConvertBits(8, dither=0), and it will automatically process in 16-bit

If you're having issues with AVS 2.6 and YV12 format, try converting to YV24 first (ideally in 16-bit). That conversion needs to be done anyway.

gmail123

24th August 2017, 17:06

avs 2.6

https://imgbox.com/hJBS0AvY

gmail123

28th August 2017, 15:26

avs+,in megui, script:
AddAutoloadDir("D:\video\MeGUI\tools\avisynth_plugin")
LoadPlugin("D:\video\MeGUI\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("C:\Users\pc\Desktop\am.mkv")
ConvertBits(16)
SuperRes(3, .43, 0, """nnedi3_rpow2(2, nns=4, cshift="Spline16Resize")""")
ConvertBits(8, dither=0)
but
https://i.imgbox.com/Cd4F7oz6.png

gmail123

28th August 2017, 15:42

how to use Precision=3 or Precision=2?
please help me, Correct the error in the script.

ConvertToShader(3)
LWLibavVideoSource("C:\Users\pc\Desktop\am.mkv")
ExecuteShader(last,Clip1Precision=3,Precision=3,OutputPrecision=2)
ConvertFromShader(3)

ConvertBits(16)
SuperRes(3, .43, 0, """nnedi3_rpow2(2, nns=4, cshift="Spline16Resize")""")
ConvertBits(8, dither=0)

MysteryX

28th August 2017, 17:11

LWLibavVideoSource("C:\Users\pc\Desktop\am.mkv")
ConvertToShader(3)
ExecuteShader(last,Clip1Precision=3,Precision=3,OutputPrecision=2)
ConvertFromShader(2)

If OutputPrecision=2, ConvertFromShader must be 2. Note, however, that Precision=3 is half-float and it is slow to convert on the CPU. It is generally recommended to use 2(int) for input/output and 3(half-float) for internal processing on the GPU.

Also, ExecuteShader requires a command chain to execute. Right now you've got nothing to execute.

ConvertBits(16)
SuperRes(3, .43, 0, """nnedi3_rpow2(2, nns=4, cshift="Spline16Resize")""")
ConvertBits(8, dither=0)

This looks like a bug. I'll have to look into fixing a few bugs.

SaurusX

29th August 2017, 14:21

Thanks for your work on this, MysteryX. At this point I don't think there's a better upscaling process than SuperRes.

thecoreyburton

7th September 2017, 13:57

Hi MysteryX,

I'm looking to use AviSynthShader to apply various Retroarch shaders (https://github.com/libretro/common-shaders) to losslessly dumped pixel game footage and was wondering if you could help me. I've only ever lightly explored the world of shaders - enough to know that CG and HLSL are extremely similar (although not identical) - but I was hoping that some of those might work. So far I've had no luck, even for shaders known to work with HLSL compilers. I get a simple "Failed to open pixel shader" error message when trying the following script:

AVISource("Lossless.avi")
SourceFile=Last
ConvertToShader(Precision=1)
Shader("C:\dot.cg")
ExecuteShader(last, SourceFile, Clip1Precision=1, Precision=1, OutputPrecision=1)
ConvertFromShader(Precision=1,Format=RGB32)

In this case, test.cg can be any one of the shaders from the above link (though if something specific is required, I can select one). Is it an incompatibility between languages, or am I doing something wrong?

Edit: Here's a proper example file. (http://www.mediafire.com/file/r3hlknxdk61kun7/dot.cg) I'd like to get this working, though I know it may not be possible.