AviSynthShader + SuperRes

[CkJ]

Originally Posted by MysteryX

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.

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.

[musicvideos4k]

Originally Posted by CkJ

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]

Originally Posted by CkJ

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]

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]

This time i did remove all non-relevant posts. I gave musicvideos4k a long weekend off.

[Alex-Kid]

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]

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]

Originally Posted by Alex-Kid

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]

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]

Try with PlanarIn=false, PlanarOut=false

It only requires DX9; but some graphic cards don't support single-plane textures.

[MysteryX]

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!

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]

@MysteryX

Your last posts resolved the issue, thank you!

[Flux]

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]

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.ph...82#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/aqlcgzdsh76...0r2172.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-arti...ase-Notes.aspx

[Flux]

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]

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]

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.

[musicvideos4k]

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]

Originally Posted by Flux

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]

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.