madVR - high quality video renderer (GPU assisted)

[NicolasRobidoux]

Mathias:
I know everybody throwing UI requests at you, but IMHO one knob for deblur (even when using tensor methods) set at 1 by default (which you could call 100, although going over 100 is OK) with tensor methods, and possibly at .98... (or 1, really) for EWA, and one knob for sigmoidization, set at 0 when downsampling and 11.5 (or 10, which you could call 100, and again it can go over 100) would satisfy the tweaking needs of many people.
If you prefer defaults that are set "at the center", you could call deblur 1 "50", and you could have sigmoidization 11.5 (or 10) be called "50" as well. Gives a better idea that it can go up as well as down.
Something like that.
Then, someone who wants something sharper when enlarging could quickly play with the deblur and the sigmoidization level.
Or vice versa: Someone wanting some denoising or whatever.
Warning: Although I am not sure, there is some pretty strong evidence that the default sigmoidization when downsampling significantly should be 0.
You probably got the message reading my various ImageMagick writings.
P.S. Just dawned on me that allowing the deblur to go over 1, be it tensor or EWA, would probably mess up your code, since at some point your stencil will start touching more pixels, as if you were downsampling.
So maybe 100 = 1 for tensor methods = .98... for EWA ones is a better choice.

[NicolasRobidoux]

Mathias:
If it makes your life easier, you can use 0.9891 instead of the whole billion digits number. Nobody will see the difference chopping off a few digits.

[NicolasRobidoux]

Mathias:
After thinking about this for a while, I've decided that the solution to the out of gamut issue most likely to work best is to extend the sigmoidal with straight lines at the limits of the gamut.
Will work on this later. Grad student just knocked on my door.

[madshi]

Not sure what you guys want to achieve but you could modify the atanh to fit every range (a, b): atanh_mod(x) = log((a + x)/(b - x))/2. If a and b are known this is really cheap.
Nah, that's too easy... :D

Seriously, I'm not sure if I generally like the idea to fit the range because I fear it might change the look of the image somewhat. So I think I'll rather do special processing for those values outside the valid range.

You are aware that there is a discussion of exactly this in "The Recommendations", yes?
Not really, but I've read it now, thanks.

Here is a better idea, inspired by yours (and somewhat reminiscent of the sRGB handling of the gamma curve's slope singularity at 0): Extend the curves past 0 and 1 with straight lines (which I feel like an idiot not having thought of before).
Do you think this is better in terms of quality? Or do you think it would be easier for my shader code? I've already implemented the mirroring and it's pretty easy to code. Ok, doing a straight line would be possible, too, but it wouldn't make the code any simpler. It might even be more complex. So I'm wondering whether you think using a straight line would give better results?

I know everybody throwing UI requests at you, but IMHO one knob for deblur (even when using tensor methods) set at 1 by default (which you could call 100, although going over 100 is OK) with tensor methods, and possibly at .98... (or 1, really) for EWA, and one knob for sigmoidization, set at 0 when downsampling and 11.5 (or 10, which you could call 100, and again it can go over 100) would satisfy the tweaking needs of many people.
If you prefer defaults that are set "at the center", you could call deblur 1 "50", and you could have sigmoidization 11.5 (or 10) be called "50" as well. Gives a better idea that it can go up as well as down.
Something like that.
Then, someone who wants something sharper when enlarging could quickly play with the deblur and the sigmoidization level.
Or vice versa: Someone wanting some denoising or whatever.
Warning: Although I am not sure, there is some pretty strong evidence that the default sigmoidization when downsampling significantly should be 0.
You probably got the message reading my various ImageMagick writings.
P.S. Just dawned on me that allowing the deblur to go over 1, be it tensor or EWA, would probably mess up your code, since at some point your stencil will start touching more pixels, as if you were downsampling.
So maybe 100 = 1 for tensor methods = .98... for EWA ones is a better choice.
Having a blur/sharpen slider that works for *all* algorithms is more attractive to me than having it just for one algorithm. So now that I understand how I could implement such a slider for all algorithms, maybe I'll actually implement it. I'm not sure if I should do that for sigmoidization, too. I'm already have people asking left and right here in this thread which resampling settings they should use, and that without such added sliders.

Generally, I believe video playback is somewhat of a different animal compared to video encoding (avisynth) or photo editing. With both video encoding and photo editing, you might want to have sliders so you can fine tune the resampling algorithm to the video/photo at hand. However, video playback is somewhat different. Most madVR users just use madVR for simple playback, playing one movie after the other. They don't really want to tweak settings specific to one movie. Because of that I kind of doubt the usefulness of having a multitude of sliders. Ideally, I'd like to reduce the scaling settings page in madVR to just one slider which allows the user to choose between sharpness and being artifact-free. But right now that's not possible, too many choices. And currently it's all still too much a matter of taste. Furthermore not all GPUs can do all algorithms in realtime, so I still have to offer so many alternatives. Still, I already find the settings too complicated right now, so I'm really afraid of adding even more settings.

As you mentioned before, maybe an expert/noob settings switch could be the solution, but I don't have such a switch yet, and I don't have the time to implement it now. Soooooo many other things I still have to do which are way more important. So for now I guess I'll just add a simple checkbox for sigmoidization with a fixed contrast value, and I'll leave everything else (including a blur slider) for later.

If it makes your life easier, you can use 0.9891 instead of the whole billion digits number. Nobody will see the difference chopping off a few digits.
It's just a constant in my shader code, so the number of digits makes no difference.

[madshi]

@blackjack12:

good news. After replacing my old Radeon 3850 with a brand new 7770 today, I'm now able to reproduce the issue you reported. Fixing this should be relatively easy now (I hope). No more feedback needed from you for this problem!

[Pat357]

I have a little problem:
I created a custom resolution with 59,94 Hertz and added it and the native 60 Hertz resolution to the madVR display modes list (both 1280x1024).
It works well with 720p59,94 and 1080p60 videos but for a 1080p59,94 it refuses to choose 59,94 Hertz. :(
What's going wrong?
I had the same problem today, until I noticed that the filename contained "60p". This overwrites the 59.94Hz and Madvr will switch to 60Hz instead of 59.94.
After renaming (delete "60p"), I got 59.94, just like it should :)

[TheLion]

Seriously, I'm not sure if I generally like the idea to fit the range because I fear it might change the look of the image somewhat. So I think I'll rather do special processing for those values outside the valid range.



Would it make your life easier to simply discard any BtB values, as these shouldn't/must not be displayed anyway when properly calibrated. "Above White" is different because those values are supposed to be displayed (=give a bit more contrast headroom).

[TheLion]

Having a blur/sharpen slider that works for *all* algorithms is more attractive to me than having it just for one algorithm. So now that I understand how I could implement such a slider for all algorithms, maybe I'll actually implement it. I'm not sure if I should do that for sigmoidization, too. I'm already have people asking left and right here in this thread which resampling settings they should use, and that without such added sliders.


I for one would welcome such a "blur/sharpen" slider for *all* algorithms very much. This may even avoid some "which option is best" questions as it is much more simple to grasp than methods like bicubic versus Lanczos versus Jinc.. "Just use the algorithm which fits your GPUs performance and decide the "sharpness" to your liking"

But I also understand your predicament with overloading the UI and users minds by too many choices :sly:

[madshi]

TheLion, I thought you wanted to refrain from further wishes, so you wouldn't delay other features like custom shaders and 3D? :p And no, it wouldn't avoid any questions *at all*, because Bicubic and Lanczos and all the other things would still be there, as well.

[NicolasRobidoux]

I've had another idea on how to fix the "out of gamut" issue: For values outside the valid range I could practically mirror the sigmoidization S curve. Meaning e.g. for values "> 1" I would do "2 - value" before *and* after sigmoidization. And for values "< 0" I could do "abs" before sigmoidization and then simply restore the "-" sign after sigmoidization. What do you think?I hate it (pardon my French).
For many many reasons, one of them being that it introduces a "corner" in the curve pretty much at the last place where we want one.

[Pat357]

Will read the rest after making coffee for my wife!


Some things are different around here : my wife makes coffee for me ! ;)
:p

[TheLion]

TheLion, I thought you wanted to refrain from further wishes, so you wouldn't delay other features like custom shaders and 3D? :p And no, it wouldn't avoid any questions *at all*, because Bicubic and Lanczos and all the other things would still be there, as well.

You are right, very convincing argumentation. Consider me dead silent :sly:

[madshi]

I hate it (pardon my French).
For many many reasons, one of them being that it introduces a "corner" in the curve pretty much at the last place where we want one.
Maybe I'm being stupid, but why would there be a corner? Please note that I'm mirroring the S-curve in both X and Y directions.

[Pat357]

Maybe I'm being stupid, but why would there be a corner? Please note that I'm mirroring the S-curve in both X and Y directions.
Wouldn't concave/(convex) become convex/(concave) by this ?

[NicolasRobidoux]

Maybe I'm being stupid, but why would there be a corner? Please note that I'm mirroring the S-curve in both X and Y directions.
I suck. No corner.
Even then, I really don't like the change in concavity.

[NicolasRobidoux]

I'm still thinking about this, and I'm close to my "best quick proposal".
(Ignore everything I've written so far. I think what I have is a cleaner, more likely to robustly give give good results in the presence of somewhat large possible overshoots and somewhat small possible undershoots, that takes the HVS and higher sensitivity to darks into account.)

[madshi]

Maybe I'm not explaining things properly. What I'm doing right now is pretty much this:

http://madshi.net/sigmoidalMirroring.jpg
The valid range is [0, 1]. BTB and WTW can roughly be in the range of [-0.003, 1.2].

[NicolasRobidoux]

Mathias:
I understood. (Even though my "mind plotting" put a corner where there is none.)

[Pat357]

Maybe I'm not explaining things properly. What I'm doing right now is pretty much this:

http://madshi.net/sigmoidalMirroring.jpg
The valid range is [0, 1]. BTB and WTW can roughly be in the range of [-0.003, 1.2].

Just as I thought : change in sign from the second derivate on 0 and on 1
Concave -> convex on 0 and 1.

Mathias : original curve :values y become closer to each other when x is coming closer to 0; this is not so for the "mirrored curve, as the y values go further apart when x is becoming smaller.(more negative)
The same happens for x=1

[madshi]

Yeah, there's a change from concave to convex, but what else could we do? At 0.0 the curve is almost a horizontal line. If we try to add a straight line to cover values < 0.0 then there actually *will* be a corner. The only proper way to continue the curve < 0.0 without changing from concave to convex and without adding a corner would be to make the line totally horizontal. But that would be identical to simple clipping, which is not what I want to do.

Another option would be to change the S-curve to cover out-of-range values. But I would really like to avoid that. I'd like the S-curve to perfectly cover the valid values, so that they get the best treatment.

[TheLion]

Yeah, there's a change from concave to convex, but what else could we do? At 0.0 the curve is almost a horizontal line. If we try to add a straight line to cover values < 0.0 then there actually *will* be a corner. The only proper way to continue the curve < 0.0 without changing from concave to convex and without adding a corner would be to make the line totally horizontal. But that would be identical to simple clipping, which is not what I want to do.

Another option would be to change the S-curve to cover out-of-range values. But I would really like to avoid that. I'd like the S-curve to perfectly cover the valid values, so that they get the best treatment.

I don't want to disturb the "big boys while playing" but this approach makes perfect sense me.

[NicolasRobidoux]

Mathias:
This is not what I'm about to propose (which I suspect you won't like), but if you have the straight line have the slope of the sigmoidal at the attachment points you don't introduce a corner, and you don't change convexity (although there is a jump in second derivative, which is clamped to zero; note however that "^" has constant convexity, even though it does not even have a matching slope at the corner).

[NicolasRobidoux]

I do admit, however, that the right straight line segment will hit 1.2 in a galaxy far away.

[NicolasRobidoux]

I'm OK with light and dark being treated somewhat asymmetrically, esp. if A is closer to 0 than B is to 1, which it is.
Because we are more sensitive to slight dark variations.
The point is not to throw perceptual color spaces, like sRGB, out the window, it is to tame their extreme interaction with negative lobes.
So yes, my upcoming suggestion is not "perfect" but I think it may give better "worst case scenario" results, and good results overall.
I actually was wondering before all of this whether I should break the perfect symmetry between 0 black and 1 white.
Well, now I have to.

[madshi]

But isn't the slope of the sigmoidal at the attachment points very very nearly zero? Meaning the straight line would be almost horizontal? I'm wondering how far away such an approach would be from simple clipping?

[NicolasRobidoux]

It is nearly horizontal when using contrast=11.5.
However, we're working with floating point arithmetic, so it's not the same as clipping, because it IS reversible.
Analogy (with no sigmoidization):
Multiply your x values by 10^-10 before entering the process, and multiply the final result by 10^10 at the end.
You'll get the same as if you don't, because linear filtering "commutes" with affine transformations.
It's like a change of units.
---
So, extending the sigmoidal curve with straight lines with matching slopes is like a very drastic change of units, like going from meters to parsecs, or from 8-bit to 16-bit.
It's still just a change of units.
Which is why this is my second best fix.

[NicolasRobidoux]

Just to make sure: You're using regular floats or doubles, yes?
This is not fixed point arithmetic.
Or are results clipped at some intermediate stage?

[NicolasRobidoux]

Mathias:
I remembered some simplifications that I could not use with ImageMagick.
My next suggestion will be much cheaper, provided I am using "real floating point numbers".

[madshi]

It's all IEEE 32bit float ("s23e8"). No doubles. Curious to hear about your suggestion... :)

[Moony349]

For advanced settings; rather than take the time to modify the UI, maybe an ini file would work? That way, the "hardcore" could customize all of the variables to their liking while the "softcore" wouldn't be overwhelmed because they wouldn't see the variables in the first place.

On another note; DVD subtitles through xy-vs filters look horrible and I would love to be able to sigmoidify/image wizardry calculus trig idk I just want to watch pretty things upscale those too :) Obviously, not a priority.

[blackjack12]

@blackjack12:

good news. After replacing my old Radeon 3850 with a brand new 7770 today, I'm now able to reproduce the issue you reported. Fixing this should be relatively easy now (I hope). No more feedback needed from you for this problem!

Great...

This is exactly what I see on my systems. Old "legacy" Radeon 4890 works without issue with the latest builds, the newer 6570 is where problems are seen.

Also seeing issues on my NVidia 560Ti but I think if you find the core issue on your Radeon 7770 system it is the same thing.

Keep up the great work and look forward to your "fixes" and updates.

[NicolasRobidoux]

===============================================
Sigmoidization with over and undershoots HOW TO
===============================================

by Nicolas Robidoux, Grand Poobah of the Sacred Order of EWA and
Sigmoidiza. (Heed or else!)

Suppose that we have one channel of image data x which is
strongly constrained to the closed interval (endpoints included)
[A,B] (madshi tells me that, roughly, [A,B]=[-.0003,1.2]) and
which can reasonably be interpreted as one component of linear light.

No need for a fudge factor: Hitting A or B is fine.

First, choose a contrast. Like in the ImageMagick code, let's call the
contrast "a". a should be a float > 0. As a approaches 0,
sigmoidization has less and less of an effect, so you may as well
short circuit it out. I generally like values between 7 and 12 with the
sigmoidal-contrast function that corresponds the [A,B]=[0,1]. With a
different [A,B], different contrast may be best. (I may produce a
private version of ImageMagick to see what happens. I have not yet,
so this advice is made "blindly".)

Set

s = tanh(0.25*a)

Step 1:

First, the description that is there to connect with the earlier way:

Convert your input to the "sigmoidal color space", that is,
"replace" every x by the value y computed as follows:

y = 0.5 + (2.0/a) * atanh(-s+(2.0*s)*(x-A)/(B-A))

= 0.5 + (2.0/a) * atanh(s*((A+B)/(A-B))+(2.0*s/(B-A))*x)
<- multiply-add inside

If your original x was in [A,B], y is in [0,1].

Now, we are in the "normalized sigmoidal color space".

---

However, we "live in a floating world":

If you are actually storing "standard signed floats", not some sort of
fixed point floats that are clipped to [0,1] or something like that,
there is a greatly simplified formula because I don't need to make sure
I stay within [0,1]. Here is this simplified version. (I also take
into account the fact that there is no direct atanh, and the fact that
there are more output pixels than input pixels since we are enlarging,
so I want to push operations "toward the front" if possible.)

With the same s as before (which is a constant), just store:

y = atanh(b+m*x)

where

b = s*((A+B)/(A-B))

and

m = s*(2.0/(B-A))

and

atanh(x) = 0.5*ln((1+x)/(1-x))

Step 2:

Upsample as usual, using the y values. Let's say that we get a pixel
value of w.

Step 3: Convert w back to "linear color space":

z = tanh(w)

final value = -(b/m) + (1/m)*z

Only clamp if you want to. Step 3 does not care about what interval w
is in.

-----

There you have it:

With the small image: one multiply-add, then one add, one subtract,
one divide, one natural log, and one multiply.

Then the usual upsampling by filtering

With the large image: tanh, then another multiply-add.

That's it.

-----

I'm not 100% sure that this will always look better (once we find the
right contrast) than the straight line extension approach, but I
bet my Grand Poobah insignia that it usually does.

It's kind of a mixed perceptual/symmetrizing/pragmatic sigmoidization
approach. Which boils down to the standard one when [A,B]=[0,1].

[madshi]

Thanks, Nicolas, I appreciate the time you invested into this!!

Is this new stuff different to your original idea to stretch the S curve to cover the extended value range? Is the curve still a perfectly symmetrical S curve? Or does the curve have a somewhat different form now?

[strumf666]

Don't want to sound too impatient (but I am), some test build please? ;)

[sneaker_ger]

On another note; DVD subtitles through xy-vs filters look horrible and I would love to be able to sigmoidify/image wizardry calculus trig idk I just want to watch pretty things upscale those too :) Obviously, not a priority.

Since xy-vsfilter directly renders onto the picture before madVR gets the subtitles, I don't think madshi can do anything about it. There is a custom subtitle pin for madVR+xy-vsfilter in the works but not yet released. Once it is ready it could be done, but I think it would be the task of the xy-vsfilter team, so you should propose there if you have any ideas on how to make low resolution DVD subtitles look good on HD displays.

[NicolasRobidoux]

I expect that slightly larger contrasts will be desirable with the new sigmoidization.

[sunnah]

Dear Madshi or anyone who could answer my question,

I didn't find the reason in this forum yet, but why was SoftCubic 100 recommended for Chroma upscaling?

[Asmodian]

Here (http://forum.doom9.org/showthread.php?t=146228&highlight=SoftCubic+chroma&page=682) is a big discussion about chroma scaling from this thread. It offers lots of different reasons for different resizers but there really isn't a "correct" answer. There are trade-offs for any option. That said I have been impressed by the new options being worked on, if you have the GPU to handle them.

I don't agree with the poster named "6233628" (I think the choice for chroma is also just a recommendation) but they do offer good examples. Note these are worst case examples that show the issues with softcubic that 6233628 doesn't like.

A great quote from madshi himself:

Since all resamplers have their strengths and weaknesses, it's all a matter of taste, as has been said many times in this thread. SoftCubic blurs (= desaturates) chroma, so what? Lanczos rings and Mitchell-Netravali shows aliasing. None of these algorithms is perfect. From my point of view, the chroma channels are often those with the biggest aliasing artifacts (very much depending on source, though), and SoftCubic helps a lot there. But I know it's just my point of view and I know 6233638 has a different opinion. That's why all these are options and everybody can choose what they like best. Depending on the content you use for showing differences, some algorithms will look better than others. If you want to show how bad SoftCubic is for chroma upsampling, choose a sample where blurred chroma is especially obvious. If you want to show how bad Mitchell-Netravali is, choose a sample where aliasing is especially obvious. Maybe there'll be a clear "best" algorithm for chroma upsampling in the future, but I don't think there currently is. You just have to pick your poison on which strengths/weaknesses are most important to you.

[turbojet]

Creating a different advanced/simple user interface would take hours, days even. Just adding a blur parameter would not take that long, of course. But just adding a dropdown and label etc isn't all there is to it: I'd have to:

(1) Extend the settings records.
(2) Modify madVR to read, write, understand and use the new setting.
(3) Probably add a toggle keyboard shortcut.
(4) Make sure the setting is only available for cubic algorithms.
(5) Change my resampling weight calculator to support custom blur.
(6) Think about how to make the dropdown work with Bicubic, SoftCubic, CatmullRom and Mitchell. Using the same blur value for all wouldn't work because they have different blur values on their own. Of course it would be possible to limit negative blur capability to Bicubic, only.

All added up it might easily take 2-3 hours. More if I'm stupid and introduce bugs. Add to that that the user interface gets more complicated again, which means that new users will ask not only "which is the best algorithm" but also "which blur factor should I use" etc.

I didn't realize it would take so long but makes sense now. Blur would just be another variable and wouldn't it have the same answer as to the same questions today, find the best for your eyes?

I prefer the idea to offer a fully configurable cubic resampler, which could replace all the other cubic based algorithms (Mitchell, Bicubic, Catmull-Rom, SoftCubic). But then, that would definitely be a settings for experts, only, and will have to wait until I have separate beginner/expert settings.

I agree but didn't know you were going to do a beginner gui, adding one more variable to bicubic and removing 3 resizers I would think make the gui simpler.

I somewhat agree, but you can't run avisynth scripts *after* scaling, when using madVR, so shaders have their use. Also GPUs get much faster every year, while CPUs get only slightly faster. So I think in the long run it makes sense to run these kind of algorithms all on the GPU. Furthermore: If you have a good GPU, you can run algorithms on it which avisynth scripts couldn't do in realtime on a CPU. Whether it is easily possible to convert such complex avisynth scripts to a GPU shader is another question, though.

True but APU/SOC are becoming more and more popular as desktops dwindle and we have yet to see windows 8 tablets plus there's one big road block in the not-so-distant future, 4k displays. I had asked about running avisynth scripts after resizing but the gpu -> cpu -> gpu looked like a resource hog, maybe I'm wrong. Wish you good luck with a good sharpening and/or deband shader as currently the options are abysmal.

I was mainly thinking about HDMI 1.4 frame packed output. That will not be easy because all ATI, Nvidia and Intel have custom development solutions for that. But this should be the ultimate goal. Doing SBS or Top/Bottom is kind of yesterday.

Oh okay, not very familiar with 3D stuff, like many, it gives me a headache and I'll never choose it when given the choice.

It is not uninteresting, but I much prefer Lanczos or Jinc over Bicubic with negative blur. Bicubic has too much aliasing for my taste.

I somewhat agree on Jinc but I cannot stand Lanczos on video anymore. It adds a lot of dots to faces which aren't in the source, also happens on some flat surfaces, jinc greatly reduces this. Bicubic is cleaner but blurs away some face textures when it's set to 0. It's all academic though as Jinc and Lanczos aren't usable without dropped frames in my situation. In the parking meter test the bicubic-1 words are more legible then the others and there's textures (especially in top left of the meter) that are much tougher to see with jinc, lanczos3, lanczos4, bicubic0. The little amount of aliasing doesn't bother me nearly as much as the softer picture. However if it would have been 4x downsize I'd put bicubic-1 last, there's way too many artifacts on large downsizing because of the lack of blur.

Look, if I knew a way to support negative blur without making the settings dialog more complicated, I would consider it. Maybe I will add it in the future when I find the time to do separate settings dialogs for noobs and experts. But for now I don't want to implement it because I don't want to spend that time and because I don't want to make the settings dialog more complicated. Just have a bit of patience.

Okay good, the last post seemed like you were writing it off. It's not something I need this week, month or even year. I'll wait patiently, thanks!

[DragonQ]

So Jinc is the best scaler when combined with anti-ringing, right? My chroma upsampler is still set to bicubic 75, as it has been for ages - is it worth using anti-ringing with this too?

[Asmodian]

There is no best but I do like Jinc + anti-ring though it keeps my GTX 680 a lot more active. :D

Bicubic doesn't ring (much?), it's problem is more with aliasing.

[NicolasRobidoux]

Is this new stuff different to your original idea to stretch the S curve to cover the extended value range? Is the curve still a perfectly symmetrical S curve? Or does the curve have a somewhat different form now?The curve is still a perfectly symmetrical S curve over the interval [A,B], not over [0,1], unless -A=B-1. So, I believe the answer to the first question is "no", the answer to the second is "yes, but maybe not the way you understand it", and to the third, "no, in a sense, but also yes, in a sense".
Although this is different than the sigmoidization I've used, I think that actually this may work better than any other fix because of the fact that conversion from Y'CbCr over and undershoots when converted to linear RGB.
I really do. I don't want to go into a big lecture as to why, because the proof (or disproof) will be in the pudding.
However, I'll also do the math for the fix that extends the S in a straight line past [0,1], in case you want to try that too. That would be my "second best fix".
I really really don't like the mirroring solution.

[cyberbeing]

NVIDIA pushed out new WHQL drivers supporting all cards yesterday.

306.97 WHQL English (WinVista/Win7/Win8 x64) (http://www.nvidia.com/object/win8-win7-winvista-64bit-306.97-whql-driver.html)
306.97 WHQL International (WinVista/Win7/Win8 x64) (http://www.nvidia.co.uk/object/win8-win7-winvista-64bit-306.97-whql-driver-uk.html)

306.97 WHQL English (WinVista/Win7/Win8 x86) (http://www.nvidia.com/object/win8-win7-winvista-32bit-306.97-whql-driver.html)
306.97 WHQL International (WinVista/Win7/Win8 x86) (http://www.nvidia.co.uk/object/win8-win7-winvista-32bit-306.97-whql-driver-uk.html)

306.81 WHQL English (WinXP x86) (http://www.nvidia.com/object/winxp-306.81-whql-driver.html)
306.81 WHQL International (WinXP x86) (http://www.nvidia.co.uk/object/winxp-306.81-whql-driver-uk.html)

[6233638]

I don't agree with the poster named "6233628" (I think the choice for chroma is also just a recommendation) but they do offer good examples. Note these are worst case examples that show the issues with softcubic that 6233628 doesn't like.I still maintain that there's not much to choose from with Chroma. The purpose of Chroma upsampling is only to get the best match to the Luma image, and it is always 2x scaling. You don't use Chroma upsampling to tailor the look of the image to your personal preference the way you might decide to use a softer/sharper Luma algorithm depending on your preference for sharpness, tolerance for ringing/aliasing etc.

If you use a chroma algorithm that is too soft, colour bleeds out the edges of objects, and the brightness/saturation is reduced. (particularly with finer details) If you use one that is too sharp, objects can be brighter than they should be, and ringing becomes a problem. I've still never seen a sample from anyone using SoftCubic for Chroma that actually shows it to be beneficial, and I must say that I find it extremely rare for aliasing to be a problem with chroma. (at least using an algorithm that suffers from aliasing, nothing will fix it if it's a part of the source)


I've actually been doing testing again recently due to the introduction of the anti-ringing filter. (and actually, have reviewed it a couple of times in the past - I don't think the post you linked to was the most up-to-date)
I didn't really want to post anything yet though, because I haven't had the time to really look into it yet, and there has been a lot of interesting discussion regarding the scaling algorithms recently. (and technical discussion that is beyond me - my choices are based on observations and measurements from the final scaled images)
It sounds like there could be some interesting developments in the near future, which I didn't want to detract from, nor did I want to write up a big post that could be outdated pretty quickly.

For what it's worth though, the anti-ringing filter has noticeably changed the results - I'm actually quite liking Lanczos 3 with it so far with all the samples I've tried, but that is from very incomplete testing. I'm quite sure there will be samples where Lanczos is too sharp, and that I just haven't run into them yet.
I don't know that I'm a fan of Jinc for Chroma though. There has only been one sample I've tried where it has looked best, and there were some noticeable drawbacks.

[trip_let]

I know that the focus right now is on greater things, but can anybody else check and confirm? MadVR does not work when the player is on a monitor in portrait mode for me (I've tried in previous versions as well as the most recent one, with MPC-HC; using Mobility Radeon HD 3650).

Seems like there have been a couple previous posts in this thread about this issue, but I did not find any resolution:

Okay, I'm using MadVR v0.74. I notice that when I use it in conjunction with MPC-HC and the latest version of FFDShow when I try to open a videoon or drag it to my portrait monitor MPC-HC freezes and forces me to end the process in the Task Manager (windows 7 and amd 6950 if that matters). Here's how it's set up:

http://img683.imageshack.us/img683/7114/madvr.png
[removed image tags so it doesn't hog the page]

Everything works fine when switching to EVR Custom. I don't know if there is something wrong on my end but it seems that this version has an issue rendering a file on a portrait set display.

Anyone else have this issue?

madshi, when you get to it please check if it's possible to make madvr work with the native Nvidia Rotation from the driver.
Basically how to reproduce the issue is to right-click Desktop, go to Nvidia Control Panel, Rotate Display, and pick e.g. Portrait (flipped).
Then when playing with madvr the picture is just black, sound is ok.
Thanks.

For me, it doesn't crash. The screen is just black, and it doesn't play. If a video is playing on another monitor and is dragged to one in portrait, it will go black and pause the video without crashing. So there's no sound for me either. Playback can resume if the player is moved back to a landscape-orientation monitor. Likewise for me, it works with the other MPC-HC renderers, just not with MadVR.

Portrait / landscape can be set in AMD / Nvidia control panels or Windows "screen resolution" page.

To be honest, I actually have some 256 x 384 content that could really use some high-quality upscaling to 1080 x 1620 size on a 1080p monitor. Well, having normal 4:3 / 16:9 content also work would be nice too, for whenever my main monitor is set to portrait (of course, changing the orientation and physically rotating the thing does not take more than half a minute, but still...). :o

[sunnah]

Here (http://forum.doom9.org/showthread.php?t=146228&highlight=SoftCubic+chroma&page=682) is a big discussion about chroma scaling from this thread. It offers lots of different reasons for different resizers but there really isn't a "correct" answer. There are trade-offs for any option. That said I have been impressed by the new options being worked on, if you have the GPU to handle them.
:
Yes I have a really High-End GPU, I just want to use the most efficient option that's available. But as madshi already said: most taps doesn't mean directly being the best. (because of the added ringing even with anti-ringing) Altough the anti-ringing option is a true blessing in madvr now
There is no best but I do like Jinc + anti-ring though it keeps my GTX 680 a lot more active. :D

Bicubic doesn't ring (much?), it's problem is more with aliasing.
I think we should encourage people more to go after their own taste. I personally like Jinc 4 taps + anti ringing, 8 taps is a little too much ringing in my opinion. The sharpness difference between the two is almost forgetable. If some people are doubting look for the less ringing option. And of course you have to look at your GPU too.

[Asmodian]

I think we should encourage people more to go after their own taste. I personally like Jinc 4 taps + anti ringing, 8 taps is a little too much ringing in my opinion.

True, and that is what I am using too. ;)
tbh, Jinc 8 taps + anti-ring is too much for my video card (GTX 680) doing 720p/1080p -> 2560x1440.

I still maintain that there's not much to choose from with Chroma.

I did take your advice and try bicubic 75 and Mitchell-Netravali. I liked them and used bicubic 75 until recently, trying 3 tap Jinc + anti-ring for chroma now. I am just not convinced there is really a correct method. :)

[ajp_anton]

Nicolas &... um... Mathias? =)
If the curve only is defined in [0,1], then I don't see the problem with clipping. Introducing a new curve for out-of-range values seems kind of arbitrary, and there's the convex/concave problem.
Of course, I'm no expert on this, and I haven't even tried it myself. But it "feels" better to just extend the [0,1] input range to cover all possible values. Would that make it look weird? Or just clip it =).

[ryrynz]

Nicolas &... um... Mathias? =)

LOL, hey now.. He's Madshi to us. Maybe when you reach NicolasRobidoux's level you can get away with being on a first name basis :D

[NicolasRobidoux]

The issue is where the BTB and WTW come from, and what is done with them.
Which I don't fully understand, so I have to go with my guts.
-----
When solving real world problems, math should shadow the world, not the other way around.
Cows are not spheres, (ir)regardless of how elegant the proof becomes with this assumption.

The Grand Poobah of Postmodern Mathematics and Other Fuzzy Religions

P.S. The sigmoid curve is a tool, not a prescription. Once you (meaning me) have decided that the way to deal with over and undershoots is more or less to stretch things exponentially near gamut extremes, it's a way of piecing two exponential curves smoothly given that one of them is upside down.
Maybe piecing two gamma curves or other power laws would be better. Actually, I may have to try just that: Symmetrize a pair of gamma curves.
Or something that evenly spreads over and undershoots computed explicitly from the filter kernel. (Numerical math nightmare.)
Maybe. But the sigmoid curve seems to work well. Better than a few others I quickly tried. Probably cluelessly.