YAP (Yet Another Player) v0.9.5

[Orf]

Shiandow, thank you very much, this is really helps.
I just wonder again what funny thing life is. The bunch of scripts on a first unenlightened glance hides a really big story beneath them.And I have to admit also you've got really impressing way to express your thoughts. Sometimes I've even remember long forgotten fillings when I was a student on a professors lections

Need some time to think it all over, and if you don't mind may be I'll ask you more later...

[Orf]

YAP 7.3 is out. Bug-fixing release mostly. The renderer was switched from D3D 10.1 to D3D 11 in this version because of upcoming shaders support. Please report if you have any problems in UI/video display areas

foxyshadis,
is this thread splitting thing was really necessary ? I think first two messages in new thread belongs to YAP thread as well as some other stuff there. And IMHO this new thread is starting from nowhere anyway (and probably will ends there too)...

[foxyshadis]

Well, it's your thread, I'll leave it then.

[Orf]

foxyshadis, thanks, I prefer it to stay here, 'cause it easier for me to analyze it this way

[Orf]

Shiandow, is following script syntax looks OK to you ?

; NEDI image doubler
; Copyright by Shiandow
Image1 = NEDI-I(InputImage, InputWidth, InputHeight);
Image2 = NEDI-HInterleave(InputImage, Image1, 2 * InputWidth, InputHeight);
Image3 = NEDI-II(Image2, 2 * InputWidth, InputHeight); 
Image4 = NEDI-VInterleave(Image2, Image3, 2 * InputWidth, 2 * InputHeight);
OutputImage = Resize(Image4, OutputWidth, OutputHeight);

[Shiandow]

Yeah, that looks pretty good. It's pretty similar to how I wrote it with MPDN's Renderscript system, but somewhat more compact.

[Orf]

Shiandow, I think I've managed the way to support it. But other thing still bothers me. As far as I understand both MPDN and MPC-HC use built-in resizer shaders to do final resizing. YAP currently can do only linear filtering resizing. Will it ruin the output of NEDI image doubler or not ? And if so, what should I use instead ? I see your SuperRes pack includes Lanczos hlsl's. Can it be modified to do a general type resizing (not 2x) ?

p/s the general idea is not to use any hardcoded resize shaders, but to allow adding any resizer shaders via YAP interface as well as any other shader packs

[Shiandow]

Well, using bilinear resizing after using NEDI would be a bit of a shame, it would still be better than only using bilinear resizing but for optimal quality you should use a better resizer. There's no reason those resizers have to be hardcoded though, although it's pretty convenient if you don't have to write your own rescalers every time you need one.

Anyway, if you have some system that can support the operations needed to get NEDI to work, then that should also be enough to write scalers. You could adapt those shaders I included with SuperRes, but I think I've also have some other shaders lying around that could more easily be adapted into general upscalers. No downscalers though, I still haven't got round to making one; they require slightly more work.

[Orf]

>>Well, using bilinear resizing after using NEDI would be a bit of a shame

That's what I was afraid of

>>There's no reason those resizers have to be hardcoded though, although it's pretty convenient if you don't have to write your own rescalers every time you need one

May be it is, cause MPDN stores it resize shaders inside password protected zip archive for some reason. Don't know it is a sources or compiled ones

>> if you have some system that can support the operations needed to get NEDI to work

I do not have one. Currently I'm just trying to design and implement one

>>I think I've also have some other shaders lying around that could more easily be adapted into general upscalers

If you can give some example of such an general upscaler it will be very helpful on my current stage

[Shiandow]

Well here's two somewhat general upscalers. The first one scales the input by a factor of 1.5 horizontally and the second does so vertically. It first calculates the position 'pos' in pixels, and then interpolates the value at that position. Since it does horizontal and vertical scaling separately you can only change one coordinate of pos, you can however change that value to whatever you want. For fun try uncommenting "pos.x = pos.x*scale + 10*sin((tex.y + p0[2]/21)*2*acos(-1));" and "pos.y = pos.y*scale + 10*sin((tex.y + p0[2]/34)*2*acos(-1));"

You can make other upscalers by changing the definition of the "Weight" and "taps". I think MPDN and MadVR use precalculated weights, which might be faster if the weights are hard to calculate (like with Jinc), but could be slower if they are easy to calculate (as with Lanczos).

// -- Settings --
#define scaling lanczos

// -- Misc --
sampler s0 : register(s0);
float4 p0 :  register(c0);
float2 p1 :  register(c1);

#define width  (p0[0])
#define height (p0[1])

#define px (p1[0])
#define py (p1[1])

// -- Scaling --
#define scale 1.5

#define bicubic 1
#define MN(B,C,x) (x <= 1.0 ? ((2-1.5*B-C)*x + (-3+2*B+C))*x*x + (1-B/3.) : (((-B/6.-C)*x + (B+5*C))*x + (-2*B-8*C))*x+((4./3.)*B+4*C))
#define MitchellNetravalli(x) (MN(1./3.,1./3.,abs(x)))

#define lanczos 2
#define pi (acos(-1))
#define sinc(x) (x == 0 ? 1 : sin(x)/(x))
#define Lanczos(x) (sinc(pi*abs(x))*sinc(pi*abs(x)/taps))

#if scaling == bicubic
	#define taps 2
	#define Weight MitchellNetravalli
#elif scaling == lanczos
	#define taps 3
	#define Weight Lanczos
#endif

// -- Input processing --
#define Get(x,y) 	(tex2D(s0,float2(px,py)*(pos + float2(x,y) + 0.5)))

// -- Main code --
float4 main(float2 tex : TEXCOORD0) : COLOR {
	// Calculate position	
	float2 pos = (tex*p0.xy - 0.5);
	pos.x /= scale;
//	pos.x = pos.x*scale + 10*sin((tex.y + p0[2]/21)*2*acos(-1));

	// Calculate offset
	float offset = frac(pos.x);
	pos.x -= offset;

	//Scale image horizontally
	float4 avg = 0; 
	float W = 0;
	for (int x = -taps+1; x<=taps; x++) 
	{ 
		float w = Weight(x-offset);
		avg += Get(x,0)*w;
		W += w;
	}

	return avg/W;
}

// -- Settings --
#define scaling lanczos

// -- Misc --
sampler s0 : register(s0);
float4 p0 :  register(c0);
float2 p1 :  register(c1);

#define width  (p0[0])
#define height (p0[1])

#define px (p1[0])
#define py (p1[1])

// -- Scaling --
#define scale 1.5

#define bicubic 1
#define MN(B,C,x) (x <= 1.0 ? ((2-1.5*B-C)*x + (-3+2*B+C))*x*x + (1-B/3.) : (((-B/6.-C)*x + (B+5*C))*x + (-2*B-8*C))*x+((4./3.)*B+4*C))
#define MitchellNetravalli(x) (MN(1./3.,1./3.,abs(x)))

#define lanczos 2
#define pi (acos(-1))
#define sinc(x) (x == 0 ? 1 : sin(x)/(x))
#define Lanczos(x) (sinc(pi*abs(x))*sinc(pi*abs(x)/taps))

#if scaling == bicubic
	#define taps 2
	#define Weight MitchellNetravalli
#elif scaling == lanczos
	#define taps 3
	#define Weight Lanczos
#endif

// -- Input processing --
#define Get(x,y) 	(tex2D(s0,float2(px,py)*(pos + float2(x,y) + 0.5)))

// -- Main code --
float4 main(float2 tex : TEXCOORD0) : COLOR {
	// Calculate position	
	float2 pos = (tex*p0.xy - 0.5);
	pos.y /= scale;
//	pos.y = pos.y*scale + 10*sin((tex.y + p0[2]/34)*2*acos(-1));

	// Calculate offset
	float offset = frac(pos.y);
	pos.y -= offset;

	//Scale image vertically
	float4 avg = 0; 
	float W = 0;
	for (int y = -taps+1; y<=taps; y++) 
	{ 
		float w = Weight(y-offset);
		avg += Get(0,y)*w;
		W += w;
	}

	return avg/W;
}

[Orf]

Thanks, will give them a try tomorrow. But after the first look, a few questions, silly maybe. Based on what I've seen in your and JanWillem32 code.
1) Why width and height scaling should be doing as separate passes (steps) ?
2) I should change "define scale" to DstWidth/SrcWidth or DstHeight/SrcHeight respectively ? This will require to recompile the shader each time. Can we avoid this by defining constant buffer where I will pass DstWidth and DstHeight so shader can use them ? The same goes for bicubic vs lanczos setting
3) "You can make other upscalers by changing the definition of the "Weight" and "taps" ". This phrase is simply goes out of my understanding, sorry

[Shiandow]

1) It isn't necessary to do width and height scaling separately but it's faster. You could do it in one go, which would make the main loop look something like the following:

for (int X = -taps+1; X<=taps; X++) 
for (int Y = -taps+1; Y<=taps; Y++) {
	int2 XY = {X,Y};
	Avg += Get(X,Y)*Weight(XY-offset);
	W += Weight(XY-offset);
}

but this way you'll need to read (2*taps)*(2*taps) pixels, instead of (2*taps) + (2*taps), so doing it in 2 steps will generally be faster. However it isn't always possible to do it in two steps, the most important example is "Jinc" which can't be done in 2 steps, this is the reason that using Jinc in MadVR is so much slower than using Lanczos with the same number of taps.

2) You should indeed change "scale" to DstWidth/SrcWidth for the first shader and DstHeight/SrcHeight for the second one, and it is probably a good idea to use a constant buffer for this. Or you could put the dimensions of the textures in a constant buffer, and calculate "scale" from that. I'm not sure if it is a good idea to use a constant buffer to switch between lanczos and bicubic, if you're not careful the compiler will decide to calculate both and pick the correct one at the end, and to allow the optimizer to do it's job better it's probably a good idea to compile separate versions for lanczos and bicubic.

3) Perhaps this page will help, the thing I call "Weight" is what they call "sample weight" in their plot and "taps" is the maximal "sample distance" for which the "sample weight" isn't 0. For instance, bilinear is 0 when the sample distance is larger than 1 so the number of taps is 1. And the sample weight decreases linearly from 1 to 0 as the sample distance goes from 0 to 1, so the weight is given by: 1 - abs(x). You could then make a bilinear upscaler by taking the shaders I posted and redefining "Weight" and "taps" as follows:

#define Weight(x) 1 - abs(x)
#define taps 1

[Orf]

Shiandow, thanks again, and you was right, all seems to feet surprisingly well in the following scheme:

Shader pack definition file (Lanczos.spk):

; Lanczos resizer shader pack by Shiandow
#define PackType Resizer
Image1 = LanczosW(InputImage, OutputWidth, InputHeight);
OutputImage = LanczosH(Image1, OutputWidth, OutputHeight);

LanczosW.hlsl

// -- Misc --
sampler s0 : register(s0);
float4 p0 :  register(c0);
float4 p1 :  register(c1);
float4 p2 :  register(c2);

#define SrcWidth  (p0[0])
#define SrcHeight (p0[1])

#define px (p1[0])
#define py (p1[1])

#define DstWidth  (p2[0])
#define DstHeight (p2[1])

// -- Scaling --
#define scale DstWidth / SrcWidth

#define pi (acos(-1))
#define sinc(x) (x == 0 ? 1 : sin(x)/(x))
#define Lanczos(x) (sinc(pi*abs(x))*sinc(pi*abs(x)/taps))

#define taps 3
#define Weight Lanczos

// -- Input processing --
#define Get(x,y) 	(tex2D(s0,float2(px,py)*(pos + float2(x,y) + 0.5)))

// -- Main code --
float4 main(float2 tex : TEXCOORD0) : COLOR {
	// Calculate position	
	float2 pos = (tex*p0.xy - 0.5);
	pos.x /= scale;
//	pos.x = pos.x*scale + 10*sin((tex.y + p0[2]/21)*2*acos(-1));

	// Calculate offset
	float offset = frac(pos.x);
	pos.x -= offset;

	//Scale image horizontally
	float4 avg = 0; 
	float W = 0;
	for (int x = -taps+1; x<=taps; x++) 
	{ 
		float w = Weight(x-offset);
		avg += Get(x,0)*w;
		W += w;
	}

	return avg/W;
}

LanczosH.hlsl

Omitted. The same principals used as in LanczosW.hlsl

P/S Need to do a lot of code changes and testing to give more feedback... Can take some time...

[Orf]

Shiandow, about this upscalers vs downscalers thing. Did you meant that lanczos is no good for downscaling at all ? Or you meant there's better algorithms for that, but it can be used too ? If image processing chain should have abilities to use different shader packs for upscaling/downscaling/pre resizing/post resizing, this will result in pretty complex scheme that user will have to setup in the end. How do you think, is this setup can be simplified to use fixed upscale=pre resize, downscale=post resize shader pack applying scheme ?

[Shiandow]

No I just find downscalers slightly more annoying because you're no longer summing a fixed number of pixels. Anyway, you can use lanczos for downscaling, although most people seem to prefer mitchell-netravalli or bicubic. I agree that you can get quite a complicated scheme if you need to configure every processing step, but I don't really know a good way around that, having good defaults will probably help.

[Orf]

Since I'm kind of out of tune on the theme myself, I can only try to make some constructor for adding custom shaders or shader packs. Defaults, when it seems most everyone have different preferences ? I simply don't know them... May it will be better if I'll make some preview version that shows my vision on how that constructor should look like, care to take a look, try to add some shader code may be, and discuss it then ?

[Shiandow]

If you have an idea for what it should look then of course I could have a look at it. Picking sensible defaults is probably not that difficult, I think it will be harder to allow people to do understand how to do anything that isn't the default. MPDN's renderscripts have a similar problem, it's very hard to make clear how and when to use which processing.

[Orf]

Yes, and I hope this interface will be ready soon. And before it will be released, just want you too look at it critically, may be I've missed something important, may be it can be improved to be more clear from end user point of view. And yes, I've tried to look on how it is done in MPDN, and can't even get a clear picture on how it supposed to work...

[Anima123]

I'd say putting Siandow's diagram as part of the setting interface would be great.

[Orf]

Anima123, why do you want this ? I think diagram is not a part of shader setting process from user perspective. Its only might be interesting for shader pack developers