AviSynthShader + SuperRes [Archive]

MysteryX

2nd October 2015, 21:50

Shiandow wrote a scaling algorithm called SuperRes that greatly enhances upscaling. Unfortunately, it wasn't possible to use this code in AviSynth and I really wanted to use it. So, I wrote an AviSynth plugin that allows running any HLSL pixel shaders through DirectX9.

Download the latest release here (v1.6.4, September 20th 2017)
https://github.com/mysteryx93/AviSynthShader/releases
Source code available on GitHub
https://github.com/mysteryx93/AviSynthShader

This plugin allows running HLSL pixel shaders within AviSynth. This gives access to various HLSL filters that haven't been programmed in AviSynth.

Note: Shiandow's SuperRes is not what is typically being called SuperRes; it's something else. It does not "create" any details like traditional SuperRes or Sharpening algorithms do. It doesn't have any temporal effect either, it works with frames one by one. Here's the way it works. It wraps around other resizers. After doubling the image size (with NNEDI3 for example), it resizes it back down with Bicubic and compares it with the original, producing a diff map representing details that were lost while upscaling. Then, it does its magic from that diff map. How? Well... with this code (https://github.com/zachsaw/MPDN_Extensions/blob/master/Extensions/RenderScripts/SuperRes/SuperResEx.hlsl). Results speak for themselves. I found it to work best with NNEDI3(nns=4)

Syntax information on GitHub (https://github.com/mysteryx93/AviSynthShader)

Special thanks to Shiandow for writing such amazing code, and especially to make it open source!

Special thanks to Madshi for taking the time to give very valuable pointers when nobody else was able to help!

Here are comparison images
ImageSource("Lighthouse.png").ConvertToRGB24()

Note: Since uploading these comparison, SuperRes has slightly changed. The newer version has less ringing and softer images.

1. Original
2. Spline16
3. nnedi3_rpow2(4, nns=4, cshift="Spline16Resize")
4. SuperXBR(edgeStrength=.6, weight=.6), twice
5. SuperRes(2, .43, 0, """edi_rpow2(2, nns=4, cshift="Spline16Resize")"""), twice
6. SuperResXBR(2, .6, xbrEdgeStrength=2.3, xbrSharpness=1.2), twice
7. SuperResXBR(1, .7, xbrEdgeStrength=.1, xbrSharpness=.7), twice

Lighthouse
http://s20.postimg.cc/kvxnnc315/Lighthouse.png (http://postimg.cc/image/kvxnnc315/) http://s20.postimg.cc/yqrcs282h/Lighthouse_Spline16.png (http://postimg.cc/image/yqrcs282h/) http://s20.postimg.cc/qzamti3x5/Lighthouse_NNEDI3.png (http://postimg.cc/image/qzamti3x5/) http://s20.postimg.cc/qjurmqsm1/Lighthouse_Super_XBR.png (http://postimg.cc/image/qjurmqsm1/) http://s20.postimg.cc/5jkzo0vyx/Lighthouse_Super_Res.png (http://postimg.cc/image/5jkzo0vyx/) http://s20.postimg.cc/rjx0o4s7t/Lighthouse_Super_Res_XBR.jpg (http://postimg.cc/image/rjx0o4s7t/) http://s20.postimg.cc/kag1j6315/Lighthouse_Super_Res_XBR_tweak.jpg (http://postimg.cc/image/kag1j6315/)

Clown
http://s20.postimg.cc/dmgoidduh/Clown.jpg (http://postimg.cc/image/dmgoidduh/) http://s20.postimg.cc/a44olzcyh/Clown_Spline16.png (http://postimg.cc/image/a44olzcyh/) http://s20.postimg.cc/5yts02f6h/Clown_NNEDI3.png (http://postimg.cc/image/5yts02f6h/) http://s20.postimg.cc/xjmlrbwpl/Clown_XBR.png (http://postimg.cc/image/xjmlrbwpl/) http://s20.postimg.cc/ze1xq1mft/Clown_Super_Res.png (http://postimg.cc/image/ze1xq1mft/) http://s20.postimg.cc/v290kit3t/Clown_Super_Res_XBR.jpg (http://postimg.cc/image/v290kit3t/) http://s20.postimg.cc/enjolp0ih/Clown_Super_Res_XBR_weak.jpg (http://postimg.cc/image/enjolp0ih/)

Eclipse (x2)
http://s20.postimg.cc/i3dmushg9/Eclipse.jpg (http://postimg.cc/image/i3dmushg9/) http://s20.postimg.cc/kpt5bq8nt/Eclipse_Spline16.png (http://postimg.cc/image/kpt5bq8nt/) http://s20.postimg.cc/c3pvr4wnt/Eclipse_NNEDI3.png (http://postimg.cc/image/c3pvr4wnt/) http://s20.postimg.cc/e0mlvpnbt/Eclipse_XBR.png (http://postimg.cc/image/e0mlvpnbt/) http://s20.postimg.cc/j4brn5brt/Eclipse_Super_Res.png (http://postimg.cc/image/j4brn5brt/) http://s20.postimg.cc/fjbknekt5/Eclipse_Super_Res_XBR.jpg (http://postimg.cc/image/fjbknekt5/)

MysteryX

2nd October 2015, 21:52

SuperRes is one of may shaders that can be run with AviSynthShader. This particular shader greatly enhances upscaling quality and runs on top of any other algorithm you're already using such as NNEDI3.

SuperRes(input, passes, strength, softness, hqdownscaling, upscalecommand)

In Shaders\SuperRes\SuperRes.avsi. Thanks to Shiandow for writing this great code!

Arguments:

passes: How many SuperRes passes to run. Default=1.

strength: How agressively we want to run SuperRes, between 0 and 1. Default=1.

softness: How much smoothness we want to add, between 0 and 1. Default=0.

hqdownscaling: True to downscale using Bicubic, false to downscale using Bilinear.

upscalecommand: An upscaling command that must contain offset-correction. Ex: """nnedi3_rpow2(2, cshift="Spline16Resize")"""

Shiandow provides many other HLSL shaders available here that can be integrated into AviSynth.

https://github.com/zachsaw/MPDN_Extensions/tree/master/Extensions/RenderScripts

Here's a comparison of NNEDI3 with and without SuperRes.

Original
http://s30.postimg.cc/76lymfa3x/Original.jpg (http://postimg.cc/image/76lymfa3x/)

NNEDI3
http://s30.postimg.cc/53bjerab1/NNEDI3.jpg (http://postimg.cc/image/53bjerab1/)

NNEDI3 + SuperRes (passes=1, strength=1, softness=0)
http://s30.postimg.cc/b5j658yr1/Super_Res.jpg (http://postimg.cc/image/b5j658yr1/)

MysteryX

2nd October 2015, 22:06

As of right now, ConvertFromFloat isn't working towards RGB32. By fixing this, it would allow avoiding an unnecessary RGB-YUV conversion within SuperRes and may increase quality and performance.

The conversion code is here, could someone familiar with RGB32 help me on this one?

https://github.com/mysteryx93/AviSynthShader/blob/master/Src/ConvertFromFloat.cpp#L54

Then, we could also avoid an unnecessary conversion by doing the SuperRes downscaling via a Shader; I don't have any such code right now, and I don't know if the DLL code will have to be tweaked to allow HLSL resizing.

Another limitation is that although the library contains a HLSL YUV-RGB conversion and converting back and forth works fine, I get weird distortion after running any other shaders. When using CPU conversion, it works fine. However, the CPU conversion code is Rec601 instead of Rec709. Since it gets converted back using the same algorithm, it doesn't distort the output, but it may cause a slight distort on the shader processing.

foxyshadis

3rd October 2015, 01:34

You're officially my hero.

Edit: You're not incrementing dst properly. Since it's char, you're writing to it like:

00000000
ABC00000
ADEF0000
ADGHI000
etc.

A simple fix is swapping &dst[x],&dst[x+1],&dst[x+2] with &dst[(x*4)+2],&dst[(x*4)+1],&dst[x*4]. Note that I swapped the order because RGB32 is actually BGRA in memory.

The way the function's designed now isn't the greatest, but at least it'll work, that's most important.

MysteryX

3rd October 2015, 03:22

Thanks. Now it almost looks OK but the image is still corrupted. It gives a similar effect as to when I'm trying to use the HLSL YUV-RGB conversion.

http://s8.postimg.org/kezny3pdt/RGB.jpg (http://postimg.org/image/kezny3pdt/)

I also added a "folder" parameter to SuperRes to specify where to find the .cso files.

foxyshadis

3rd October 2015, 05:03

Is dst memsetted to 0? Could be garbage in the alpha bit. Actually, it's only happening on white, so it's probably not clamping. Should move the clamping outside of the if yuv/rgb block, along with memsetting (or just manually setting alpha to 0 each pixel).

MysteryX

3rd October 2015, 19:10

Great, it now supports converting to/from RGB32. SuperRes's downscaling is now done in RGB32, avoiding unnecessary RGB-YUV conversion. It considerably further increases quality.

http://s1.postimg.org/ywdz41xsb/Super_Res_RGB.jpg (http://postimg.org/image/ywdz41xsb/)

2 areas that still need improvement:

1. Find a Bicubic HLSL shader to avoid unnecessary conversion for downscaling.

2. Convert YUV-RGB in Rec709 colorspace. Because it is currently converting in the Rec601 colorspace, the sharpening effect may slightly pull towards certain colors.

Contributions or suggestions are welcomed on those.

And then, of course, there are all kinds of performance optimizations that could be implemented.

Here are some performance numbers. CPU-Z isn't reading my GPU usage properly so I can't measure what's happening on the GPU.

nnedi3_rpow2(2, cshift="Spline16Resize")
60fps @ 55% CPU
SuperRes(1, 1, 0, true, """nnedi3_rpow2(2, cshift="Spline16Resize")""")
4.5fps @ 12% CPU

MT=8
nnedi3_rpow2(2, cshift="Spline16Resize", Threads=2)
80fps @ 83% CPU
SuperRes(1, 1, 0, true, """nnedi3_rpow2(2, cshift="Spline16Resize", Threads=2)""")
15fps @ 85% CPU

Khanattila

3rd October 2015, 19:29

I have not had yet the opportunity to see the workings of Shiandow's SuperRes. Maybe is Farsiu or Mitzel. Really I have no idea.
I could make it a plugin like KNLMeansCL. If ever I have time.

MysteryX

3rd October 2015, 19:41

MysteryX

3rd October 2015, 20:47

I have added support for processing standard 8-bit-per-channel instead of 16-bit-per-channel. Simply add parameter "precision=1" to each conversion and shader calls. Quality is considerably lowered.

http://s17.postimg.org/hq0abhzob/Super_Res_Low_Precision.jpg (http://postimg.org/image/hq0abhzob/)

With MT=8
SuperRes(1, 1, 0, true, """nnedi3_rpow2(2, cshift="Spline16Resize", Threads=2)""")
I get 24fps @ 78% CPU

Khanattila

3rd October 2015, 22:06

SuperRes doesn't work like typical resize algorithms. It runs around other resizers. So let's say you want to use NNEDI3, it takes the larger image and the original image, does a Bicubic resize on the enlarged image to size it back down to the original, and then creates a difference map between the two, showing the details that were lost during the upsizing. From that diff map, it restores details and edges that were lost. Brilliant idea. It makes even basic resizers like Bilinear look decent.

Originally he was working on the Lab colorspace that definitely requires half-float data, and lately he dropped that to use Linear RGB colorspace. Perhaps I could try running with 8-bit-per-channel to see if there is a significant quality penalty.
Fairsu: pdf (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCEQFjAAahUKEwiF6Le8mafIAhXEWxoKHVEpAqg&url=https%3A%2F%2Fusers.soe.ucsc.edu%2F~milanfar%2Fpublications%2Fjournal%2FSRfinal.pdf&usg=AFQjCNGJxos8M3zENBWM0hDpVBz2mpuFOw&sig2=13oKvRdCwKgFKLLcTueuiQ&cad=rja).
Mitzel: pdf (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB8QFjAAahUKEwjP0tPfmafIAhXHCBoKHSlnBSE&url=https%3A%2F%2Fvision.in.tum.de%2F_media%2Fspezial%2Fbib%2Fmitzel_et_al_dagm09.pdf&usg=AFQjCNGe47IRN26hgwFe3-VaNlS1smvEeQ&sig2=yZsH7IOp4OHMj8d8CmjJ_A&bvm=bv.104317490,d.d2s&cad=rja).

That's what I was talking about. Like me or tritical, we did not invent NLMeans, but we simply implement a well known algorithm :)

MysteryX

3rd October 2015, 22:26

When using SuperRes, NNEDI3 and EEDI3 give almost identical output. Which means I can get rid of the ridiculously-expensive EEDI3.

1 pass with strength=.85 gives almost the same result as 2 passes with strength=.425, and 2 passes looks slightly better. 2 passes with NNEDI3 is faster than 1 pass with EEDI3. Splitting in 3 or more passes gives the exact same thing as 2 passes.

MysteryX

4th October 2015, 00:45

That's what I was talking about. Like me or tritical, we did not invent NLMeans, but we simply implement a well known algorithm :)
Shiandow isn't just implementing an existing algorithm, and this code isn't final. He's still working on it to try to find a better way to use Smoothness. Right now, it works better with Smoothness=0.

I'm seeing a weird bug when using 2 passes with strength=0.425, sometimes I get Access Violation, and it's random. Sometimes it starts anyway, and then fails unexpectedly. Now I'm running it with 1 pass with strength=0.85 and it's been running for half an hour without any issue. I really don't see why running a second pass could cause any such issue...

vivan

4th October 2015, 01:28

I have not had yet the opportunity to see the workings of Shiandow's SuperRes. Maybe is Farsiu or Mitzel. Really I have no idea.One thing that should be noted is that Shiandow's SuperRes is not a Super Resolution algorithm. I'd call it a "reverse downscaler" - it modifies upscaled image so that downscaled upscaled image is closer to the original image.

Shiandow

4th October 2015, 15:37

One thing that should be noted is that Shiandow's SuperRes is not a Super Resolution algorithm. I'd call it a "reverse downscaler" - it modifies upscaled image so that downscaled upscaled image is closer to the original image.

It's called "single frame super resolution" in literature though. The current implementation is most closely related to the method described in this paper (http://vision.eecs.northwestern.edu/papers/conference/2007/ICME07_Dai_final.pdf). The algorithms described by Faisru and Mitzel are for multi frame super resolution, which uses similar techniques but with a different goal.

MysteryX

4th October 2015, 18:45

I fixed a crash when the DX9 device was lost.

I also replaced the code to copy the data in and out of DX9 with AviSynth's BitBlt, and it considerably increases performance by itself.

input.ConvertToFloat().ConvertFromFloat() renders 38fps @ 12% CPU, and if I disable YUV-RGB conversion, 42fps. Could someone look at how this short code could be optimized?

MysteryX

4th October 2015, 19:53

The Access Violation error seems to be an out of memory error, plain and simple.

After playing some more with the settings, softness is actually working pretty well when using Strength=1 and 2 or 3 passes.

This is the best result I got with Passes=3, Strength=1, Softness=.25

http://s9.postimg.org/msn9rajyj/Super_Res3pass.jpg (http://postimg.org/image/msn9rajyj/)

There should be further increase in quality once I get to do Bicubic downscaling via shader, as it will avoid clamping on the diff map.

MysteryX

5th October 2015, 03:15

One thing I love about SuperRes is that before, to get the best quality upscaling, I would have to combine EEDI3 and NNEDI3 in the right order and add just the right amount of sharpening at 3 different stages.

With SuperRes, I get better quality with only NNEDI3 and no artificial sharpening. No fine-tuning is necessary per video, standard NNEDI3 frame doubling with SuperRes(Passes=2, Strength=1, Softness=.3) is working perfect for all the videos I tried so far.

For the media encoder I was working on, it will make it much simpler.

MysteryX

7th October 2015, 00:44

Updated the code and DLL.

- Increased performance
- Added Shader Width and Height parameters to set the output frame size. Default = same as source clip.

MysteryX

8th October 2015, 06:58

Fixed float-byte rounding to be more accurate by adding .5f before rounding. Slight performance improvement.

This results in the colors being slightly brighter, and the SuperRes Diff map to be more accurate which slightly improve its effectiveness.

I could make it a plugin like KNLMeansCL. If ever I have time.
As far as writing a native AviSynth version, I don't know if that would work. Originally, Shiandow was using the Lab colorspace which definitely requires half-float processing. He finally dropped it to use RGB Linear (not Gamma) colorspace. I doubt the YUV-RGB conversion could be avoided, and from my tests processing it with non-float data, the quality is considerably lower. This algorithm is very sensitive to details and must be processed with half-float precision. In that sense, perhaps native approaches wouldn't even be better than this. The GPU is much better at processing float data than the CPU.

Ghostlamer

8th October 2015, 12:27

Is there any way to make it work with rfactor larger than 2.
My script:

XviD4PSPPluginsPath = "C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\"

LoadPlugin(XviD4PSPPluginsPath+"nnedi3.dll")
LoadPlugin(XviD4PSPPluginsPath+"Shader.dll")

Import(XviD4PSPPluginsPath+"SuperRes.avsi")

SetMTMode(3,3)

AviSource("F:\2K\00.avi", audio=false, pixel_type="YV12")

SetMTMode(2)

SuperRes(2, 1, 0, false, """nnedi3_rpow2(rfactor=4, cshift="Spline16Resize", Threads=1)""")

Spline64Resize(2560,1380)

Without mtmode and rfactor 4 - stable working, but with 0.80fps with 6% cpu usage and 0% gpu, if i use rfactor=4 and setmtmode with more than 2 threads - crash, with 2 threads 1.40-1.60 fps and very low cpu and gpu usage.
Resolurion of original video 712x384.

MysteryX

8th October 2015, 17:14

It crashes because you're going past the 2GB memory limit. The code will need to be optimized.

Performance can be improved by rewriting the functions to convert frames to/from float. The float/halffloat conversion can be done with a buffer instead of 1 by 1 which probably would increase performance. Having a HLSL Bicubic resize function also would help.

As far as memory usage, I'm not sure what can be done. Each DirectX 9 device is creating its own threads and managing its own memory. A DX9 device is created each time a Shader is called. If there are 8 shader calls within SuperRes, and 4 threads, then that's 32 DX9 devices.

You can analyze your script with AVSMeter. Using 1 pass instead of 2 also will increase performance. According to my tests, NNEDI3 works best with 2 threads.

Try this
SuperRes(1, .85, 0, false, """nnedi3_rpow2(rfactor=4, cshift="Spline16Resize", Threads=2)""")

Khanattila

8th October 2015, 17:42

Fixed float-byte rounding to be more accurate by adding .5f before rounding. Slight performance improvement.

This results in the colors being slightly brighter, and the SuperRes Diff map to be more accurate which slightly improve its effectiveness.

As far as writing a native AviSynth version, I don't know if that would work. Originally, Shiandow was using the Lab colorspace which definitely requires half-float processing. He finally dropped it to use RGB Linear (not Gamma) colorspace. I doubt the YUV-RGB conversion could be avoided, and from my tests processing it with non-float data, the quality is considerably lower. This algorithm is very sensitive to details and must be processed with half-float precision. In that sense, perhaps native approaches wouldn't even be better than this. The GPU is much better at processing float data than the CPU.

Have you tried to normalize data in uint32_t? Without use floating-point numbers.
If working with processor is much faster.
unorm32 = (UINT32_MAX * (value - VALUE_MIN)) / (VALUE_MAX - VALUE_MIN)

If for example VALUE_MIN is 0 and VALUE_MAX is 255.
unorm32 = (4294967295 * value) / 255 = 16843009 * value
0 --> 0
1 --> 16843009
2 --> 33686018
...
255 --> UINT32_MAX

Groucho2004

8th October 2015, 18:16

Have you tried to normalize data in uint32_t? Without use floating-point numbers.
If working with processor is much faster.
Indeed. What's up with the obsession of some folks using floats lately? Even 64 bit (u)int is faster than 32 bit float.

MysteryX

8th October 2015, 19:04

Have you tried to normalize data in uint32_t? Without use floating-point numbers.
I could do some more experiment with that, the shader processing can be done with uint data. However, the way color conversion is currently done creates overflow so that won't work just yet; there would be "stuff" to fix in the color conversion first. The HLSL color conversion code should avoid overflow, but I was seeing weird behaviors when I tried using it so that's not yet working.

If we can get color conversion to avoid overflow and work properly, then we could try processing with uint data and see what performance difference it makes.

MysteryX

8th October 2015, 19:35

I'm leaving to China for 2 weeks and won't be playing with this. If someone wants to look into the code, you could look into
1. Getting the HLSL color conversion to work; or having CPU conversion that avoids overflows
2. Getting the shader to run with uint data (changing buffer format); which requires not having overflows
3. Optimizing the ConvertToFloat and ConvertFromFloat functions. Precision could have 3 values for ConvertToFloat, ConvertFromFloat and Shader functions: 1 (8-bit per channel), 2 (16-bit uint per channel) or 3 (16-bit float per channel)

luigizaninoni

8th October 2015, 19:37

I must be missing something obvious, but have you any idea why is AvsPMod giving error:

LoadPlugin: unable to load "c:\users\admin\desktop\shaders\shader.dll",Module not found. Install missing library ?

shader.dll is definitely in that directory

My script:
LoadPlugin("C:\Users\admin\Desktop\Video\Staxrip\Applications\DGMPGDec\DGDecode.dll")
LoadPlugin("c:\users\admin\desktop\shaders\shader.dll")
MPEG2Source("C:\Users\admin\Desktop\10-07-05-40-01-mozzibrb-TELECOLOR temp files\10-07-05-40-01-mozzibrb-TELECOLOR.d2v",cpu=6,ipp=true,moderate_h=40,moderate_v=60,idct=5)
Crop(2, 2, -2, -2)
QTGMC(Preset="Slow")
SelectEven()
SuperRes(2, 0.85, 0, true, """nnedi3_rpow2(rfactor=2, cshift="Spline16Resize", Threads=2)""", "C:\users\admin\desktop\shaders\")

Ghostlamer

8th October 2015, 20:14

It crashes because you're going past the 2GB memory limit. The code will need to be optimized.

Im using virtualdub and when the crash occurs, vdub process eat only 800-1100 mb.
Script working with setmtmode(3 and 5) instead of 2 (with more than 2 threads), but the output video - buggy (mode 3, 4-5 fps), low perfomance (mode 5, 0.5-0.8 fps).

Try this
SuperRes(1, .85, 0, false, """nnedi3_rpow2(rfactor=4, cshift="Spline16Resize", Threads=2)""")
Thanks for the advice.

MysteryX

8th October 2015, 20:41

btw, if anyone wants to play with the code, it's pretty simple, but you need
- DirectX SDK (http://www.microsoft.com/en-us/download/details.aspx?id=6812)
- Visual Studio (I'm making very little use of C++, it could be adapted to standard C with little changes)

GitHub allows you to download the source code, make your own changes and upload your contributions to the code. It takes some time to learn how use but then is very useful for collaborative projects. TortoiseGit makes it much easier to use.

Groucho2004

8th October 2015, 20:51

I must be missing something obvious, but have you any idea why is AvsPMod giving error:

LoadPlugin: unable to load "c:\users\admin\desktop\shaders\shader.dll",Module not found. Install missing library ?

shader.dll is definitely in that directory
Which OS are you using? If you're using Vista or above, use Dependency Walker to find out what's missing, possibly some of the DX stuff.

Ghostlamer

8th October 2015, 20:59

MysteryX, Triple quotes can be bypassed?, why I ask?, there is a script mt_pipeline http://forum.doom9.org/showthread.php?t=163281 , it allows to bypass the 2gb limit, but it also uses triple quotation marks and conflicts with supereres (but works very well with many others), i just not avisynth guru, do not know much.

MysteryX

8th October 2015, 21:34

I tried applying the 4GB patch to AVSMeter.exe, and it didn't work. The flag D3DXCONSTTABLE_LARGEADDRESSAWARE must also be added within the DX9 source code to make that work. Not sure why it hasn't worked yet.

Groucho2004

8th October 2015, 21:47

I tried applying the 4GB patch to AVSMeter.exe, and it didn't work.
LARGEADDRESSAWARE is one of linker options I use for the 32 Bit binary. No need to patch.

luigizaninoni

8th October 2015, 22:14

Which OS are you using? If you're using Vista or above, use Dependency Walker to find out what's missing, possibly some of the DX stuff.

Problem solved. d3dx9_43.dll was actually missing. Thank you very much for your kind advice

MysteryX

8th October 2015, 22:39

Problem solved. d3dx9_43.dll was actually missing. Thank you very much for your kind advice
How come was that file missing? Isn't it a system file that "should" already be there?

I just did an experiment with processing frames with int data instead of float. When initializing the device, I replaced the format D3DFMT_A16B16G16R16F by D3DFMT_A16B16G16R16. The performance is slightly faster but not that much. We might save some more in the data conversion. Obviously, with this test, the image was corrupt because it was processing half-float data as if it was uint, but it looked better than I would have expected.

There is definitely a bottleneck somewhere and it isn't the half-float shader processing.

In terms of numbers, I'm using this script
SetMTMode(3,4)
AviSource("Preview.avi", audio=false, pixel_type="YV12")
SetMTMode(2)
SuperRes(2, .42, 0, true, """nnedi3_rpow2(2, cshift="Spline16Resize", Threads=2)""")
Distributor()

With D3DFMT_A16B16G16R16 or D3DFMT_A16B16G16R16F, I get almost exactly the same numbers: 12fps @ 53% CPU. Memory usage also is the same.

One thing I found out is that creating a .def file (such as AVSMeter.def) with "STACKSIZE 512KB" in it slightly increases performance.

I also just did another quick test: removing the half-float conversions. It still calculates in float but then converts into short. Performance went way up from 12fps to 15-16fps.

Shiandow

8th October 2015, 23:32

Have you tried to normalize data in uint32_t? Without use floating-point numbers.
If working with processor is much faster.
unorm32 = (UINT32_MAX * (value - VALUE_MIN)) / (VALUE_MAX - VALUE_MIN)

If for example VALUE_MIN is 0 and VALUE_MAX is 255.
unorm32 = (4294967295 * value) / 255 = 16843009 * value
0 --> 0
1 --> 16843009
2 --> 33686018
...
255 --> UINT32_MAX

Indeed. What's up with the obsession of some folks using floats lately? Even 64 bit (u)int is faster than 32 bit float.

Well ,the original SuperRes code (designed for MPDN) used 16 bit uint for most of the processing. It does store an intermediate results in float, but that conversion is handled by the GPU itself. I'm not even sure if that part is necessary, signed ints would probably work just as well.

However the shaders will still use floats (single precision) internally. And as far as I know GPUs aren't that good at integer (or fixed point) arithmetic, but maybe that's changed.

Khanattila

8th October 2015, 23:43

Well ,the original SuperRes code (designed for MPDN) used 16 bit uint for most of the processing. It does store an intermediate results in float, but that conversion is handled by the GPU itself. I'm not even sure if that part is necessary, signed ints would probably work just as well.

However the shaders will still use floats (single precision) internally. And as far as I know GPUs aren't that good at integer (or fixed point) arithmetic, but maybe that's changed.

GPU are TERRIBLE with integer. But it have a fast internal conversion from integer to float.

Like KNLMeansCL, this is the way forward:
Read Integer Buffer --> GPU internal Conversion to normalized float --> Processing float --> GPU internal Conversion to integer --> Write to Integer Buffer.

Anyway, in this case it is better not to use float rather than converting by CPU.

MysteryX

9th October 2015, 01:06

I wouldn't be surprised if the DX9 function to convert half-float data is delegated to the GPU then, and that's what the buffer-processing function is for. If that's the case, then right now I'm sending commands to the GPU one by one. If I batch them into a buffer to be processed all at once, then performance would probably be MUCH better. Worth a try!

MysteryX

9th October 2015, 02:51

I edited ConvertToFloat to use a buffer for half-float conversions. It still calculates as float (which could be optimized by calculating int instead), stores all data into a large float buffer, converts the whole frame at once, then copy back into the frame. ConvertFromFloat doesn't have those changes yet.

That change brought the performance up from 12fps to 14.5fps.

MysteryX

9th October 2015, 03:36

ConvertToFloat and ConvertFromFloat are now both using a buffer for half-float conversion. Performance is now 18.5fps instead of 12fps. It could be further improved by calculating int data instead of float.

With this optimization, the CPU usage is also now higher, even with only 4 threads, so the whole script is running considerably faster.

Edit: I adapted ConvertToFloat to calculate color conversion with INT instead of FLOAT, performance further increased.

MysteryX

10th October 2015, 05:17

I further increased performance by using DirectXMath DirectX::PackedVector::XMConvertFloatToHalfStream instead of D3DXFloat32To16Array.

It went from 18.5fps to 20fps. CPU usage at only 40%.

ConvertToFloat is faster when calculating in INT, but ConvertFromFloat is faster with FLOAT than with INT.

luquinhas0021

5th November 2015, 04:19

MysteryX

6th November 2015, 00:11

New version v0.9.1 is released. It greatly reduces memory usage!! This version allows running several shaders in a row by creating command chains and calling ExecuteShader() at the end.

https://github.com/mysteryx93/AviSynthShader

As for SuperRes, it cannot yet fully benefit from this as I'm still missing a Bicubic downscaling shader that needs to be run in the middle. I can only combine 2 of the shader calls (twice if doing 2 passes), yet that's enough to considerably reduce memory usage. ConvertToFloat and ConvertFromFloat have also been modified to reduce memory usage.

With this version, you'll be able to run 8 threads without any issue.

If I can get a Bicubic downscaler, then we could remove unnecessary ConvertFromFloat and ConvertToFloat, as well as chain all of the commands to run at once, which would greatly improve memory usage and performance.

This Cubic code would work for Bicubic upscaling, but Bicubic downscaling requires a few tweaks. I can't do this as I know nothing about HLSL programming.
https://github.com/zachsaw/MPDN_Extensions/blob/master/Extensions/RenderScripts/ChromaScaler/Chroma.hlsl

MysteryX

6th November 2015, 00:42

Here's a comparison of the image quality.

Original
Spline16
NNEDI3(nns=4)
NNEDI3(nns=4)+SuperRes(passes=2, strength=.42)
http://s21.postimg.org/na30zwo2r/Original.png (http://postimg.org/image/na30zwo2r/)http://s21.postimg.org/vtmexnwf7/Spline16.png (http://postimg.org/image/vtmexnwf7/)http://s21.postimg.org/71msqff8j/NNEDI3.png (http://postimg.org/image/71msqff8j/)http://s21.postimg.org/amio9njs3/NNEDI3_Super_Res.png (http://postimg.org/image/amio9njs3/)

Result speak for themselves. It makes the image shaper without creating any artificial details.

If I eventually get a Bicubic HLSL downscaling, there might be a 'slight' further quality improvement.

wonkey_monkey

6th November 2015, 01:05

Here's a comparison of the image quality.

Result speak for themselves.

I find it very hard to see any difference. I don't think your choice of test image was a very good one - it doesn't have a lot of detail and looks very JPEGy.

luquinhas0021

6th November 2015, 01:10

Bloax

6th November 2015, 01:20

https://dl.dropboxusercontent.com/u/63152810/itnse3.png
Here's a nice still image if you need one. :-)

MysteryX

6th November 2015, 01:46

Here's some tests with the lighthouse and clown.

Original
Spline16
NNEDI3(nns=4, cshift="Spline16Resize")
NNEDI3+SuperRes(passes=2, strength=.42)
SuperRes+nnedi3_rpow2(rfactor=2, nsize=0, nns=4, qual=2, etype=0, cshift="SincResize", ep0=4, threads=0, opt=0, fapprox=0)
NNEDI3(nns=4, cshift="Spline16Resize")+SuperRes(passes=3, Strength=1, Softness=.85)

http://s24.postimg.org/qpoo33g41/Lighthouse_Original.png (http://postimg.org/image/qpoo33g41/)http://s24.postimg.org/o9mup8y1d/Lighthouse_Spline16.png (http://postimg.org/image/o9mup8y1d/)http://s24.postimg.org/fotiy2nv5/Lighthouse_NNEDI3.png (http://postimg.org/image/fotiy2nv5/)http://s24.postimg.org/3qryk6k41/Lighthouse_Super_Res.png (http://postimg.org/image/3qryk6k41/)http://s24.postimg.org/ep3olqpn5/Lighthouse_Sinc.png (http://postimg.org/image/ep3olqpn5/)http://s9.postimg.org/7cbmxgi0r/Lighthouse_Soft.jpg (http://postimg.org/image/7cbmxgi0r/)

http://s24.postimg.org/k85rjl5qp/Clown_Original.png (http://postimg.org/image/k85rjl5qp/)http://s24.postimg.org/qx7plv1ox/Clown_Spline16.png (http://postimg.org/image/qx7plv1ox/)http://s24.postimg.org/5ma5hljkh/Clown_NNEDI3.png (http://postimg.org/image/5ma5hljkh/)http://s24.postimg.org/n3iuqg9qp/Clown_Super_Res.png (http://postimg.org/image/n3iuqg9qp/)http://s24.postimg.org/panjxqvyp/Clown_Sinc.png (http://postimg.org/image/panjxqvyp/)http://s7.postimg.org/ewqjjvsxj/Clown_Soft.png (http://postimg.org/image/ewqjjvsxj/)

I see more difference between NNEDI3 and NNEDI3+SuperRes than between Spline16 and NNEDI3. There's also something funny happening with the reds... the reds are different but actually looks better with SuperRes. I've seen in a video with a chair where half of it was plain red (color cropping), that the texture of the chair somehow came back after passing it through SuperRes and it looked more like a chair afterwards. It must have to do with the way it's doing color conversion, but it's accidental. It seems to 'sometimes' recover cropped colors. Somehow. Another time I've seen it turn overflow colors into some other color

MysteryX

6th November 2015, 02:00

luquinhas0021, I couldn't answer the technical of how it's doing its job internally, but in SuperRes.avsi, you can see the diff map by returning the output of SuperResDiff.cso instead of processing the image with it.

Bloax, here's the result with your image

http://s10.postimg.org/7omfwhbcl/Eclipse_Original.png (http://postimg.org/image/7omfwhbcl/)http://s10.postimg.org/bz13s2gfp/Eclipse_Spline16.png (http://postimg.org/image/bz13s2gfp/)http://s10.postimg.org/madgkq851/Eclipse_NNEDI3.png (http://postimg.org/image/madgkq851/)http://s10.postimg.org/amjeq6j05/Eclipse_Super_Res.png (http://postimg.org/image/amjeq6j05/)http://s24.postimg.org/cyknk9841/Eclipse_Sinc.png (http://postimg.org/image/cyknk9841/)http://s7.postimg.org/wpc3rra5z/Eclipse_Soft.png (http://postimg.org/image/wpc3rra5z/)

luquinhas0021

6th November 2015, 02:06

Nice, MysteryX. The differences from nnedi3 upscaling to superres nnedi3 upscaling, at least the ones I realize, are less haloing and more sharpness. What if use the Sinc4, Lanczos4 and apply super resolution in each one?! I believe you apply SR in nnedi3 nns=4 with default parameters. What would happen if SR was applied in this script...?

nnedi3_rpow2(rfactor=2, nsize=0, nns=4, qual=2, etype=0, cshift="SincResize", ep0=4, threads=0, opt=0, fapprox=0)

MysteryX

6th November 2015, 02:24

I was using
nnedi3_rpow2(2, nns=4, cshift="Spline16Resize", Threads=2)

I have added the results with Sinc above.

luquinhas0021

6th November 2015, 02:31

it stayed sharper than all others algorithms! As I expected. After, I will test your SR algorithm with Lanczos4, because Sinc makes much ringing.
Only one question: You alrady put etype=1 (minimize squared error)? Comparing with etype=0, what you like more?

I JUST SEE YOU USED SINC EP0 =4.

MysteryX

6th November 2015, 02:39

I copy/pasted your command. I personally prefer the Spline16 over Sinc which looks more artificially processed.

I'm adding another test: NNEDI3(spline16)+SuperRes(Passes=3, Strength=1, Softness=.85)

Shiandow added Softness for the purpose of being able to use higher strength and passes and then softening it down. So far I wasn't convinced... I'll see better with this test. The previous tests I made, these settings looked good too, but not better than Passes=2, Strength=.42. Let's see what we get! HD pictures might make it better.

OK. With Softness, Clown and Eclipse look a LOT better, but it makes Lighthouse look like a painting. It works for some content but not all. Passes=2 with Strength=.42 gives more consistent results.

luquinhas0021

6th November 2015, 02:49

The algorithm you just post generates more ringing in letters of Eclipse image. But increases sharpness on Clown image. Maybe use 3 passes of superres don't be a gorgeus thing to do in all images. I suggest to you use my script, instead (...cshift="SincResize", ep0=4...), use (...cshift="Spline144resize"...) with passes=2, strenght=1 and softness=0,4.
In Lighthouse image, you last script generated aliasing in some parts.

MysteryX

6th November 2015, 07:07

Isn't Spline144 a broken algorithm? You're free to play with the algorithms and post your results.

Here are some tests with the lighthouse with NNEDI3(nns=4, cshift="Spline16Resize")

SuperRes(passes=2, strenth=XXX, softness=0)
Strength=30, 40, 50, 60, 100
http://s22.postimg.org/yct0gczkd/Lighthouse_Str30.png (http://postimg.org/image/yct0gczkd/) http://s22.postimg.org/61c1x251p/Lighthouse_Str40.png (http://postimg.org/image/61c1x251p/) http://s22.postimg.org/bqsahdb7x/Lighthouse_Str50.png (http://postimg.org/image/bqsahdb7x/) http://s22.postimg.org/fofk6ry19/Lighthouse_Str60.png (http://postimg.org/image/fofk6ry19/)http://s22.postimg.org/jfkjfcmbx/Lighthouse_Str100.png (http://postimg.org/image/jfkjfcmbx/)

SuperRes(passes=3, strenth=1, softness=XXX)
30, 40, 50, 60, 70, 80, 90, 100
http://s16.postimg.org/l1rsiyavl/Lighthouse_Soft30.png (http://postimg.org/image/l1rsiyavl/) http://s16.postimg.org/893oj0z9t/Lighthouse_Soft40.png (http://postimg.org/image/893oj0z9t/) http://s16.postimg.org/gz0rjvgr5/Lighthouse_Soft50.png (http://postimg.org/image/gz0rjvgr5/) http://s16.postimg.org/b5qpjb53l/Lighthouse_Soft60.png (http://postimg.org/image/b5qpjb53l/) http://s16.postimg.org/fg5dewa6p/Lighthouse_Soft70.png (http://postimg.org/image/fg5dewa6p/) http://s16.postimg.org/hlzo9edn5/Lighthouse_Soft80.png (http://postimg.org/image/hlzo9edn5/) http://s16.postimg.org/ao05h74wh/Lighthouse_Soft90.png (http://postimg.org/image/ao05h74wh/) http://s16.postimg.org/v6qg8itg1/Lighthouse_Soft100.png (http://postimg.org/image/v6qg8itg1/)

Which one is your favorite?

When playing with madVR, I found that NEDI+SuperRes were doing a good job together; would be worth a try to see how it compares to NNEDI3. Jinc+SuperRes, however, don't go well together.

SuperRes(passes=2, strength=.4, softness=0)

NNEDI3(nns=4, cshift="Spline16Resize")
NNEDI2(cshift="Spline16Resize")
NNEDI3(nns=3, cshift="Spline16Resize")
NNEDI3(nns=1, cshift="Spline16Resize")
http://s22.postimg.org/61c1x251p/Lighthouse_Str40.png (http://postimg.org/image/61c1x251p/)http://s8.postimg.org/4w126dncx/Lighthouse_NNEDI2_Str40.jpg (http://postimg.org/image/4w126dncx/)http://s13.postimg.org/wcfc9exkj/Lighthouse_NNEDI3_Str40.jpg (http://postimg.org/image/wcfc9exkj/)http://s14.postimg.org/xjpow0wct/Lighthouse_NNEDI3_NNS1.jpg (http://postimg.org/image/xjpow0wct/)

Honestly... NNEDI2 is doing ALMOST as good as NNEDI3(nns=4), but NNEDI3 with lower NNS gets blurrier. NNEDI2 gives a sharp output. The only downside is distortion on the white bars.

MysteryX

6th November 2015, 22:24

I have added a variant of SuperRes that does the YUV conversion via shaders. Performance is slightly lower, but the quality of colors is better. When doing YUV conversion on the CPU, I get 21fps. However, it is doing Rec.601 color conversion on Rec.709 content! When doing YUV conversion via shaders, I get 17fps (including processing NNEDI3). The first implementation might cause a very slight color distortion, and the 2nd implementation makes the colors more vivid.

To use this variant, use file SuperResYUV.avsi

Here's the comparison. Using SuperRes(passes=2, strength=.42, softness=0)

CPU conversion / GPU conversion

http://s24.postimg.org/3qryk6k41/Lighthouse_Super_Res.jpg (http://postimg.org/image/3qryk6k41/) http://s21.postimg.org/5kcn9j643/Lighthouse_YUV.png (http://postimg.org/image/5kcn9j643/)

http://s24.postimg.org/n3iuqg9qp/Clown_Super_Res.jpg (http://postimg.org/image/n3iuqg9qp/) http://s21.postimg.org/8bvx054mr/Clown_YUV.png (http://postimg.org/image/8bvx054mr/)

http://s10.postimg.org/amjeq6j05/Eclipse_Super_Res.jpg (http://postimg.org/image/amjeq6j05/) http://s21.postimg.org/499heszw3/Eclipse_YUV.png (http://postimg.org/image/499heszw3/)

EDIT: Now this is embarrassing and strange... when I put both versions side-to-side on my computer, I can clearly see a difference. But once converted to PNG, I honestly can't see any difference at all! Perhaps whatever color this makes is being discarded by PNG compression? But PNG is supposed to be lossless. Not sure on this one.

luquinhas0021

6th November 2015, 22:40

I don`t know if you saw things like me, but there`s a strange effect in lighthouse when use softness with passes=3. The bigger is amount of softness, a little, little more sharper it`s this photo. Don`t know why!
You asked me about which parameters I like. Then, for not take risk, I preffer passes=2, strenght=1, softness=0. From passes=3, looks like algorithm blurs the photo, and, with passes=3, softness sharp then. I may be wrong, but this is what I`ve seen.

MysteryX

6th November 2015, 23:48

Yeah, I don't like the effect of Softness, it's not working well. Shiandow might improve it in the future. For now, Passes=2 and Strength=.42 works best for noisy material, and for clear images, you can get away with 2 passes of strength up to 1.

I figured out what I did wrong in the last test: I was upscaling with nns=1 and comparing with the previous results that had nns=4!

Here's a new test of frame quadrupling.

Spline16
edi_rpow2(2, nns=4, cshift="Spline16Resize") uses NNEDI3 but fixes a few details
SuperRes(passes=2, strength=.42)
SuperRes (YUV conversion done on GPU)
SuperRes (YUV conversion done on GPU) + NNEDI2

http://s18.postimg.org/nf8rjtcet/4x_Clown_Spline.png (http://postimg.org/image/nf8rjtcet/) http://s18.postimg.org/3tfp9vklx/4x_Clown_EDI.png (http://postimg.org/image/3tfp9vklx/) http://s18.postimg.org/sp94xd79x/4x_Clown_Super_Res.png (http://postimg.org/image/sp94xd79x/) http://s18.postimg.org/4k8ffnmz9/4x_Clown_Super_Res_Yuv.png (http://postimg.org/image/4k8ffnmz9/) http://s15.postimg.org/uw6w8pfrb/4x_Clown_Super_Res_NNEDI2.jpg (http://postimg.org/image/uw6w8pfrb/)

http://s23.postimg.org/xgk2zw7qf/4x_Lighthouse_Spline16.png (http://postimg.org/image/xgk2zw7qf/) http://s23.postimg.org/xulezhrtz/4x_Lighthouse_NNEDI3.png (http://postimg.org/image/xulezhrtz/) http://s23.postimg.org/sx7uedpuv/4x_Lighthouse_Super_Res.png (http://postimg.org/image/sx7uedpuv/) http://s23.postimg.org/ljsgff5t3/4x_Lighthouse_Super_Res_NNEDI3.png (http://postimg.org/image/ljsgff5t3/) http://s23.postimg.org/nzu9t9nvr/4x_Lighthouse_Super_Res_NNEDI2.png (http://postimg.org/image/nzu9t9nvr/)

Interestingly enough, the 3rd one (which is the I had been testing before) has some distortion with frame quadrupling! Not sure where that's coming from... The newer implementation doesn't have that distortion... or is that the distortion I saw when using NNEDI2? Here's also with NNEDI2 to compare.

EDIT: NNEDI2 is *slower* than NNEDI3(nns=4), so we can discard it, although it gives *almost* identical results. The new implementation with YUV conversion on the GPU does give considerably better image quality. There's a lot less color distortion on the Lighthouse.

luquinhas0021

7th November 2015, 03:39

Can you provide me the file I should paste in Avisynth plug-in folder? Or can you tell me how I install your algorithm in Avisynth?

MysteryX

7th November 2015, 05:48

I have improved the performance of the YUV conversion via shaders.

You'll need Shader.dll and the AVSI and CSO files within "Shaders\SuperRes". You might have to specify the "folder" argument to tell SuperRes.avsi where to find all the CSO files. Ideally I'll want to automate that parameter.

SuperRes converts colors on the CPU, while SuperResYUV converts via Shaders. I'll probably remove the CPU-conversion implementation as the other one gives better quality, and now performance is similar. It "was" slower but then the CPU usage was also lower so you could just increase the amount of threads to make it up. Now it runs even better.

foxyshadis

7th November 2015, 06:53

MysteryX, I didn't speak any SR algorithm creates artificial details. What I wanted say is common SR algorithms analizes a set of neighbour frames or, in a single image, a lot of similar patterns, in order to, let's say, replicate details from a frame to another.
Your algorithm first upscale image using some algorithm, then downscale it using BiCubic and compare it to original image, creates a difference map, upscale the missing parts and paste into upscale image. This was what I understood.
But, generally, upscaling are detail lossy and downscaling, too. So, probably, the difference map will show so much difference. What I really want know is how the details that are in original image, but aren't in downscaled upscaled image, are pasted into upscaled image, i.e, how this details are upscaled.
David Horman, I don't see so much difference too. The maximum I see was some ringing, in SuperRes image, disappear.

You should be using the term temporal super-resolution to minimize everyone's confusion over your posts. The SuperRes shader could be considered non-linear spatial super-resolution (the way deconvolution is also spatial super-resolution). Please open another thread if you'd like to discuss research into temporal super-resolution, since that's drifting way off topic; if you can come up with something good, I'm all ears. I'd suggest actually having a prototype to discuss instead of just throwing open the discussion, though.

foxyshadis

7th November 2015, 07:01

http://s23.postimg.org/sx7uedpuv/4x_Lighthouse_Super_Res.png (http://postimg.org/image/sx7uedpuv/) http://s23.postimg.org/ljsgff5t3/4x_Lighthouse_Super_Res_NNEDI3.png (http://postimg.org/image/ljsgff5t3/)

Any reason why CPU vs GPU results in such a strong red->blue color shift? The same applies to clown, too. Different color matrices maybe?

http://s18.postimg.org/sp94xd79x/4x_Clown_Super_Res.png (http://postimg.org/image/sp94xd79x/) http://s18.postimg.org/4k8ffnmz9/4x_Clown_Super_Res_Yuv.png (http://postimg.org/image/4k8ffnmz9/)

The clown also doesn't seem to make a lot of sense: SR CPU has a ton of aliasing, while SR GPU has none. Obviously that's a point in GPU's favor, but any idea why that is?

MysteryX

7th November 2015, 08:26

I didn't create the name for the shader; if you have any complaints about the name, contact Shiandow directly :) It's not temporal, it only processes frames one at a time.

The CPU color conversion is for Rec.601 while the content is Rec.709. Obviously, this creates some slight color distortion. It also creates some overflows. The Shader conversion is Rec.709 and doesn't create overflow. I also saw that the CPU conversion code was creating some image distortion, not sure exactly why.

I just realized. Since the GPU conversion doesn't overflow, I can use UINT16 data instead of half-float for the video buffers. This may slightly increase processing speed, and mostly it will greatly save on data conversion time as it currently needs to convert to/from half-float 7 times when running 2 passes!! This should greatly improve performance!

MysteryX

7th November 2015, 10:40

v0.9.2 is released. SuperRes.avsi now uses GPU conversion; you can still test CPU conversion with SuperResCPU.avsi

It now converts to UINT16 data instead of half-float. Convert with precision=2 for UINT16, precision=3 for half-float. "convertYuv" parameters are now false by default.

Performance went from 21.5fps to 27fps!

The output appears to be exactly the same.

MysteryX

7th November 2015, 20:18

Further improved performance, especially on the UINT16 conversion. Also fixed a mix-up in HLSL files that might have corrupted the output if you tried it yesterday.

I'm now getting 33fps. It's getting very decent!

By the way, this might also cause color distortion. I don't know if it's using the right color matrix here.
ImageSource("Lighthouse.png").ConvertToYV12()

luquinhas0021

7th November 2015, 20:45

MysteryX, you`ve done the test with eedi3 sclip nnedi3 + superres? Both nnedi3 and eedi3 in parameters which gives maximum quality. If yes, stays sharper and retains more details than nnedi3 only or eedi3 only?

MysteryX

7th November 2015, 21:27

I had tried EEDI3 a while ago and it didn't give good results. EEDI3 gives a softer image. SuperRes works better with something more sharp. Jinc doesn't work well either.

sqrt(9801)

10th November 2015, 20:20

Hi.

I've been trying to convert Super-xBR for use with AvisynthShader, and it looks like there's an issue when using command chains on shaders that take parameters.

Here is my script :

edge_strength = 1
weight = 1
third_pass = true

ColorBars(width=640, height=480, pixel_type="RGB32")

input=ConvertToFloat(precision=3)
input

Shader(path="Shaders/Super-xBR/super-xbr-pass0.cso",\
clip1=1,output=1,\
param1="args0="+string(edge_strength,"%.32f")+","+string(weight,"%.32f")+"0,0f",\
param2="size0="+string(width/2)+","+string(height)+","+string(2./width,"%.32f")+","+string(1./height,"%.32f")+"f",\
height=width,width=height*2)

Shader(path="Shaders/Super-xBR/super-xbr-pass1.cso",\
clip1=1,output=1,\
param1="args0="+string(edge_strength,"%f")+","+string(weight,"%f")+"0,0f",\
param2="size0="+string(width/2)+","+string(height)+","+string(2./width,"%.32f")+","+string(1./height,"%.32f")+"f")

third_pass ? Shader(path="Shaders/Super-xBR/super-xbr-pass2.cso",\
clip1=1,output=1,\
param1="args0="+string(edge_strength,"%f")+","+string(weight,"%f")+"0,0f",\
param2="size0="+string(width/2)+","+string(height)+","+string(2./width,"%.32f")+","+string(1./height,"%.32f")+"f") : nop

last.ExecuteShader(input,precision=3)

ConvertFromFloat(format="RGB32",precision=3)

First, you'll notice that the width/height parameters taken by the Shader function are actually reversed. Second, here's the output :

http://abload.de/thumb/chaino9s3d.png (http://abload.de/image.php?img=chaino9s3d.png)

Outputting the results of the first two passes to a new clip makes thing worse, since it seems to ignore the width/height parameters specified in the first command.

Shader(path="Shaders/Super-xBR/super-xbr-pass0.cso",\
clip1=1,output=2,\
param1="args0="+string(edge_strength,"%.32f")+","+string(weight,"%.32f")+"0,0f",\
param2="size0="+string(width/2)+","+string(height)+","+string(2./width,"%.32f")+","+string(1./height,"%.32f")+"f",\
height=width,width=height*2)

Shader(path="Shaders/Super-xBR/super-xbr-pass1.cso",\
clip1=2,output=3,\
param1="args0="+string(edge_strength,"%f")+","+string(weight,"%f")+"0,0f",\
param2="size0="+string(width/2)+","+string(height)+","+string(2./width,"%.32f")+","+string(1./height,"%.32f")+"f")

third_pass ? Shader(path="Shaders/Super-xBR/super-xbr-pass2.cso",\
clip1=3,output=1,\
param1="args0="+string(edge_strength,"%f")+","+string(weight,"%f")+"0,0f",\
param2="size0="+string(width/2)+","+string(height)+","+string(2./width,"%.32f")+","+string(1./height,"%.32f")+"f") : nop

Output :
http://abload.de/thumb/chain2rosmj.png (http://abload.de/image.php?img=chain2rosmj.png)

If I execute the shaders one by one, like so :

input=ConvertToFloat(precision=3)
input

Shader(path="Shaders/Super-xBR/super-xbr-pass0.cso",\
clip1=1,output=1,\
param1="args0="+string(edge_strength,"%.32f")+","+string(weight,"%.32f")+"0,0f",\
param2="size0="+string(width/2)+","+string(height)+","+string(2./width,"%.32f")+","+string(1./height,"%.32f")+"f",\
height=width,width=height*2)

input=last.ExecuteShader(input,precision=3)

input

Shader(path="Shaders/Super-xBR/super-xbr-pass1.cso",\
clip1=1,output=1,\
param1="args0="+string(edge_strength,"%f")+","+string(weight,"%f")+"0,0f",\
param2="size0="+string(width/2)+","+string(height)+","+string(2./width,"%.32f")+","+string(1./height,"%.32f")+"f")

input=last.ExecuteShader(input,precision=3)

input

third_pass ? Shader(path="Shaders/Super-xBR/super-xbr-pass2.cso",\
clip1=1,output=1,\
param1="args0="+string(edge_strength,"%f")+","+string(weight,"%f")+"0,0f",\
param2="size0="+string(width/2)+","+string(height)+","+string(2./width,"%.32f")+","+string(1./height,"%.32f")+"f") : nop

third_pass ? last.ExecuteShader(input,precision=3) : nop

ConvertFromFloat(format="RGB32",precision=3)

I get this (same output as Super-xBR in MPDN, as far as I can tell) :
http://abload.de/thumb/not-chainbssao.png (http://abload.de/image.php?img=not-chainbssao.png)

Sure, it works, but the increased VRAM usage is not negligible.
Now, if I hardcode the shaders' parameters into the HLSL files and chain the resulting shaders :

input=ConvertToFloat(precision=3)
input

Shader(path="Super-xBR/super-xbr-hardcoded-pass0.cso",\
clip1=1,output=1,\
height=width,width=height*2)

Shader(path="Super-xBR/super-xbr-hardcoded-pass1.cso",\
clip1=1,output=1)

third_pass ? Shader(path="Super-xBR/super-xbr-hardcoded-pass2.cso",\
clip1=1,output=1) : nop

last.ExecuteShader(input,precision=3)

ConvertFromFloat(format="RGB32",precision=3)

I get exactly the same output (verified with ImageMagick's compare function), so I won't link another image. ;P

TL;DR :
1) There's an issue when using command chains on shaders that take parameters.
2) The width and height parameters taken by the Shader function are reversed.
3) The width and height parameters taken by the Shader function are ignored when not outputting to clip #1.

MysteryX

10th November 2015, 20:58

Keep in mind that by default it's not converting pixel type from YUV to RGB anymore, but you're using RGB as the image source so that's not an issue. If you do need to convert, the recommended approach is to either
A) Chain a call to YuvToGamma with other shader calls (performance cost)
or even better
B) Include a call to YuvToGamma within the first Shader being called (no extra overhead)

As for precision, you can use 3 (half-float) for testing and development but this code path is considerably slower. Once it's working, Precision=2 (default) is recommended unless you need to have values that overflow the 0-1 range.

I was told by Shiandow that in HLSL, it's difficult to get some code to *not* execute, so if parts of code are optional, he'd rather compile a different version of the file (such as the final pass of SuperRes).

As for the parameters, you're right: Width and Height were reversed. This is now fixed.

As for the rest, could you send me your files so that I can reproduce the issues locally? Send me both the files that work and the files that don't work.

sqrt(9801)

11th November 2015, 01:07

Sure thing. CSO and HLSL files should be attached to the post (it's just a lazy hack of MPDN's Super-XBR code). Hardcoded versions is meant for 2X upscaling 640x480 clips.

Additionally, I think I've figured out what's going on with the shader parameters.

I made a simple shader, which takes a single float value as input and multiplies every pixel by it.

sampler s0 : register(s0);
float mul : register(c0);

float4 main(float2 tex : TEXCOORD0) : COLOR0
{
return mul*tex2D(s0,tex);
}

And here's my test script :
ColorBars(width=640, height=480, pixel_type="RGB32")

ConvertToFloat()
input=last

Shader(path="Shaders/test.cso",\
clip1=1,output=1,\
param1="mul=.5f")

last.ExecuteShader(input)

ConvertFromFloat(format="RGB32")

And here's the output :
http://abload.de/thumb/test13pybx.png (http://abload.de/image.php?img=test13pybx.png)

Now if I chain the shader twice with different values for mul :
Shader(path="Shaders/test.cso",\
clip1=1,output=1,\
param1="mul=1f")

Shader(path="Shaders/test.cso",\
clip1=1,output=1,\
param1="mul=.5f")

It looks like mul is set to 0.5 for the entire chain :
http://abload.de/thumb/test2atzco.png (http://abload.de/image.php?img=test2atzco.png)

So I compiled the same shader with "register(c0)" replaced with "register(c1)."

# c0
Shader(path="Shaders/test.cso",\
clip1=1,output=1,\
param1="mul=1f")

# c1
Shader(path="Shaders/test2.cso",\
clip1=1,output=1,\
param1="mul=.5f")

Which gives me the correct result.

So I'm guessing that basically, a register is set to the last value entered in the chain... or something like that. Bummer.

MysteryX

11th November 2015, 01:56

Ah... got it. The ConstantTable containing parameters isn't switching properly when setting the pixel shader...

MysteryX

11th November 2015, 02:25

Not yet sure what's the right way of solving this, but I made a temporary fix. It's now working, although the design and performance may not be optimal. For now I'm re-parsing and re-setting all parameters on every call.

sqrt(9801)

11th November 2015, 21:06

Doesn't seem to work on my end, I'm not sure why.

Anyway, I've attached a shader for bicubic resampling since you've been looking for one. Since this my first time coding anything more complex than an inversion shader in HLSL, I may (read "must") have gotten some things wrong. :p

Example of use :
input_width = 1600
input_height = 1024

output_width = 640
output_height = 180

ColorBars(width=input_width, height=input_height, pixel_type="RGB32")
Subtitle("Réfrigérateur !", align=1, size=80)

source=last

Shader(path="bicubic.test.cso",\
param1="out_size=" + string(output_width) + "," + string(output_height) + "," + string(1./output_width,"%.32f") + "," + string(1./output_height,"%.32f") + "f",\
param2="in_size=" + string(input_width) + "," + string(input_height) + "," + string(1./input_width,"%.32f") + "," + string(1./input_height,"%.32f") + "f",\
param3="BC=" + string(1/3.,"%.32f") + "," + string(1/3.,"%.32f") + "f",\
width=output_width,height=output_height)

last.ExecuteShader(source.ConvertToFloat())

ConvertFromFloat(format="RGB32")

Compare(source.BicubicResize(640, 180, b=1./3., c=1./3))

Output :
http://abload.de/img/testwduvz.png (http://abload.de/image.php?img=testwduvz.png)

This should theoretically enable running multiple SuperRes passes in a single command chain, among other things, but I keep running into that issue with shader parameters. orz

MysteryX

11th November 2015, 22:29

Thanks! Are you sure your Bicubic downscaling is working? You may contact Shiandow if you need help with the specifics of the implementation. Or he might review your final code to ensure it's designed right.

Heck, better as well produce a shader that works both for upscaling or downscaling.

Once you're sure the Bicubic downscaling is working properly on its own, I can integrate it into the chain and test/debug/benchmark it at the same time. I also want to see whether there is a noticeable quality difference.

For handling color spaces, is there a AVS function to get the current color space? Right now ConvertToFloat supports YV24 and RGB32, while SuperRes only supports YV24. "SuperResDiffCpu.cso" could be renamed "SuperResDiffRgb.cso" to process RGB clips that require no YUV conversion. Then within SuperRes.avsi, I run the regular shaders if the source is YV24, and the 2nd version if the source is RGB32. But how do I get the source format?

As for all other formats, they are also supported if you just call ConvertToYV24() or ConvertToRGB32() before SuperRes.

By the way, whenever you see a large image like this, keep in mind that once converted to 16-bit-per-channel, Clip.Width is twice bigger than it should be so it needs to be divided by 2.

sqrt(9801)

11th November 2015, 23:55

Upscaling/downscaling works in the sense that I don't get any visible difference compared to Avisynth's internal bicubic resizer in my tests. PSNR is usually around 60 dB, which is okay, I guess ? Seriously though, this is probably due to the higher precision, and the way the shader treats borders. I think Avisynth also resizes in two passes ??

I've also noticed some difference when using it in SuperRes. The current version using the internal bicubic filter actually produces incorrect color on some parts of the ColorBars clip, probably because the clip is converted to linear RGB (via the GammeToLinear shader) beforehand. That issue doesn't appear when using the bicubic shader.

As for getting a clip's colorspace from a AVS script, you have the IsRGB24/IsRGB32/IsYV12/IsYV24 etc. functions. They should get the job done.

MysteryX

12th November 2015, 04:19

I tried your Bicubic. First, better call the main function "main" so that we don't need any special arguments to compile.

Then, with your CSO file, setting the arguments failed. Not sure why. I tried compiling the file myself to know I'm working with the right thing.

If I type in this command, then it loops indefinitely and never compiles.
"C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Utilities\bin\x86\fxc.exe" /T ps_3_0 /Fo "Bicubic.cso" "src\SuperRes\Bicubic.hlsl"

I think something is wrong.

sqrt(9801)

12th November 2015, 04:42

I'm not sure why the CSO doesn't run. Have you tried with the sample AVS script I posted earlier ?

Compilation takes longer than usual because the loops can't be unrolled. It takes ~90 seconds to compile on my end with the same command (more or less, I just have an additional /O3 switch.)

MysteryX

12th November 2015, 07:41

OK I got it working. I also fixed the issue with shader parameters. This fix may have a slight performance cost for now but at least it's finally working.

As expected, running all shaders in a chain with HLSL Bicubic downscaling does improve the quality very slightly. With MT=8, memory usage went down from 921MB to 688MB which is considerable. Performance is slightly better with CPU usage considerably lower.

I have also added support for YV24 and RGB32 in SuperRes.avsi. However, I can't test it with RGB32 because NNEDI3 doesn't support RGB32!

Could you send me your Super-xBR code when you got it fully working? I'll add it to the project.

MysteryX

12th November 2015, 08:02

In practice, the benefits are greater. In a more complex script that calls SuperRes twice combined with a bunch of other processing, memory usage went down from 1700MB to 1000MB, and performance went up from 5fps to 7fps!

MysteryX

12th November 2015, 22:09

I have improved the handling of shader parameters to fix a few issues
- Improved performance by avoiding to parsing string values on every call
- Invalid values now return an error
- INT vectors now supported
- Default values specified within the shader should now be respected

**BREAKING CHANGE**
The format of parameters has changed. Instead of
Param1="input=640,480f"
it will now be
Param1="640,480f"

Parameters are now configured by index only, we don't need to pass the names anymore.

I'm still hesitating whether the first param should be called Param1 or Param0... and also for clips.

StainlessS

12th November 2015, 22:52

For handling color spaces, is there a AVS function to get the current color space? Right now ConvertToFloat supports YV24 and RGB32, while SuperRes only supports YV24. "SuperResDiffCpu.cso" could be renamed "SuperResDiffRgb.cso" to process RGB clips that require no YUV conversion. Then within SuperRes.avsi, I run the regular shaders if the source is YV24, and the 2nd version if the source is RGB32. But how do I get the source format?

Here something that might assist (OK in both v2.6 and v2.58).

Function ColorSpaceIx(clip c) {
cs=c.IsRGB24?0:c.IsRGB32?1:c.IsYUY2?2:c.IsYV12?3:-1
return(cs>=0||VersionNumber<2.6)?cs:c.IsY8?4:c.IsYV16?5:c.IsYV24?6:c.IsYV411?7:-1
}

EDIT: Above is for script, which is what I thought you meant.
If was meaning C/CPP then you will have more problems unless providing both v2.5 and v2.6 plugins.

sqrt(9801)

12th November 2015, 23:00

"Parameters are now configured by index only"

What does that mean exactly ? Param1 sets c0, param2 sets c1, etc... ?

MysteryX

13th November 2015, 00:35

It's already working for RGB colorspace.

"Parameters are now configured by index only"

What does that mean exactly ? Param1 sets c0, param2 sets c1, etc... ?
Yes

I have just added support to convert to/from RGB24. Now we can test NNEDI3 and SuperRes without YUV conversion.

MysteryX

13th November 2015, 01:06

Here are some image tests in RGB24, without YUV conversion.

ImageSource("Lighthouse.png").ConvertToRGB24()

1. Spline16Resize(Width*4, Height*4)
2. edi_rpow2(2, nns=4, cshift="Spline16Resize", threads=2), twice
3. edi_rpow2(4, nns=4, cshift="Spline16Resize", threads=2)
4. SuperRes(2, .43, 0, """edi_rpow2(2, nns=4, cshift="Spline16Resize", threads=2)""", PluginPath), twice
5. SuperRes(2, .43, 0, """edi_rpow2(4, nns=4, cshift="Spline16Resize", threads=2)""", PluginPath)

http://s21.postimg.org/mwcg0d91v/Lighthouse_Spline16.png (http://postimg.org/image/mwcg0d91v/) http://s21.postimg.org/pg82ugwlv/Lighthouse_NNEDI3_2.png (http://postimg.org/image/pg82ugwlv/) http://s21.postimg.org/xbim9a68j/Lighthouse_NNEDI3_4.png (http://postimg.org/image/xbim9a68j/) http://s7.postimg.org/hfs3ar1lj/Lighthouse_Super_Res_2.png (http://postimg.org/image/hfs3ar1lj/) http://s7.postimg.org/bqbuqfvfb/Lighthouse_Super_Res_4.png (http://postimg.org/image/bqbuqfvfb/)

EDIT: That's wrong, SuperRes doesn't appear to be running!

sqrt(9801)

13th November 2015, 01:34

Yeah, it looks like that last update broke something. Shaders don't seem to do anything at all right now.

MysteryX

13th November 2015, 01:51

OK it's fixed and I updated the images.

**Breaking Change**
You now set C0 with Param0 and C1 with Param1, instead of C0 with Param1 and C1 with Param2. For clips, it's still S0=Clip1, S1=Clip2.

The SuperRes image is considerably darker than the NNEDI3 version, not sure why. If the pixel conversion would slightly darken, then there would be a slight color tone between running it once or twice, which is not the case.

Suicycle

13th November 2015, 10:55

hello everyone. this looks like a great app. thanks for the hard work and sharing it.

I am getting this error every time I try to launch the codes below and can't figure out what is wrong.

Error line :
ConvertFromFloat : Source must be float-precision RGB

These are the codes I am using. (got them from this thread) I am not a programmer. I don't know anything about coding. So all I am doing is to copy paste the codes I find on the internet (mostly in this forum). But I have checked out the basic usage of Avisynth for beginners.

I have Avisynth 2.6 installed with VirtualDub 1.10.4
I am on a win 8.1 64bit pc but avisynth and virtualdub are 32 bits.
I have tried the same codes with other avisynth versions. I always got an error (not the same error tho)

LoadPlugin("C:\Program Files\AviSynth\Plugins\nnedi3.dll")
LoadPlugin("C:\Program Files\AviSynth\Plugins\Shader.dll")
Import("Shaders\SuperRes\SuperRes.avsi")
SetMTMode(3,4)

ImageSource("1.png").ConvertToYV12()

SetMTMode(2)

SuperRes(2, 1, 0, false, """nnedi3_rpow2(rfactor=4, cshift="Spline16Resize", Threads=1)""" )

Spline64Resize(2560,1380)

I get the same error even if I take out the .ConvertToYV12() code. I have tried it with jpgs, tifs, pngs etc. I get the error every time. What should I do? any ideas?

sqrt(9801)

13th November 2015, 15:55

ImageSource outputs to RGB24 by default. Try with ConvertToRGB32 or use ImageSource("1.png", pixel_type = "RGB32")

Also, it looks like you're using an outdated version. You should update it, since the new version supports more colorspaces.

MysteryX

13th November 2015, 17:18

Don't forget to pass the "folder" parameter to SuperRes so it knows where to find the CSO files. Also make sure you have the latest DLL as I have been updating it many times.

Suicycle

14th November 2015, 01:09

Thank you, it works now. I updated all the files, added the file path and then realized there was something extra in the codes. I removed it and it worked.

MysteryX

14th November 2015, 07:41

sqrt(9801), do you have Super-xBR working? If so, can you send it over?

sqrt(9801)

14th November 2015, 13:23

Sure thing. A (haphazardly made) AVS function is included.

Btw, it looks like your version of the SuperRes shader is outdated compared to the one currently found in the MPDN_Extensions repo.

MysteryX

14th November 2015, 19:05

The SuperRes code I have is Oct 2, there's a Oct 10 versio. You're right.

What is super-xbr-params.inc ?

Could you also include a .BAT file to batch-compile the files?

MysteryX

14th November 2015, 20:24

The new version of GPU-Z now detects my GPU usage on my Radeon HD 7670M.

I've done a benchmark test.
SetMTMode(3,8)
AviSource("F:\AVSMeter\Preview.avi", audio=false, pixel_type="YV12")
SetMTMode(2)
SuperRes(2, .43, 0, """nnedi3_rpow2(2, cshift="Spline16Resize", Threads=2)""")
Distributor()

It runs at 34fps, with GPU usage between 60-70%. Increasing threads to 16 doesn't help much; at first it's considerably higher and then it goes back down.

Groucho2004

14th November 2015, 22:59

sqrt(9801)

15th November 2015, 00:00

super-xbr-params.inc is just part of the super-xbr.hlsl file (you can see it has an #include "super-xbr-params.inc" directive.) Not sure why Hyllian felt the need to make a separate file just for the shader's parameters.

As for batch compilation, this is the command I've used.
fxc.exe /T ps_3_0 /O3 /E main_fragment /D Pass=0 /Fo super-xbr-pass0.cso super-xbr.hlsl

fxc.exe /T ps_3_0 /O3 /E main_fragment /D Pass=1 /Fo super-xbr-pass1.cso super-xbr.hlsl

fxc.exe /T ps_3_0 /O3 /E main_fragment /D Pass=2 /Fo super-xbr-pass2.cso super-xbr.hlsl

MysteryX

15th November 2015, 01:01

Super-xBR is working. Here are some tests of image quadrupling

NNEDI3
Super-xBR (default settings)
NNEDI3 + SuperRes
Super-xBR + SuperRes
Super-xBR(edgeStrength=.6, weight=.6)
Super-xBR(edgeStrength=.6, weight=.6) + SuperRes

http://s9.postimg.org/e0sq5p41n/Clown_NNEDI3.png (http://postimg.org/image/e0sq5p41n/) http://s9.postimg.org/vteadkla3/Clown_Super_XBR.png (http://postimg.org/image/vteadkla3/) http://s9.postimg.org/44rn61y9n/Clown_Super_Res.png (http://postimg.org/image/44rn61y9n/) http://s9.postimg.org/e4mjly9iz/Clown_Super_Res_XBR.png (http://postimg.org/image/e4mjly9iz/) http://s1.postimg.org/qi5wic04b/XBR_6.png (http://postimg.org/image/qi5wic04b/) http://s1.postimg.org/6z1b8z1cr/Super_Res_XBR_6.png (http://postimg.org/image/6z1b8z1cr/)

Way too much ringing. So far NNEDI3 + SuperRes is what works best.

Edit: added Super-xBR with edgeSrength=.6 and weight=.6

SuperRes reduces Super-xBR's halo, and this video is almost as good as NNEDI3+SuperRes

MysteryX

15th November 2015, 03:42

I have released Super-xBR and updated SuperRes AVS script. I also applied some updates to the SuperRes HLSL code.

Right now for Super-xBR I'm not doing YUV-RGB conversion... and it looks pretty much the same in YUV or RGB.

MysteryX

15th November 2015, 05:46

sqrt(9801), if you got some time, perhaps you could look into doing the same with NEDI?
https://github.com/zachsaw/MPDN_Extensions/blob/master/Extensions/RenderScripts/Shiandow.Nedi.NediScaler.cs

MysteryX

15th November 2015, 06:10

You do remember what the "Distributor()" call does (http://forum.doom9.org/showthread.php?p=1728771#post1728771), right?
Removing Distributor() does reduce the amount of threads and considerably reduces CPU usage, although performance is about the same overall. Thanks

MysteryX

15th November 2015, 06:54

I fixed the slight darkening issue.

Conversion to UINT16 gave values between 0 and 255*256=65280. Add 128 to avoid darkening when converting back.

sqrt(9801)

15th November 2015, 15:19

Why not just multiply the UINT8 value by 257 ?

As for NEDI, I'll check it out. Thanks for the suggestion.

MysteryX

15th November 2015, 17:50

Why not just multiply the UINT8 value by 257 ?
Interesting suggestion. Multiplying by 257 and dividing by 256 would produce "valid" results but would cause a subtle shift in colors.

Suicycle

15th November 2015, 18:07

Hello again, guys I have a question. I hope this is not out of topic but say that I have a 1080p footage which is nicely shot with a DSLR.

Even though the footage has no quality problem, when I upload it to Youtube, the quality will be reduced automatically.

So what I am planning to do is that I will upscale the 1080p footage (say by 2x) by using SuperRes and then downscale it back to 1080p using one of the good downscale functions (blackmanresize maybe?). Since SuperRes will enhance the quality when it upscales, it will look better when downscaled. And then I'll upload it to Youtube like that.

Does this make sense? Is my logic right?

MysteryX

15th November 2015, 20:10

Your output when you upload it to YouTube will still be 1080p. What benefit will you get? YouTube won't reduce your resolution, but it will greatly reduce the bitrate.

The only way for YouTube to use a higher bitrate is to upload it in higher resolution, such as in 2160 resolution. In which case, it will re-encode using a higher bitrate.

Suicycle

15th November 2015, 21:53

OK I got it, since it's only about bit rate, then downscaling won't change anything. Thank you.

MysteryX

15th November 2015, 23:42

I tested with the updated SuperRes code and with the HLSL Bicubic code. Quality is *considerably* better. The shape of objects is much more defined than before. Not sure if it's due to the Bicubic code or due to the SuperRes core update.

Edit: Interesting... in my script, I'm running InterFrame after SuperRes, and the update is causing InterFrame to generate more accurate frames. I didn't expect this update to have so much impact. In theory, the new encoded video (after all my processing) should be about the same size, and in practice, the new video is 87.3MB instead of 85.4MB with fixed quality encoding, because there are more details to encode. That's a big difference!

The readme file will need to be considerably updated.

MysteryX

16th November 2015, 03:29

Version 1.0 released.

luigizaninoni

18th November 2015, 13:05

great plugin, still slowish with intel HD4600, so no hope of real time, but results are great.

I guess that porting to Vapoursynth and/or to Avisynth+ 64bits would not really help, since the bottleneck is the graphic card, isn't it ?

MysteryX

18th November 2015, 14:59

You can use SuperRes for real-time playback with madVR, but both NNEDI3 and SuperRes are very expensive so don't count on it unless you have a top-end graphic card!

SuperRes makes even Bicubic upscaling look decent. If you upscale with Bicubic and run a single pass, then you'll get much higher performance.

That being said, with my Radeon HD 7670M, I can't get GPU usage to go above 60-70%. Not exactly sure where the bottleneck is.

luquinhas0021

19th November 2015, 21:25

MysteryX

20th November 2015, 01:03

MysteryX, is the superresolution plugin you are discussing here able to take off the artifacts which are introduced by some upscaling algorithm? Example: bicubic -1, 1 is sharpest, but generates a lot of aliasing. If I use this same type of bicubic, with your superresolution plugin, will result image be free of aliasing, or, at least, with less aliasing compared with result image of only bicubic?

It does appear so. That's the case with Super-xBR. It generates very sharp images but massive ringing, and applying SuperRes on top of it reduces the ringing and makes it very decent. Experiment with it.

jinkazuya

23rd November 2015, 06:02

I also have some problem using this script too. According to the error message, it is stated that "There is no function named ConvertToFloat". I checked the script, there is no such a function but there is such a function call within the code. Besides there is also no function named ConvertFromFloat either.

StainlessS

23rd November 2015, 16:44

jinkazuya
You will also need to say where the relevant plugins are, and if you are audoloading or explicitly loading (in your script).
You best at least provide your script so that MysteryX can see what you are doing wrong.
It sounds like the plugin is not being loaded.

MysteryX

24th November 2015, 07:42

MysteryX

24th November 2015, 23:20

Version 1.1 released.

What's new:
- Shader will now attempt open relative paths in the same folder as the DLL.
- Folder argument removed from SuperRes and Super-xBR. CSO files must be in the same folder as Shader.dll
- Added ColorMatrix.avsi for high bit dept color matrix conversion to avoid banding
- SuperRes now has srcMatrix601 argument allowing to convert color matrix while running SuperRes with no performance cost.

https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.1

SSH4

25th November 2015, 09:24

Am i only one here who think that original NNEDI 2x/4x looks MUCH better in any case than SuperRez(NNEDI,EEDI,Makemehappy,pass=100) ?

Groucho2004

25th November 2015, 09:29

Am i only one here who think that original NNEDI 2x/4x looks MUCH better in any case than SuperRez(NNEDI,EEDI,Makemehappy,pass=100) ?You may be the only one who bothered to compare them. :D

SSH4

25th November 2015, 09:50

You may be the only one who bothered to compare them. :D

Ah, my mistake. This is public diary? ;)

But serious.
SuperRes version of Clown picture looks like billinear upscaled awarpsharped and blurred after this picture.

"In the Nightside Eclipse" upscaled cover looks good because original source have uniform noise from scanned offset print. And such median/awarpsharp filters can help "remove" this noise without losing much details.

Groucho2004

25th November 2015, 10:26

SuperRes version of Clown picture looks like billinear upscaled awarpsharped and blurred after this picture.

"In the Nightside Eclipse" upscaled cover looks good because original source have uniform noise from scanned offset print. And such median/awarpsharp filters can help "remove" this noise without losing much details.
I assumed that you compared the scalers with real footage, not static images. So, nothing new really...

SSH4

25th November 2015, 11:16

I assumed that you compared the scalers with real footage, not static images. So, nothing new really...

Spatial "filter" have better result in "real" video footage than on static frame?

Idea of diff between NNEDI3 and billinear scale have rights to live. At least for creating mask for problematic part of image that you can refine. But "real" mpeg encoded footage will produce non usable mask in this method, because of noise and encoding blocks.
So faster and better just create edge mask with masktools and "smart" sharp edges on image.
Oops i just reinvented Deede's scripts for sharpen ;)

Anyway, sorry. I just asked for opinion about quality in results of this "SuperRes".

MysteryX

25th November 2015, 17:01

Spatial "filter" have better result in "real" video footage than on static frame?

Idea of diff between NNEDI3 and billinear scale have rights to live. At least for creating mask for problematic part of image that you can refine. But "real" mpeg encoded footage will produce non usable mask in this method, because of noise and encoding blocks.
So faster and better just create edge mask with masktools and "smart" sharp edges on image.
Oops i just reinvented Deede's scripts for sharpen ;)

Anyway, sorry. I just asked for opinion about quality in results of this "SuperRes".
It's actually working very well on noisy videos. NNEDI3 cannot be applied for noisy MPEG sources, what worked was EEDI3 followed by NNEDI3. With SuperRes, I'm able to do it only with NNEDI3.

MysteryX

25th November 2015, 21:10

Here's a sample noisy 288p MPEG video re-encoded with this script.

PluginPath=""
LoadPlugin(PluginPath+"Shader.dll")
LoadPlugin(PluginPath+"KNLMeansCL.dll")
LoadPlugin(PluginPath+"nnedi3.dll")
Import(PluginPath+"edi_rpow2.avsi")
Import(PluginPath+"ResizeX.avsi")
Import(PluginPath+"SuperRes.avsi")
LoadPlugin(PluginPath+"svpflow1.dll")
LoadPlugin(PluginPath+"svpflow2.dll")
Import(PluginPath+"InterFrame2.avsi")

SetMTMode(3,8)
AviSource("Preview.avi", audio=true, pixel_type="YV12")
SetMTMode(2)
Crop(0, 0, -8, -0)
SetMTMode(5)
KNLMeansCL(D=2, A=1, h=3, device_type="GPU")
SetMTMode(2)
SuperRes(2, 0.43, 0, """edi_rpow2(2, nns=4, cshift="Spline16Resize", Threads=2)""", srcMatrix601 = true)
InterFrame(Cores=8, Tuning="Smooth", NewNum=60000, NewDen=1001, GPU=true)
SuperRes(2, 0.43, 0, """edi_rpow2(2, nns=4, cshift="Spline36Resize", fwidth=944, fheight=724, Threads=2)""")
Spline36Resize(940, 720, 0, 4, -4, -0)

Original video (https://www.spiritualselftransformation.com/files/media-encoder-old.mpg)

New video (https://www.spiritualselftransformation.com/files/media-encoder-new2.mkv)

Previously, the best approach was to use EEDI3+NNEDI3 which gave a more blurry result. Afterwards, I improved with 2-3 passes of fine-tuned sharpening at various stages of the scaling. The SuperRes version looks better and I can go without EEDI3 and without sharpening.

SSH4

26th November 2015, 03:12

It's actually working very well on noisy videos. NNEDI3 cannot be applied for noisy MPEG sources, what worked was EEDI3 followed by NNEDI3. With SuperRes, I'm able to do it only with NNEDI3.

NNEDI3 Can and Work perfectly with noisy MPEG sources. Just check some great upscales made by anime release groups.

But "Noise MPEG Source" + NNEDI3 != "perfect upscale".

You should divide work for steps.

Analyzing source and understanding problems it have.

Healing noised, blocked mpeg source (if you can't find/buy better quality source for you work).
Usually in this step you will use temporal denoisers with MVDegrain/Dfttest/etc with motion compensation with detail protection with masks etc.

After healing source you can upscale with NNEDI.

After this you can sharpen or refine upscaled picture.
And in final you can add some noise back for hide some upscale/deblocking errors and for better encoding.

Just check Example scripts from MVTools2, dfttest.

Sometime you need use different methods for different part of source video. For video - one method, for hardcoded subtitle another. And merge results in final step. But not one bullet for all.

Hmm, just checked on your source. dfttest(sigma=30) and nnedi3 give better result than your SuperRes 8)

foxyshadis

26th November 2015, 10:03

Hmm, just checked on your source. dfttest(sigma=30) and nnedi3 give better result than your SuperRes 8)

If you're going to claim something's better, at least post a screenshot comparison so we can judge too.

MysteryX

26th November 2015, 16:22

If you're going to claim something's better, at least post a screenshot comparison so we can judge too.
I agree. There are standard protocols to follow on this forum. If asking for help on a video, post that video. If claiming better results, post exact script and screenshots to compare. Standard stuff you should know.

I've previously tried working with any EEDI3/NNEDI3 combination, KNLMeans and FF3DFilter denoisers. NNEDI3 was too sharp for that source. The result of Denoise+EEDI3+NNEDI3 was fine... except that when playing the unprocessed video with madVR with SuperRes activated, I couldn't say for sure whether the original video or the processed video looked better. Perhaps my processed video looked 'slightly' better, but the one passing through madVR with SuperRes was definitely sharper. Now the new processed videos are definitely better.

If you find something that works better, I'd love to see it!

MysteryX

26th November 2015, 18:58

v1.2 released (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.2)

What's new:
- Added precisionIn and precisionOut arguments to ExecuteShader, allowing converting data on the GPU
- SuperRes, Super-sBR and ColorMatrix scripts adapted to convert with precision=1 while doing the processing with precision=2
- Removed D3DCREATE_DISABLE_PSGP_THREADING flag from DirectX9 device
- Performance is similar, memory usage is slightly lower and CPU usage is considerably lower

Here's a benchmark comparison while running SuperRes
SuperRes(2, .42, 0, """nnedi3_rpow2(2, cshift="Spline16Resize", Threads=2)""")

Before
FPS (min | max | average): 1.882 | 1000000 | 28.72
Memory usage (phys | virt): 598 | 679 MB
Thread count: 158
CPU usage (average): 57%

With data conversion on the GPU
FPS (min | max | average): 1.778 | 1000000 | 27.33
Memory usage (phys | virt): 590 | 662 MB
Thread count: 158
CPU usage (average): 51%

Without the D3DCREATE_DISABLE_PSGP_THREADING flag
FPS (min | max | average): 1.882 | 1000000 | 27.38
Memory usage (phys | virt): 595 | 666 MB
Thread count: 166
CPU usage (average): 45%

The performance isn't better. In fact it is 'slightly' slower. However, memory usage is slightly lower (679 to 666), and CPU usage is considerably lower (57% to 45%).

EDIT: This update now makes it possible to do the processing with half-float data (precision=3) since the conversion doesn't need to be done on the CPU. This results in higher performance. This change will be in the next release, and for now you can apply this fix by replacing precision=2 with precision=3 in SuperRes.avsi on ExecuteShader.

FPS (min | max | average): 2.667 | 1000000 | 29.09
Memory usage (phys | virt): 594 | 666 MB
Thread count: 169
CPU usage (average): 45%

SSH4

27th November 2015, 03:05

If you're going to claim something's better, at least post a screenshot comparison so we can judge too.
really strange seen this from such skilled doom9 member. I thought you better than me understand difference between any kind spatial "magic" and temporal denoisers.

Ok.

I did not preprocess source or postprocess results.

http://s14.postimg.org/rjpcn8359/New_File_3_002340.png (http://postimg.org/image/rjpcn8359/) http://s14.postimg.org/epratvppp/New_File_3_002341.png (http://postimg.org/image/epratvppp/)

http://s14.postimg.org/uzhgws0dp/New_File_3_006180.png (http://postimg.org/image/uzhgws0dp/) http://s14.postimg.org/ftbf5uact/New_File_3_006181.png (http://postimg.org/image/ftbf5uact/)

Both results are weird. But at least dfttest(sigma=30) don't have so much weird mpeg blocks. And this is only simple sigma=30. dfttest can be adjusted in spatial and temporal parts use noise sample etc., or if you need better results can use with motion compensation.

UPD:
Hmm. I did not seen any words about realtime upscaling.
But if SuperRes is realtime upscaler all my question are useless.

bxyhxyh

27th November 2015, 07:25

That superpupermagicshaderscript actually looks better for me.

When I doing 720p DVD upscales on animated source, I prefer nnedi3+"debilinear" combination.
DVD animations 2x upscaled by nnedi3 looks like it is upscaled from 720p source using bilinear.
And Debilinear helps to reduce "blown up" effect of them. Because it inverts blown up effect caused by Bilinear.
But SuperRes seems widen the lines.

For live action sources, nnedi3 is not really good choice to upscale for me. So I choose better one by comparing them.
Actually I don't even upscale them.

This is a comparison
DGDecode_mpeg2source("VTS_01_1.d2v", info=3)
#SuperRes(2,upscalecommand="""nnedi3_rpow2(2,nns=4,cshift="spline36resize",fwidth=960,fheight=720)""")
#nnedi3_rpow2(2,nns=4).Dither_convert_8_to_16().Dither_resize16(960,720,-0.5,-0.5,kernel="bilinear",invks=true).Ditherpost(mode=6)
#Spline36Resize(960,720)
source - https://dl.dropboxusercontent.com/u/58215671/Other/source.png
Spline36 - https://dl.dropboxusercontent.com/u/58215671/Other/spline36.png
nnedi3+deb - https://dl.dropboxusercontent.com/u/58215671/Other/nnedi%2Bdeb.png
SuperRes - https://dl.dropboxusercontent.com/u/58215671/Other/superres.png

SSH4

27th November 2015, 10:42

Well if you prefer dark artifacts on edges. Than SuperRes is right choice!

http://s1.postimg.org/p9yczusiz/image.png (http://postimg.org/image/p9yczusiz/)http://s1.postimg.org/41koife23/image.png (http://postimg.org/image/41koife23/)
Spline36 SuperRes

I tried upscale non-animation source, and eedi+nnedi is probably best for this. But for Anime NNEDI still unbeatable.

That superpupermagicshaderscript actually looks better for me.
BTW.
This is comparison between simple temporal denoiser + nnedi3 upscale with "BlackBox" pre/post processing shader.
Just add LimitedSharpenFaster or any other wonderful Didée sharpen script to "temporal denoiser + nnedi3" and result will be amazing.

bxyhxyh

27th November 2015, 11:10

Well if you prefer dark artifacts on edges. Than SuperRes is right choice!

I tried upscale non-animation source, and eedi+nnedi is probably best for this. But for Anime NNEDI still unbeatable.

BTW.
This is comparison between simple temporal denoiser + nnedi3 upscale with "BlackBox" pre/post processing shader.
Just add LimitedSharpenFaster or any other wonderful Didée sharpen script to "temporal denoiser + nnedi3" and result will be amazing.

For your sample pictures, SuperRes actually looks better. Those black artifacts are already in the source and SuperRes strengthened it due to its "line widening" artifact.
Then you destroyed picture details and artifacts with a denoiser when you use nnedi3.
I think you should call superres after you denoise it like you did with nnedi3. Then that would be a fair comparison.

Now you say you'll sharpen it? It's just comparison between resizer/upscalers, you know.

For my one picture sample, nnedi3+debilinear (debilnear is a resizer) definitely looks better. SuperRes widened the lines. I think old versions wasn't like that.
Edit: When I used Debilinear with SuperRes, it have created halo, since SuperRes's result is very sharp.

MysteryX

27th November 2015, 18:03

Both results are weird. But at least dfttest(sigma=30) don't have so much weird mpeg blocks. And this is only simple sigma=30. dfttest can be adjusted in spatial and temporal parts use noise sample etc., or if you need better results can use with motion compensation.
Post the full script you're using for both.

To compare apples with apples, are you using a denoiser in both cases? Here's we're comparing the upscaler, not the denoiser. This does NOT replace the denoiser, it is still required in both cases.

As for blocking, a lot of it "disappears" when converting to AVI with FFMPEG. I don't know why or how, but this mysterious deblocking appears to be doing a better job than when playing with AviSynth deblocking filters.

For the line widening, we could compare with the previous version of the code, as it was updated at some point.

bxyhxyh

27th November 2015, 20:26

Shiandow

27th November 2015, 20:55

About this line widening and creating "black snow" (I don't know what it is called properly) artifact, was it like this in previous versions? I used the very first version once for test purpose and I really don't remember this artifact.

Well it isn't in the MPDN version (or the MadVR version for that matter), so something seems to be going wrong.

MysteryX

27th November 2015, 20:59

I recompiled the previous version of SuperRes HLSL code, see attached file. This is for when you apply on Rec.709 YUV content. Just replace the 3 CSO files and see what difference you find.

I also asked a few questions to Shiandow and he replied this
There's something wrong with the SuperRes implementation though, the examples in the AviSynthShader thread don't look anything like I've seen before. SuperRes isn't supposed to be *that* different from Spline or NNEDI.

Not sure what to say about that, or what could be different.

I'm also wondering something about the color conversion. The YUV frames in AviSynth, are the levels 0-255 or 16-255? If that's wrong, it could cause distortion in the conversion. Although for the PNG samples in the first post, I'm doing it on RGB so it's not doing any YUV conversion. By default it assumes 0-255 levels.

foxyshadis

27th November 2015, 21:02

really strange seen this from such skilled doom9 member. I thought you better than me understand difference between any kind spatial "magic" and temporal denoisers.

That's why I asked you to back up those claims; different people have wildly different opinions on upscaled images, making a flat "better" inaccurate, and it became instantly obvious that you were comparing with a bad quality source when you posted the pics. The better your input to SuperRes, the better your output. SuperRes is just a replacement for nnedi3, not dfttest+nnedi3.

MysteryX

27th November 2015, 21:12

sqrt(9801), Shiandow also said this about your Bicubic code

That downscaler seems about right.

Although to make it faster it would probably be best to split it into two parts, first scaling horizontally then vertically. And to make it compile faster you could try replacing "[loop]" with "[fastopt]", although you might want to check if this gives the same output.

loneboyz

28th November 2015, 03:28

I'm testing resize from old NTSC DVD source, convert ratio 4:3 fullscreen up ratio 16:9 widescreen 576p
Between two version of SuperRes, ver 1.2 had darker than on the edge although same script

eedi3 + sclip nnedi3:
http://1.t.imgbox.com/l1jHVLC3.jpg (http://imgbox.com/l1jHVLC3)

SuperRes v1.0
http://0.t.imgbox.com/fqEvlmOy.jpg (http://imgbox.com/fqEvlmOy)

SuperRes v1.2
http://7.t.imgbox.com/tEGNZ6ht.jpg (http://imgbox.com/tEGNZ6ht)

MysteryX

28th November 2015, 04:58

Yeah. That's probably due to taking 8-bit input/output and doing the conversion on the GPU in the latest version.

Try editing SuperRes.avsi and play with precisionIn and precisionOut parameters of ExecuteShader (and match the corresponding ConvertToFloat functions)

MysteryX

28th November 2015, 19:18

PrecisionOut=1 works fine, but using PrecisionIn=1 causes that distortion. I have edited the scripts to use PrecisionIn=2 until the bug is corrected.

v1.2.1 released. Same DLLs, only scripts updated.
https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.2.1

loneboyz

29th November 2015, 07:40

@MysteryX, thank for your work!

after tried again, it's seem ok but have little different color of output

bxyhxyh

29th November 2015, 15:39

How different?

Interesting suggestion. Multiplying by 257 and dividing by 256 would produce "valid" results but would cause a subtle shift in colors.
BTW, why divide by 256, if you multiplied by 257?

wonkey_monkey

29th November 2015, 19:18

I think it's because integer division usually (according to the C++ spec) rounds down.

If you started with a value of 0xff (full white), multiplying it by 257 gives you 0xffff (full white). Dividing by 257 again gives you 0xff again, which is fine, but what if you subtracted 1 first, before the division? Then you'd be at 0xfffe, which, after dividing by 257, rounds down to 0xfe (which is way off what you'd expect as an 8-bit approximation of 0xfffe). If you instead divide by 256, the rounding down works in your favour by getting you back to 0xff.

MysteryX

29th November 2015, 20:41

I just did a comparison between my implementation and MPDN. Wow, there's a big difference!

AviSynthShader
http://s20.postimg.org/jjig2f8bd/Clown_Super_Res_Avi_Synth.png (http://postimg.org/image/jjig2f8bd/)

MPDN
http://s20.postimg.org/gdxuc7pp5/Clown_Super_Res_MPDN.png (http://postimg.org/image/gdxuc7pp5/)

I really have no clue where the difference could be coming from!

Edit: The problem is with the HLSL Bicubic downscaler

Here's a screenshot with the HLSL downscaler disabled and doing the downscaling in AviSynth. Almost identical to MPDN
http://s20.postimg.org/sh35zs0rd/Clown_Bicubic.jpg (http://postimg.org/image/sh35zs0rd/)

MysteryX

29th November 2015, 21:44

Version 1.2.2 released
- For SuperRes, HLSL Bicubic downscaler is broken and has been disabled. Downscaling is now done in AviSynth
- There will be a performance hit and it will take a lot more memory, but the image will be good. Until HLSL Bicubic is fixed.

Someone will need to fix the Bicubic downscaler HLSL code.

On top of giving a corrupt output, it could use a few performance tweaks. I know nothing about HLSL programming so someone else must do it.

That downscaler seems about right.

Although to make it faster it would probably be best to split it into two parts, first scaling horizontally then vertically. And to make it compile faster you could try replacing "[loop]" with "[fastopt]", although you might want to check if this gives the same output.

To compare the output of SuperRes with and without Bicubic.cso, compare Shaders\SuperRes\SuperRes.avsi and Shaders\SuperRes\SuperResBicubic.avsi

bxyhxyh

30th November 2015, 02:03

I think it's because integer division usually (according to the C++ spec) rounds down.
but what if you subtracted 1 first, before the division? Then you'd be at 0xfffe, which, after dividing by 257, rounds down to 0xfe (which is way off what you'd expect as an 8-bit approximation of 0xfffe). If you instead divide by 256, the rounding down works in your favour by getting you back to 0xff.
Then I think it should be converted to float and divided by 257.0.
Or can we directly divide integer by float? (I forgot)
Then round result to the closest integer.

MysteryX

30th November 2015, 02:09

Then I think it should be converted to float and divided by 257.0.
Or can we directly divide integer by float? (I forgot)
Then round result to the closest integer.
The conversion is working. Doing such a division would be more expensive performance-wise than bit-shifting. No need to change the current code unless we add assembly optimization to process 8 pixels at a time.

MysteryX

30th November 2015, 02:21

The latest version isn't as bad as I thought on memory, now that the format conversion code had been optimized and runs very fast. I ran a test and would get about 200fps with ConvertToFloat().ConvertFromFloat(), doing bit-shifting on each pixel and doing no YUV-RGB conversion; and if I remember that was in non-MT mode. It's not a bottleneck anymore.

As for memory usage, I'm running 8 threads of complex scripts and it's taking only 1GB, even though there are many devices getting created. Whatever memory bottleneck we were experiencing before isn't such an issue now, apparently.

Performance is in fact slightly better, as the "broken" Bicubic downscaler isn't well optimized.

MysteryX

30th November 2015, 03:11

I have updated the screenshots on the first page. The default in MPDN is SuperRes with 2 passes of strength=1 with Super-xBR with EdgeStrength=1, Sharpness=1. I tried with that and it's giving good results. See screenshots on first page.

There are a few things I had to tweak to get SuperRes+SuperxBR to run properly, which are not yet released. You can get the updated SuperRes.avsi here. (https://github.com/mysteryx93/AviSynthShader/blob/master/Shaders/SuperRes/SuperRes.avsi)

MysteryX

30th November 2015, 05:32

Now that's weird... after doing a bunch of tests and tweaks, when I'm re-testing the original script (SuperResBicubic.avsi in the repository), it gives a good output. Almost identical to MPDN except that it's very slightly sharper, which may be due to slightly different NNEDI3 configuration.

Can someone else test the latest version, and compare SuperRes.avsi (with AviSynth downscaling) with SuperResBicubic.avsi (with HLSL downscaling), and tell me whether the distortion is still there? I've done plenty of tests and now I'm confused as to what happened.

Another weird thing: if I disable YUV-RGB conversion, the output is *exactly* the same!! It does a GammaToLinear conversion on the YUV content and it doesn't seem to cause any distortion, which brings a few questions... but that works, somehow. In SuperRes.avsi, we just have to set "convertYuv=false" within the code.

foxyshadis

30th November 2015, 07:29

I should point out that rgb 255*16 and yuv 235*16 is defined to be white in 16-bit mode, specifically so you don't have to compensate for 255.9 or anything like that. So it should be divided by 255.0 to get 0-1.0 and then multiplied back by 255. Using anything else probably won't really hurt, it's float after all, but using different constants will cause a slight shift.

MysteryX

30th November 2015, 16:47

OK I've done more testing on it after getting some sleep.

The distortion shown in the last screenshots happens when PrecisionIn=1. v1.2.1 should have fixed that already. Something got mixed up somewhere.

There's a slight difference between doing the internal processing with Precision=2 (UINT16) or Precision=3 (half-float). Doing processing with Precision=2 causes a slight darkening! That's where the slight darkening is coming from. Computing with half-float fixes it. So what works best is to use PrecisionIn=2 (1 causes image distortion), Precision=3 (2 causes slight darkening) and PrecisionOut=1.

v1.2.1 'should' be fine.

Which means, HLSL Bicubic is working. It still would be nice to add the performance optimization mentioned earlier.

As for doing Bicubic downscaling in HLSL or converting and doing it in AviSynth (rounded to 8-bit), there's no quality difference whatsoever. Or perhaps 10% of the pixels would have a difference of 1? Nothing visible.

There's still an issue with Super-xBR: a distortion line on the right and at the bottom. I'm still investigating how to fix this.

sqrt(9801)

30th November 2015, 18:44

sqrt(9801), Shiandow also said this about your Bicubic code

The funny thing is that it shouldn't work, if we follow the theory as it is explained by the author of ImageWorsener, (http://entropymine.com/imageworsener/resample/) and this has me on suicide watch right now.
I am also working on separating the resizer into two passes/shaders (and adding a shift parameter for NEDI), which makes compilation much faster (<1 second on my box), so [fastopt] isn't necessary here.
I am still trying to figure out why I am getting an incorrect output with the right formula though.

There's still an issue with Super-xBR: a distortion line on the right and at the bottom. I'm still investigating how to fix this.
I'm suspecting this is because the shader clamps textures coordinates between 0 and 1.
I've only recently found out that the input images are shifted by half a pixel when mapped to a texture, so the texture coordinates should be clamped between 0 and 1-pixel_size or 1-.5*pixel_size (?) to get a correct output. I'm not too sure about that, to be honest.

MysteryX

30th November 2015, 18:55

I'm suspecting this is because the shader clamps textures coordinates between 0 and 1.
I've only recently found out that the input images are shifted by half a pixel when mapped to a texture, so the texture coordinates should be clamped between 0 and 1-pixel_size or 1-.5*pixel_size (?) to get a correct output. I'm not too sure about that, to be honest.
There's a 0.5 shift that has to be added when rendering textures, which is done already.

It does seem to be related to the clamping of overflow values. I tried changing it but haven't yet been successful.

Btw, I tried re-encoding videos with YUV conversion disabled. In that case, the colors appeared washed out. I'm really not sure why it worked with the still image with ConvertToYV12, but I guess at this point it doesn't matter if it's not working on live footage.

Here's the reason why Precision must be 3 to process SuperRes: the Diff requires negative values, which means half-float data is required. Otherwise these get cropped and the image gets darker.

loneboyz

1st December 2015, 03:12

it's seem ok but have little different color of output

v1.2.1 'should' be fine.

The colors of the output's nearly correct than source when I edited script

ConverttoRGB24(matrix="Rec601")

SuperRes(2, .43, 0, """edi_rpow2(2, nns=4, cshift="Spline16Resize")""") # srcMatrix601=true
SuperRes(2, .43, 0, """edi_rpow2(2, nns=4, cshift="Spline36Resize", fwidth=708, fheight=576)""") # srcMatrix601=true

ConverttoYV12(matrix="Rec601")

I've also tweaked x264 command, adjust ps-trellis set 0.0 to 0.05, last result is fine and smoother

MysteryX

1st December 2015, 03:48

I've also tweaked x264 command, adjust ps-trellis set 0.0 to 0.05, last result is fine and smoother
I had never heard of ps-trellis; looking at it. Default is --psy-rd 1.0:0.0, and some recommend --psy-rd 1.0:1.0

I use encoding preset 'veryslow', do you know if that's set to 0 by default on that preset?

Would you recommend me to set that value to 1.0 or to 0.05?

Btw, I just tested SuperRes with Softness; that's corrupt right now, no idea why. When Softness=0 (the way I always use it), it works.

I'll also add that with the full script I posted earlier, encoding the full video took just over an hour with the previous method of EEDI3+NNEDI with various passes of light sharpening. With SuperRes, not only is the result better and requires less fine-tuning per video, but it also encodes in just 45-50 minutes.

MysteryX

1st December 2015, 04:00

loneboyz

1st December 2015, 04:51

I had never heard of ps-trellis; looking at it.

Typing wrong. Ok, exact PsyRD & PsyTrellis with default --psy-rd 1.0:0.0

Nothing at all that only by experience and in fact, i tried PsyTrellis set other many values, from 0.0 to 1.0 and finally choose the best result

MysteryX

1st December 2015, 04:58

Typing wrong. Ok, exact PsyRD & PsyTrellis with default --psy-rd 1.0:0.0

Nothing at all that only by experience and in fact, i tried PsyTrellis set other many values, from 0.0 to 1.0 and finally choose the best result
For a general-purpose encoder, I'm wondering whether I should leave it to 0.0 or set it to something else. Apparently it was 1.0 before and then they changed the default to 0.0, probably because it could cause slight artifacts. 0.05 does sound like close to the default while getting "some" benefits from it.

MysteryX

2nd December 2015, 00:40

I've fixed a bunch of issues with SuperRes and Super-xBR, such as a distortion line at the right and bottom of Super-xBR and a sub-pixel shift when ThirdPass=false. It now works with Precision=1 which gives a nice 10% performance boost and reduces memory usage. There's one last detail I want to fix before releasing the next version. I get 45-50fps with SuperRes(1, .85, 0, """nnedi3_rpow2(2, cshift="Spline16Resize", threads=2)""") with MT=8 threads

Meanwhile, now that SuperRes is implemented right, here's a comparison of its Softness argument
First picture is Passes=2, Strength=.5, Softness=0
Other pictures are Passes=3, Strength=1, Softness = 0,.2, .4, .6, .8 and 1

http://s20.postimg.org/d5zbz17mh/Strength50.png (http://postimg.org/image/d5zbz17mh/) http://s20.postimg.org/n20eyodeh/Softness00.png (http://postimg.org/image/n20eyodeh/) http://s20.postimg.org/qhnxuhl95/Softness20.png (http://postimg.org/image/qhnxuhl95/) http://s20.postimg.org/qrvgdtzvd/Softness40.png (http://postimg.org/image/qrvgdtzvd/) http://s20.postimg.org/eeim6xa6x/Softness60.png (http://postimg.org/image/eeim6xa6x/) http://s20.postimg.org/ufb7jw82h/Softness80.png (http://postimg.org/image/ufb7jw82h/) http://s20.postimg.org/o2w2a2509/Softness100.png (http://postimg.org/image/o2w2a2509/)

I have to say that Softness=.6 is looking pretty good. The white bars are much better defined.

MysteryX

2nd December 2015, 04:38

Released v1.3 (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.3)

What's new:
- SuperRes distortion problems fixed. Colors should now be accurate.
- Shaders now use PrecisionIn=1 and convert frames to 16-bit on the GPU
- 10% performance increase and lowered memory usage
- Fixed SuperRes when using Softness parameter
- Overflow coordinates now use 'clamp'
- Fixed distortion line at the right and bottom of Super-xBR
- Fixed sub-pixel shift with Super-xBR when ThirdPass=false
- Super-xBR 'weight' argument renamed to 'sharpness'
- ConvertToFloat renamed to ConvertToShader, ConvertFromFloat renamed to ConvertFromShader
- ConvertToShader/ConvertFromShader, removed convertYuv argument
- ConvertToShader/ConvertFromShader, precision default is now 1
- All arguments now start with a uppercase letter
- Added PrecisionIn argument to SuperRes and Super-xBR. Set to 0 to call ConvertToShader within the shader; set to 1-3 if it is already converted.

There is a restriction with Super-xBR where you cannot disable the third pass unless PrecisionIn = 0. The reason is that when using only 2 passes, a sub-pixel shift must be applied. It is currently being done in AviSynth after converting back. Perhaps we could recompile the HLSL code for the 2nd pass to include the sub-pixel shift for when the 3rd pass is disabled.

MysteryX

2nd December 2015, 08:08

After doing some more tests with SuperRes's softness parameter, it still doesn't work well on noisy material, in which case I get the best result with Passes=2 and Strength=.43

For quality material, however, there are other options:
1. Using higher sharpness with softness
2. Using Super with Super-xBR (which gives an artificial look on noisy material but looks sharp on some quality material)

Also, the performance gain with the new version is higher than I expected. Perhaps the reason is that the bottleneck is the memory transfer between the CPU and GPU, and it reduces that memory transfer.

Bloax

2nd December 2015, 22:46

Perhaps the reason is that the bottleneck is the memory transfer between the CPU and GPU, and it reduces that memory transfer.
Yes - memory transfers between the CPU and the GPU are actually one of the biggest performance issues when it comes to making use of the GPU for calculations in a non-rendering setup.

MysteryX

2nd December 2015, 23:47

I've also tweaked x264 command, adjust ps-trellis set 0.0 to 0.05, last result is fine and smoother
I've made encoding tests. Adding "-psy-rd 1:0.05" does make a big difference! Otherwise the encoded image is slightly blurry (with -crf 24). With psy-trellis=0.05, the image is considerably clearer and it preserves better the shape of the details. Encoded file went from 90.1MB to 92.0MB, to give an idea of the extra details. With psi-trellis=1, encoded file was 97.5MB, the encoding took considerably longer and the noises are too sharp.

Considering how much of a difference 0.05 makes, and considering how close it still is to the default value, I think it's safe to use it as the default. I haven't tested it on all types of contents, but I don't think it will hurt.

I also tested encoding to 768p with crf=25, and it's losing more details at a similar file size.

Encoding to 720p with crf=25 and psy-trellis=0.05 is what works best.

loneboyz

3rd December 2015, 03:09

Encoding to 720p with crf=25 and psy-trellis=0.05 is what works best.

Thanks for your advice! It should be set to the default value, is 0.0. Cause maybe, I've used earlỉer SuperRes version and taken the result compare with the result of eedi3+nnedi3 that generate too blurry.

I've just edited scipt, add mt_lutxy before call SuperRes twice, and the result image is considerably clearer

source fillter: with TFM + DeHalo_alpha + KNLMeansCL + GradFun3
http://1.t.imgbox.com/kQmqgbu0.jpg (http://imgbox.com/kQmqgbu0)

eedi3 + sclip nnedi3:
http://1.t.imgbox.com/l1jHVLC3.jpg (http://imgbox.com/l1jHVLC3)

SuperRes 1.3
http://2.t.imgbox.com/kTCabWB8.jpg (http://imgbox.com/kTCabWB8)

Mt_lutxy + SuperRes 1.3
http://2.t.imgbox.com/GhATEQLS.jpg (http://imgbox.com/GhATEQLS)

MysteryX

3rd December 2015, 05:39

Interesting. How do you use mt_lutxy and what does it do exactly? Can you post you exact command? I'm not familiar with that command.

Are you saying psy-trellis should be left to 0.0 instead of 0.05? What are your thoughts on that?

bxyhxyh

3rd December 2015, 07:20

mt_lut and others are from masktool plugin.
For mt_lut you can apply specific expression on pixels.
For example mt_lut("x 10 +") you're brightening it with 10 value. It also can work on chroma channels.
I think you should read about it from its documentation.

I was planning to ask what formula are you using on ConvertToFloat and ConvertFromFloat, If you weren't going to fix that darkening issue so I can fix manually with mt_lut().

Edit:
Oh it was about mt_lutxy(). It is the same as mt_lut(). But takes two clip's pixel value.
mt_lutxy(a,b,"x y + 7 /") you're adding a, b clips then dividing it by 7

loneboyz

3rd December 2015, 08:50

How do you use mt_lutxy and what does it do exactly?

I'm only learn and try to follow this (http://forum.doom9.org/showthread.php?t=171526&page=4)

what does it do exactly or not? I'm not sure. Please correct me if I did something wrong.

This's script that I used

LoadPlugin("F:\Setup\Encode\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("F:\Setup\Encode\Work\partner.d2v")
LoadPlugin("F:\Setup\Encode\MeGUI\tools\avisynth_plugin\TIVTC.dll")

tfm(order=1).tdecimate()
Vinverse(sstr=2.7, amnt=255, uv=3, scl=0.25)
Trim(1190, 0).crop(6, 64, -6, -52)

#denoise
DeHalo_alpha(ss=2,rx=2.0,ry=2.0,darkstr=0,highsens=80)

KNLMeansCL(d=1, a=1, h=2, device_type="GPU")
#~ dfttest(sigma=16)

GradFun3 (smode=2)

#~ sharpen(0,0.25)
mt_lutxy(last,last.RemoveGrain(20,-1),\
"x y == x x x y - abs 0.25 ^ 4.0 * x y - 2 ^ x y - 2 ^ 5 + / * x y - x y - abs / * 1 x y - abs 32 / 4 ^ + / + ?",U=2,V=2)

SR_Path = "F:\Setup\Encode\Tools\Avisynth.Plugin\AviSynthShader-1.3\"
LoadPlugin(SR_Path + "Shader.dll")
Import(SR_Path + "ColorMatrix\ColorMatrix.avsi")
Import(SR_Path + "SuperRes\SuperRes.avsi")
Import(SR_Path + "Super-xBR\super-xbr.avsi")

#~ ConverttoRGB24(matrix="Rec601")
ColorMatrix601to709()
SuperRes(2, .43, 0, """edi_rpow2(2, nns=4, cshift="Spline16Resize")""") # srcMatrix601=false

#~ mt_lutxy(last,last.RemoveGrain(20,-1),\
#~ "x y == x x x y - abs 0.25 ^ 4.0 * x y - 2 ^ x y - 2 ^ 5 + / * x y - x y - abs / * 1 x y - abs 32 / 4 ^ + / + ?",U=2,V=2)

SuperRes(2, .43, 0, """edi_rpow2(2, nns=4, cshift="Spline36Resize", fwidth=708, fheight=576)""") # , srcMatrix601=false

ColorMatrix709to601()

#~ Spline36Resize(708, 576)

Twarp2()
#~ LimitedSharpenfaster(edgemode=1,strength=20,ss_x=1.5,ss_y=1.5)
#~ AutoAdjust(output_tv=false,high_quality=true,auto_balance=true)
SmoothLevels(gamma=1, Ecenter=64, Lmode=1, dither=100, darkSTR=50, brightSTR=100, Ecurve=0) #Ecenter =32,darkSTR=50,brightSTR=50

Trim(20775, 28398)

Are you saying psy-trellis should be left to 0.0 instead of 0.05? What are your thoughts on that?

What I known, Psy-trellis useful in case source grainy and it also depends on your eyes

MysteryX

3rd December 2015, 18:06

mt_lutxy(last,last.RemoveGrain(20,-1),\
"x y == x x x y - abs 0.25 ^ 4.0 * x y - 2 ^ x y - 2 ^ 5 + / * x y - x y - abs / * 1 x y - abs 32 / 4 ^ + / + ?",U=2,V=2)
mt_lutxy doesn't do anything on its own. It simply makes it easy to implement other algorithms without creating a brand new filter. Heck, HLSL with AviSynthShader also makes it easy to implement new algorithms without creating brand new filters, and I suspect that the HLSL way will be considerably faster (would have to be tested).

So basically, you're applying sharpening before upscaling. It can work in some cases but it's something to be very careful about, and it needs to be fine-tuned for each video. Have you tried other sharpeners, such as FF3DFilter's sharpening? That's what I was using before to sharpen the source before upscaling.

ColorMatrix601to709()
By using this outside of SuperRes, you're adding an extra unecessary chroma conversion and you're losing color data. You're better to bundle it into other operations.

Or perhaps convert it to YV24 first, call ColorMatrix601to709, SuperRes, and then convert back to YV12. This way you won't lose chroma data between these two. YV24, however, is much heavier for AviSynth standard filters, but lighter for when it needs to be converted to perform HLSL operations.

By the way, I haven't done any tests on videos that are sensitive to banding. In those cases, should I add a deband such as GradFun3 at the beginning and a dither at the end to create some random noise? And then I suppose those should be left disabled for videos that don't have banding. My 288p videos have too much noise to have banding.

MysteryX

3rd December 2015, 18:54

Could you try with FF3DFilter's sharpening, or simply increase SuperRes's strength, to compare?

I just tried applying FF3DFilter sharpening before upscaling and it's worsening the noise in the images. Before when I used FF3DFilter to denoise, its sharpening was necessary, but with KNLMeans the result is already sharp so I don't need it anymore.

And by the way, SmoothLevels is depreciated; see SmoothAdjust (http://forum.doom9.org/showthread.php?t=137479).

loneboyz

4th December 2015, 05:30

mt_lutxy doesn't do anything on its own.
So basically, you're applying sharpening before upscaling. It can work in some cases but it's something to be very careful about, and it needs to be fine-tuned for each video.

Yes, mt_lutxy doesn't give much but I only want to instead of Sharpen
I had to increase the strength of KNLMeans, from h=1.45 to 2 and then 2.2 after add mt_lutxy

Have you tried other sharpeners, such as FF3DFilter's sharpening?
I have not tried it in this script, FF3DFilter or Dftest, perhaps they're too strong but too slowly. Follow me, KNLMeans would be enough.

Or perhaps convert it to YV24 first, call ColorMatrix601to709, SuperRes, and then convert back to YV12
I'll try your way

And by the way, SmoothLevels is depreciated; see SmoothAdjust (http://forum.doom9.org/showthread.php?t=137479).

SmoothAdjust, it seems slow when I called it in my scrip

#SmoothLevels(gamma=1, Ecenter=64, Lmode=1, dither=100, darkSTR=50, brightSTR=100, Ecurve=0) #Ecenter =32,darkSTR=50,brightSTR=50
AutoAdjust(output_tv=false,high_quality=true,auto_balance=true)
Can you give me any advice on this?

MysteryX

4th December 2015, 17:58

If you really want to process Rec601 videos with SuperRes, then the best way would be to recompile SuperResFinal709.cso with compiler flags making it Rec601. Shaders\SuperRes\CompileHLSL.bat has all the command-lines to compile the script. I'll compile this one for you. We need to add "/DKb=0.114 /DKr=0.299" at the end.

"C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Utilities\bin\x86\fxc.exe" /T ps_3_0 /Fo "SuperResFinal601.cso" "src\SuperRes\SuperRes709.hlsl" /DFinalPass=1 /DKb=0.114 /DKr=0.299

Attached is the compiled CSO file (once approved by the admin)

Just edit the SuperRes.avsi to use that one for the final pass instead of the 601 one. Then you won't need to convert color space back and forth.

I never tried AutoAdjust or SmoothAdjust so I can't comment on that.

luquinhas0021

4th December 2015, 18:27

Really is an amazing work the your improvements in this plug-in. There`s way of you implement it, includding color space conversion, in double precision floating point? Only curiosity: if you made this plug-in turn a stand-alone software, includding some resizers versions, would stand-alone be faster than plug-in? The development of stand-alone would be more laborious than the development of plug-in?

MysteryX

4th December 2015, 18:31

What do you mean by stand-alone? It has to take its data somewhere and output it somewhere. What would be the use if it's not part of a chain of scripts?

The bottleneck is the memory transfer between the CPU and GPU. Graphic cards aren't designed to read from the GPU so the bandwidth to transfer back is limited.

madVR doesn't have this limitation because it's processing series of filters on the GPU and then rendering to the screen, which allows it to use the full GPU power.

luquinhas0021

4th December 2015, 18:36

"Stand-alone" is the same of "software". Like you transform nnedi3 plug-in in a software that only makes resize using nnedi3 core,with a GUY.

MysteryX

4th December 2015, 18:46

I have a GUI within the Natural Grounding Player, in Tools | Media Encoder

I'll be releasing the next version soon, which will have considerable upgrades to the Media Encoder, including adding SuperRes into it. This new version encodes faster, gives much better quality and produces smaller files.

luquinhas0021

4th December 2015, 19:09

I saw your player. It requires MadVR, but the computer I use (Intel Core i3 1st generation without dedicated GPU) doesn't run it well. There's a way of emulate FP 32/64 processing, in CPU?

MysteryX

4th December 2015, 19:31

It supports and facilitates the use of madVR, but it is in no way required. That's only useful for video playback.

When it comes to the Media Encoder, madVR has nothing to do with it.

Although I'm not exactly sure about the requirements for it to work properly. AviSynth needs to be installed, which comes with SVP. Then I'm not sure whether it works just like that, or if LAV Filters must be installed, or if K-Lite Codec Pack must be installed. Perhaps someone could test that and let me know. What is touchy is for the Media Encoder "Preview" button to work, loading the AVS script in Windows Media Player without complaining that it is an unrecognized format. After upgrading to Windows 10, it started complaining again that it didn't recognize the format and clicking "Yes" would still open it. Re-installing K-Lite Codec Pack (with LAV Filters) solved the issue for me.

Although if your CPU is old with no decent GPU, encoding might be very slow.

At the end of the day, this software is only a wrapper that takes a list of 39 files (DLL, AVSI, EXE, CSO) and makes them work together to streamline the encoding process via AviSynth and FFMPEG.

MysteryX

5th December 2015, 06:10

mt_lutxy(last,last.RemoveGrain(20,-1),\
"x y == x x x y - abs 0.25 ^ 4.0 * x y - 2 ^ x y - 2 ^ 5 + / * x y - x y - abs / * 1 x y - abs 32 / 4 ^ + / + ?",U=2,V=2)
OK I tried your method of sharpening. It does somehow mix very well with SuperRes to make the resulting image much sharper. With noisy material, however it amplifies the noise so it doesn't work. But then, for quality material, does adding sharpening first give anything better than simply increasing the strength of SuperRes?

I also did some testing about other Cubic downscaling configurations here (http://forum.doom9.org/showthread.php?p=1748689#post1748689), and the conclusion is that although Cubic(-.6,0) appears to give better result than the default Cubic(1/3,1/3) on the Lighthouse, after testing on a real video, it lost some of the textures and details, so the current implementation still works best.

Then about running 3 passes instead of 2, I could see slight differences on the colors when running it on the Lighthouse in RGB24, but when testing on a real video in YV12, I really can't see any difference except very subtle details here and there. It seems the color precision benefits are lost in the chroma conversion to YV12, so it has benefits in the RGB24 space but not in the YV12 space.

MysteryX

6th December 2015, 09:29

There's a way of emulate FP 32/64 processing, in CPU?
If you're asking whether it's possible to process pixel shaders on the CPU, I don't know of any way to do it; and it would be very slow.

I'm implementing conversion to/from DitherTools for 16-bit resize, and I'm testing with it. It can be used as the NNEDI3 subpixel shift.

Here are some images of subpixel shift

Upscale="""edi_rpow2(2, nns=4, cshift="Spline16Resize", lsb=true, threads=2)"""
SuperRes(2, .43, 0, Upscale, lsb_in=true)

1. Standard (lsb=false)
2. Subpixel shift with lsb=true, then convert to 8-bit and run SuperRes
3. Subpixel shift with lsb=true, feeding SuperRes with 16-bit data

http://s20.postimg.org/nlztqn6qh/Subpixel_Shift.png (http://postimg.org/image/nlztqn6qh/) http://s20.postimg.org/xym4cq09l/Subpixel_Shift_Dither1.png (http://postimg.org/image/xym4cq09l/) http://s20.postimg.org/7etjakzq1/Subpixel_Shift_Dither2.png (http://postimg.org/image/7etjakzq1/)

The difference is very minimal. It's not worth using for subpixel shift.

Here are sample images with dither resize

Upscale="""edi_rpow2(2, nns=4, cshift="Spline16Resize", lsb=false, threads=2)"""
SuperRes(2, .43, 0, Upscale, lsb_in=false)
Upscale="""edi_rpow2(2, nns=4, cshift="BicubicResize", a1=-.6, a2=0, fwidth=""" + \
string(int(width*1.77)) + ", fheight=" + string(int(height*1.77)) + ", lsb=true, threads=2)"
SuperRes(2, .43, 0, Upscale, lsb_in=true)

1. Standard (lsb=false)
2. Resize with lsb=true, then convert to 8-bit and run SuperRes
3. Resize with lsb=true, feeding SuperRes with 16-bit data

http://s20.postimg.org/9prlerahl/Resize.png (http://postimg.org/image/9prlerahl/) http://s20.postimg.org/kdvcdlkgp/Resize_Dither1.png (http://postimg.org/image/kdvcdlkgp/) http://s20.postimg.org/3snpxxtcp/Resize_Dither2.png (http://postimg.org/image/3snpxxtcp/)

http://s20.postimg.org/xoj774b15/Clown_Resize.png (http://postimg.org/image/xoj774b15/) http://s20.postimg.org/5cxna2r4p/Clown_Resize_Dither1.png (http://postimg.org/image/5cxna2r4p/) http://s20.postimg.org/e98fe0hqx/Clown_Resize_Dither2.png (http://postimg.org/image/e98fe0hqx/)

The difference is subtle but it's there. The difference between 1 and 2 is about the same as the difference between 2 and 3. The difference is more visible on the clown image. It's also worth nothing that since the CPU-GPU memory transfer is the bottleneck, using more of the CPU won't lower the overall performance so we can do 16-bit processing on the CPU while the GPU is busy.

As for downsizing, Cubic(-.6,0) is giving a more accurate image than the default Bicubic. For SuperRes's internal downscaling, however, the default Bicubic gives a sharper image while Cubic(-.6,0) causes it to lose some details and get softer.

MysteryX

6th December 2015, 19:07

I accidentally made those tests with SuperRes using Cubic(-.6,0) as a downscaler, which causes the image to be softer.

Here's the clown again with standard Bicubic

http://s20.postimg.org/d1uhlsrmh/Clown_Resize.png (http://postimg.org/image/d1uhlsrmh/) http://s20.postimg.org/phr7fjkyh/Clown_Resize_Dither1.png (http://postimg.org/image/phr7fjkyh/) http://s20.postimg.org/h0waid5nd/Clown_Resize_Dither2.png (http://postimg.org/image/h0waid5nd/)

MysteryX

6th December 2015, 21:06

The next version with DitherTools support is almost ready.

Here's a comparison on a noisy video. It is the full script I posted earlier. I do the encoding with crf=24. Note that there are slight variances in the way InterFrame generates the frames.

1. Bicubic downscaling at the end (86.6MB file)
2. Cubic(-.6,0) downscaling at the end (87.7MB file)
3. Cubic(-.6,0) downscaling with DitherTools and passing 16-bit data into SuperRes (87.4MB file)

http://s20.postimg.org/w6ok42rix/Bicubic.png (http://postimg.org/image/w6ok42rix/) http://s20.postimg.org/ee2zw7aah/Cubic.png (http://postimg.org/image/ee2zw7aah/) http://s20.postimg.org/9gpfb38bd/Cubic_Dither.png (http://postimg.org/image/9gpfb38bd/)

MysteryX

6th December 2015, 22:39

Version 1.3.1 released (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.3.1)

What's new:
- Added support to convert to/from DitherTools' Stack16 format
- All Precision parameters are now 2 by default to avoid confusion
- ConvertToShader/ConvertFromShader: now have 'lsb' argument. When true, it converts to/from Stack16 format. Only YV12 and YV24 are supported.
- ExecuteShader: Added Clip1Precision-Clip9Precision instead of PrecisionIn, allowing input clips with various precisions
- ExecuteShader: PrecisionOut is now OutputPrecision
- SuperRes: Added MatrixIn and MatrixOut arguments instead of srcMatrix601 which gives more flexibility for color matrix conversion
- SuperRes and Super-xBR: Added lsb_in, lsb_upscale and lsb_out to convert to/from Stack16 format
- SuperRes and Super-xBR: PrecisionIn replaced with Convert. When true, the source must be precision=2
- ColorMatrix601to709 is now ColorMatrixShader
- ColorMatrixShader: Added MatrixIn and MatrixOut arguments giving more flexibility for color matrix conversion

MysteryX

7th December 2015, 01:30

Here's my updated best script to upscale SD content to HD. I'm testing it on the worse-case 288p noisy VCDs, so that if it works with that, it will work for most content.

PluginPath=""
LoadPlugin(PluginPath+"KNLMeansCL.dll")
LoadPlugin(PluginPath+"Shader.dll")
LoadPlugin(PluginPath+"nnedi3.dll")
LoadPlugin(PluginPath+"FTurn.dll")
Import(PluginPath+"edi_rpow2.avsi")
Import(PluginPath+"ResizeX.avsi")
Import(PluginPath+"SuperRes.avsi")
LoadPlugin(PluginPath+"dither.dll")
Import(PluginPath+"dither.avsi")
LoadPlugin(PluginPath+"svpflow1.dll")
LoadPlugin(PluginPath+"svpflow2.dll")
Import(PluginPath+"InterFrame2.avsi")

SetMTMode(3,8)
file = "Preview.avi"
AviSource(file, audio=true, pixel_type="YV12")
SetMTMode(5)
KNLMeansCL(D=2, A=1, h=3, device_type="GPU")
SetMTMode(2)
Double="""edi_rpow2(2, nns=4, cshift="Spline16Resize", Threads=2)"""
SuperRes(2, 0.43, 0, Double, MatrixIn="601")
InterFrame(Cores=8, Tuning="Smooth", NewNum=60000, NewDen=1001, GPU=true)
Double="""edi_rpow2(2, nns=4, cshift="BicubicResize", a1=-.6, a2=0, lsb=true, fwidth=960, fheight=720, Threads=2)"""
SuperRes(2, 0.43, 0, Double, lsb_upscale=true)

Original (https://www.spiritualselftransformation.com/files/media-encoder-old.mpg)

Encoded with x264 --preset "veryslow" --crf 24 -psy-rd 1:0.05 (https://www.spiritualselftransformation.com/files/media-encoder-new2.mkv)

loneboyz

8th December 2015, 05:47

MysteryX, your job is great. Finally, I felt satisfied with the result that lastest SuperRes give out.

I removed Mt_luxy and some color tweak in script because they can cause loss of precision while upscaling. I also tested with LimitedSharpenFaster insert at the end of script, its result very impressive, has no difference than the result of original encode (no upscale).

The last thing remain, I'm considering that has too small spots on this source, I can use Despot filter or the same as Clense, but before or after upscale?

MysteryX

8th December 2015, 15:21

The last thing remain, I'm considering that has too small spots on this source, I can use Despot filter or the same as Clense, but before or after upscale?
Liquid paper on the screen?

MysteryX

9th December 2015, 04:08

I experimented with 10-bit encoding.

If I simply use x264-10bit.exe with the same script posted above on 288p VCD content, encoding time is about 10-20% longer and file size is very slightly smaller, while I'm not quite such whether the 8-bit or 10-bit files have best quality. It's pretty much equal. Not worth the overhead and lack of compatibility.

However, I can feed 10-bit data to the encoder by replacing the last part of the script with this. The final resize and SuperRes will be performed with 16-bit precision and output that to x264-10bit.exe

Double="""edi_rpow2(2, nns=4, cshift="BicubicResize", a1=-.6, a2=0, lsb=true, fwidth=960, fheight=720, Threads=2)"""
SuperRes(2, 0.43, 0, Double, lsb_upscale=true, lsb_out=true)
Dither_out()

Note: there is a small bug in the last release of SuperRes. Edit SuperRes.avsi, and replace "ConvertFromShader(1" with "ConvertFromShader(PrecisionOut". Otherwise, lsb_out won't work.

Then, I encode with this command. The latest version of avs2yuv support --input-depth 16 which can make this command simpler by avoiding to provide all the metadata, but the latest version of avs2yuv is freezing for me. The previous version I had is working; not sure which version I have, but it works.

avs2yuv.exe -raw "Script.avs" -o - | x264-10bit.exe --demuxer raw --input-depth 16 --input-res 940x720 --fps 59.94
--preset veryslow --crf 24 --psy-rd 1:0.05 --output ""output.264"" --frames 10000 -

Here's the comparison
10-bit encoding result (https://www.spiritualselftransformation.com/files/media-encoder-new-10bit.mkv) (90.9 MB)
8-bit encoding result (https://www.spiritualselftransformation.com/files/media-encoder-new2.mkv) (92.2 MB)

The 10-bit encoding chain took about 40% longer, but the quality is better. However, it won't be compatible with all devices.

There is one weird difference between the 8-bit and 10-bit versions, which I'd like to have your feedback on. Both files have the same size (940x720) and the cropping of the original file is the same. However, there is a small difference in the vertical stretching where the 8-bit video is missing a line at the bottom compared to the 10-bit video. This is a plus for the 10-bit encoding chain, and... why is there such a distortion on the 8-bit video?

SSH4

9th December 2015, 05:27

On such sources, 10bit... no 8bit is a huge overhead. 4 or 6bit for High-end quality for VCR rips is more than enough :) (1/2 joke)

10 bit can help with videos with smooth gradients. And if this gradients take most part of video frame...
For example like in some latest computer only made anime. 10 bit will help you avoid bandings on average encoding settings.

So i think you don't need 10bit h264 here.

MysteryX

9th December 2015, 05:42

I got curious when I searched online and read that 10-bit encoding gives 10-20% higher quality (or 10-20% smaller file) with any video source, even 8-bit sources.

With this test, however, a 10-bit video source is required to see such benefit. It still is a 10% quality gain for 40% performance cost.

Now this got me even more curious about something else: why is the 8-bit encoding distorted?

SSH4

10th December 2015, 03:27

mod16?

loneboyz

11th December 2015, 18:29

Liquid paper on the screen?

Yes. After google with doom9, bla bla and this problem (http://forum.doom9.org/showthread.php?p=1749506#post1749506)

bxyhxyh

12th December 2015, 06:31

What does strength argument affect? Only sharpness?
I'm asking this since you always choose 0.43 in your test scripts.

MysteryX

12th December 2015, 06:42

What does strength argument affect? Only sharpness?
I'm asking this since you always choose 0.43 in your test scripts.
Strength affects the sharpness yes. The reason I use 0.43 is because that's the value that is working the best with my noisy 288p VCDs. The Lighthouse picture can take a higher value.

bxyhxyh

12th December 2015, 07:04

So nothing to do with details except sharpness?

MysteryX

14th December 2015, 06:34

It has the *result* of sharpness, except that it *recovers* details instead of *creating* details.

bcn_246

18th December 2015, 10:43

MysteryX

20th December 2015, 19:27

Can I ask what your system specs are, and the resolution/frame rate/source type of the video you tested it on?

Peace :)
Intel Quad-Core i7 3630QM with Radeon HD 7670M

I'm testing on a 288p video

bxyhxyh

27th December 2015, 08:44

How does lsb_out=true work?
It always returns me the double width clip.
If it's how supposed to work, how can I convert it to normal 16bit stacked clip after superres call?

MysteryX

28th December 2015, 01:24

There's a bug and I haven't yet made an official release with the fix. In SuperRes.avsi, replace "ConvertFromShader(1" with "ConvertFromShader(PrecisionOut"

MysteryX

28th December 2015, 04:06

After doing some testing, the AviSynthShader approach has a serious advantage over OpenCL implementations.

The bottleneck is the memory transfers between the CPU and GPU.

With KNLMeansCL, using A=2 instead of A=1 has a massive impact on performance.

With SuperRes, however, using 2 passes instead of 1 pass is giving me the exact same performance even though it works twice harder.

Why?

Because shader chains allow running as many operations as you want before returning the output, and since the GPU processing power is limited by the memory transfers, using twice more GPU processing has 0 impact on memory transfers.

This means this approach is excellent for heavy-processing operations, especially those requiring YV24 or RGB data. For singular light operations, however, the transfer bandwidth can get wasted fast.

If you want to run several HLSL operations in a row, you could easily edit the scripts to suit your needs and chain it all up in a single call.

MysteryX

28th December 2015, 06:10

If someone wants to port NNEDI3...
https://github.com/zachsaw/MPDN_Extensions/tree/master/Extensions/RenderScripts/NNEDI3

There might be some advantages to it. First, it would allow processing NNEDI3 with 16-bit depth. Second, it *might* not have performance overhead compared to SuperRes if both are run together, since running more commands in the same chain won't increase memory transfers. I know the AviSynth version of NNEDI3 is well optimized, and I'd be curious to see how it would perform in this case since the GPU is under-utilized anyway.

It would take a stand-alone version of NNEDI3, and then another script that combines NNEDI3 and SuperRes to run in the same chain. What I'm not sure about is how to do the sub-pixel shift in HLSL.

MysteryX

28th December 2015, 07:11

btw I found something that makes SuperRes shine even more. If I use KNLMeans with cmode=true to also denoise the chroma, I can apply a stronger SuperRes. See for yourself.

Without SuperRes

AviSource("Preview.avi", pixel_type="YV12")
ConvertToYV24()
KNLMeansCL(D=1, A=2, h=2.1, cmode=true, device_type="GPU", device_id=0)
ConvertToYV12()
ColorMatrixShader(MatrixIn="601")
edi_rpow2(2, nns=4, cshift="Spline16Resize", Threads=2)
edi_rpow2(2, nns=4, cshift="BicubicResize", a1=-.6, a2=0, fwidth=960, fheight=720, Threads=2)

http://s20.postimg.org/thske2l7d/NNEDI3.png (http://postimg.org/image/thske2l7d/)

With SuperRes

AviSource("Preview.avi", pixel_type="YV12")
ConvertToYV24()
KNLMeansCL(D=1, A=2, h=2.1, cmode=true, device_type="GPU", device_id=0)
ConvertToYV12()
Double="""edi_rpow2(2, nns=4, cshift="Spline16Resize", Threads=2)"""
SuperRes(1, 1, 0, Double, MatrixIn="601")
Double="""edi_rpow2(2, nns=4, cshift="BicubicResize", a1=-.6, a2=0, lsb=true, fwidth=960, fheight=720, Threads=2)"""
SuperRes(1, 1, 0, Double, lsb_upscale=true)

http://s20.postimg.org/nuw7gliop/Super_Res.png (http://postimg.org/image/nuw7gliop/)

sqrt(9801)

28th December 2015, 11:30

If someone wants to port NNEDI3...
https://github.com/zachsaw/MPDN_Extensions/tree/master/Extensions/RenderScripts/NNEDI3

You'll need to add support for SM5 in AvisynthShader first. :p

MysteryX

28th December 2015, 18:07

You'll need to add support for SM5 in AvisynthShader first. :p
Oh.

Using ShaderModel 5 requires DirectX 11 DirectCompute instead of DirectX 9.

I had worked on that implementation before; and then reverted back to DX9 when I realized configuring parameters was complex complicated. Everything else was pretty straightforward. Exact same logic as DX9 but replacing the commands with new names that make more sense. The DirectX code is well separated from the AviSynth code to make it easy.

That still would be considerable work that I won't have time for.

luquinhas0021

28th December 2015, 23:55

MisteryX, the Natural Grounding Player v1.3 is coming soon? Your last update was about 6 months (v1.2.1) and has no superresolution.

MysteryX

29th December 2015, 01:58

MisteryX, the Natural Grounding Player v1.3 is coming soon? Your last update was about 6 months (v1.2.1) and has no superresolution.
Yes, I just finished it; just have to release it. It has GREAT improvements to the Media Encoder!!

In the meantime, here's AviSynthShader v1.3.2 (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.3.2)

What's new:
- Added FormatOut to all scripts to set output format
- Fixed SuperRes when using lsb_out
- Removed bogus "info" in Super-xBR

MysteryX

29th December 2015, 03:11

Natural Grounding Player v1.3 is here (https://github.com/mysteryx93/NaturalGroundingPlayer/releases/tag/v1.3). Merry Christmas!!

Natural Grounding Player Media Encoder thread is here (http://forum.doom9.org/showthread.php?p=1751320#post1751320)

Overdrive80

29th December 2015, 03:17

Hi, thanks for your work. One question, I am testing your code with some modification, this:

DGDecode_mpeg2source("E:\Dragon Ball\DB_13\074\VideoFile.d2v", info=3)

assumetff()

tfm(order=1,pp=6,mode=4).tdecimate(mode=1)

Spline36Resize(720,480,6,0,-3,-6)

ConvertToYV24()

ChromaReconstructor() # Dont smooth

KNLMeansCL(D=1, A=2, h=2.1, cmode=true, device_type="GPU", device_id=0)
ConvertToYV12()
Double="""edi_rpow2(2, nns=4, cshift="Spline16Resize", Threads=2)"""
SuperRes(1, 1, 0, Double, MatrixIn="601")
Double="""edi_rpow2(2, nns=4, cshift="BicubicResize", a1=-.6, a2=0, lsb=true, fwidth=960, fheight=720, Threads=2)"""
SuperRes(1, 1, 0, Double, lsb_upscale=true)

spline36resize(640,480) # its for comparison

return last

http://s6.postimg.org/5dvwjlku9/Sin_t_tulo.png

The result is good, but in dark areas is too smoothing and lost details (background). Any configuration less destrutive for your code, type as sourcematch in qtmgc??

MysteryX

29th December 2015, 03:43

What is causing the loss of details? With SuperRes, you can play with Strength and Passes, such as Passes=2 with Strength=.45

and perhaps your loss of details is due to KNLMeansCL?

Overdrive80

29th December 2015, 12:34

Ok, apologize me. It is KNLMeansCl which causes lost of details.

Edit: I get a good result but its bit slooooooow XD:

Original: 640x480; Upsize: 960x720
http://s6.postimg.org/j50dlt9s1/Captura_de_pantalla_2015_12_29_13_31_42.png

Code:

DGDecode_mpeg2source("E:\Dragon Ball\DB_13\074\VideoFile.d2v", info=3)

assumetff()

tfm(order=1,pp=6,mode=4).tdecimate(mode=1)

Spline36Resize(720,480,6,0,-3,-6)

ConvertToYV24()

ChromaReconstructor()

ConvertToYV12()

Double="""edi_rpow2(2, nns=4, cshift="Spline16Resize", Threads=2)"""

SuperRes(1, 1, 0, Double, MatrixIn="601")

Double="""edi_rpow2(2, nns=4, cshift="BicubicResize", a1=-.6, a2=0, lsb=true, fwidth=960, fheight=720, Threads=2)"""

SuperRes(1, 1, 0, Double, lsb_upscale=true)

#/*Prefiltrado*/#

original=last

pre=original.BrightDfttestMod(sbright=8.5, smedium=2.0, sdark=0,th_low=20, th_med=40, th_high=100, tbsize=1,lsb=true,mode=6)

mascara=original.mt_edge("hprewitt",thY1=8, thY2=255,thc1=0,thc2=255)

prefiltrado=mt_merge(pre, original, mascara)

#Temporal degrain

tr = 6

last=prefiltrado.SMDegrain (tr, thSAD=570, thSADC=180,lsb=true,lsb_out=true,thSCD1=570,thSCD2=160, blksize=8, overlap=4,search=4,contrasharp=false)

#/*Otros*/#

csmod16(lsb_in=true, lsb=true)

gradfun3(mode=6,lsb_in=true, lsb=false)

Unsharphq(19,1.6,0.2,show=false)

santiag(aa=15)

hysteria(showmask=false,strength=0.9,lowthresh=32,highthresh=32)

luquinhas0021

29th December 2015, 15:27

overdrive80, suggestion: instead use spline 36 and edi, apply spline 144 or lanczos 4, and nnedi3, and change cshift: put spline144 or lanczos4. Post here the result. Your result you`ve posted is a bit blurry, if we compare with original image.

Overdrive80

29th December 2015, 17:09

The code is here, you can change at your way. I am only playing with that tool.

luquinhas0021

29th December 2015, 17:56

whats the difference between superres and superres xbr?

MysteryX

29th December 2015, 18:41

Edit: I get a good result but its bit slooooooow XD:
ChromaReconstructor is very slow; remove it to get a performance boost.

ConvertToYV24()
ChromaReconstructor()
ConvertToYV12()

And this is useless! There's no point in calling ChromaReconstructor to throw away the data right after.

whats the difference between superres and superres xbr?
SuperRes runs around resizers to restore the details while upscaling.

Super-xBR is a frame-double algorithm, similar to NNEDI3.

SuperRes require a frame-double algorithm to run: either NNEDI3, EEDI3 or Super-xBR.

luquinhas0021

29th December 2015, 18:53

super-xbr or nnedi3: what you preffer?
Ah, in "Super-xBR 100", what the "100" means?

Overdrive80

29th December 2015, 19:10

And this is useless! There's no point in calling ChromaReconstructor to throw away the data right after.

Oh, my mistake, I just limited to copy and paste your code. :(

If I remove Converttoyv12, I get this:

http://postimg.org/image/s1g7mv6pp/

I had add Converttoyv12 before of Hysteria because dont admit YV24

EDIT: Problem of SMDegrain, neither admit YV24

MysteryX

29th December 2015, 20:02

super-xbr or nnedi3: what you preffer?
Ah, in "Super-xBR 100", what the "100" means?
Strength parameter; actually it should be 1. Default is Strength=1, Sharpness=1.

Super-xBR seems to be doing a good job on some material. It is very sharp but has serious ringing problems, which are then reduced by applying SuperRes.

I personally prefer NNEDI3 because its results are more consistent.

Overdrive80

29th December 2015, 20:10

http://s6.postimg.org/3yzdrzq2p/Captura_de_pantalla_2015_12_29_20_07_17.png

http://s6.postimg.org/8m5ftrdfl/Sin_t_tulo.png

#Obviously, garbage is accentuated

Double="""edi_rpow2(2, nns=4, cshift="SincResize", Threads=8)"""

SuperRes(1, 1, 0, Double, MatrixIn="601")

Double="""edi_rpow2(2, nns=4, cshift="SincResize", a1=-.6, a2=0, lsb=true, fwidth=960, fheight=720, Threads=8)"""

SuperRes(1, 1, 0, Double, lsb_upscale=true)

luquinhas0021

29th December 2015, 20:17

MisteryX, edge strenght goes from 0 to 5. 1 is the maximum acceptable value? 1 is the maximum acceptable value of sharpness? Super-xBR in Dither16 generates less artifacts? You talked you preffer nnedi3, but a lot of people says Super-xBR retains more details than nnedi3. You told me that use Super-xBR with SuperRes reduces ringing. What about sharpness where there isn`t ringing: reduces? Super-xBR is equal sharp or sharper than sinc4? And compared with the monstruosly sharp, and aliased, Bicubic b=-1, c=1?

MysteryX

29th December 2015, 21:24

I haven't played much with Super-xBR. Post your discoveries.

luquinhas0021

30th December 2015, 04:02

MisteryX, I downloaded the .zip file of AviSynth Shader 1.3.2 and tried install it, but I can't do it work. How I install properly, considering I downloaded the AviSynthShader-1.3.2.zip?
I had the Microsoft C++ 2008, 2010, 2012 and 2013 (All of them in last updates) and Microsoft .NET Framework 4.5.2 and 4.6.1, and AviSynth 2.6 ST. Windows 7 32 bits.

MysteryX

30th December 2015, 05:59

luquinhas0021, what error are you getting? AviSynthShader depends neither on VC runtime libraries (they're included, I know it's not good for DLLs but I'm not seeing any issue), nor on .NET.

Here's something cool. The bottleneck is memory transfers, right?

I've done a hybrid between SuperRes and Super-xBR, called SuperResXBR. It performs both operations at the same time, reducing memory transfers and increasing performance.
https://github.com/mysteryx93/AviSynthShader/tree/master/Shaders/SuperResXBR

Using KNLMeansCL with cmode=true allows me to use stronger SuperRes, which further reduces the halo effects of Super-xBR. I'm using SuperRes with 2 passes of .50 or .75, and Super-xBR with its default settings, and it looks just as good as NNEDI3+SuperRes and even slightly better and sharper. Quality is better.

Performance-wise, you'll get about the same performance as NNEDI3+SuperRes, EXCEPT that the CPU runs at 15% instead of 45%! If I encode with x265, this leaves a LOT more CPU juice to run the heavy encoder.

There's only one issue. Here are the screenshots of my complex script with NNEDI3 (left) vs Super-xBR (right). There is a line of distortion at the top with Super-xBR. Anyone has an idea about how to fix that? These screenshots are with 2 passes of .50. 2 passes of .75 works fine with NNEDI3 but appear too much for Super-xBR.
http://s20.postimg.org/zfaojhnfd/Super_Res_NNEDI3.png (http://postimg.org/image/zfaojhnfd/) http://s20.postimg.org/tfritks0p/Super_Res_XBR.png (http://postimg.org/image/tfritks0p/)

Edit: here's a really good shot. In the middle is NNEDI3+SuperRes(Passes=2, Strength=.75). On the right is the following script. To see how far we've gone, on the left is NNEDI3(nns=4)
http://s20.postimg.org/rrsdexe55/Good_NNEDI3.jpg (http://postimg.org/image/rrsdexe55/) http://s20.postimg.org/e9lh2n1zt/Good_Super_Res_NNEDI3.png (http://postimg.org/image/e9lh2n1zt/) http://s20.postimg.org/cgikebgt5/Good_Super_Res_XBR.png (http://postimg.org/image/cgikebgt5/)

With such quality difference, I can forgive the distortion at the top; or crop it afterwards.

file="Preview.avi"
AviSource(file, audio=True, pixel_type="YV12")
ConvertToYV24()
KNLMeansCL(D=1, A=2, h=2.1, cmode=true, device_type="GPU", device_id=1)
ConvertToYV12()
Crop(0, 0, -8, -0)
SuperResXBR(2, .6, 0, xbrEdgeStrength=2.5, xbrSharpness=1.2, MatrixIn="601")
InterFrame(Cores=8, Tuning="Smooth", NewNum=60000, NewDen=1001)
SuperResXBR(2, .6, 0, xbrEdgeStrength=2.5, xbrSharpness=1.2)
ResizeX(944, 720, 0, 4, -4, -4, kernel="Bicubic", a1=-.6, a2=0)

luquinhas0021

30th December 2015, 15:12

I'm with AviSynthShader-1.3.2's .zip file. What should I do now?

foxyshadis

30th December 2015, 16:00

I'm with AviSynthShader-1.3.2's .zip file. What should I do now?

Don't be so helpless. Install the plugin like any other plugin. Put the shaders anywhere you want and call them with Shader("C:\Path\To\File") like opening any other file.

MysteryX

30th December 2015, 23:23

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

Version 1.3.3: December 30th 2015
- Shader.dll: Added the option to copy clip data without processing by leaving Path empty
- Shader.dll: Fixed a bug where input textures were unecessarily copied for each command. This slightly increases performance and reduces CPU usage
- Added SuperResXBR, a hybrid between SuperRes and Super-xBR that runs both in the same command chain, reducing memory usage and improving performance
- SuperRes: Fixed a bug where YUV-RGB conversion was ignored when Convert=false
- SuperRes: Added ConvertYuv to specify whether to convert YUV-RGB data or not

When I did the previous tests with Super-xBR combined with SuperRes, it wasn't doing the YUV-RGB conversion which slightly deteriorated the image. By fixing this, results are better and it is seriously good. Performance is also very good. On a 288p clip with a quad-core i7 and a Radeon HD 7670M, I'm getting 55fps with a simple call to SuperResXBR. This is getting interesting.

luquinhas0021

31st December 2015, 00:59

Mistery, for installing your plugin, all I need is paste Shader.dll on Avisynth's plugin folder (I did it)? In Avisynthshader.zip, comes a bunch of .cso files? What I do with them? Avisynth Shader requires some other plugin or a Windows component for it work?
I did the follow script, but Avisynth speaked that the function SuperXBR doesn't exist:

ImageSource("C:\Users\Fernando H. Silva\Documents\Lucas\Imagens\Cat.jpg")
SuperXBR(EdgeStrenght=1, Sharpness=1)
Some is incomplete?

I've tried this follow script:

LoadPlugin("Shader.dll")

ImageSource("C:\Users\Fernando H. Silva\Documents\Lucas\Imagens\Cat.jpg")
SuperXBR(EdgeStrenght=1, Sharpness=1)

The message that player shows is: "Unable to load "Shader.dll": module not found. Install missing library?"

I'm with v1.3.3. My DirectX is the 11.1.

foxyshadis

31st December 2015, 01:40

It's Avisynth 2.6 only, and you need the DirectX runtimes (https://www.microsoft.com/en-us/download/details.aspx?DisplayLang=en&id=35) installed. But in this case, you probably just need a full path to the plugin, instead of just the name. The .cso files are the shaders.

MysteryX, I notice in your avsi files, you have no provision for the path to the shaders. Since virtually anything can change the current directory, or people may elect to keep the folder structure as-is, it makes more sense to have a path="" option to point to the shaders, and perhaps trying both pathless and with a local known path if that fails, like SuperRes looking in both ".\" and "SuperRes\".

MysteryX

31st December 2015, 03:17

Before I had an option to specify the path. Now it will look in the same folder as Shader.dll. Before I had all the CSO files in the same folder as all other plugins. Now I created a sub-folder called Shaders and put Shader.dll and all CSO files in there, to make it cleaner. It uses DirectX9.

Make sure to import SuperResXBR.avsi. If the DLL doesn't load, however, I don't know. Perhaps it's not finding it.

luquinhas0021

1st January 2016, 04:52

MisteryX, please, post results of Superres-xBR of Clown and Lighthouse images. The image you posted the results is too blocky.

MysteryX

1st January 2016, 17:37

MisteryX, please, post results of Superres-xBR of Clown and Lighthouse images. The image you posted the results is too blocky.
I'll post these later. For now, Super-xBR has a half-pixel shift to the right and a 1-pixel vertical stretching. This makes SuperRes run a little bit offset. And if you run it twice, it doubles the distortion. I'll see what I can do.

MysteryX

5th January 2016, 20:18

I made another improvement to SuperResXBR: adding WidthOut and HeightOut parameters, allowing to downscale the result before transfering back from the GPU.

This allows to downscale with high-bit-depth and to reduce memory transfers

This change isn't released into a package but you can get the updated file here
https://github.com/mysteryx93/AviSynthShader/blob/master/Shaders/SuperResXBR/SuperResXBR.avsi

MysteryX

7th January 2016, 07:12

WOW. I spent a lot of time trying to port it to DX11 with DirectCompute, to realize DirectCompute would require the shaders to be written differently, and to realize that Super-xBR, after all, is already written with PS_3_0.

Then the next is how to configure the STRUCT parameters... I spent quite a bit of time to allow configuring greater arrays of values, to realize that the STRUCT wasn't even being used. In the end, I realized the parameters being used are in the separate included file.

And the file compiles as-is with PS_3_0. It simply got broken in the unnecessary adaption.

Simply recompiling the original HLSL file solves the distortion problem... duh...

Will test and release soon.

MysteryX

7th January 2016, 19:54

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

What's new:
- Shader.dll: It is now possible to set parameter as vectors with more than 4 values
- Super-xBR and SuperResXBR: Fixed image distortion.
- SuperResXBR: Added WidthOut, HeightOut, b and c to do a final Bicubic resize before reading from GPU, reducing memory transfers

I added image comparison of SuperResXBR to the first post. Now that I look at it, Lighthouse doesn't look that good. Definitely a LOT more details coming out, but also lots of ringing and the straight lines appear like zigzags. You can tone down settings to remove ringing, but the zigzags remain. The 2 other images look very good. These problems only seem apparent on images with straight lines.

Edit: I just added another version of Lighthouse with weak settings that looks better

Hyllian

8th January 2016, 01:00

5. SuperRes(2, .43, 0, """edi_rpow2(2, nns=4, cshift="Spline16Resize")"""), twice

http://s20.postimg.org/5jkzo0vyx/Lighthouse_Super_Res.png (http://postimg.org/image/5jkzo0vyx/) http://s20.postimg.org/ze1xq1mft/Clown_Super_Res.png (http://postimg.org/image/ze1xq1mft/) http://s20.postimg.org/j4brn5brt/Eclipse_Super_Res.png (http://postimg.org/image/j4brn5brt/)

I'd like to understand this config. It's called SuperRes. Does it use Spline16Resize as the resizer?

This is the best combo in my eyes.

sqrt(9801)

8th January 2016, 02:07

It uses NNEDI3(_rpow2) and Spline16Resize for correcting the center shift.

And the file compiles as-is with PS_3_0. It simply got broken in the unnecessary adaption.

Simply recompiling the original HLSL file solves the distortion problem... duh...

Does that mean it was always possible to just compile the original HLSL file from the MPDN_Extensions repo and have it work in AvisynthShader ? If so, I kinda feel stupid, haha.

MysteryX

8th January 2016, 02:47

Does that mean it was always possible to just compile the original HLSL file from the MPDN_Extensions repo and have it work in AvisynthShader ? If so, I kinda feel stupid, haha.
Yes. Don't take it personal.

It means we can also port NNEDI3 the same way. I see NNEDI3 had to be compiled many times... perhaps compiling at run-time and being able to set HLSL compile-time parameters would be useful?

This is the best combo in my eyes.
SuperResXBR is working surprisingly well on my 288p VCD sources.

loneboyz

8th January 2016, 02:52

- SuperResXBR: Added WidthOut, HeightOut, b and c to do a final Bicubic resize before reading from GPU, reducing memory transfers

It seem still old, I can't see this parameter of function in script?

MysteryX

8th January 2016, 03:54

It seem still old, I can't see this parameter of function in script?
Oups. Fixed.

SuperResXBR seems very good on irregular textures and live action footage, even when it has artifacts. However, it's not as good on geometric forms and straight lines.

loneboyz

8th January 2016, 05:41

MysteryX

8th January 2016, 05:47

Thank MysteryX!

Follow your documentation, SuperResXBR with default b=0, c=0.75 when downscale with Bicubic (call second after larger upscale). So, what this has different from your previous settings b=-0.6, c=0 in SuperRes?
-.6,0 actually looks very similar to 0,.75, and 0,.75 just looks slightly better.

And this goes right back to what's written in the Bicubic documentation about these settings
http://avisynth.nl/index.php/Resize

Hyllian

8th January 2016, 13:01

SuperResXBR is working surprisingly well on my 288p VCD sources.

I'm trying to understand what is SuperResXBR.

Did you put both shaders inside one and called it that way? Or have you put those shaders separately and wrote a script to call both shaders one after the other, then called it that way?

That's because they're very distinct shaders with different purposes.

sqrt(9801)

8th January 2016, 17:56

As far as I can tell, it's just a wrapper for SuperRes, using Super-XBR as the upscaler.

Same as using something like SuperRes(2, .43, 0, """SuperXBR()"""), but faster because the output of Super-XBR isn't transferred to RAM.

Yes. Don't take it personal.

It means we can also port NNEDI3 the same way.
I'm not. Messing up is the best way to learn (and nourish my inferiority complex), IMO. I mostly feel bad for wasting your time. <_>

It looks like NNEDI3 still needs SM 5.0, though. As for compiling at run-time, I guess it depends on how much time it takes to compile the shaders ?

MysteryX

8th January 2016, 18:20

I'm trying to understand what is SuperResXBR.

Did you put both shaders inside one and called it that way? Or have you put those shaders separately and wrote a script to call both shaders one after the other, then called it that way?

That's because they're very distinct shaders with different purposes.
According to doc:
Enhances upscaling quality, combining Super-xBR and SuperRes to run in the same command chain, reducing memory transfers and increasing performance.

Arguments are the same as SuperRes and Super-xBR

Hyllian

8th January 2016, 18:31

Thanks for the answer.

And those screenshots (all number 5), are they NNEDI3 + Spline16 + SuperRes? They look perfect!

MysteryX

8th January 2016, 19:24

And those screenshots (all number 5), are they NNEDI3 + Spline16 + SuperRes? They look perfect!

Yes

5. SuperRes(2, .43, 0, """edi_rpow2(2, nns=4, cshift="Spline16Resize")"""), twice

I'd be curious to see the quality and performance difference if we run NNEDI3 on the GPU in the same run -- with high-bit-depth. It still needs to be implemented. It might be slower than the CPU version of NNEDI3.

MysteryX

13th January 2016, 06:45

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

What's new:
- Combined all scripts into one file for simplicity
- Shortened some of the parameters
- SuperXBR: Removed ThirdPass argument, added MatrixIn and MatrixOut
- SuperXBR and SuperResXBR: Now does YUV to RGB color conversion

jpsdr

15th January 2016, 09:46

5. SuperRes(2, .43, 0, """edi_rpow2(2, nns=4, cshift="Spline16Resize")"""), twice

What do you mean exactly by twice ?

Can you provide the avs script used for this case ?

:thanks:

jpsdr

15th January 2016, 12:13

I've just tried, and have the following error message, translated it gives :
The entry point of the procedure Direct3DCreate9Ex cannot be found in the library of dynamic links d3d9.dll.

Edit : It doesn't seem to be realy important, i don't know. Now, script is telling that it can't find "ConvertToShader".
I thought the package was self efficiant. Others things are to download ?
I found nothing in the first post about any other thing to download, and nothing about some specific install to make.

MysteryX

15th January 2016, 16:44

Direct3DCreate9Ex requires Windows Vista or above. What OS are you using?

Search this error message in Google, you'll find interesting information (https://www.google.com/search?q=The+entry+point+of+the+procedure+Direct3DCreate9Ex+cannot+be+found+in+the+library+of+dynamic+links+d3d9.dll)

This, perhaps? (https://www.youtube.com/watch?v=tgbU7ucM0s0)

jpsdr

15th January 2016, 17:46

Ok, it explains things. I've first try at work, where my PC is under Windows XP. I've just tried at home, with PC under Window 7 x86, it worked fine, thanks.
Little question : Do you have an x64 version by any chance ?

MysteryX

15th January 2016, 22:55

Do you have an x64 version by any chance ?
No I haven't done a x64 version yet. I guess it shouldn't be difficult, but I haven't got into looking at how to do a x64 compilation with C++.

MysteryX

16th January 2016, 06:52

Oh, I just found a use for SuperRes's Softness parameter! I got a video where Super-xBR causes too much ringing, yet it still looks slightly better than with NNEDI3. In which case, it's useful to use SuperRes with greater strength to neutralize the ringing (2 passes of Strength=1), and Softness allows for that. Still not perfect, but it looks good

jinkazuya

16th January 2016, 08:22

Is it possible for somebody to enlighten me on how to install this plugin? It would be great cuz it is nice to enhance some of the videos in high quality. Thanks.

jpsdr

16th January 2016, 11:21

MysteryX

16th January 2016, 20:22

I've tried to build the project, so i've clone github, try to build, but there was an error saying that "d3d9x.h" can't be found.
I've seen DirectX SDK was needed, so i get it, install it, try to build again, still the same error... What am i missing ?
You need DirectX (June 2010) SDK
https://www.microsoft.com/en-ca/download/details.aspx?id=6812

Btw you must uninstall VC++ 2010 Redistributables before installing it, otherwise setup will fail.

Install AviSynthShader just like any other filter. Either copy the files into your Plugins folder, or into any folder and load the DLL and AVSI files. The CSO files must be in the same folder as the DLL.

Peronally, I created a sub-folder called Shaders containing the DLL, AVSI and all CSO files, and import the DLL and AVSI manually.

jpsdr

17th January 2016, 09:56

You need DirectX (June 2010) SDK
https://www.microsoft.com/en-ca/download/details.aspx?id=6812

As i've said, i've installed it.

Btw you must uninstall VC++ 2010 Redistributables before installing it, otherwise setup will fail.

Yes... I've learned it the hard way...:sly:

But there is still the result when i try to build :

1>------ Début de la génération*: Projet*: Shader, Configuration*: Release Win32 ------
1> ConvertFromShader.cpp
1>f:\prg\x264\avisynthshader\src\ConvertFromShader.h(7): fatal error C1083: Impossible d'ouvrir le fichier include*: 'd3dx9.h'*: No such file or directory
1> ConvertToShader.cpp
1>f:\prg\x264\avisynthshader\src\ConvertToShader.h(7): fatal error C1083: Impossible d'ouvrir le fichier include*: 'd3dx9.h'*: No such file or directory
1> ExecuteShader.cpp
1>f:\prg\x264\avisynthshader\src\ExecuteShader.h(4): fatal error C1083: Impossible d'ouvrir le fichier include*: 'd3dx9.h'*: No such file or directory
1> Init.cpp
1>f:\prg\x264\avisynthshader\src\ConvertToShader.h(7): fatal error C1083: Impossible d'ouvrir le fichier include*: 'd3dx9.h'*: No such file or directory
1> Shader.cpp
1>f:\prg\x264\avisynthshader\src\Shader.h(4): fatal error C1083: Impossible d'ouvrir le fichier include*: 'd3dx9.h'*: No such file or directory
1> D3D9RenderImpl.cpp
1>f:\prg\x264\avisynthshader\src\D3D9Macros.h(2): fatal error C1083: Impossible d'ouvrir le fichier include*: 'd3dx9.h'*: No such file or directory
========== Génération*: 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

I have no issue installing the filter and using it, it's just i've try to build it (VS2015 Update 1), and still failled.

MysteryX

18th January 2016, 03:23

Do you have a 32-bit or 64-bit system? In project properties, these are configured under Linker|Input|Additional Dependencies.

Perhaps you need to update the paths under VC++ Directories.

aegisofrime

18th January 2016, 06:14

Hi MysteryX. I have read the documentation a few times but I'm still confused. If I'm reading it right, if I call SuperResXBR I do not need to call SuperRes, correct? The wording seems to imply that calling SuperResXBR will also call SuperRes and Super-XBR without any need for me to call them...

loneboyz

18th January 2016, 09:56

The way I see, it is considered that the combination of SuperRes with Super-XBR. Instead of calling both SuperRes and Super-XBR, then you'll only call SuperResXBR. The results is the same.

jpsdr

18th January 2016, 11:23

Do you have a 32-bit or 64-bit system? In project properties, these are configured under Linker|Input|Additional Dependencies.

Perhaps you need to update the paths under VC++ Directories.

I have a 32-bit system. Never thought this could affect the build process, i thought that path for SDK were added automaticaly on VS product when installed.

Ok, thanks for the information nevertheless, i'll check this evening when back home.

aegisofrime

18th January 2016, 13:01

The way I see, it is considered that the combination of SuperRes with Super-XBR. Instead of calling both SuperRes and Super-XBR, then you'll only call SuperResXBR. The results is the same.

The thing that confused me is that SuperResXBR does not have a Upscaler parameter. That is pretty much a required parameter that you must pass to SuperRes. The absence of this parameter in SuperResXBR caused me to have doubts.

CkJ

18th January 2016, 13:34

The thing that confused me is that SuperResXBR does not have a Upscaler parameter. That is pretty much a required parameter that you must pass to SuperRes. The absence of this parameter in SuperResXBR caused me to have doubts.

You mean the scale factor? I think it's 2x because 3 and 7 have the same size.
3. nnedi3_rpow2(4, nns=4, cshift="Spline16Resize")
7. SuperResXBR(1, .7, xbrEdgeStrength=.1, xbrSharpness=.7), twice

Hyllian

18th January 2016, 14:44

During my development and tests, I think the best values for super-xbr params (xbrEdgeStrength, xbrSharpness) are in these ranges:

xbrEdgeStrength between 1.0 and 2.0 (1.5 is the best for the clown image).
xbrSharpness between 0.3 and 1.0 (above 1.0 inctroduce some strange artifacts and intensify the ringing too much).

MysteryX

18th January 2016, 17:12

I have a 32-bit system. Never thought this could affect the build process, i thought that path for SDK were added automaticaly on VS product when installed.
It changes the path from "Program Files" to "Program Files (x86)" to find the DirectX SDK files.

The thing that confused me is that SuperResXBR does not have a Upscaler parameter. That is pretty much a required parameter that you must pass to SuperRes. The absence of this parameter in SuperResXBR caused me to have doubts.
That's because the upscaler is hard-coded as SuperRes-xBR. Instead of passing an upscaler string, you pass Super-xBR's parameters. It gives almost the same result as calling them separately, except that performance is higher due to reduced memory transfers, and quality is slightly better due to processing the whole thing in 16-bit without any rounding.

During my development and tests, I think the best values for super-xbr params (xbrEdgeStrength, xbrSharpness) are in these ranges:

xbrEdgeStrength between 1.0 and 2.0 (1.5 is the best for the clown image).
xbrSharpness between 0.3 and 1.0 (above 1.0 inctroduce some strange artifacts and intensify the ringing too much).
That's for Super-xBR on its own. When adding SuperRes, it greatly reduces ringing and it changes the game.

MysteryX

18th January 2016, 18:42

I added support for 64-bit but haven't tested it. You guys can play with it and let me know if there is any problem.
https://github.com/mysteryx93/AviSynthShader/blob/master/Release/Shader-x64.dll

I was wondering how to download a specific file from GitHub... found it... just press the "Raw" button.

jpsdr

18th January 2016, 20:51

Changing the VC++ directory solved issue, thanks.

luquinhas0021

20th January 2016, 22:45

I am trying use AviSynth Shader 1.3.5, with this following script line

SuperXBR(MatrixIn="Rec601", EdgeStrength=1.5, Sharpness=0.9, MatrixOut="Rec709")

When I go open the .avs file in MPC-BE 1.4.5, the player shows: "SuperXBR doesn't have a function name called "EdgeStrength". What can I do to solve this?

MysteryX

20th January 2016, 22:52

I changed the parameter names but didn't update the documentation on this page. Look at parameters information on the GitHub page (https://github.com/mysteryx93/AviSynthShader), or within the AVSI file.

bxyhxyh

19th February 2016, 05:49

Please tell me how 2 pass is better than 1 pass.
I'm not saying 1 pass is enough or something.

I'm asking what really pass settings do.

MysteryX

19th February 2016, 11:49

Honestly, 2 passes with Str=.45 is almost the same as 1 pass with Str=.9, with very slight quality improvement based on the source.

If you want more Strength (sharpness) than 1, then 2 passes will allow you to increase the strength further.

2 passes with Str=.6 appears to be identical to 3 passes with Str=.6

Oh, and if you use the Softness parameter, it will only have an effect if you use 2 passes.

bxyhxyh

20th February 2016, 05:28

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

MysteryX

20th February 2016, 07:01

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.

luigizaninoni

4th March 2016, 20:47

MysteryX

6th March 2016, 13:49

SuperRes works fine with Avisynth+ 64-bit
Good to know! Still haven't tested it :)

burfadel

7th March 2016, 05:53

Good to know! Still haven't tested it :)

Works fine here too :). Is it generically compiled or optimised?

I notice that SuperRes has recently been updated in the recent MPDN extensions (potentially better quality and faster), any chance of this plugin being updated with the changes?

MysteryX

7th March 2016, 15:57

Oh, you're right. The new version will give performance improvement. Super-xBR was also updated. I also want to integrate SSimDownscaler.

Not sure when I'll have time to do that. If someone else wants to do the update, I'll integrate the changes.

It is generically compiled. Since the bottleneck is the memory transfers from the GPU back to the CPU, I doubt you'll get much improvement from compile optimizations.

MysteryX

2nd May 2016, 09:41

v1.3.6 released! (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.3.6)

What's new:
- Includes the x64 DLL
- Updated SuperRes and Super-xBR to the latest version
- SuperRes is now over 50% faster by using custom downscaler!

Todo: Implement SSimDownscaler

MysteryX

5th May 2016, 11:10

v1.3.7 released! (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.3.7)

What's new:
- Fixed SuperRes as the last upgrade was broken
- SuperRes 20-50% faster than previously
- SuperRes now produces a softer result but with much less ringing and its setting can be increased for extra sharpness

Here is a benchmark comparison

SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("AviSource",3)
AviSource("Preview.avi", audio=false, pixel_type="YV12") #288p video
SuperResXBR(2, 0.6, 0, XbrStr=2, XbrSharp=1.2, MatrixIn="601")
SuperResXBR(2, 0.6, 0, XbrStr=2, XbrSharp=1.2)
Prefetch(8)

SuperRes v1.3.5

Frames processed: 518 (0 - 517)
FPS (min | max | average): 0.485 | 1000000 | 11.23
Memory usage (phys | virt): 557 | 869 MB
Thread count: 143
CPU usage (average): 8%

SuperRes v1.3.7

Frames processed: 523 (0 - 522)
FPS (min | max | average): 0.444 | 1000000 | 16.03
Memory usage (phys | virt): 610 | 990 MB
Thread count: 162
CPU usage (average): 12%

Note: Super-xBR+SuperRes is working with AviSynth+ MT, but NNEDI3+SuperRes won't work with the latest AviSynth+ MT build because the image gets shifted to the left. AVS 2.6 is still the most reliable for this.

luigizaninoni

5th May 2016, 13:56

MysteryX, could you make a Vapoursynth version of you excellent plugin ? MT works much better in VS than in Avisynth

MysteryX

5th May 2016, 16:09

MysteryX, could you make a Vapoursynth version of you excellent plugin ? MT works much better in VS than in Avisynth

It would require a lot of work from my part and I personally have no need for VapourSynth; neither do I know anything about VapourSynth.

Not only the DLL code-base would have to be adapted, the whole AVSI script file would also have to be rewritten.

I don't know how easy or hard it is to adapt the DLL, but I don't think it will happen anytime soon unless someone else decides to implement it.

I will however work on implementing SSimDownscaler.

On a side note, I wouldn't expect much performance difference between VapourSynth and AviSynth as the bottleneck is memory transfers from the GPU to the CPU which will remain the same either way.

luigizaninoni

6th May 2016, 06:03

On a side note, I wouldn't expect much performance difference between VapourSynth and AviSynth as the bottleneck is memory transfers from the GPU to the CPU which will remain the same either way.

Ah, so that's the reason I'm seeing lowish GPU and CPU % usage. Ok, so porting to VS would be practically useless from this point of view

MysteryX

6th May 2016, 06:15

Ah, so that's the reason I'm seeing lowish GPU and CPU % usage. Ok, so porting to VS would be practically useless from this point of view
Correct.

I do, however, make great savings in memory transfers by executing all the shaders at the same time before returning them from the GPU.

madVR can make much better use of the GPU because it doesn't need to trasfer back from the GPU; it only displays forward.

MysteryX

8th May 2016, 08:54

Here are some image comparison with the latest version.

1. nnedi3_rpow2(4, nns=4, cshift="Spline16Resize")
2. SuperResXBR(2, 0.6, XbrStr=2, XbrSharp=1), old version, twice
3. SuperResXBR(2, 0.6, XbrStr=2, XbrSharp=1), new version, twice
4. SuperResXBR(2, 1, XbrStr=2.2, XbrSharp=1.4), new version, twice

http://s20.postimg.org/5yts02f6h/Clown_NNEDI3.jpg (http://postimg.org/image/5yts02f6h/) http://s20.postimg.org/6uu9t4vyx/Clown_Update_Old.png (http://postimg.org/image/6uu9t4vyx/) http://s20.postimg.org/76bq5wcex/Clown_Update_New.png (http://postimg.org/image/76bq5wcex/) http://s20.postimg.org/8b5sb9yvt/Clown_Update_Sharp.png (http://postimg.org/image/8b5sb9yvt/)

http://s20.postimg.org/qzamti3x5/Lighthouse_NNEDI3.jpg (http://postimg.org/image/qzamti3x5/) http://s20.postimg.org/5ickr8yjd/Lighthouse_Update_Old.png (http://postimg.org/image/5ickr8yjd/) http://s20.postimg.org/fgxjdq7yx/Lighthouse_Update_New.png (http://postimg.org/image/fgxjdq7yx/) http://s20.postimg.org/awbcyso9l/Lighthouse_Update_Sharp.png (http://postimg.org/image/awbcyso9l/)

MysteryX

16th May 2016, 14:06

SSimDownscaler is almost ready BUT there is a weird bug where the border pixel gets random noise which I haven't figured out yet.

However, here's a real-life comparison of before and after.

Before: Super-XBR(Str=20, Sharp=12) + SuperRes(2 passes of Str=.6), twice, with Bicubic downscaling(B=0, C=.75)
http://s20.postimg.org/lmjd9r1zt/SSim_Before.png (http://postimg.org/image/lmjd9r1zt/)

After: Super-XBR(Str=30, Sharp=15) + SuperRes(2 passes of Str=1), twice, with SSimDownscaler(Str=1)
http://s20.postimg.org/m0kp9cm3d/SSim_After.png (http://postimg.org/image/m0kp9cm3d/)

The new image is definitely softer and requires higher settings; pretty much max settings to get similar sharpness. The artifacts and halos, however, are much weaker than in the previous image.

With softer artifacts, I suspect that the MP4 compressibility will be higher and there will be additional gain there.

MysteryX

17th May 2016, 08:52

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

What's new:
- Tweaked DLL for better MT support (thanks to Pinterf)
- ConvertToShader, ConvertFromShader and Shader now support MT=1. ExecuteShader supports MT=2.
- Added SSimDownscaler for high-quality downscaling
- SuperResXBR now uses SSimDownscaler instead of Bicubic for final resize
- Added fWidth, fHeight, fStr and fSoft to SuperRes, SuperXBR and SuperResXBR
- Fixed a bug in the DLL where it wouldn't search the DLL's folder to find non-compiled HLSL shaders with relative path.
- Fixed a bug where CLAMP for out-of-bound pixels was only applied to the first clip.

MysteryX

17th May 2016, 13:48

Here's an image comparison of SSimDownscaler

I'm downscaling by 1.3 and then multiplying by 3 with Spline16

1. Bicubic
2. Bicubic(0, .75)
3. SSim(.5)
4. SSim(.5, Soft)
5. SSim(1)
6. SSim(1, Soft)

http://s20.postimg.org/mse6h2bix/Clown_Down_Bicubic.png (http://postimg.org/image/mse6h2bix/) http://s20.postimg.org/yis3yg4bd/Clown_Down_Bicubic75.png (http://postimg.org/image/yis3yg4bd/) http://s20.postimg.org/cywz499eh/Clown_Down_SSim5.png (http://postimg.org/image/cywz499eh/) http://s20.postimg.org/hwajpdbdl/Clown_Down_SSim5_Soft.png (http://postimg.org/image/hwajpdbdl/) http://s20.postimg.org/k8ijmynyx/Clown_Down_SSim1.png (http://postimg.org/image/k8ijmynyx/) http://s20.postimg.org/5qlceywnt/Clown_Down_SSim1_Soft.png (http://postimg.org/image/5qlceywnt/)

http://s20.postimg.org/hslbmuva1/Lighthouse_Down_Bicubic.png (http://postimg.org/image/hslbmuva1/) http://s20.postimg.org/4ppp3l521/Lighthouse_Down_Bicubic75.png (http://postimg.org/image/4ppp3l521/) http://s20.postimg.org/jvvquiv2x/Lighthouse_Down_SSim1.png (http://postimg.org/image/jvvquiv2x/) http://s20.postimg.org/s6hk2cqmx/Lighthouse_Down_SSim1_Soft.png (http://postimg.org/image/s6hk2cqmx/) http://s20.postimg.org/eoanq2ehl/Lighthouse_Down_SSim5.png (http://postimg.org/image/eoanq2ehl/) http://s20.postimg.org/9ffms6w2h/Lighthouse_Down_SSim5_Soft.png (http://postimg.org/image/9ffms6w2h/)

Which would you say is best?

I have to admit that SSim fails with the Lighthouse... Bicubic(0,.75) looks best.

The following are simply divided by 1.3

http://s20.postimg.org/slstvdck9/Eclipse_Down_Bicubic.png (http://postimg.org/image/slstvdck9/) http://s20.postimg.org/y11jwc449/Eclipse_Down_Bicubic75.png (http://postimg.org/image/y11jwc449/) http://s20.postimg.org/f65t5x42h/Eclipse_Down_SSim1.png (http://postimg.org/image/f65t5x42h/) http://s20.postimg.org/p4qrsedi1/Eclipse_Down_SSim1_Soft.png (http://postimg.org/image/p4qrsedi1/) http://s20.postimg.org/n1gurn74p/Eclipse_Down_SSim5.png (http://postimg.org/image/n1gurn74p/) http://s20.postimg.org/lnp7wc7vd/Eclipse_Down_SSim5_Soft.png (http://postimg.org/image/lnp7wc7vd/)

MysteryX

17th May 2016, 14:09

Here's more

http://s20.postimg.org/7avry0nvd/Orig_Down_Bicubic.png (http://postimg.org/image/7avry0nvd/) http://s20.postimg.org/en183k63d/Orig_Down_Bicubic75.png (http://postimg.org/image/en183k63d/) http://s20.postimg.org/sffmz6wux/Orig_Down_SSim1.png (http://postimg.org/image/sffmz6wux/) http://s20.postimg.org/904v633kp/Orig_Down_SSim1_Soft.png (http://postimg.org/image/904v633kp/) http://s20.postimg.org/omw4jghcp/Orig_Down_SSim5.png (http://postimg.org/image/omw4jghcp/) http://s20.postimg.org/3sjs1mmzd/Orig_Down_SSim5_Soft.png (http://postimg.org/image/3sjs1mmzd/)

Honestly the difference in this one is minimal.

luquinhas0021

18th May 2016, 05:34

It's clear for me that SSIM maintain more detail and it's sharper than Bicubic. Great choice, Mystery!
SuperRES upscaling with nnedi3 with those optimal configurations I told you, with SSIM downscaler, beats SuperResXBR, non-soft, with SSIM downscaler? both in sharpness and detail retention.
I'm a little curious about SuperRES with Spline 144 upscaler and SSIM downscaler

MysteryX

18th May 2016, 07:48

Version 1.4.1 is ready (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.4.1)

What's new:
- Bug fix: SuperRes and SuperResXBR were performing downscaling in YUV format which caused quality loss
- Bug fix: MatrixOut parameter was ignored
- Both SSim and Bicubic can now be used for downscaling
- SuperRes, SuperXBR and SuperResXBR now have these parameters: fDownscaler, fWidth, fHeight, fStr, fSoft, fB, fC
- SSimDownscaler now has these parameters: Downscaler, Width, Height, Str, Soft, B, C
- SSimDownscaler: changed parameter W to Width, H to Height

MysteryX

18th May 2016, 10:09

Here are some image comparison with the new version.

1. NNEDI3+Bicubic
edi_rpow2(4, nns=4, cshift="BicubicResize", a1=0, a2=.75, fwidth=int(width*3.2)/2*2, fheight=int(height*3.2)/2*2)

2. SuperRes+Sinc
U="""ResizeX(int(Width*3.2)/2*2, int(Height*3.2)/2*2, kernel="Sinc")"""
SuperRes(2, Str=1, Soft=.15, Upscale=U)

3. SuperRes+NNEDI3+Bicubic
SuperRes(2, Str=1, Soft=.15, Upscale="""edi_rpow2(2, nns=4, cshift="Spline16Resize")""")
U="""edi_rpow2(2, nns=4, cshift="BicubicResize", a1=0, a2=.75, fwidth=int(width*1.6)/2*2, fheight=int(height*1.6)/2*2)"""
SuperRes(2, Str=1, Soft=.15, Upscale=U)

4. SuperRes+NNEDI3+SSim
U="""edi_rpow2(2, nns=4, cshift="Spline16Resize")"""
SuperRes(2, Str=1, Soft=.15, Upscale=U)
SuperRes(2, Str=1, Soft=.15, Upscale=U, fWidth=int(Width*1.6)/2*2, fHeight=int(Height*1.6)/2*2, fStr=1)

5. SuperRes+SuperXBR+SSim
SuperResXBR(2, Str=1, Soft=.15, XbrStr=2.2, XbrSharp=1.3)
SuperResXBR(2, Str=1, Soft=.15, XbrStr=2.2, XbrSharp=1.3, fWidth=int(Width*1.6)/2*2, fHeight=int(Height*1.6)/2*2, fStr=1)

http://s20.postimg.org/b6vbos4pl/Clown_Down_Nnedi_Bicubic.png (http://postimg.org/image/b6vbos4pl/) http://s20.postimg.org/f72h10v6h/Clown_Down_Super_Res_Sinc.png (http://postimg.org/image/f72h10v6h/) http://s20.postimg.org/tc8a2u47t/Clown_Down_Super_Res_Nnedi_Bicubic.png (http://postimg.org/image/tc8a2u47t/) http://s20.postimg.org/uv89lk061/Clown_Down_Super_Res_Nnedi_Ssim.jpg (http://postimg.org/image/uv89lk061/) http://s20.postimg.org/lysw3vk61/Clown_Down_Super_Res_Xbr_Ssim.jpg (http://postimg.org/image/lysw3vk61/)

http://s20.postimg.org/qpxczn2e1/Lighthouse_Down_Nnedi_Bicubic.png (http://postimg.org/image/qpxczn2e1/) http://s20.postimg.org/c9a3l2cwp/Lighthouse_Down_Super_Res_Sinc.png (http://postimg.org/image/c9a3l2cwp/) http://s20.postimg.org/5dpv1yift/Lighthouse_Down_Super_Res_Nnedi_Bicubic.png (http://postimg.org/image/5dpv1yift/) http://s20.postimg.org/asyl2x9zt/Lighthouse_Down_Super_Res_Nnedi_Ssim.png (http://postimg.org/image/asyl2x9zt/) http://s20.postimg.org/qonf680k9/Lighthouse_Down_Super_Res_Xbr_Ssim.png (http://postimg.org/image/qonf680k9/)

I cannot test Spline144 because ResizeX is required for pixel shift correction and it doesn't support Spline144.

luquinhas0021

18th May 2016, 19:41

It's clear SuperRES + SuperXBR + SSIM is better!!!
Your plugin is compatible with Vapoursynth R32?

MysteryX

19th May 2016, 17:16

Oups, I was processing SSim AFTER SuperRes instead of BEFORE! I fixed it to downscale first which increases both performance and quality.

Version 1.4.2 (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.4.2)

What's new:
- SuperRes and SuperResXBR: Final downscaling is now done before processing SuperRes which increases both quality and performance
- Shader: If not specified Param0 is now set to Width,Height and Param1 is set is 1/Width,1/Height
- SSimDownsdaler: Soft default value changed from .5 to 1

No it doesn't support VapourSynth.

luquinhas0021

19th May 2016, 20:48

Why no more 0.5 for soft?
Advice: turn back to 0.5!!!

As you use to do, can you post results with new version (I suggest only SuperRES + SuperRESXBR, because it's better from far), with soft = 0.5 and soft = 1?
I will provide the ways like I test your plugin, if possible, today (In Brazil, is 16:50 hours). I promise you.
You think is good use, in SuperRES + SuperRESXBR, Soft = 0 and Str = 2 or 3?

MysteryX

20th May 2016, 04:02

I was using SSim with Strength=1 because the image was still too soft even with SuperRes at max and SuperXBR with the new algorithm... but that's because I was applying SSim AFTER applying SuperRes instead of before. Now the result is sharper so I'll have to test again to see how SSim's strength and SuperRes interact with each other, and how it compares to Bicubic.

MysteryX

20th May 2016, 05:16

Here are some updated images.

1. SuperRes+SSim+NNEDI3
U="""edi_rpow2(2, nns=4, cshift="Spline16Resize")"""
SuperRes(2, Str=1, Soft=.15, Upscale=U)
SuperRes(2, Str=1, Soft=.15, Upscale=U, fWidth=int(Width*1.6)/2*2, fHeight=int(Height*1.6)/2*2, fStr=.6)

2. SuperRes+SSim+SuperXBR
SuperResXBR(2, Str=1, Soft=.15, XbrStr=2.3, XbrSharp=1.3)
SuperResXBR(2, Str=1, Soft=.15, XbrStr=2.3, XbrSharp=1.3, fWidth=int(Width*1.6)/2*2, fHeight=int(Height*1.6)/2*2, fStr=.6)

3. SuperRes+Bicubic+SuperXBR
SuperResXBR(2, Str=1, Soft=.15, XbrStr=2.3, XbrSharp=1.3)
SuperResXBR(2, Str=1, Soft=.15, XbrStr=2.3, XbrSharp=1.3, fWidth=int(Width*1.6)/2*2, fHeight=int(Height*1.6)/2*2, fDownscaler="Bicubic")

http://s20.postimg.org/ok3ioifvd/Clown_Down_Superres_Ssim_Nnedi.png (http://postimg.org/image/ok3ioifvd/) http://s20.postimg.org/jwxgmqsih/Clown_Down_Superres_Ssim_Xbr.png (http://postimg.org/image/jwxgmqsih/) http://s20.postimg.org/e3rzzx68p/Clown_Down_Super_Res_Bicubic_Xbr.jpg (http://postimg.org/image/e3rzzx68p/)

http://s20.postimg.org/mgt3gug2h/Lighthouse_Down_Superres_Ssim_Nnedi.png (http://postimg.org/image/mgt3gug2h/) http://s20.postimg.org/9dxgxkpuh/Lighthouse_Down_Superres_Ssim_Xbr.png (http://postimg.org/image/9dxgxkpuh/) http://s20.postimg.org/gwl7jy6l5/Lighthouse_Down_Super_Res_Bicubic_Xbr.jpg (http://postimg.org/image/gwl7jy6l5/)

Fixed 2 details, will release another version after the image tests.

According to my tests, downscaling with SSim(Str=.5 or Bicubic(B=0,C=.75) gives almost identical results. Perhaps SSim just very slightly preserves more details. The main advantage of SSim in this case is that you can fine-tune it.

MysteryX

20th May 2016, 06:57

Version 1.4.3 is ready! (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1%2C4%2C3)

What's new:
- Fixed a bug introduced in SuperRes
- SuperResXBR now performs downscaling in Linear Light
- SSimDownscaler now performs downscaling in Linear Light
- SSimDownsdaler: Str default value changed back to .5

MysteryX

20th May 2016, 15:14

After doing some testing on real video footage... Bicubic(0,.75) actually gives a better result than SSim(.8), and it is also faster. The result is very similar but the edges are sharper.

I also did an encoding test with the same script and same settings except that one used SSim downscaling before SuperRes and the other used Bicubic. I used x265 encoding with fixed quality 22.
- SSim(.8): 89.1mb
- Bicubic(0,.75): 89.6mb

This indicates that there are more details to encode.

I'm getting pretty decent performance with this new version of SuperRes and with Bicubic.

I've added images above with Bicubic to compare.

luquinhas0021

21st May 2016, 01:34

MysteryX, is there some error in script above?

SuperResXBR(Passes=3, Str=1, Soft=0, XbrStr=4, XbrSharp=1.5, fDownscaler="SSim", fStr=1, fSoft=false, fB=0, fC=1)

I wrote it, and it was executed; after, I tried run it again, but... Didn't run. I guarantee you I didn't change the parameters. I ran it in a Windows computer, with LAV Filters 0.68.1 and MPC-BE 1.4.5, last update.

Your plugin don't recognize XbrStr=5, although you write in readme it does.
I put this same below script with a video, but didn't run.

Maybe the problem is the Avisynth 2.6.0 itself. I installed it again, but I didn't enough time to test.

MysteryX

21st May 2016, 07:51

what error do you get? Btw there is no need to specify fB and fC when using SSim

MysteryX

21st May 2016, 15:36

Ah! Interesting.

With 3 passes of SuperRes, there is barely any visible difference at first. BUT! It makes the video more encoder-friendly. The same video with 2 passes encodes at 95.9MB and with 3 passes at 94.7MB (with x265 fixed quality) and the encoded video is also clearer. After encoding, the small performance difference between 2 and 3 passes is worth it.

Edit: With 4 or 5 passes, there is a further reduction of the encoded file size. However, there is also a reduction of details after encoding. Thus, 3 passes appear to be what's working best according to my tests.

luquinhas0021

21st May 2016, 19:45

Both in Windows Media Player, last version, and in MPC-BE, last stable version, shows: "it's not possible render the file", translating from portuguese.

MysteryX

22nd May 2016, 01:03

Both in Windows Media Player, last version, and in MPC-BE, last stable version, shows: "it's not possible render the file", translating from portuguese.
Have you tried playing other scripts? Have you tried running SuperResXBR without arguments? We don't even know whether the problem is related to AviSynthShader.

luquinhas0021

22nd May 2016, 01:22

I think the problem, or an it piece, is in Avisynth 2.6.0, because I've tried run a simple Bicubic upscaling, and I didn't can make it.
As I told you, I installed it again, but I didn't have time enough to play with it.
What I guessed so strange was the instability of SuperResXBR. One time, the script I wrote worked; other time, it didn't do.
I was with MPC-BE 1.4.6 beta (From this I ran SuperResXBR script). I was think it was the problem, then I go back to MPC-BE 1.4.5 stable, but the problem wasn't it. I will install the MPC-BE 1.4.6 beta again.

luquinhas0021

22nd May 2016, 01:55

You wrote that SuperRes with passes = 2 generates a bigger file, when compressed, that SuperRes with passes = 3. This means passes = 2 makes a sharper (Or more detailed) image?
Can I say that this script is like a SuperResXBR visible sharpest (Or more detailed) settings:
SuperResXBR(Passes=2 or 3, Str=1, Soft=0, XbrStr=5, XbrSharp=1.5, fDownscaler="SSim", fStr=1, fSoft=false, fB=0, fC=1)?
Ah, your last image comparison show the clown and lighthouse images, but it's four by four times bigger than the original ones, no-upscaled, that you show in first image comparison. But the SuperResXBR has factor 2 of upscaling. So, can you put here the original images you used in last image comparison?

MysteryX

22nd May 2016, 06:31

You wrote that SuperRes with passes = 2 generates a bigger file, when compressed, that SuperRes with passes = 3. This means passes = 2 makes a sharper (Or more detailed) image?
I find it sharper with Passes=3 after encoding.

Passes=5 loses some details somehow.

I'm running it twice: Double+InterFrame+Double. I just tried the first double with 5 passes and the 2nd with 3 passes and the result was great!

Here's the file size with each pass settings
2 passes: 89.6MB
3 passes: 88.3MB
4 passes: 87.8MB (loss of details)
5 passes: 87.6MB (loss of details)
5 passes + 3 passes: 87.4MB (sharp!)

http://s20.postimg.org/r65pjljvd/Passes2.png (http://postimg.org/image/r65pjljvd/) http://s20.postimg.org/nqdla1mmx/Passes3.png (http://postimg.org/image/nqdla1mmx/) http://s20.postimg.org/rk71j73yx/Passes4.png (http://postimg.org/image/rk71j73yx/) http://s20.postimg.org/5oz1pzhzt/Passes5.png (http://postimg.org/image/5oz1pzhzt/) http://s20.postimg.org/pto0hpmft/Passes53.png (http://postimg.org/image/pto0hpmft/)

Can I say that this script is like a SuperResXBR visible sharpest (Or more detailed) settings:
SuperResXBR(Passes=2 or 3, Str=1, Soft=0, XbrStr=5, XbrSharp=1.5, fDownscaler="SSim", fStr=1, fSoft=false, fB=0, fC=1)?
This will look distorted with big halos.

In the screenshots above, I'm using
SuperResXBR(3, 1, 0.15, XbrStr=2.7, XbrSharp=1.3, fWidth=1012, fHeight=778, fDownscaler="Bicubic", fB=0, fC=.75)

Can you put here the original images you used in last image comparison?
The original images are in the first post of this thread.

luquinhas0021

23rd May 2016, 01:49

MysteryX, honestly, I didn't see any difference between 3 passes and 5 + 3 passes, unless artifacts shift. My screen is good and has optimal color/luminous calibration, and I saw with zoom 100%.
Mystery, I used this above script for Clown and Lighthouse images, but, fortunately, it didn't stay distorted or with big halos:
SuperResXBR(Passes=3, Str=1, Soft=0, XbrStr=4, XbrSharp=1.5, fDownscaler="SSim", fStr=1, fSoft=false, fB=0, fC=1)
Maybe I down XbrStr from 4 to 3.7, in order to avoid any possible distortions, without loss of details and sharpness. But this is it!
You had spoken SSIM retains more details that Bicubic; after, spoke Bicubic 0.75 and SSIM 0.8 are almost equal, but the edges in Bicubic 0.75 are sharper (I imagine 0.75 and 0.8 refers to "fC" parameter). This why I put SSIM with fC=1: retain more details and to be equal or sharper than Bicubic 0.75.

MysteryX

23rd May 2016, 04:34

SSim doesn't use fB and fC parameters

Are you really seeing better results with SSim than with Bicubic before applying SuperRes? I'm considering changing the default downscaling method to Bicubic.

or maybe, to avoid confusion, I could share the same fB and fC parameters for both SSim or Bicubic, and remove fStr and fSoft.

luquinhas0021

23rd May 2016, 05:05

I didn't test Bicubic, because, when I tried run the script, happened the error I told you.
I'm considering the technical information you spoke.
SSIM doesn't use fB and fC parameters in your plugin or, really, it, originally, don't have b and c parameters? Where is 0.8, from SSIM 0.8, from? There's way like I increase or decrease this number?
I don't advice you remove fStr neither fSoft anyhow, unless you put, by default, fSoft=0 and fStr=1.

MysteryX

23rd May 2016, 08:21

SSim uses fStr=.5 and fSoft=false by default.
Bicubic uses fB=0 and fC=.75 by default.

"maybe" I could change the syntax so that SSim uses fB instead of fStr and fC instead of fSoft (0 or 1)

This syntax simplification could become more significant if another downscaler gets added into the mix.

You cannot run it with Bicubic but it works with SSim? What error are you getting?

luquinhas0021

23rd May 2016, 20:17

MisteryX wrote:
"SSim uses fStr=.5 and fSoft=false by default."

Change fStr to 1: people doesn't matter with a few rings if sharpness and detail maintenance is bigger!

MisteryX wrote
"maybe" I could change the syntax so that SSim uses fB instead of fStr and fC instead of fSoft (0 or 1)"

MisteryX wrote
In Bicubic, "b" is relative to softness and "c" to sharpness. I think you will make trouble in user's head if you put the SSIM parameters in way you told.

MisteryX wrote
"You cannot run it with Bicubic but it works with SSim? What error are you getting?"

There's was a time when SSIM ran; there's was a time when it didn't run; with Bicubic, never run.

MysteryX

24th May 2016, 04:07

There's was a time when SSIM ran; there's was a time when it didn't run; with Bicubic, never run.
I can't help unless you give me more details.

Using fB and fC arguments for both kernels isn't different from the way other shared resizers work such as ResizeX, where you have 2 parameters to configure whatever kernel is selected.

In Bicubic, "b" is relative to softness and "c" to sharpness. I think you will make trouble in user's head if you put the SSIM parameters in way you told.

As long as these parameters are documented.

And that way, it's lot easier to implement other resizers.

luquinhas0021

25th May 2016, 03:17

I was using a broken Avisynth, I realized. So, I will test with unbroken Avisynth and, if some error occur, I will tell you.

MysteryX

25th May 2016, 14:42

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

What's new:
- Renamed SSimDownscaler to ResizeShader
- Removed fStr and fSoft arguments. With SSim, fB = Strength (0 to 1), fC = Soft (0 or 1)
- Renamed fDownscaler argument to fKernel and Downscaler to Kernel
- fKernel and Kernel default value is now Bicubic
- DLL now specifies its supported MT modes to AviSynth+ so SetFilterMTMode is no longer necessary

bilditup1

2nd June 2016, 04:46

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

Quick question MysteryX - you mentioned in the other thread that AviSynthShader may be used for color matrix operations. Should a resize down (or up) to the desired size happen before or after calling ColorMatrixShader()?
I ask because it a resize is supposed to be done before color matrix processing when using Dither.

MysteryX

2nd June 2016, 05:55

bilditup1

2nd June 2016, 08:13

AviSynthShader needs to convert from YUV to RGB to process anything anyway. If you want to downscale the image, you might as well use SSim and convert colorspace at the same time. This will convert from Rec601, resize using SSimDownscaler, and convert back using Rec709

ResizeShader(Width, Height, Kernel="SSim", MatrixIn=601")

And converting to 601 (downscaling), I guess it would be

ResizeShader(Width, Height, Kernel="Bicubic", MatrixIn="709", MatrixOut="601")

right?

Also: should this be done before or after deinterlacing? After, is what I'd guess.

One more thing -

ColorMatrixShader(input, MatrixIn, MatrixOut, FormatOut)

Converts the color matrix with 16 bit depth to avoid banding. Source can be YV12, YV24, RGB24 or RGB32.

How much of a concern is banding when using ResizeShader instead of ColorMatrixShader?

MysteryX

2nd June 2016, 11:21

De-interlace first.

The difference between ColorMatrixShader and ResizeShader is that the various Shader functions allow processing the color correction at the same time without any performance penalty. And since the bottleneck is in memory transfers, performing various operations at once is a great performance benefit.

Use ColorMatrixShader only when you don't need any of the other functions to perform that operation alone.

bilditup1

2nd June 2016, 12:19

MysteryX

3rd June 2016, 11:11

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

What's new:
- DitherTools (lsb_in/lsb_out) support was broken for the various functions and has been fixed
- ConvertToShader and ConvertFromShader now use Bicubic for chroma resizing when lsb=true
- ConvertToShader and ConvertFromShader now give an error if lsb=true and Precision=1

Note: There is still an issue where the x64 version takes over twice as much memory

When processing YV12 data, there is a slight loss of chroma data during the ConvertToYV24 conversion. If you want maximum quality, you should first convert to YV24 using DitherTools and set lsb_in and lsb_out to true. However, this may degrade performance by half because memory transfers are the bottleneck.

Dither_convert_8_to_16()
Dither_resize16(Width, Height/2, kernel="Bicubic", csp="YV24")
SuperResXBR(5, 1, 0.15, XbrStr=2.7, XbrSharp=1.3, MatrixIn="601", lsb_in=true, lsb_out=true)
Dither_resize16(Width, Height/2, kernel="Bicubic", csp="YV12")
DitherPost()

When upscaling SD material such as 288p, it is recommended to keep the maximum amount of data for the first image doubling as the size of each frame is limited so the performance cost is low. You can also use KNLMeans with lsb_inout before calling SuperResXBR. Then for the second double, you can do it directly on YV12 or YV24 data as the performance cost would be higher and the quality retention would be smaller.

So the rule of thumb is: with the smaller image, try to preserve as much of the details before extrapolating it. With the larger image, you can trade quality for performance as the loss of details is only extrapolated data anyway.

MysteryX

6th June 2016, 11:05

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

What's new:
- Minor performance improvements
- Removed ColorMatrixShader
- ConvertFromShader no longer uses 'invks' when converting to YV12 using DitherTools

About ColorMatrixShader, it was designed to shift the color matrix in 16-bit to avoid banding. However, because it was calling ConvertToYV24 and ConvertTo12, rounding occured there which nullify any advantage over the standard ColorMatrix function or over the DitherTools conversion method. As a work-around, I could make ColorMatrixShader convert between YV12 and YV24 using DitherTools, but if it depends on DitherTools, it has no advantage over simply doing it the DitherTools way. Thus, I removed this function.

The best way to do shift the color matrix is to do it while calling another function such as SuperResXBR; or to use the standard methods (ColorMatrix or DitherTools).

If you want to avoid rounding errors (loss of data) when processing YV12, first convert it to 16-bit LSB format using DitherTools (Dither_convert_8_to_16) and call the shader method with lsb_in=true, lsb_out=true. It will then automatically perform the conversion between YV12 and YV24 in high-bit-depth.

ConvertToShader/ConvertFromShader will then internally convert using these functions

Dither_resize16nr(Width, Height/2, kernel="Spline36", csp="YV24")
Dither_resize16nr(Width, Height/2, kernel="Spline36", csp="YV12")

MysteryX

8th June 2016, 15:47

OMG. I found the performance bottleneck.

Replaced the flag D3DPRESENT_INTERVAL_DEFAULT with D3DPRESENT_INTERVAL_IMMEDIATE (https://msdn.microsoft.com/en-us/library/windows/desktop/bb172585(v=vs.85).aspx)

The driver will wait for the vertical retrace period (the runtime will "beam follow" to prevent tearing). Present operations will not be affected more frequently than the screen refresh; the runtime will complete at most one Present operation per adapter refresh period. This is equivalent to using D3DSWAPEFFECT_COPYVSYNC in DirectX 8.1. This option is always available for both windowed and full-screen swap chains. See remarks.

Performance went WAY up and I'm doing all kind of other performance improvements. A new version will be out soon!

MysteryX

11th June 2016, 12:16

Here are some preliminary benchmarks on the latest developments (available in the GitHub repository)

ColorBarsHD(352, 288).KillAudio()
ConvertToYV24()
SuperResXBR()
SuperResXBR()
Prefetch(8)

Current version (1.4.6)

FPS (min | max | average): 2.286 | 1000000 | 22.36
Memory usage (phys | virt): 311 | 656 MiB
Thread count: 131
CPU usage (average): 26%

Version 1.5

FPS (min | max | average): 3.200 | 1000000 | 26.71
Memory usage (phys | virt): 333 | 344 MiB
Thread count: 113
CPU usage (average): 5%

4 threads instead of 8

FPS (min | max | average): 5.818 | 1000000 | 27.04
Memory usage (phys | virt): 193 | 200 MiB
Thread count: 69
CPU usage (average): 5%

Let's try with Stack16 input and output. As of right now the output is corrupt because of a bug in the new ConvertShader functions but hopefully that will be fixed soon; it shouldn't affect the GPU performance.

ColorBarsHD(352, 288).KillAudio()
ConvertToYV24()
Dither_convert_8_to_16
SuperResXBR(lsb_in=true, lsb_out=true)
SuperResXBR(lsb_in=true, lsb_out=true)
DitherPost()
Prefetch(8)

Version 1.4.6

FPS (min | max | average): 0.207 | 1000000 | 3.208
Memory usage (phys | virt): 478 | 916 MiB
Thread count: 140
CPU usage (average): 3%

Version 1.5

FPS (min | max | average): 0.800 | 1000000 | 13.15
Memory usage (phys | virt): 481 | 496 MiB
Thread count: 122
CPU usage (average): 13%

4 threads instead of 8

FPS (min | max | average): 1.684 | 1000000 | 13.36
Memory usage (phys | virt): 312 | 318 MiB
Thread count: 78
CPU usage (average): 12%

So far, we have a 21% performance increase and 70% memory reduction in 8-bit, and a 316% performance increase and 65% memory reduction in 16-bit.

I'll see if I can turn this into a MT_NICE filter. It would require creating a memory pool for all the textures similar to a pool cache that was implemented in AviSynth+. If I can get that to work, memory usage will go considerably further down.

MysteryX

13th June 2016, 13:53

Got it working with MT_NICE_FILTER and a dynamic allocation pool. Here's the result with 4 threads.

FPS (min | max | average): 5.333 | 1000000 | 25.57
Memory usage (phys | virt): 136 | 153 MiB
Thread count: 31
CPU usage (average): 4%

Performance is slightly lower than 27fps but memory usage is considerably lower.

if I run this new code design with MT_MULTI_INSTANCE, I get this

FPS (min | max | average): 6.400 | 1000000 | 27.07
Memory usage (phys | virt): 193 | 218 MiB
Thread count: 71
CPU usage (average): 5%

So far MT_MULTI_INSTANCE is still working better unless I can do some more optimization, but either way, memory usage is a lot lower than before.

MysteryX

14th June 2016, 07:23

MysteryX

14th June 2016, 10:21

Woah... once integrated into a complex script (and the threads are busy working on other filters), the picture is different!!

MT_MULTI_INSTANCE, 4 threads
13.43fps, 478MB, 15% CPU

MT_MULTI_INSTANCE, 8 threads
14.43fps, 677MB, 18% CPU

MT_NICE_FILTER, 4 threads
14.81fps, 435MB, 16% CPU

MT_NICE_FILTER, 8 threads
17.13fps, 555MB, 18%

We got a winner!!!

MysteryX

15th June 2016, 17:01

MysteryX

18th June 2016, 14:47

Convert functions are now working.

Now this is embarassing. There are still image differences with the previous version, but as I investigate, it appears LSB wasn't working at all in the last version!

- Fixed ConvertToShader(2) was generating noise in the 2nd byte
- Fixed ConvertToShader(2, lsb=true) was causing brightening
- Fixed ConvertFromShader(2, lsb=true) was corrupting the lsb data

Chikuzen's version of the converters looks OK... Kind of hard to compare when the previous version was wrong.

Well... view it this way. Version 1.4.6 is auto-applying dithering :)

MysteryX

21st June 2016, 18:05

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

Major improvements:
- Major performance improvements (~double)
- Replaced D3DPRESENT_INTERVAL_DEFAULT with D3DPRESENT_INTERVAL_IMMEDIATE which removed the performance cap
- Added Ordered Dithering (16x16) before returning 8-bit-depth data
- Shader: Clip1-Clip9 can now have values between 0 and 100
- Shader: Added Precision parameter to specify different output precisions per shader
- Shader: Now detecting whether to compile file or not based on extension (.hlsl or .cso)
- Shader: ShaderModel default value is now 'ps_3_0'
- ExecuteShader: Full support for MT_NICE_FILTER under AviSynth+. When MT is enabled, it will alternate threads between 2 engines for optimal performance. AviSynth 2.6 will use it with MT=2.
- ExecuteShader: Added PlanarOut parameter to return output as YV24 planar data
- ExecuteShader: Can now transfer YV24 source clips as planar data
- ExecuteShader: Precision can now be 0 to process with Y8
- ConvertToShader/ConvertFromShader: Added assembly optimizations (thanks to Chikuzen!!)
- ConvertToShader/ConvertFromShader: Added Planar parameter to convert to YV24 (thanks to Chikuzen!!)
- ConvertToShader/ConvertFromShader: Added opt parameter to specify the optimization path to execute
- ConvertToShader/ConvertFromShader: Now support Precision=0 for Y8
- ConvertToShader/ConvertFromShader: Precision default value is now 1
- Added PlanarIn and PlanarOut parameters to all shader scripts, mostly useful for performance tweaks
- Fixed ConvertToShader(2) was generating noise in the 2nd byte
- Fixed ConvertToShader(2, lsb=true) was causing brightening
- Fixed ConvertFromShader(2, lsb=true) was corrupting the lsb data
- ConvertFromShader: Format default value is now YV24 instead of YV12
- SuperXBR and ResizeShader: Added ConvertYuv parameter for consistency

Note: This version comes with 4 DLLs: Regular (SSE2), AVX, x86 and x64. The AVX brings increased performance when using ConvertToShader with Precision=3 which is not used by default in Shader.avsi. The AVX version will fail if your CPU doesn't support it. The SSE2 version is recommended.

The Dither feature was added at the last minute and hasn't been fully tested. Give it a try and let me know if something needs to be tweaked.

luigizaninoni

22nd June 2016, 12:35

Issue with SuperRes in 1.5.0: The following script immediately crashes with AVS+ 64-bit (inside staxrip):

LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Stax64\Apps\Plugins\avs\aWarpSharp2\aWarpSharp.dll")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Stax64\Apps\Plugins\avs\Decomb\Decomb.dll")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Stax64\Apps\Plugins\avs\L-SMASH-Works\LSMASHSource.dll")
Import("C:\Users\luigi.TZMS\Desktop\Video\Stax64\Apps\Plugins\avs\QTGMC\QTGMC.avsi")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Stax64\Apps\Plugins\avs\masktools2\masktools2.dll")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Stax64\Apps\Plugins\avs\mvtools2\mvtools2.dll")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Stax64\Apps\Plugins\avs\nnedi3\nnedi3.dll")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Stax64\Apps\Plugins\avs\RgTools\RgTools.dll")
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LWLibavVideoSource("Y:\work\prova_temp\prova.m2v", format = "YUV420P8")
vid0=last
vid=(QTGMC(vid0,Preset="Slower",EzDenoise=0.9,denoiser="dfttest",NoisePreset="Slower").SelectEven())
vid2=QTGMC(vid0,Preset = "Slow",InputType=1,EzDenoise=0.6,denoiser="dfttest",NoisePreset="Slower")
ConditionalFilter(vid0,vid,vid2,"IsCombed()" , "=" , "True")
Crop(0, 2, -0, -2)
MergeChroma(aWarpSharp(depth=10), aWarpSharp(depth=20))
Overlay(last, ColorYUV(off_y=-8, off_u=8, off_v=-2), 0, 0, GreyScale(last).ColorYUV(cont_y=30))
SuperRes(2,0.65,0,"""nnedi3_rpow2(2, cshift="Spline16Resize")""",MatrixIn="601")
Prefetch(3)

Same script works fine in 1.4.6

MysteryX

22nd June 2016, 13:32

It may have to do with ExecuteShader now running as MT_NICE_FILTER.

nnedi3_rpow2 fails under AviSynth+ MT, while instead calling it through edi_rpow2 does work. The reason is a bit complicated.

Reel.Deel

22nd June 2016, 13:45

nnedi3_rpow2 fails under AviSynth+ MT

This issue was fixed in the latest nnedi3 version: http://forum.doom9.org/showthread.php?p=1768995#post1768995

Mystery Keeper

22nd June 2016, 13:59

MysteryX

22nd June 2016, 14:38

I don't get you people comparing x64 builds against x86. x64 is not supposed to be faster or slower. It is needed to access more memory. Because with x86 if you hit 4GB (that's the maximum you can get only on x64 OS with properly built executable) - you crash. With complex scripts and FullHD content you can easily exceed that memory load.
x64 is generally a bit faster when implemented properly.

In the case of AviSynthShader, however, there are no benefits there as the CPU isn't the bottleneck.

The x64 version in fact takes a LOT more memory. DirectX just manages the memory differently in x64 and I haven't found any way to fix that...

Mystery Keeper

22nd June 2016, 19:23

MysteryX, simple. x64 doesn't take "a lot" more memory. The memory usage increase comes from the doubled pointer size. The more pointers used - the more memory they take.

MysteryX

23rd June 2016, 01:15

There aren't many pointers in my program; yet AVSMeter showed and memory usage is over TWICE HIGHER! So instead of taking 900MB, the script might take 2.3GB. What takes memory are the texture buffers on the CPU and GPU which are managed by DirectX 9 and the graphic driver.

Although I haven't found the cause nor the solution, v1.5 takes a lot less memory in both cases.

MysteryX

24th June 2016, 08:25

I'm seeing two bugs already. Lsb output is broken (corruption of dark colors) and ResizeShader(kernel="SSim") corrupts a line at the bottom when not using lsb_out. Will have to investigate.

Edit: the lsb issue occurs when using only one of lsb_in/lsb_out. Using it twice cancels the distortion. There is also a bug in SSimDownscaler.

MysteryX

24th June 2016, 09:46

I found an easy way to make dither and banding visible: upscaling ColorBars

First, the Ordered Dither shader is doing a pretty good job. In fact, it's doing better than Dither Tools' ordered dither (mode=0). Not sure how mode=0 got implemented; perhaps with a matrix that is too small. I'm using a 16x16 matrix.

Second thing to notice is that there is color distortion between DitherShader and Dither0. This was really confusing because I only see a very slight color difference in VirtualDub, and once I copy both into PhotoShop, the color difference becomes greater!??

Third thing to notice is that Dither6 completely distorts the dark colors. Would love to hear experts' opinion on this one!

ColorBarsHD(300, 200)
ResizeShader(600, 500, kernel="bicubic")

https://s32.postimg.org/rjqa84je9/Dither_Shader.png (https://postimg.org/image/rjqa84je9/)

ColorBarsHD(300, 200)
ResizeShader(600, 500, kernel="bicubic", lsb_out=true)
DitherPost(mode=0)

https://s32.postimg.org/sjgl3tyk1/Dither_Mode0.png (https://postimg.org/image/sjgl3tyk1/)

ColorBarsHD(300, 200)
ResizeShader(600, 500, kernel="bicubic", lsb_out=true)
DitherPost(mode=6)

https://s32.postimg.org/wh3ut8ldd/Dither_Mode6.png (https://postimg.org/image/wh3ut8ldd/)

But then, to make it even more confusing, this one looks fine.

ColorBarsHD(300, 200)
Dither_convert_8_to_16
dither_resize16(600, 500)
DitherPost(mode=6)

https://s31.postimg.org/uxbh88nlz/Dither_Resize6.png (https://postimg.org/image/uxbh88nlz/)

Maybe ShaderResize is returning out-of-range values that DitherPost doesn't know what to do with?

MysteryX

29th June 2016, 09:11

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

What's new:
- Shader: Added Defines parameter to configure HLSL shaders before compilation
- Restructured the files to compile several HLSL files on-demand with compilation parameters. Reduced the amount of shader files from 41 to 26.
- Fixed: Texture overflow method wasn't properly reset to CLAMP after dithering with WRAP
- ExecuteShader: Changed default values Clip1Precision=1, OutputPrecision=1, Precision=3
- ResizeShader: Changed default values to Kernel="Bicubic", B=1./3, C=1./3. Defaults for downscalers remain B=0, C=.75
- MatrixIn and MatrixOut now support PC colors for matrix conversion. Valid values are now 601, 709, Pc601 and Pc709.
- ResizeShader: Added Kernel="ColorMatrix" to perform color matrix conversion without resizing

jrodefeld

29th June 2016, 14:56

Okay, I've been trying to get this filter to work for me with no success. I'm not even entirely sure I have it installed correctly. If anyone could give a basic, clear explanation of how to install and how to write a basic script for this plugin, I'd really appreciate it.

I've been trying to add this command to other AVS scripts I have that I know already work. Then I want to load the script into Virtualdub. But Virtualdub is crashing every time. It is the same basic crash and error message that I get every time I make an error in a script. I'm honestly not entirely clear what all the commands do for this filter. I've been basically copying and pasting different script examples I've found in this thread. Some of the documentation is a little over my head, so I think I need a dumbed down version.

Any help would really be appreciated.

luigizaninoni

29th June 2016, 15:02

jrodefeld

29th June 2016, 15:02

Okay, here's the script I'm using right now:

DirectShowSource("D:\Downloads\-- RAW DM2 ENDING --.avi")

LoadPlugin("C:\Program Files (x86)\AviSynth\plugins\Shader.dll")

QTGMC(Preset="Slow")
SelectEven()

Decimate()

Crop(0,90,0,-90)

SuperRes(1, .85, 0, false, """nnedi3_rpow2(rfactor=4, cshift="Spline16Resize", Threads=1)""")

Any ideas?

MysteryX

29th June 2016, 15:04

First, does it work without SuperRes? Can you get it to work by removing some components?

What version of AviSynth are you using?

luigizaninoni

29th June 2016, 15:07

Did you put all the files that came with shader.dll in the same folder as shader.dll ? that is, in your case, in C:\Program Files (x86)\AviSynth\plugins\Shader.dll ?

Also, try removing "false" from your syntax

luigizaninoni

29th June 2016, 15:11

My syntax is usually

LWLibavVideoSource("Y:\work\prova_temp\prova.m2v", format = "YUV420P8")

SuperRes(2,0.65,0,"""nnedi3_rpow2(2,shift="Spline16Resize")""",MatrixIn="601")

And it works fine

jrodefeld

29th June 2016, 15:21

Okay, I discovered something else. Even when I remove the SuperRes line from my script but keep the "LoadPlugin" line, VirtualDub still crashes. So there must be some problem with the DLL files, my version of AviSynth or something else. Just for the record, when I remove the SuperRes line AND the LoadPlugin line, the script loads just fine so I know the other commands are working. I've used this script many times minus the SuperRes stuff.

And yes, I've copied over all the other files that came with the shader.dll file into the same directory.

I'm using either AviSynth 2.5.8 or 2.6. I can't recall at the moment, but it's never given me any trouble before.

Any other ideas?

raffriff42

29th June 2016, 15:24

This is what worked for me (using the actual path to the shader folder of course)SetWorkingDir (http://avisynth.nl/index.php?title=Internal_functions/SetWorkingDir)("c:\...\shaders")
...

An alternative, not tested: adding the shader folder to your PATH (https://www.google.com/search?q=windows+set+path+variable)

luigizaninoni

29th June 2016, 15:24

Maybe your are loading the plugin from your autoload plugin folder, so AVS crashes trying to load the same plugin twice ?

Groucho2004

29th June 2016, 15:37

Then I want to load the script into Virtualdub. But Virtualdub is crashing every time. It is the same basic crash and error message that I get every time I make an error in a script.
How about telling us what that error message is? Or, even better, analyse your Avisynth install with AVSMeter (http://forum.doom9.org/showthread.php?t=165528):
"avsmeter -avsinfo -log". This will create a log file which you should post in case there are errors ("avsinfo.log" is created in the current (working) directory).

jrodefeld

29th June 2016, 15:43

How about telling us what that error message is? Or, even better, analyse your Avisynth install with AVSMeter (http://forum.doom9.org/showthread.php?t=165528):
"avsmeter -avsinfo -log". This will create a log file which you should post in case there are errors ("avsinfo.log" is created in the current (working) directory).

The error message is: "Oops - VirtualDub has crashed.", "An out-of-bounds memory access (access violation) occurred..."

This is the same message I get any time there is any problem with a script, so I doesn't seem to pinpoint the problem.

I'll try the AVSMeter program and see if that gives any idea what could be the problem.

jrodefeld

29th June 2016, 16:08

Okay, I've made some progress. I decided to re-install AviSynth and try it again. I actually installed AviSynth+. Anyway, I am not getting the same crashes in Virtualdub that I was getting before. However, I am getting some other error messages.

I'm using the exact script luigizaninoni recommended, but I'm getting this error: "There is no function named ConvertToShader"

Any idea what this means and what I can do about it?

Groucho2004

29th June 2016, 16:16

Any idea what this means and what I can do about it?There are several possibilities. This could be resolved in minutes if you would do what I suggested.

jrodefeld

29th June 2016, 16:38

There are several possibilities. This could be resolved in minutes if you would do what I suggested.

Okay, I've been running AVSMeter and it crashes before it is done. The error is:

"AVSMeter - Avisynth Script Testing has stopped working"

Before it did crash, it did say that d3dx9_43.dll was missing. I installed it and I don't get the same error anymore, I'm getting a different error.

Now it says "Avisynth open failed: Shader: Failed to open pixel shader YuvToLinear.hlsl"

Not sure what that means. Maybe I can get AVSMeter to run all the way through without crashing. Or maybe you or someone else knows what the above error means.

Groucho2004

29th June 2016, 16:43

Now it says "Avisynth open failed: Shader: Failed to open pixel shader YuvToLinear.hlsl".
I'm sure the author will help you with that, I'm not familiar with this shader thingy.

Maybe I can get AVSMeter to run all the way through without crashing. Or maybe you or someone else knows what the above error means.
Once you have all required files in the right places it will surely run.

MysteryX

29th June 2016, 17:42

d3dx9_43.dll was missing? Was OS are you using for not having DirectX9?

It looks for HLSL files in the same folder as the DLL. Make sure they are at the right place. To make sure the right DLL is being loaded, you can place those in a separate folder and use LoadPlugin on the DLL.

jrodefeld

29th June 2016, 17:44

I got it to work! I don't know why, but when I used an older version of the AviSynthShader package, it worked fine. The new version didn't work for me for some reason.

Anyway, I haven't had a chance to fully test it out yet, but this probably will be my default method of upscaling from now on.

MysteryX

6th July 2016, 15:21

Version 1.5.2 is ready (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.5.2)

What's new:
- All standard shader files are now included within the DLL.
- If a shader file of the same name is also found in the DLL's folder, that one will be taken first.
- Recompiled with AviSynth+ r2022's headers. It won't won't work with older AviSynth+ (AviSynth 2.6 is OK)

citroenfan

10th July 2016, 10:55

Thank you very much MysteryX for your time and effort to write this script and to make it better and better.
I'm using it for upscaling material in SD resplution (720×576 pixels, living in PAL country) to HD.
Together with QTGMC and VideoFred/Johnmeyer scripts (for some other restoration work)
it gives really good results.

Working with various avisynth scripts almost ten years now, so I think I'm relative skilled with this.

I'm using your script from version 1.3.1 (when I found it).
Last version which I'm using without problems is 1.4.6.
But with versions from 1.5.0 I'm having a problem, I could not make them to work, tried everything I know.

My computer is running Windows7 64 bit, but as most avisynth plugins I'm using are 32bit (there is no 64bit versions for some of them or if exist they are buggy or not working with particular avisynth or...)
all my work is in 32bit chain.

Shader.dll is in Avisynth/plugin folder, as superres.avsi (for working 1.31) or shader.avsi (when working with 1.46).

When working with shader.dll from version 1.3.1., script version 1.3.1 (SuperRes.avsi) and up-scaling material in 960×720pixels to 1440×1080pixels with MT version of Avisynth 2.60 I'm geting speed about 6,90fps.

When working with shader.dll from version 1.5.2., script version 1.3.1 (SuperRes.avsi) and up-scaling material in 960×720pixels to 1440×1080pixels with MT version of Avisynth 2.60 I'm getting speed about 30,50fps.

When tried to get the script 1.52 to work, I only get the message "Failed to open pixel shader YuvToLinear.hlsl"

In attachments I send you avsmeter logs so maybe you can see what went wrong and help me to correct the problem.

Thank you once more and best regards.

MysteryX

10th July 2016, 11:21

Strange. The latest version includes all the HLSL and CSO files within the DLL.

Try copying all these files into the same folder as the DLL to see if that helps.
https://github.com/mysteryx93/AviSynthShader/tree/master/Src/Shaders

I can't yet read the log files until they are approved.

Try running the files manually with something like this

input = ConvertToShader()
Shader("YuvToGamma.hlsl")
Shader("GammaToYuv.hlsl")
last.ExecuteShader(input)
ConvertFromShader()

Let me know what you find out. Is there the possibility of regional settings with the "." causing interference somewhere? I don't know.

luigizaninoni

10th July 2016, 13:58

I have exactly the same issue as citroenfan.

Putting the files that you linked in the same folder as the dll does not help

Running the files manually with
input = ConvertToShader()
Shader("YuvToGamma.hlsl")
Shader("GammaToYuv.hlsl")
last.ExecuteShader(input)
ConvertFromShader()

works perfectly

If I use shader.dll from 1.5.2 but shader.avsi from 1.4.6 it works.

So I suppose that the problem lies in shader.avsi (in the changes after 1.4.6)

luigizaninoni

10th July 2016, 13:59

Also, how would I check if regional settings are a problem ? My regional settings are Italian, so . for 1.000 (one thousand) and , for 1,32 (one point thirty-two)

MysteryX

10th July 2016, 14:16

When using 601 color matrix, it passes floating-point values to configure the conversion shaders before compilation. Perhaps that's where it's failing. If you stick to 709 color matrix, does it work? You can also play with the AVSI file and trim it down until you get to the issue.

luigizaninoni

10th July 2016, 14:42

MysteryX

10th July 2016, 15:03

Are you able to do a simple ResizeShader with Bicubic? Which functions fail and which ones work? By playing around with the AVSI file, you can narrow down the part that isn't working.

If even the Bicubic ResizeShader doesn't work, you can copy its script code into your main script and simplify it until you get it to execute.

luigizaninoni

10th July 2016, 15:33

DGSourceIM("F:\work\prova_temp\prova.dgim")
SuperXBR()

works

SuperRes doesn't work

luigizaninoni

10th July 2016, 15:34

DGSourceIM("F:\work\prova_temp\prova.dgim")
SuperRes(2,0.65,0.0,"""nnedi3_rpow2(2, cshift="Spline36Resize",fwidth=1920,fheight=1080)""")

not working

luigizaninoni

10th July 2016, 15:45

Trying to simplify,
DGSourceIM("F:\work\prova_temp\prova.dgim")
SuperRes(2,0.65,0.0,"""nnedi3_rpow2(rfactor=2)""")

does not work

luigizaninoni

10th July 2016, 15:47

I am unable to reproduce it now, but avsmeter gave an error message concerning line 121 of shader.avsi - which is eval(upscale)

MysteryX

10th July 2016, 15:58

Are you using MT with a version of NNEDI3 that has an issue with MT mode? A new version of NNEDI3 was released to fix that.

luigizaninoni

10th July 2016, 15:59

it looks unbelievable, but avsmeter every four or five attempts is able to run:
DGSourceIM("F:\work\prova_temp\prova.dgim")
SuperRes(2,0.45,0.01,"""nnedi3_rpow2(2, cshift="Spline16Resize")""")

without errors. The other attempts end with system access violation, or no message at all

Every other application (avspmod, staxrip, mpchc, virtualdub) are unable to open the script, and exit without error message

luigizaninoni

10th July 2016, 16:03

my nnedi3 version is 9.4.22, it is the latest as far as I know. released on 30 may 2016

luigizaninoni

10th July 2016, 16:07

and I am running the script single-threaded, anyway. With AVS+ 64-bit

MysteryX

10th July 2016, 16:21

And this happens *only* with SuperRes? All other functions are working fine?

Do you have the latest version of AVS+?

luigizaninoni

10th July 2016, 16:39

SuperXBR, SuperResXBR, ResizeShader all work

Only superres doesn't

That's all there is to try, isn't that ?

My avs+ is the latest (r2022)

MysteryX

10th July 2016, 16:49

Does NNEDI3 on its own work? oh... maybe it hasn't been recompiled with the latest AVS headers.

luigizaninoni

10th July 2016, 17:00

Yes it works. I use it all' the time. Actually I Can use shader.dll from 1.5.2 and shader.avsi from 1.4.6 and everything works fine. (i don't know if it is totally correct though). I simply have to put all' the cso and hlsl in the same folder. Shaders.dll 1.5.2 seems much faster than 1.4.6

MysteryX

10th July 2016, 17:36

I'm getting an Access Violation on
nnedi3_rpow2(2,nns=4,cshift="spline16")

I don't even know if an updated version has been published; haven't seen it.

Try with AviSynth 2.6, that might work as it won't be affected by the AVS+ header change issue.

luigizaninoni

10th July 2016, 17:49

Thanks, I'll try again if a new version of nnedi3 comes out

loneboyz

11th July 2016, 02:29

When tried to get the script 1.52 to work, I only get the message "Failed to open pixel shader YuvToLinear.hlsl"

I also get a similar error above, the current I'm running Avisynth 2.6 32bit on system Window 7 x64 Ultimate. I can't running begin from ver 1.51 onward

MysteryX

11th July 2016, 03:12

I can't get NNEDI3 to work, either with AviSynth 2.6 or AVS+; that will need to be fixed first.

If I remove sub-pixel shift from NNEDI3, however, it works.
This runs fine for me with AviSynth 2.6

SuperRes(Upscale="""nnedi3_rpow2(2)""", MatrixIn="Pc601", MatrixOut="709")

I cannot reproduce the problem with YuvToLinear.hlsl

MysteryX

11th July 2016, 05:59

OK I'm seeing something wrong with the latest version. Although it is supposedly MT_NICE_FILTER, I just saw I was mistakenly still registering it as MT_MULTI_INSTANCE. Which means that when running 8 threads, it might actually be creating 16 engines!? With MT_NICE_FILTER it is freezing and giving access violation. Need to investigate more.

It's surprising that memory usage and performance were still good! We might have another performance boost surprise then :)

MysteryX

11th July 2016, 09:24

- Fixed: Filter was accidentally being registered as MT_MULTI_INSTANCE on AviSynth+
- Fixed: Filter did not work with MT_NICE_FILTER
- Fixed: Filter wasn't creating the second core (back to square one with MT_MULTI_INSTANCE)
- ExecuteShader: Added Engines parameter to specify the number of cores to run when using MT_NICE_FILTER

Engines is 2 by default, and in heavy scripts where you are calling at least 2 Shader functions, you can get a small performance boost by setting Engines to 1.

However, I'm not able to reproduce the issue you guys are having. I don't think you're affected by the bug I just fixed; yours was behaving exactly as if it was a simple MT_MULTI_INSTANCE filter. I'd want this solved before releasing a new version.

To Groucho who said that reducing the scope of the lock wouldn't make a difference because memory transfers don't take any time, results show otherwise.

ColorBarsHD(width = 352, height = 288, pixel_type = "YV24").killaudio().assumefps(25, 1)
SuperResXBR(Engines=2)
SuperResXBR(Engines=2)
Prefetch(8)

With thread lock excluding transfers in/out:

FPS (min | max | average): 3.021 | 1000000 | 24.53
Memory usage (phys | virt): 245 | 255 MiB
Thread count: 43
CPU usage (average): 5%

With a unique_lock at the beginning of GetFrame (which behaves similarly to MT_SERIALIZED)

FPS (min | max | average): 1.247 | 1000000 | 20.46
Memory usage (phys | virt): 223 | 233 MiB
Thread count: 45
CPU usage (average): 2%

It's easy to verbally assault people. Just make sure what you say makes sense. Otherwise it's called trolling, and it goes against the forum rules. You should already know that.

TurboPascal7

11th July 2016, 09:40

With a unique_lock at the beginning of GetFrame (which behaves similarly to MT_SERIALIZED)
It doesn't behave similarly to MT_SERIALIZED. It blocks every bloody thread in the core.

Imagine you've got a filter chain with 100500 filters and only one of those filters is MT_SERIALIZED. When the core has to execute that MT_SERIALIZED filter, it can use exactly one thread for it. Other threads are free to do other stuff, like executing some filter calls required for the next frame.

Now imagine that filter is registered as MT_NICE_FILTER and has an unique_lock inside its GetFrame. The core happily tries to run that filter in multiple threads at the same time, blocking every single thread but one. Now those threads can do exactly nothing but simply idle there waiting for their turn. So in essence you just ruined every possible optimization the core might have for filter chains with MT_SERIALIZED filters. Good job.

MysteryX

11th July 2016, 09:53

Calls to MT_SERIALIZED come from various threads. As for the implementation/optimizations details, I don't know much more, except that MT_SERIALIZED really is a crutch on performance.

TurboPascal7

11th July 2016, 09:55

Calls to MT_SERIALIZED come from various threads.
Not at the same time.

MysteryX

11th July 2016, 09:58

No, not at the same time. In complex scripts where the CPU is the bottleneck, AVS probably has an opportunity for small optimization by routing threads elsewhere. In this demo script, however, that makes no difference as there's nothing else to run.

Bottom line is: don't use MT_SERIALIZED unless for source filter or for compatibility, and reduce the scope of locks.

TurboPascal7

11th July 2016, 10:00

In complex scripts where the CPU is the bottleneck, AVS probably has an opportunity for small optimization by routing threads elsewhere. In this demo script, however, that makes no difference as there's nothing else to run.
My point exactly. You're actively making your filter worse for anything but trivial benchmarks. Moreover, you give other people wrong advice to mark filters as nice and then using locks internally to prevent crashes. Please stop doing that.

Groucho2004

11th July 2016, 10:12

To Groucho who said that reducing the scope of the lock wouldn't make a difference because memory transfers don't take any time, results show otherwise.
What? I merely pointed out your tendency to blame the poor performance results of your outlandish experiments on memory performance - in a different thread and context, by the way. I think you're losing your grip on reality.

MysteryX

11th July 2016, 13:34

TurboPascal, you have a good point that MT_SERIALIZED does give AVS an opportunity for optimization in complex scripts. Let's see how it shows up in real-life.

Plain script

ColorBarsHD(width=800, height=600, pixel_type="YV24").killaudio().assumefps(25, 1)
SuperResXBR(Engines=1)
Prefetch(8)

MT_SERIALIZED
FPS (min | max | average): 1.571 | 1000000 | 22.75
Memory usage (phys | virt): 213 | 215 MiB
Thread count: 28
CPU usage (average): 2%

MT_NICE_FILTER
FPS (min | max | average): 2.498 | 1000000 | 23.51
Memory usage (phys | virt): 237 | 238 MiB
Thread count: 28
CPU usage (average): 3%

2 Engines
FPS (min | max | average): 3.160 | 1000000 | 26.81
Memory usage (phys | virt): 276 | 279 MiB
Thread count: 33
CPU usage (average): 4%

Let's try on my full script to upscale 288p to 768p. Script includes KNLMeans, 2x SuperResXbr, InterFrame and various 16-bit tools.

MT_SERIALIZED
FPS (min | max | average): 1.080 | 19.69 | 7.930
Memory usage (phys | virt): 643 | 698 MiB
Thread count: 49
CPU usage (average): 9%

MT_NICE_FILTER
FPS (min | max | average): 3.436 | 1000000 | 13.27
Memory usage (phys | virt): 680 | 736 MiB
Thread count: 52
CPU usage (average): 27%

No point in setting 2 engines because there are already 2 shader functions

or let's try heavier GPU processing with complex CPU work

ColorBarsHD(width=1940, height=1080).killaudio().assumefps(25, 1).ConvertToYV12()
SMDegrain(thsad=200, prefilter=2, lsb=true)
SuperResXBR(5, 1, .15, fWidth=2600, fHeight=1500, fKernel="SSim", Engines=1)
Prefetch(8)

MT_SERIALIZED
FPS (cur | min | max | avg): 1.809 | 0.218 | 1.903 | 1.729
Memory usage (phys | virt): 1036 | 1044 MiB
Thread count: 34
CPU usage (current | average): 16% | 17%

MT_NICE_FILTER
FPS (cur | min | max | avg): 3.531 | 0.311 | 1000000 | 3.059
Memory usage (phys | virt): 1109 | 1125 MiB
Thread count: 34
CPU usage (current | average): 34% | 32%

2 Engines
FPS (min | max | average): 0.260 | 1000000 | 2.713
Memory usage (phys | virt): 1184 | 1203 MiB
Thread count: 39
CPU usage (average): 33%

Flawless Victory

Edit: I just fixed something that fixes an occasional image corruption and further improves performance. My full script went from 13.27fps to 16fps.

I think this closes the topic of MT_SERIALIZED vs MT_NICE_FILTER with lock (MT_SERIALIZED going back to its grave).

The last test is curious; performance is lower with 2 engines, but then there's an unknown bottleneck within SMDegrain.

What? I merely pointed out your tendency to blame the poor performance results of your outlandish experiments on memory performance - in a different thread and context, by the way. I think you're losing your grip on reality.
I don't try to speculate on the cause. I simply show benchmarks.

The situation with KNLMeans really isn't very different than here. In fact the issues are exactly the same.

MysteryX

11th July 2016, 14:09

For the crash, currently NNEDI3 and AviSynthShader are not compiled with the same headers, and thus won't work together in AviSynth+ until NNEDI3 is recompiled.

So for now use AviSynth 2.6 for testing.

Oh, I think I know what's happening. If you're not using the latest build of NNEDI3, it works fine with AVS+ as it doesn't try to self-register its MT mode; but crashes if trying to run as MT_NICE_FILTER. Perhaps it starts crashing from the versions of AviSynthShader that self-register as MT_NICE_FILTER which also cause NNEDI3 to run as MT_NICE_FILTER.

Using edi_rpow2.avsi works, otherwise you'll have to use AviSynth 2.6 for now.

MysteryX

12th July 2016, 13:24

Version 1.5.3 is ready! (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.5.3)
- Fixed: Filter was accidentally being registered as MT_MULTI_INSTANCE on AviSynth+
- Fixed: Filter did not work with MT_NICE_FILTER
- Fixed: Filter wasn't creating the second core (back to square one with MT_MULTI_INSTANCE)
- ExecuteShader: Added Engines parameter to specify the number of cores to run when using MT_NICE_FILTER
- MT_NICE_FILTER now working as expected
- Performance boost and lower memory usage

This time the AVX build isn't included as the script isn't currently using any conversion to float.

Next will be to support converting to/from the new Avisynth+ INT16/FLOAT types.

loneboyz

13th July 2016, 03:33

Upgrade the script 1.53, I still get an new error message "Failed to open pixel shader YuvToGamma.hlsl"

MysteryX

13th July 2016, 04:44

Upgrade the script 1.53, I still get an new error message "Failed to open pixel shader YuvToGamma.hlsl"
Which function gives you that error? Do the other functions work? This can also depend on the video format you're working with.

As the old saying goes, post your script.

loneboyz

13th July 2016, 05:41

As the old saying goes, post your script.

I'm try this script

ColorBars(pixel_type="YV12")
KNLMeansCL()

SR_Path = "F:\Setup\Encode\Tools\Avisynth.Plugin\AviSynthShader-1.5.3\"
LoadPlugin(SR_Path + "Shader.dll")
Import(SR_Path + "Shader.avsi")

SuperResXBR(3, Str=1, Soft=.15, XbrStr=2.5, XbrSharp=1, fWidth=720, fHeight=576)

MysteryX

13th July 2016, 06:08

This script works here.

Can you try with ConvertToRGB() ? That way it will skip YUV-RGB conversion.

loneboyz

13th July 2016, 08:06

I tried with ConvertToRGB() before call SuperResXBR, but not success

It's appear another message "Failed to open pixel shader SuperXBR.hlsl"

MysteryX

13th July 2016, 09:25

Then D3DXCompileShader fails on your system for some reason.

What OS are you using? Do you have DirectX 9c installed? (https://www.microsoft.com/en-us/download/details.aspx?id=34429)

loneboyz

13th July 2016, 09:33

Now, my system Windows 7 Ultimate 64bit (6.1 Build 7601), DirectX version 11. Tks!

MysteryX

13th July 2016, 13:11

Transferring the question to gamedev.net (http://www.gamedev.net/topic/680313-d3dxcompileshader-failing-on-user-computer/)... ah... might have something to do with the D3DXCompileShader function I'm using being deprecated. Edit: Searching online, using the newer D3DCompile gives error on Windows 7 with missing D3dcompiler_47.dll

Now I'm thinking. You take 16-bit output, dither to 8-bit YV24, then convert to YV12. The chroma dithering is kind of lost in the resize.

Wouldn't the quality be better if I'd resize the chroma in 16-bit, and then apply dithering to each plane and output YV12 data directly? We'd also get a serious performance gain by having YV12 output instead of YV24. This would however require considerable changes to the code structure. We'd get gains both on quality and performance.

loneboyz

14th July 2016, 03:07

The problem still can not be solved although I copied to SysWOW64 with missing D3dcompiler_47.dll, and I'm continuing to search

MysteryX, thank a lot for your help

MysteryX

14th July 2016, 03:17

Can you try installing DirectX 9c and see if that helps?

If not, can you try installing DirectX SDK (June 2010) and see if that helps?

That would help identify the issue.

Edit: Apparently it does indeed have dependencies on DX redistributables that must be installed separately. Since running the script with pre-compiled files does work, then it's only that function that has a bunch of dependencies. I'll try to instead use D3DCompile and to ship D3dcompiler_47.dll with it.

MysteryX

15th July 2016, 05:06

Version 1.5.4 is ready! (https://github.com/mysteryx93/AviSynthShader/releases/edit/v1.5.4)

What's new:
- MatrixIn/MatrixOut: Changed 601 to Rec601, 709 to Rec709.
- Fixed: It wasn't working on Windows 7
- All HLSL files now pre-compiled and included in DLL
- Much faster initialization
- ExecuteShader: Added Resource parameter. When true, it will only open internal resources without searching for a physical file

Note: You can use this with custom HLSL and compile them on-demand, but it may not work on Windows 7 due to missing D3dcompiler_47.dll. Pre-compiling all HLSL scripts into CSO files solves that problem.

loneboyz

15th July 2016, 07:17

Script 1.5.4 has been worked on my system

Many thank MysteryX!

MysteryX

15th July 2016, 07:46

I'm sure you'll enjoy the performance boost :)

luigizaninoni

15th July 2016, 12:11

1.5.4 solves all my issues. New shader.avsi works fine. No need to put all hlsl and cso in same directory. By the way, nnedi3_rpow2 works fine (64-bit, of course)

citroenfan

15th July 2016, 16:43

MisteryX, thank you for all your work.

I downloaded 1.5.4. version, but still unable to make it to work properly.

When tried to run it with avsmeter I got message "execute shader: process frame failed", shader.avsi, line 144.

Running W7 64bit
Nnedi3.dll v 0.9.4.22 for x86 (last version, ) is in C:\Program Files (x86)\AviSynth\plugins, there are also shader.avsi and shader.dll

avisynth 2.60.

please could you help me to resolve the problem?
thank you in advance.

my script
LoadPlugin("C:\PROGRA~2\GORDIA~1\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth\plugins\shader.dll")
Import("C:\Program Files (x86)\AviSynth\plugins\Shader.avsi")
Import("C:\Users\XXX\Downloads\QTGMC-3.32.avsi")
file=("G:\TV\xxx.d2v")
mpeg2source(file)
ConvertToYV12(interlaced=true)
AssumeTFF()
QTGMC( Preset="Slower" )
SelectEven()
# CROPPING
crop(18,74,696,428)
Double="""nnedi3_rpow2(2, nns=4, cshift="Spline36Resize", fwidth=1280, fheight=720, Threads=2)"""
SuperRes(3, 1.00, 0, Double)

MysteryX

15th July 2016, 16:51

citroenfan, do the other shader methods, such as SuperResXBR, work?

jammupatu

15th July 2016, 17:10

Hi,

I can't get any 1.5 version to work. This latest one (1.5.4) doesn't crash with VDub / Avspmod / Avsmeter like the earlier 1.5 builds do, but it errors out with:

"ExecuteShader: ProcessFrame failed."
<path to plugindir>\Shader.avsi, line 144.

This is the example script which I ran today (I've tried multiple others, too):

ColorBars(pixel_type="YV12")
KNLMeansCL()
SuperResXBR(3, Str=1, Soft=.15, XbrStr=2.5, XbrSharp=1, fWidth=720, fHeight=576)

EDIT: SuperRes doesn't work either; same failure.

I'm running Nvidia 980 SLI and Intel 4600 graphics on Windows 10 (14388 Fast Ring). I can replicate this issue inside a virtual Windows 7. This situation affects both scenarios, 64 and 32 bit versions with either official Avisynth 2.6 or Avisynth+. Here is my current Avs info:

32 bit:

C:\Program Files\Avsmeter216>AVSMeter.exe -avsinfo

AVSMeter 2.2.9 (x86) - Copyright (c) 2012-2016 Groucho2004

Avisynth version string: AviSynth+ 0.1 (r1576, x86)
File version: 2.6.0.5
Avisynth Interface Version: 5
Muli-threading support: No
Linker/compiler version: 11.0
Avisynth DLL location: C:\Windows\SysWOW64\AviSynth.dll
Avisynth DLL time stamp: 2014-01-02, 19:14:26
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins

[Avisynth CPP 2.6 plugins]
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\eedi3.dll (0.9.2.1)
C:\Program Files (x86)\AviSynth+\plugins\ffms2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\KNLMeansCL.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\masktools2.dll (2.1.0.0)
C:\Program Files (x86)\AviSynth+\plugins\mvtools2.dll (2.7.0.22)
C:\Program Files (x86)\AviSynth+\plugins\nnedi3.dll (0.9.4.22)
C:\Program Files (x86)\AviSynth+\plugins\RgTools.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\Shader.dll (n/a)

[Avisynth CPP 2.5 plugins]
C:\Program Files (x86)\AviSynth+\plugins\LSMASHSource.dll (n/a)

64 bit:

C:\Program Files\Avsmeter216>AVSMeter64.exe -avsinfo

AVSMeter 2.2.9 (x64) - Copyright (c) 2012-2016 Groucho2004

Avisynth version string: AviSynth+ 0.1 (r2022, MT, x86_64)
File version: 0.1.0.0
Avisynth Interface Version: 6
Muli-threading support: Yes
Linker/compiler version: 14.0
Avisynth DLL location: C:\Windows\System32\AviSynth.dll
Avisynth DLL time stamp: 2016-07-08, 12:36:56
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64

[Avisynth CPP 2.6 plugins]
C:\Program Files (x86)\AviSynth+\plugins64+\DirectShowSource.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\ImageSeq.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\Shibatch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\TimeStretch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64\eedi3.dll (0.9.2.1)
C:\Program Files (x86)\AviSynth+\plugins64\ffms2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64\KNLMeansCL.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64\masktools2.dll (2.1.0.0)
C:\Program Files (x86)\AviSynth+\plugins64\mvtools2.dll (2.7.0.22)
C:\Program Files (x86)\AviSynth+\plugins64\nnedi3.dll (0.9.4.22)
C:\Program Files (x86)\AviSynth+\plugins64\RgTools.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64\Shader-x64.dll (n/a)

[Avisynth CPP 2.5 plugins]
C:\Program Files (x86)\AviSynth+\plugins64\LSMASHSource.dll (n/a)

EDIT: tested again with both, 32b and 64b, running r2043 of Avisynth+ and encountering same error.

KNLMeansCL has a parameter called device_id which you can use to force a specific graphics card to be used. Could this be helpful? I'm free for testing a debug logging enabled dll if needed etc.

BR,

-j-

PS. Here is a link to the 1.5.4 version without the need to login to Github: https://github.com/mysteryx93/AviSynthShader/releases/download/v1.5.4/AviSynthShader-1.5.4.zip

PS #2. Below is a dump of Windows Event viewer which shows 1.5.3 crash on that virtual W7:

Faulting application name: Veedub64.exe, version: 1.10.4.0, time stamp: 0x526d9af3
Faulting module name: Shader-x64.dll, version: 0.0.0.0, time stamp: 0x57737327
Exception code: 0x40000015

citroenfan

15th July 2016, 18:23

When replaced lines

Double="""nnedi3_rpow2(2, nns=4, cshift="Spline36Resize", fwidth=1280, fheight=720, Threads=2)"""
SuperRes(3, 1.00, 0, Double)

with line

SuperResXBR(3, Str=1, Soft=.15, XbrStr=2.5, XbrSharp=1, fWidth=720, fHeight=576)

get the message
ExecuteShader: ProcessFrame Failed... Shader.avsi line 220

Avisynth version string: AviSynth 2.60, build:Feb 20 2015 [03:16:45]
File version: 2.6.0.5
Avisynth Interface Version: 6
Muli-threading support: Yes
Linker/compiler version: 12.0
Avisynth DLL location: C:\Windows\SysWOW64\AviSynth.dll
Avisynth DLL time stamp: 2015-02-20, 02:18:42
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth\plugins

[Avisynth CPP 2.6 plugins]
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\AutoAdjust.dll (2.5.0.0)
C:\Program Files (x86)\AviSynth\plugins\DirectShowSource.dll (2.6.0.2)
C:\Program Files (x86)\AviSynth\plugins\fturn-26.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\KNLMeansCL.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\MedianBlur2.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\msharpen.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\nnedi3.dll (0.9.4.22)
C:\Program Files (x86)\AviSynth\plugins\RgTools.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\SangNom2.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\TCannyMod.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\TEMmod.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\tmaskcleaner.dll (n/a)

[Avisynth CPP 2.5 plugins]
C:\Program Files (x86)\AviSynth\plugins\autolevels.dll (0.6.0.0)
C:\Program Files (x86)\AviSynth\plugins\avstp.dll (1.0.1.0)
C:\Program Files (x86)\AviSynth\plugins\Decomb.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\DePan.dll (1.10.1.0)
C:\Program Files (x86)\AviSynth\plugins\DePanEstimate.dll (1.9.2.0)
C:\Program Files (x86)\AviSynth\plugins\dfttest.dll (1.9.4.0)
C:\Program Files (x86)\AviSynth\plugins\DGDecode.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\dither.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\EEDI2.dll (0.9.2.0)
C:\Program Files (x86)\AviSynth\plugins\EEDI2_imp.dll (0.9.2.0)
C:\Program Files (x86)\AviSynth\plugins\eedi3.dll (0.9.1.0)
C:\Program Files (x86)\AviSynth\plugins\exinpaint.dll (0.2.0.0)
C:\Program Files (x86)\AviSynth\plugins\FFT3DFilter.dll (2.1.1.0)
C:\Program Files (x86)\AviSynth\plugins\flash3kyuu_deband.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\hqdn3d.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\mt_masktools-26.dll (2.0.48.0)
C:\Program Files (x86)\AviSynth\plugins\mvtools2.dll (2.6.0.5)
C:\Program Files (x86)\AviSynth\plugins\nnedi.dll (1.3.0.0)
C:\Program Files (x86)\AviSynth\plugins\nnedi2.dll (1.6.0.0)
C:\Program Files (x86)\AviSynth\plugins\RemoveDirt.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\RemoveDirtS.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\RemoveDirtSSE2.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\RemoveGrain.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\RemoveGrainSSE2.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\RepairSSE2.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\SSE2Tools.dll (n/a)
C:\Program Files (x86)\AviSynth\plugins\tcanny.dll (1.0.0.0)
C:\Program Files (x86)\AviSynth\plugins\TCPDeliver.dll (1.0.0.6)
C:\Program Files (x86)\AviSynth\plugins\TDeint.dll (1.1.0.0)
C:\Program Files (x86)\AviSynth\plugins\TEdgeMask.dll (0.9.0.0)
C:\Program Files (x86)\AviSynth\plugins\TTempSmooth.dll (0.9.4.0)
C:\Program Files (x86)\AviSynth\plugins\VerticalCleanerSSE2.dll (n/a)

MysteryX

15th July 2016, 18:24

I would think this could be due to a multi-threading issue with MT_NICE_FILTER, but when you run it with AviSynth 2.6, it runs as MT_MULTI_INSTANCE, and it still crashes.

Your script doesn't have any MT either. Will have to investigate... Why would it work for luigizaninoni and not for citroenfan and jammupatu?

Out of curiosity, try setting argument PlanarOut=false

As for specifying the device, this is not possible with DirectX 9. If you have dual-graphics, you have to configure the application to use the desired card.

jammupatu

15th July 2016, 18:46

Out of curiosity, try setting argument PlanarOut=false

As for specifying the device, this is not possible with DirectX 9. If you have dual-graphics, you have to configure the application to use the desired card.

PlanarOut=false fixes both SuperRes and SuperResXBS for me on my physical Windows 10 machine. Didn't try on virtual W7. Avisynth+ gives only a blue frame on 64bit builds when using SuperResXBR. Don't know if this is intended?

AVS versions:

Avisynth 2.6.0 Alpha 5 [130918] 32 bit
Avisynth+ r2022 and r2043 64 bit

Script:

ColorBars(pixel_type="YV12")
KNLMeansCL(device_id=1)
## comment out the function not being tested
SuperResXBR(2, Str=1, Soft=.15, XbrStr=2.5, XbrSharp=1, fWidth=720, fHeight=576, PlanarOut=false)
#SuperRes(Upscale="""nnedi3_rpow2(2, cshift="Spline16Resize")""", PlanarOut=false)
Info()

Thanks for the info about the DX9 limitation.

BR,

-j-

citroenfan

15th July 2016, 18:53

with the argument "PlanarOut=false" script 1.5.4. now working.

thank you MysteryX for your time and effort to make all this and helping me!

Best regards!

jammupatu

15th July 2016, 19:13

Regarding the blue frame, I decided to test SuperResXBR PlanarOut=False on Avisynth+ r2043 with proper video and the video comes out seriously broken. See attached pic.

BR,

-j-

MysteryX

16th July 2016, 03:37

PlanarOut requires different texture formats and the compatibility of texture formats depend on the GPU driver.

For both of you, what graphic card are you using? If you have a dual-graphics, does if fail with both cards?

I haven't done much testing at all on the x64 version, will have to test.

citroenfan

16th July 2016, 05:26

I'm using Nvidia GeForce GTX 960 on Windows 7 64-bit
(model ASUS STRIX GTX 960 DirectCU II OC)

luigizaninoni

16th July 2016, 08:44

On my PC with Intel HD4000 everything works fine without further tweaks

On my other PC with Nvidia GTX960 I need to add PlanarOut=false otherwise I get the same error as Jammapatu:

"ExecuteShader: ProcessFrame failed."
<path to plugindir>\Shader.avsi, line 144.

jammupatu

16th July 2016, 16:22

Hi, GPU-Z reports the load for the filters is running on Nvidia 980. I tried to force IGPU Intel to be the first one in BIOS (it's normally set to PCI-E 1 which hosts the 1st Nvidia 980) and set default monitor to the Intel "powered" one but I can't shift the load from Nvidia to Intel. I'm running the AVS script in VDub and in VDub's settings I can't find a clear option how to force the rendering to a specific card. I didn't find any commands/functions for setting graphics card globally in the AVS script either and since DX 9.0c doesn't allow your function to "bind" a specific graphics card, the question goes: any ideas how to shift the load to a specific card? Perhaps a different processing program than VDub? I'm also thinking if the binding can even be done in the application layer level (=VDub in this case). I'm thinking it should be on the Avisynth level instead. (E.g. the "first level" communicating with the DX API.)

BR,

-j-

MysteryX

16th July 2016, 16:27

With AMD, there is a "Configure Switchable Graphics" to set applications on "High Performance" or "Power Saving"

jammupatu

16th July 2016, 16:46

Did the load shifting by brute force; disabled both 980s in Windows' Device Manager and fired up a VDub, loaded a script with SuperResXBR active and now the Intel IGPU had load. The filter also works fine - no frame corruption.

BR,

-j-

MysteryX

17th July 2016, 11:44

Could you try with PlanarIn=true and tell me whether that works? Compatibility may different for input or output textures.

jammupatu

18th July 2016, 08:38

Hi.

Plain "PlanarIn=true" gives "ExecuteShader: ProcessFrame Failed" -error.

"PlanarOut=False, PlanarIn=true" works - no frame corruption.

Tests done only with Avisynth+ 64b.

BR,

-j-

MysteryX

18th August 2016, 11:06

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

What's new:
- Updated Avisynth headers
- Moved lock so that it doesn't cause all other filters to run as MT_SERIALIZED
- MT mode now set using SetCacheHints instead of using env2
- Planar format for precision 1 changed from D3DFMT_L8 to D3DFMT_A8 to see if it works better on NVidia cards

Please test PlanarOut with NVidia cards and tell me whether it works better. Test with 8-bit output; 16-bit output still won't work for sure.

Todo:
- Fix corruption with x64 build
- Fix PlanarOut in a nicer way, for both 8-bit and 16-bit output
- Add conversion support for Avisynth+'s new native 16-bit formats

Wilbert

21st August 2016, 17:56

I moved all the non-relevant posts which were not about the development of MysteryX's plugin to the usage forum.

MysteryX

21st August 2016, 18:12

Wilbert, I'll buy you a beer :D

jammupatu

22nd August 2016, 17:38

MysteryX

22nd August 2016, 18:24

In that case I'll have to deactivate PlanarOut for NVIDIA cards altogether.

jammupatu

24th August 2016, 15:55

In that case I'll have to deactivate PlanarOut for NVIDIA cards altogether.

Ok. Thank you very much for this piece of software and the effort regarding NVidia cards.

BR,

-j-

Wilbert

27th August 2016, 18:42

http://forum.doom9.org/showthread.php?p=1777925#post1777925

MysteryX

28th August 2016, 16:39

I'm not finding the other thread. Was it deleted? There was some good value in it and some specifically requested to never delete it as they were learning a lot from it.

Wilbert

28th August 2016, 17:06

I'm not finding the other thread. Was it deleted? There was some good value in it and some specifically requested to never delete it as they were learning a lot from it.
Yes he deleted it.

Nevilne

28th August 2016, 17:12

And here I thought we had a mod finally doing something

MysteryX

28th August 2016, 18:19

I think we all have something to learn from that incident, and it has nothing to do with video editing.

TheFluff

29th August 2016, 00:34

I think the lesson is "don't touch the poop"

raffriff42

29th August 2016, 01:01

On the positive side, I played around with some, uh, "luma upscaling algorithms" during all this and kept coming back to SuperRes - it's got a nice balance of sharpness and edge smoothing. Kudos!

MysteryX

29th August 2016, 06:43

I have to admit there is one factor that is unique to 4k upscaling: the pixels are too small to distinguish individually, and this can definitely alter the subjective experience. That's something I cannot reproduce on a 768p display where I can clearly see each pixel.

wonkey_monkey

29th August 2016, 12:21

AzraelNewtype

29th August 2016, 21:43

Also the size of the screen. It's easier to see individual pixels standing immediately next to that person's 65" 4k display than regular using distance of an iPhone 4, whose shorter dimension has even fewer lines than 768.

CkJ

30th August 2016, 06:32

the pixels are too small to distinguish individually
You can see the pixels clearly if you see the image at full size (a.k.a full resolution). Full size means you only can see a part of the larger size image (e.g 4k) on your smaller size display screen (e.g 768p). And you need to drag the scroll bar to see other parts.
If you see a larger size image on a smaller size display screen with fullscreen mode, the larger image is auto downscaled to fit your display screen. In other words, you are seeing a thumbnail.

Here's the way it works. It wraps around other resizers. After doubling the image size (with NNEDI3 for example), it resizes it back down with Bicubic and compares it with the original, producing a diff map representing details that were lost while upscaling. Then, it does its magic from that diff map.
How it works if I do an invert? I mean using superres for downscaling. E.g: SuperRes(2, .5, 0, """spline36resize(width/2, height/2)""")
Since the magic is from diff map, I think superres seem to be good to add lost details while downscaling. :)

CkJ

30th August 2016, 08:23

Original
http://i.imgbox.com/OngUFK84.png

bilinearresize(width*2, height*2)
spline36resize(width/2, height/2)
http://i.imgbox.com/ejDwWZLp.png

bilinearresize(width*2, height*2)
SuperRes(2, .5, 0, """spline36resize(width/2, height/2)""")
http://i.imgbox.com/DQ12uffJ.png

MysteryX

30th August 2016, 17:03

You can see the pixels clearly if you see the image at full size (a.k.a full resolution). Full size means you only can see a part of the larger size image (e.g 4k) on your smaller size display screen (e.g 768p). And you need to drag the scroll bar to see other parts.
Yes I can see all pixels that way; but there's a difference between seeing all the pixels clearly from 2 foot away from a 768p screen, and looking 6 foot away from a 4K screen where the pixels are too tiny to see individually. In that case it is possible that sharper pixels would actually look better. Kind of like a large TV screen looks good from far away, but when you look close there are black lines separating each pixel, yet those close-up details don't matter to the user.

How it works if I do an invert? I mean using superres for downscaling. E.g: SuperRes(2, .5, 0, """spline36resize(width/2, height/2)""")
Since the magic is from diff map, I think superres seem to be good to add lost details while downscaling. :)
I don't know; SuperRes wasn't designed for that. You can try.

Downscaling is a pretty straightforward operation and there is generally very little difference between various algorithms. It is Upscaling that requires a lot more work because new pixels need to be created. If you see improvements with downscaling, great. Most likely you won't get much more than Bicubic with tweaked B and C values to match the sharpness you want.

musicvideos4k

30th August 2016, 18:32

Yes I can see all pixels that way; but there's a difference between seeing all the pixels clearly from 2 foot away from a 768p screen, and looking 6 foot away from a 4K screen where the pixels are too tiny to see individually. In that case it is possible that sharper pixels would actually look better. Kind of like a large TV screen looks good from far away, but when you look close there are black lines separating each pixel, yet those close-up details don't matter to the user.

I don't know; SuperRes wasn't designed for that. You can try.

Downscaling is a pretty straightforward operation and there is generally very little difference between various algorithms. It is Upscaling that requires a lot more work because new pixels need to be created. If you see improvements with downscaling, great. Most likely you won't get much more than Bicubic with tweaked B and C values to match the sharpness you want.

Not surprised you are the only one here understanding the point. Anything i upscale using common methods looks blurry and actually even watching the original with a simple bicubic PS 2.0 * MPC-HC custom presenter * + the own 4K TV Upscaling looks much better than SuperRES or SuperXBR upscale, which looks blurred out and crap.

So then i decided to improve the upscaling by making it look better than what you get using TV's 4K internal upscaling + bicubic from normal media players, and still better than using MadVR.

That's what i am doing, which ive explained several times = playback for 4K Big screens, not some 22-24 inches 1080p, 1440p or even tiny 4k monitors.

You must see the content fitting the size and pixels from a display, of course a 55-85 4K screen is not being watched from 50 centimeters away.

CkJ

30th August 2016, 18:44

musicvideos4k

30th August 2016, 18:48

Now I can understand what you mean by "tiny pixels". Pixels on a 55'' 4k TV screen are smaller than pixels on a 60'' 4k TV screen. Yes, a smaller pixel actually look better than a bigger pixel.

You cannot see a 4K Pixel pattern on a tiny screen. What you are watching there is a thumbnail for your eyes, your eyes cannot see the actual pixels. Do you know the size for a pixel in a 4K 24" monitor? Even if you place your head in front the display you won't see the pixels. So, no, it does not look better, you are not seeing the pixels output, unless you are superman and you did not tell me yet. 4K looks better on bigger screens, where you can actually see what the pixels are outputting.

musicvideos4k

30th August 2016, 19:05

4K means there are 4*1920*1080 (for 16:9 AR) pixels. As far as I know a digital pixel has no size. Its size is the size of the pixel on a display screen.

No, I can, if that screen has 4*1920*1080 (for 16:9 AR) pixels.

The physical size of the pixel on the display. Every display got a pixel pattern showing R,G,B, some others using other methods of pixel patterns. The size of the pixel on a 4K Display cannot be seen if the display is tiny, you are watching a thumbnail for your eyes, literally you are being capped out by the limitations of the human eye.

That's why some people claims they see "better" a downscaled 4K to 1080p video on a 1080p display. The reason of this is the luma / chroma information is higher on a 4K image that when downsized to fit 1080p image/pixels it gets "compressed" and makes you believe is looking better.

This is what im doing for my upscale to 4K, but the opposite. I get the pixels to show what is supposed to be shown on a 4K screen:

http://imgur.com/a/uDaUd

The original is going to look blurry, even with the help of the 4k internal upscale + any resizer. The upscale is going to look cleaner and sharper, still looking the same natural aspect as the original frame. The reason of this is the added information to fit the display pixel pattern.

MysteryX

31st August 2016, 06:57

Let's not re-ignite this discussion here unless creating a separate threat. Just keeping focus to keep things constructive; plus it's a discussion that is only useful for those who have a 4k screen, which I don't.

Wilbert

2nd September 2016, 22:32

This time i did remove all non-relevant posts. I gave musicvideos4k a long weekend off.

Alex-Kid

13th September 2016, 06:54

Hello everybody, I read a lot of this thread and I would like to test this filter with some SD footage I have. However I keep getting the "ExecuteShader: ProcessFrame failed" message, no matter what function I use from Shader.avsi. For example:

avisource("BabyBlues.avi")
SuperXBR()

I'm guessing the issue could be in my video card: an ATI Radeon HD 4670, 512 MB. Am I wrong? If not, how can I get this to work with my footage?

I am on Win7 x64, Avisynth 2.6 MT, 3 GB RAM.

Alex-Kid

21st September 2016, 05:52

Does anybody know? I think my video card is too old, though it supports DX 10.1 (PS 4.1). What would be the minimum requirements on this?

brucethemoose

21st September 2016, 08:53

Does anybody know? I think my video card is too old, though it supports DX 10.1 (PS 4.1). What would be the minimum requirements on this?

SuperXBR() gives me a green screen on my DX11 6620G graphics. Not very helpful, I know... but notably, it isn't erroring out.

Also, what version of AviSynth are you using? I can't test it now, but on my 7950, all shaders on Avisynth+ x64 gave me an error when trying to encode. I might've had something configured wrong though.

Alex-Kid

21st September 2016, 22:36

I've tried AviSynth 2.6 MT only, maybe I should try other versions. I thought DX9 compatibility would be enough, as it's the version the filter use. Don't know what could I configure in my video card, or if I'm missing something else, like a specific shader driver for example.

MysteryX

19th October 2016, 06:43

Try with PlanarIn=false, PlanarOut=false

It only requires DX9; but some graphic cards don't support single-plane textures.

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.

MysteryX

8th September 2017, 17:40

You might be using a shader of the wrong version. This uses DirectX9 for processing which requires Pixel Shader version 3.0. Pixel Shader v5.1 would instead require DirectX12.

Try compiling manually using fxc

C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Utilities\bin\x86\fxc.exe /T ps_3_0 /Fo "..\YVToYuv.cso" "YVToYuv.hlsl"

MysteryX

8th September 2017, 19:28

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

What's new:
- Fixed compatibility regression with Avisynth 2.6
- Now converts properly from YV16 format with Avisynth 2.6
- Updated Avisynth headers

thecoreyburton

9th September 2017, 04:18

No such luck - but I can now see what the problem is. Thanks for the reply, I really appreciate it.

Fantastic job on the plugin, too!

gmail123

10th September 2017, 09:13

avs 2.6 is ok

gmail123

10th September 2017, 09:13

but avs + is wrong:

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

10th September 2017, 09:21

in this script:
AddAutoloadDir("D:\video\MeGUI\tools\avisynth_plugin")
LoadPlugin("D:\video\MeGUI\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("C:\Users\pc\Desktop\12.mkv")
#LanczosResize(704,380) # Lanczos (Sharp)
ConvertToShader(2)
last
Shader("D:\video\MeGUI\tools\avisynth_plugin\nnedi3.hlsl" )
Shader("D:\video\MeGUI\tools\avisynth_plugin\SuperRes.hlsl")
ExecuteShader(last,last,Clip1Precision=1,Precision=3,OutputPrecision=2)
ConvertFromShader(2)

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

https://imgbox.com/m1amfWuz

.hlsl is ok
http://imgbox.com/jfBfgJWk

MysteryX

10th September 2017, 14:41

but avs + is wrong:
Oh right there was this bug when handling HBD with the Upscale command.

SuperResXbr is probably working fine for you.

With NNEDI3.hlsl, is it using PS_3_0 format? I haven't yet found a NNEDI3 HLSL script written in 3_0 format, all I've seen were in 4_0 format which doesn't work here.

Try compiling it manually with fxc as I mentioned a few posts back.

gmail123

13th September 2017, 13:31

in this script:
Dither_convert_8_to_16()
SuperRes(3, .43, 0, """nnedi3_rpow2(2, nns=4, cshift="Spline16Resize")""")
ResizeShader(720,400)
DitherPost()
output:720*200
bug?

MysteryX

13th September 2017, 15:22

You're using Stack16 format as input, so you need to set lsb_in=true and lsb_out=true. lsb_upscale=lsb_in by default.

Also, you're using nnedi3_rpow2 on a Stack16 clip which isn't valid.

gmail123

13th September 2017, 16:18

because of :
https://thumbs.imgbox.com/93/72/fMDWgfWQ_t.png (http://imgbox.com/fMDWgfWQ)

gmail123

13th September 2017, 16:23

how to use "nnedi3_rpow2" on a Stack16 clip?
use "lsb_in=true and lsb_out=true" all wrong.

now ,I have no idea...

MysteryX

13th September 2017, 16:34

AFAIK nnedi3_rpow2 doesn't support Stack16, but you can use ConvertToStacked and ConvertFromStacked (http://avisynth.nl/index.php/ConvertStacked) to convert between native 16-bit and Stack16

csp invalid? Make sure you have the latest version of DitherTools. csp parameter is in the docs. (http://avisynth.nl/index.php/Dither_tools#Dither_resize16.2C_Dither_resize16nr)

The but with AvisynthShader is in properly detecting 16-bit clips in the Upscale command.

Perhaps this will work, haven't tested

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

gmail123

17th September 2017, 15:10

MysteryX

17th September 2017, 18:10

wrong...
dither ver 1.27.2

I am crazy...
hum... I have 1.27.1

Weird. Perhaps someone else knows about that

MysteryX

20th September 2017, 18:00

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

What's new:
- Fixed SuperRes when using high-bit-depth upscale

SaurusX

16th October 2017, 20:39

When using SuperRes is it always necessary to use ConvertoRGB24() when encoding from a DVD source? Is there any way to keep the video in YV12 and use this upscaling? There are slight color shifts as a consequence of converting color space. I'm using a GTX750 Ti.

MysteryX

16th October 2017, 22:23

SaurusX

17th October 2017, 02:35

It needs to be converted to RGB32 internally. However, if you pass in YUV data, it will do the YUV to RGB conversion on the GPU in 16-bit and convert back to YUV. Alternatively, you can convert to RGB32 in 16-bit and do several operations and then convert back to YUV yourself in 16-bit. You shouldn't be seeing color shifts unless you convert colors in 8-bit.

I am converting in 8-bit, but how do I NOT do that? I'm just using straight ConverttoRGB24(matrix="Rec709") and ConverttoYV12(matrix="Rec709") later. I was lacking the matrix specification which was causing even worse color shifts before. Now it's mitigated, but there's still something happening.

MysteryX

17th October 2017, 05:32

SaurusX

17th October 2017, 11:30

If you're using Avisynth+, you can use ConvertBits(16) and ConvertBits(8) to work in high-bit-depth.

Also is there a reason why you wouldn't just let the RGB conversation happen on the GPU? If there's a color shift, it might be due to a wrong color matrix. When doing GPU conversion, you can use MatrixIn and MatrixOut which are Rec709 by default. Perhaps your clip has Rec601. Double-check what color matrix is your source material.

I'm using AviSynth through megui. Without an explicit call of ConverttoRGB24(matrix="Rec709") I get the following error message:

https://i.imgsafe.org/5d/5db08ce153.png

So I'm not quite sure what you mean by letting the conversion happen on the GPU. Is this problem an Nvidia thing? I've already had to make two small alterations to shader.avsi where I've set PlanarOut=False.

Thanks for your help.

SaurusX

17th October 2017, 15:24

OK, reading up on the Convert filters apparently I need to be using "PC.709" instead of "Rec.709" as I only want it to keep it's current color space range and not try to stretch it again. I'll try that and see if the color changing disappears.

EDIT: I figured it out. I have to use the following in order for the colors not to shift.

ConverttoRGB24(matrix="Rec601")
SuperResXBR(3, 1, 0.15, XbrStr=2.7, XbrSharp=1.3, fWidth=960, fHeight=720, fKernel="Bicubic", fB=0, fC=.75)
ConvertToYV12(matrix="Rec709")

This is from a DVD source, BTW. I don't know why the internal conversion process isn't working, but at least the problem is solved.

MysteryX

17th October 2017, 18:28

It's possible that there's still a bug with Avisynth 2.6 if that's what you're using.

Here it's working but you're losing data on both Convert functions resulting in loss of details accuracy.

SaurusX

17th October 2017, 19:17

I am using AVISynth 2.6 with megui. For me, the ConvertoX calls seem to be unavoidable for now. I may upgrade to AVISynth+ in the future to get rid of this problem.

How much detail is lost in these conversions at any rate? For animation it seems to be completely unnoticeable.

MysteryX

18th October 2017, 18:14

Just rounding errors. Alternatively, you can also use DitherTools to do 16-bit conversion with Stack16 format.

SaurusX

19th October 2017, 16:29

SOLVED. When using AVISynth+ instead of AVISynth2.6 there is no error on loading SuperRes or SuperResXBR. Using the flag matrixin="Rec601" for this DVD source results in perfect colors that match the source and no clipping at the extremes. Thanks again for the assist.

Gser

5th November 2017, 21:39

I can't get 10-bit input to work correctly even with AVS+.

LWLibavVideoSource("file.ts", format="YUV420P10")

ResizeShader(width=1920, height=1080, kernel="SSim")
8-bit works fine though. All I get for 10-bit is this:
https://imgur.com/a/v82jg
It's not even the right resolution, its 960x1080.

ps. have you thought about adding support for bt.2020?

sneaker_ger

5th November 2017, 22:56

Gser

6th November 2017, 13:39

L-Smash doesn't support the native high bitdepth formats of AviSynth+. Either use ffms2 or try something like:
LWLibavVideoSource("file.ts", format="YUV420P16", stacked=true)
ConvertFromStacked()
ResizeShader(width=1920, height=1080, kernel="SSim")
L-Smash works just fine with avs+ formats http://avisynth.nl/index.php/LSMASHSource/LWLibavVideoSource
But it seems that I will have to use stacked as the only resizers that work directly with 10-bit are the internal ones.

sneaker_ger

6th November 2017, 14:16

L-Smash works just fine with avs+ formats http://avisynth.nl/index.php/LSMASHSource/LWLibavVideoSource
I don't read anything about AVS+ formats in there.

But it seems that I will have to use stacked as the only resizers that work directly with 10-bit are the internal ones.
I don't really know but to me this implies the AVS+ formats should be supported:
If you're using Avisynth+, you can use ConvertBits(16) and ConvertBits(8) to work in high-bit-depth.

Did you try my suggestions (unsuccessfully)?

Gser

6th November 2017, 15:02

I don't read anything about AVS+ formats in there.

I don't really know but to me this implies the AVS+ formats should be supported:

Did you try my suggestions (unsuccessfully)?
I can't demonstrate it any better that this picture.

https://imgur.com/a/60gYY

Yes I understood also that avs+ formats were supported but at least 10-bit didn't work.

Now I am using this code
LWLibavVideoSource("file.ts", stacked=true, format="YUV420P16" )
Dither_convert_yuv_to_rgb (matrix="2020", output="rgb48y", lsb_in=true)
Dither_y_gamma_to_linear (tv_range_in=true, tv_range_out=true, curve="2020", sigmoid=true)
Dither_resize16 (1920, 1080, kernel="bicubic", a1=0, a2=0.75)
Dither_y_linear_to_gamma (tv_range_in=true, tv_range_out=true, curve="2020", sigmoid=true)
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="2020", lsb=true)
Dither_quantize (10, mode=7, reducerange=true)
Dither_out ()
Prefetch(3)I'm doing the rgb conversion with dither tools as avisynthshader doesn't support bt.2020. I was hoping to process the rgb video then in avisynthshader but it processes stacked formats only in YV12 and YV24.

MysteryX

6th November 2017, 16:36

Gser

6th November 2017, 17:22

The image above isn't Stack16 format otherwise it would appear in 2 vertical sections with the bottom half showing random junk.

Note that if you pass 10-bit, it needs to be converted to 16-bit to pass into the shader. Use ConvertBits(16) before it and it should work fine.

Yes it wasn't supposed to be stacked, I was trying to directly convert planar 10-bit. And also convertbits didn't work, just gives an error about reading video. Only converting it to stacked works. There might be a problem in convertbits because just using it without resizing already gives me an error. Quite bizarre.

MysteryX

12th November 2017, 04:30

Just to be clear. The GPU works only in 8-bit, 16-bit, or 32-bit.

If you pass other formats like 10-bit, it should automatically handle the conversions but perhaps I haven't tested that much.

MysteryX

16th December 2017, 04:47

Madshi replaced NNEDI3 with NGU in madVR. I haven't tried it yet but it appears to be better as he also removed NNEDI3.

Anyone knows of available HLSL implementation of NGU?

cork_OS

16th December 2017, 09:36

Madshi replaced NNEDI3 with NGU in madVR. I haven't tried it yet but it appears to be better as he also removed NNEDI3.

Anyone knows of available HLSL implementation of NGU?
Note that there are two main NGU variants, NGU AA (madshi's rewrite of NNEDI3, somewhat improved) and NGU Sharp/Standard/Soft (madshi's own edge-directed upscaler like waifu2x, FSRCNN etc.).
I assume that NGU sources will never be shared (however madshi plans to release avisynth plugin with madVR algorithms someday). For now you can try FSRCNN from mpv, I assume.

MysteryX

16th December 2017, 17:34

Oh madshi wrote these himself? Yeah that might make it harder to implement it elsewhere as he tends to be protective with his hard work.

MysteryX

16th December 2017, 21:11

edcrfv94

18th December 2017, 00:57

OK I talked with Madshi. He's planning to release a madVR toolkit for Avisynth+ and VapourSynth, so you'll be able to use NGU + SuperRes without using AvisynthShader. When he gets the time to finish it.

I do a fast search for super-resolution FSRCNN look like much better than nnedi3, But AviSynthShader not compatible MPV glsl Shaders.

NGU Sharp compares to mpv's latest FSRCNN(X):
https://forum.doom9.org/showthread.php?p=1825432#post1825432

MysteryX

21st December 2017, 03:01

NGU looks considerably better than FSRCNN(X) that causes much more edge/color distortion. It's also a lot faster. Thanks for the benchmarks and comparison.

Now NGU+SuperRes should also look great

cork_OS

21st December 2017, 23:46

Now NGU+SuperRes should also look great
madshi said several times that SuperRes doesn't seem to be beneficial for NGU (https://forum.doom9.org/showpost.php?p=1786250&postcount=40259) and even can harm it.

MysteryX

22nd December 2017, 20:04

Have they also done comparison of SuperRes with NNEDI3 or SuperXbr, with NGU? SuperRes+Xbr was doing a great job already but had some distortion in some cases with geometric forms. I'd be curious to see NGU side-by-side.

edcrfv94

24th December 2017, 08:24

madshi said several times that SuperRes doesn't seem to be beneficial for NGU (https://forum.doom9.org/showpost.php?p=1786250&postcount=40259) and even can harm it.

EDSR look super!!!
https://github.com/LimBee/NTIRE2017

MysteryX

13th May 2018, 06:20

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

What's new:
- Fixed crash on NVidia cards when PlanarOut=true

Btw I'm hoping someone will port EDSR or other such algorithms to Avisynth... but I can only hope.

SaurusX

14th May 2018, 21:28

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

What's new:
- Fixed crash on NVidia cards when PlanarOut=true

Thanks for the fix! Does this provide any speed boost for nvidia cards?

MysteryX

15th May 2018, 03:33

Thanks for the fix! Does this provide any speed boost for nvidia cards?
Not unless you were running it with PlanarOut=false. If you did specify that, this version DOES support PlanarOut on NVidia cards. It supports L8 format in sysmem Textures, but not in PlainSurface! So I just switched it to use sysmem Textures for output as they both do the same thing.

SaurusX

22nd February 2019, 18:04

@MysteryX Any plans to port over other HLSL shaders to AVISynth? There are many out there that would be very valuable when it comes to encoding. I keep hoping.

MysteryX

25th February 2019, 14:25

@MysteryX Any plans to port over other HLSL shaders to AVISynth? There are many out there that would be very valuable when it comes to encoding. I keep hoping.

You can always list some that would be useful to port, if they are written in a compatible format. Then someone might find the time to do it. Most useful scripts already have Avisynth implementations, and this has the disadvantage of requiring RBG conversion.

SaurusX

25th February 2019, 17:31

You can always list some that would be useful to port, if they are written in a compatible format. Then someone might find the time to do it. Most useful scripts already have Avisynth implementations, and this has the disadvantage of requiring RBG conversion.

In that case let me say that it would be great to have SMAA ported over. It would be a great addition to the anti-aliasing arsenal.

https://github.com/iryoku/smaa

https://kentaroid.com/wp-content/uploads/2014/02/383b9583e09f61e6f16d1ca3c45790dd.png

Rumbah

25th February 2019, 20:43

The thing with SMAA is that it's not just a simple post filter but it uses things like a depth buffer. So it might not be usable on a simple picture/video at all.

wonkey_monkey

25th February 2019, 21:00

The thing with SMAA is that it's not just a simple post filter but it uses things like a depth buffer. So it might not be usable on a simple picture/video at all.

It can use a depth buffer for edge detection but it doesn't have to.

I'm not sure what that image is showing though. The bit in green on the left seems to already be anti-aliased after some fashion, I can't believe that the red is a simple application of SMAA to the bit in green. That looks way too good.

MysteryX

26th February 2019, 09:23

Anti-aliasing is used for rendering 3D content into the screen.

If you're only using it as a post-processing for 2D content, then it's simply yet another desharpening or blurring algorithm.

wonkey_monkey

26th February 2019, 10:35

Anti-aliasing is used for rendering 3D content into the screen.

No it isn't. Aliasing isn't a 3D-only problem.

Dogway

7th March 2019, 03:36

Do you have plans on porting the plugin to VapourSynth?

MysteryX

12th March 2019, 14:43

Do you have plans on porting the plugin to VapourSynth?

Eventually but it's far in my todo list

Dogway

12th March 2019, 15:38

pity, looks like the best tool aren't never in the same boat, wanted to try BM3D with SSIM resizer. FRC would also be a nice addition.

ChaosKing

12th March 2019, 16:58

use avsproxy in VS for FRC.

poisondeathray

12th March 2019, 17:31

If you have a working avisynth install, you can use core.avisource.AVISource too for FRC (or any avisynth script)

Dogway

12th March 2019, 20:47

Thanks ChaosKing, not sure if in this case it defeats my purpose for using more robust memory and MT handling if in the end I use avisynth. I will try SSIM and FRC with avsproxy.

ChaosKing

12th March 2019, 20:55

I like avsproxy bcs its like you're using a plugin. Input clip -> process -> output. And in VS I can also test for frame accurate seeking. Idk how if this is possible in avs.

Dogway

18th March 2019, 22:13

I don't know if it's possible to port the Jinc Resizer? the Jinc plugin that exists in avisynth doesn't support downscaling. Jinc (EWA filtering) is a very good kernel for aliasing/moiree, my aim is to downscale rendered cloth patterns using EWA filtering (not usually available in rendering or compositing software).

Alexkral

8th August 2019, 23:45

Hi, I'm having some problems with this script:

input = FFmpegSource2("video.mkv")

ScriptClip(input, """
Mean = string(AverageLuma(input) / 255.0) + "f"
c1 = ConvertToShader(input)
c2 = Shader(c1, "shader.hlsl", Param2 = Mean)
ExecuteShader(c2, c1)
ConvertFromShader(last, format = "YV12")
""")

This loads in VirtualDub, but in MPC-HC I got:

Shader: Failed to open pixel shader shader.hlsl
ExecuteShader: Initialize failed

Is there any other way to pass a runtime function to a shader?

Edit: Nevermind, copying the shader to the plugins folder solved the problem. Another thing, is there any reason for changing the order of the channels? I mean, I can handle it, but it doesn't seem like the way it should work.

ChaosKing

17th August 2019, 23:29

I found this https://github.com/bloc97/Anime4K/blob/master/Preprint.md#1080p-to-4k by accident and wanted to try this HLSL filter with your shader plugin. But I'm a bit stuck, I can't load the hlsl files. I think I can only use "compiled?" hlsl -> cso files? If yes, how can I "compile" them?

https://github.com/bloc97/Anime4K/releases

This is what I tried:
ConvertToShader(1)
Input = ffms2("test.mkv")
Shader("d:\Anime4K_Push.hlsl", Output=2)

ExecuteShader(Input, Clip1Precision=1, Precision=3, OutputPrecision=1)
ConvertFromShader(1)
Error: ExecuteShader: Source must be a command chain

p.s. Please change ShaderExecute to ExecuteShader in your github example. It took me some time to realize that the command is just wrong :)

EDIT
ok I think i need to run multiple shaders https://github.com/bloc97/Anime4K/blob/master/HLSL_Instructions.md

Input = ConvertToShader(ffms2("d:\test.mkv"))

Shader("d:\Anime4K_ComputeLum.hlsl", output=2)
Shader("d:\Anime4K_Push.hlsl", Clip1=2, output=3)
Shader("d:\Anime4K_ComputeGradient.hlsl", Clip1=3, output=4)
Shader("d:\Anime4K_PushGrad_Weak.hlsl", Clip1=4, output=1)

ExecuteShader(last, Input)
ConvertFromShader(last)
This loads now, but the output looks a bit broken.

StainlessS

18th August 2019, 11:48

I dont know nuttin bout this, but apparently the compiler (Effect-Compiler Tool - FXC.EXE) is included in DirectX SDK, and VS 2012:- https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-part1
Click on the fxc.exe link on linked page:- https://docs.microsoft.com/en-gb/windows/win32/direct3dtools/fxc
Offline Compiling:- https://docs.microsoft.com/en-gb/windows/win32/direct3dtools/dx-graphics-tools-fxc-using

Or Google stuff:- https://www.google.com/search?source=hp&ei=vylZXe8-p-OSBZT4plg&q=compile+hlsl&oq=compile+hlsl&gs_l=psy-ab.3..0j0i30l3j0i5i30l3j0i8i30l3.697.14203..14547...0.0..1.232.1427.9j4j1......0....1..gws-wiz.....0..0i131j0i10j0i22i30.F1Cav0KTJjU&ved=0ahUKEwivmvupnIzkAhWnsaQKHRS8CQsQ4dUDCAc&uact=5

ChaosKing

18th August 2019, 13:38

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 :D

EDIT: Ahh finally found the diffenrence between hlsl and glsl (directx vs opengl) https://anteru.net/blog/2016/mapping-between-HLSL-and-GLSL/
and the future seems to be SPIR-V (vulkan)

Alexkral

18th August 2019, 20:22

This loads now, but the output looks a bit broken.

I managed to make this work with some problems, this is what I have found so far:

- The default precision for ConvertToShader and ConvertFromShader is not 1, so you have to specify it.
- The input has to be RGB because otherwise the shader receives YUV channels.
- The first shader receives the channels as BGRA. The last shader has to return them as BGRA for RGB32 by changing the order again, or as GBRA for YV12 or YV24.
- The Alpha channel can be used to pass data between the shaders, but obviously it is lost at the end.

There is no need to compile the shaders. The naive luminance aproximation in the ComputeLum shader doesn't make any sense, doing it the right way compiles to less instructions.

Also, these shaders run on screen space so you have to resize before (but if you don't, the effect is quite fun with low-res videos :)).

ChaosKing

18th August 2019, 20:48

I managed to make this work with some problems, this is what I have found so far:

- The default precision for ConvertToShader and ConvertFromShader is not 1, so you have to specify it.
- The input has to be RGB because otherwise the shader receives YUV channels.
- The first shader receives the channels as BGRA. The last shader has to return them as BGRA for RGB32 by changing the order again, or as GBRA for YV12 or YV24.
- The Alpha channel can be used to pass data between the shaders, but obviously it is lost at the end.

There is no need to compile the shaders. The naive luminance aproximation in the ComputeLum shader doesn't make any sense, doing it the right way compiles to less instructions.

Also, these shaders run on screen space so you have to resize before (but if you don't, the effect is quite fun with low-res videos :)).

Ahh ok thx.
But the only thing I had to change was to add Precision=1 in ConvertToShader / ConvertFromShader. Basically it is exactly like the example on github now :p

Input is yv12 and it seems to work.

EDIT:
But the sharpening effect is a bit too extreme and produces sometimes aliasing. NGU looks much better in the comparison.
The good thing is, it's "fast".

Alexkral

18th August 2019, 21:25

It works, and the result may even be identical, but it is not correct at all. Use RGB for input and output and change the "float lum ..." line in Anime4K_ComputeLum.hlsl by this:

float lum = (c0[2] + c0[2] + c0[1] + c0[1] + c0[1] + c0[0]) / 6;

Again, it probably won't make any difference.

Alexkral

27th August 2019, 00:53

Would it be possible to increase the number of clips to 16?

poisondeathray

27th August 2019, 02:29

I can't get the Anime4k hlsl to work . "Invalid arguments to function 'Shader'" . I tried different combinations of CK's post 559, and added Precision=1 for ConvertToShader, ConvertFromShader

Can you post a full script? or whatever the "proper" way to use this ?

Thanks

Alexkral

27th August 2019, 04:07

input = FFMS2("video.mkv", colorspace = "RGB32")

c = ConvertToShader(input, Precision = 1)
Shader(c, "Anime4K_ComputeLum.hlsl", output=2)
Shader(last, "Anime4K_Push.hlsl", Clip1 = 2, output = 3)
Shader(last, "Anime4K_ComputeGradient.hlsl", Clip1 = 3, output = 4)
Shader(last, "Anime4K_PushGrad.hlsl", Clip1 = 4, output = 1)
ExecuteShader(last, c, Precision = 3, OutputPrecision = 1)
ConvertFromShader(last, Precision = 1, Format = "RGB32")

poisondeathray

27th August 2019, 04:21

Thanks Alexkral, it's working now

Alexkral

6th September 2019, 09:20

@MysteryX

Since I have read that you have said that the bottleneck is memory transfers, I would like to know if the intermediate results are also being transferred. I ask it because using a chain of shaders the GPU load is below 15%, so I wonder if maybe grouping some shaders into a heavier one could be useful to increase performance.

Dogway

12th October 2019, 10:32

I'm unable to resize single planes:

ConvertToY()
ResizeShader(3840,2160,"bicubic",0,0.4)

CombinePlanes: source bit depth is different from 16
(C:/Program Files (x86)/AviSynth+/plugins64+/Shader.avsi, line 357)
(New File (1), line 23)

StainlessS

12th October 2019, 19:06

MysteryX, (Not on-line since 27 Sept 2019),

Can you update the dead PostImage.org images in first post please.
[ Easy to do, just edit the post, and change all PostImage.org to PostImage.cc ]

EDIT: Actually, quite a lot of dead images in later posts too.
EDIT: Same in FramerateConverter thread and its predecessor thread SVP-like frame interpolation?.

tebasuna51

14th October 2019, 11:07

Can you update the dead PostImage.org images in first post please.
[ Easy to do, just edit the post, and change all PostImage.org to PostImage.cc ]

Work in first post, but not in the second.

StainlessS

14th October 2019, 16:10

Thanks for trying Teb.
I dont remember ever seeing the "Image Not Found or Removed" thing (unless it was deleted deliberately by user).
When it first happened (maybe 12 to 18 months ago), I spend several days (3 or 4 maybe) altering several hundred url's,
and I also altered some only a few days ago to restore some broken images (must have been broken for more than 12 months, they had not been deleted).

Thanx again :)

fozter

8th December 2019, 20:50

I'm kind of a noob when it comes to video post processing, so please bear with me.

I've got this 1080p/HDR10/HEVC-track that I'm trying to upscale(SuperResXBR) to 2160p while still maintaining the HDR10-part.
Running this line: SuperResXBR(passes=5, factor=2)
But when reading the github I interpret it as colormatrix bt.2020 isn't supported and that by default it will convert it to bt.709.
Is this correct? And if, can someone please point me to another plugin that can achieve this? NNEDI3 maybe?

Alexkral

10th December 2019, 10:22

You can use the HDRTools plugin to convert to BT.709 and then use SuperResXBR with FormatOut = "YUV420P10". For NNEDI3 you can do the same and use NNedi3 resize 16:

https://forum.doom9.org/showthread.php?t=175488
http://avisynth.nl/index.php/Nnedi3_resize16

Edit: It seems that Nnedi3 resize 16 is no longer available but I think if you use ConvertYuv=false AviSynth Shader will cast YUV as RGB so there's no colorspace conversion and MatrixIn/MatrixOut are not used.

fozter

10th December 2019, 23:16

Okay, will try that. Thanks!

markiemarcus

11th January 2020, 23:10

I'm observing a very slight colour shift towards green (and I'd swear a slight drop in brightness or contrast) when using high bit depth processing in Avisynth+. This is with a Rec601 source and an AMD RX 480. Doesn't occur with standard bit depths. Any suggestions? It isn't as severe as a 601/709 shift, but it is there.

SuperResXBR(MatrixIn="Rec601")
^This works fine

ConvertBits(16)
SuperResXBR(MatrixIn="Rec601")
ConvertBits(8, dither=-1)
^This experiences the colour shift.

Dither_convert_8_to_16()
SuperResXBR(MatrixIn="Rec601",lsb_in=true,lsb_out=true)
DitherPost (mode=-1)
^No colour shift. Otherwise visually different results from the above.

Perhaps it's something I'm doing wrong? It is very minor and could just be the nature of the beast.

Alexkral

13th January 2020, 20:19

As you say maybe it's just because of the upscaling, I'm also experiencing color shifts with other algos so it seems quite possible to me. Anyway you could try with ColorYuv = false.

amayra

13th January 2020, 21:59

i wish if this work in vapoursynth natively

poisondeathray

14th January 2020, 04:52

markiemarcus

14th January 2020, 13:25

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

21st May 2020, 12:35

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 :D

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

markiemarcus

16th June 2020, 01:19

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

16th June 2020, 01:42

Yes it has the same error for me

markiemarcus

16th June 2020, 01:47

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

Reel.Deel

16th June 2020, 02:36

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

16th June 2020, 03:01

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

17th June 2020, 16:44

StainlessS

17th June 2020, 17:11

Cheers MX :)

DJATOM

17th June 2020, 17:34

https://github.com/mysteryx93/AviSynthShader/commit/2481cd0db898151ec49a7455fc3262b99a521006#diff-af6f79275b08d74be68ade0a84bb01acR156
I think you slipped b = in your edits, didn't tested though

gispos

17th June 2020, 20:33

markiemarcus

17th June 2020, 23:55

By popular demand, v1.6.6 is released! (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.6.6)
- 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

18th June 2020, 23:20

By popular demand, v1.6.6 is released! (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.6.6)
- 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

19th June 2020, 00:48

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

19th June 2020, 01:09

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

see how asd and pinterf did it

StvG

19th June 2020, 02:02

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.php?p=1915174#post1915174

MysteryX

19th June 2020, 02:04

Check this post https://forum.doom9.org/showthread.php?p=1915174#post1915174
Simplest: for previous AVS versions, do the same I was doing for AVS 2.6

Alexkral

24th June 2020, 12:15

MysteryX

24th June 2020, 16:49

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. :confused:

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

24th June 2020, 18:11

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.

Alexkral

24th June 2020, 21:59

Sorry, I think I'm complicating things. What I would like to know is if, as it seems, the use of the Width and Height parameters with any Output is enough to make sure that the size of each texture is that intended.

MysteryX

27th June 2020, 03:32

if I remember, the shader takes parameters to know the input size, and the parameters added to the command are the output size. I could be wrong, but I think it's that.

Alexkral

27th June 2020, 08:50

Okay, it seems to work fine so thanks.

amayra

27th June 2020, 23:20

any plan for VapourSynth support ?

Alexkral

28th June 2020, 10:32

@Amayra, just out of curiosity, what would you use this for in VapourSynth? I mean, something that is not possible with AviSynth?

MysteryX

2nd July 2020, 22:51

Myrsloik

3rd July 2020, 12:13

I would like to add VapourSynth support. I think AviSynth/VapourSynth cross-platoform compatibility should be the standard in 2020 (although this particular project can't work outside Windows because of DirectX9)

Yet I still haven't looked into learning VapourSynth at all.

It would be useful if someone would write documentation with standard guidelines to write plugins for both VapourSynth and Avisynth, and also for making them cross-platform. Otherwise each dev needs to figure it out on their own.

Cross-platform development is so far outside the scope of everything ending in synth it's not even funny. You need a fairly thick programming book to cover that subject in general.

Here's the uncomfortable truth:
1. Did you write GPU code? Probably not portable
2. Did you write code with unaligned memory access? Probably not portable
3. Did you access the filesystem? Probably not portable
4. Did you partially access a wider numerical type in memory? Definitely not portable!
5. Are you super great at build systems? No? No portability for you!

If you write sane code that only performs some CPU calculations and nothing else it'll probably be portable without much effort but that's about it.

MysteryX

3rd July 2020, 19:04

These would be good guidelines for those starting to write new plugins. Things to know before writing the first line of code.

What's easier to do is port to VapourSynth and support both. If the actual work is done by a well-encapsulated class, then it should only require 2 separate code files to interop with each *synth?

Myrsloik

3rd July 2020, 20:16

real.finder

20th July 2020, 15:26

Alexkral

21st July 2020, 20:08

Hi MysteryX, I've been working with AviSynth Shader for some time trying to use it to run some Super-resolution CNNs implemented as pixel shaders. You can see the result here (https://github.com/Alexkral/AviSynthAiUpscale). First thing I have to say is that it works very good and fast, so I wanted to thank you for your work, it's great to be able to use a tool like this. However I have found some problems and limitations that I wanted to inform you about, so that you can see what would be necessary to solve them if this is possible:

- This works by using each plane as the input/output for a filter, so with a maximum of 9 clips, the maximum number of filters is 36. To implement a network of 64 filters (most), 16 clips would therefore be necessary. For simple models like FSRCNN, this can be solved by spliting the layers between two or more shaders, but for more complex models this would mean a large increase in the number of shaders, and apart from what this would mean for performance, there is already a limit about the maximum number of shaders that can be used in the same pass (see below).
- I'm not sure what the problem is with Y16 as this seems to have been changing. Using it as input produces the error "CombinePlanes: source has no such plane U". Using it as output returns a YUVA444P16 clip. Maybe this could help to increase performance.
- Trying to return a Y8 clip now with Precision = 0 produces the error "CombinePlanes: source bit depth is different from 16".
- Shader Model 3.0 has a limit of 224 Constant registers. This means that, for example, the maximum number of clips that can be used in a shader for a Conv3x3 layer is equal to 6. Unfortunately this can only be solved by using Shader Model 4.0 or spliting the layers as above.
- There is a limit on the maximum number of shaders that can be used in a single pass, after which an access violation error occurs. I have noticed that this limit varies slightly depending on Precision and PlanarOut. This is what I've found in case it could help you:

With Precision = 1 and PlanarOut = false, the limit is 79.
With Precision = 1 and PlanarOut = true, the limit is 76.
With Precision = 2 and PlanarOut = false, the limit is 80.
With Precision = 2 and PlanarOut = true, the limit is 77.

And I think that would be it. For the kind of models I am using, troubleshooting the Y8 and Y16 issues could help to increase performance. I don't think that solving the other issues related to increasing the number of filters or layers could be especially beneficial, because the models would be much slower and the improvement in results would be only marginal. To have the possibility of implementing other more complex networks, a solution would be necessary though.

amayra

24th July 2020, 17:49

@Amayra, just out of curiosity, what would you use this for in VapourSynth? I mean, something that is not possible with AviSynth?
will like my script to be cross-platform and all work in one VS script to run it in mpv

I find VapourSynth faster/stable then AviSynth when it comes to frame interpolation

ENunn

16th September 2020, 03:17

Don't know if anyone here still uses this, but do I have to use a combination of SuperRes and another upscaler to upscale say a 720p source to 4k? If not, how do I make it so that it doesn't scale 2x.
The results are pretty good tbh :P

SaurusX

26th September 2020, 03:13

You can just chain the upscalers together. Call one after the other with whatever sharpening you want between them. Then downscale afterwards to a final 4K res.

tyee

10th November 2020, 18:43

Trying to get this to work in AVS but having problems. I've tried to fix the syntax as best I can but after loading the avs file into Vdub I get this error -

https://i.imgur.com/Mp2lKHT.png

I see the suggested script -

ConvertToShader(1)
Input
Shader("Diff1.cso", Output=2)
Shader("Diff2.cso", Output=3)
Shader("Merge.cso", Clip1=2, Clip2=3, Output=1)
ShaderExecute(last, Input, Clip1Precision=1, Precision=3, OutputPrecision=1)
ConvertFromShader(1)

I'm not sure what "Input" means and whether "1" means precision=1?

Here is my script - I tried to copy another script in this thread.

mov = FFVideoSource("J:\video.mp4")
ConvertToShader(mov)
Shader("G:\Adaptive-sharpen - Pass one.hlsl", Output=2)
Shader("G:\Adaptive-sharpen - Pass two.hlsl", Output=1)
ExecuteShader(last, mov, Clip1Precision=1, Precision=3, OutputPrecision=1)
ConvertFromShader()

Can you see what's wrong?

Alexkral

10th November 2020, 20:52

Try this:

mov = FFVideoSource("J:\video.mp4")
Input = ConvertToShader(mov, 1)
Shader(Input, "G:\Adaptive-sharpen - Pass one.hlsl", Output = 2)
Shader("G:\Adaptive-sharpen - Pass two.hlsl", Clip1 = 2)
ExecuteShader(last, Input, Clip1Precision = 1, Precision = 3, OutputPrecision = 1)
ConvertFromShader()

Default precision in ConvertToShader is 2, so you have to specify it. Default Output on the last shader line is always 1.

tyee

11th November 2020, 06:17

OK, thanks. Tried it and got an error about opening the shader. I removed the "G:\" and copied the .hlsl files to the plugin folder and now it loads fine but the image in Vdub is not the correct aspect ratio (width is 1/2 what it should be) and it's all covered in blue. I think there was something in the instructions about floating point?

Alexkral

11th November 2020, 08:49

Yeah, I guess the shaders are these (https://github.com/bacondither/Adaptive-sharpen/tree/master/shaders). You have to set also precision in ConvertFromShader(1)

tyee

12th November 2020, 01:55

Thanks, I did have the latest but I forgot that (1) on the last line. Works fine now!

butterw2

2nd January 2021, 13:59

I've tried out Avisynth shader on a simple mp-hc video player shader. Any further advice welcome.

Mpc-hc shaders only run in rgb so it is necessary to convert to RGB32 at the input and the output.
It also seems necessary to modify the shader so that it takes bgra as input and output to get correct colors.

sampler s0: register(s0);

float4 main(float2 tex: TEXCOORD0): COLOR {
float4 c0 = tex2D(s0, tex).bgra;
...
c0+= float4(1, 0, 0, 0); //saturate red channel
...
return c0.bgra;
}

Perf overhead: tested on old intel integrated graphics i3-4150,
realtime preview at 720p60 and 1080p25 seem near achievable.
adding Prefetch(2) at the end of the script improves perf slightly but does increase cpu usage.

# AviSynth Shader v1.6.6 with Avisynth+ v3.6.1 x64 on Win10
https://github.com/mysteryx93/AviSynthShader/releases

- The default precision for ConvertToShader and ConvertFromShader is not 1, so you have to specify it.
- The input has to be RGB because otherwise the shader receives YUV channels.
- The first shader receives the channels as BGRA. The last shader has to return them as BGRA for RGB32 by changing the order again, or as GBRA for YV12 or YV24.
- The Alpha channel can be used to pass data between the shaders, but obviously it is lost at the end.

There is no need to compile the shaders.

input = FFMS2("video.mkv", colorspace = "RGB32")

c = ConvertToShader(input, Precision = 1)
Shader(c, "Anime4K_ComputeLum.hlsl", output=2)
Shader(last, "Anime4K_Push.hlsl", Clip1 = 2, output = 3)
Shader(last, "Anime4K_ComputeGradient.hlsl", Clip1 = 3, output = 4)
Shader(last, "Anime4K_PushGrad.hlsl", Clip1 = 4, output = 1)
ExecuteShader(last, c, Precision = 3, OutputPrecision = 1)
ConvertFromShader(last, Precision = 1, Format = "RGB32")

EDIT: My understanding of how avisynth shader works is as follows:
- The input video file (ex: yuv420) is loaded into avisynth (cpu).
- avisynth shader can transfer this to a pixel shader chain (dx9 .hlsl, gpu).
- mpc-hc video player shaders run in rgba. Thus the input has to be converted to RGB first (!!! avisynth shader input/output is in .bgra format meaning the shader code will have to be modified if it performs specific operations on color component).
- it would be possible to write hlsl shaders that run in yuv and you can pass parameters to the shaders via registers.
- the output gets transfered back to avisynth (cpu). The transfers between cpu/gpu have significant overhead, especially at higher resolution.
Further processing can be done in avisynth at input or output.