madVR - high quality video renderer (GPU assisted)

[NicolasRobidoux]

Originally Posted by madshi

I don't think it has anything to do with the anti-ringing filter. Try it without, you'll see similar results. Jinc simply looks different because it's a circular resampler compared to rectangular Spline or Lanczos. Jinc does look softer in some situations, but on the positive side it has noticeably less aliasing than even Lanczos. I already mentioned in my v0.84 announcement post that Lanczos still may look better in some situations due to being sharper.

Mathias:
I've not read the whole thread, but I have 3 suggestions:
1) If you find tensor Lanczos (the standard one), which is "orthogonal 2-pass" Sinc-windowed Sinc 3-lobe, too jaggy near diagonals (it's the checkerboard mode rearing its ugly head) as well as too halo-y, substitute Jinc windowing for Sinc windowing. It "softens" the rough edges of standard Lanczos just a little.
(Informal name of this filter: "Ginseng", for "Jinc-Sinc".)
Methods Recommended by Nicolas Robidoux: Recommended Upsampling Methods (Enlarging)
2) If you find EWA Lanczos (Jinc-windowed Jinc 3-lobe) too soft, you can sharpen it doing something which does not work so well with tensor Lanczos: rescale the filter extent, which is a fairly trivial change once any of them is programmed. In particular, you get an EWA filter which is about as sharp as the above tensor Ginseng (which itself is about as sharp as standard Lanczos) by rescaling the EWA disc so that it has radius exactly 3. A side effect of this rescaling is that any scanline of the enlargement only needs 6 scanlines of the original as data, just like for tensor Lanczos. This method is often called "EWA Lanczos Radius 3". The rescaling factor is 3 over the radius of the "raw" Jinc 3-lobe disc, which is the third root of J_1(pi*x). Specifically, it is .9264075766146068. It's not as free of artifacts as the "full width" EWA Lanczos. But it sure is sharper.
In any case, I don't recommend using "full width" EWA Jinc-windowed Jinc 3-lobes. At least, "tighten it" a little. With a rescaling factor of .99, .98, .95 or ???. But don't use it at full width. Maybe start with 0.9891028367558475 (I'm afraid this value may not be exact down to last full decimal because the library I used to compute it is not as accurate as I wish when dealing with Bessel functions), which minimizes worst case "cross-talk" between the original scan lines. This is one of two variants of a method called EWA LanczosSharp. (Which is not much sharper than the plain EWA Lanczos.)
3) If you want to be a bit more adventurous, I suggest you sigmoidize. Given that I imagine that you have a luma or luminance channel at the ready, the idea is that you convert to a synthetic color space that pushes non-extreme pixel values toward the center of the gamut, do the upsampling using a linear or nonlinear filter on these values, and then undo the compression. What this does is that it minimizes the extreme halos that arise from mid-tones. Or you could do it with all three channels. If you use (which I'm sure you don't) sRGB as input and output colorspaces, you can fake this by computing the color negative, converting applying the transformation from linear RGB to sRGB (as if they are not already), resampling, and then applying the transformation from sRGB to linear RGB, and finally taking the color negative. I imagine that similar "faking" can be done with, say, La*b*.
Examples involving sRGB to sRGB enlargements are found here: Enlarge with sRGB, RGB, LAB, LUV, XYZ, sigmoidal...?
Warning: Use a very recent ImageMagick, preferably in HDRI, if you want to try this yourself with it.

[NicolasRobidoux]

Summary of my last comment #2: The EWA Lanczoses (which I believe you call Jinc) have an easy "knob" which fairly predictably affects sharpness.

[TheLion]

Originally Posted by NicolasRobidoux

Summary of my last comment #2: The EWA Lanczoses (which I believe you call Jinc) have an easy "knob" which fairly predictably affects sharpness.

Personally I like the "organic" look of madVRs EWA Lanczos aka Jinc implementation. But it is a touch too soft compared to Lanczos3/4 for my taste.

So your suggestion, Nicolas, is probably just what is needed ;-)

Looking at your link "Ginseng" looks like a sweetspot and is probably an even "better" alternative than standard Lanczos.

[NicolasRobidoux]

Originally Posted by TheLion

Personally I like the "organic" look of madVRs EWA Lanczos aka Jinc implementation. But it is a touch too soft compared to Lanczos3/4 for my taste.

Warning: Ginseng is a very lightly "tamed" tensor (standard orthogonal) Lanczos.
It does not have the "look and feel" of EWA Lanczos. But it's closer to it than standard Lanczos.
To get more sharpness out of EWA Lanczos without losing the organic feel, use the "knob" described in 2).

[blackjack12]

Originally Posted by madshi

@nev, that's quite possible, but then why does v0.82.5 work for him? It must be related to a change in madVR, too, somehow.

@blackjack12: Try this test build:

http://madshi.net/madVRblackjack.rar

Does this work better for you? If not, there are 2 more things that could explain the difference:

(1) In v0.83 and newer I've removed some of the tweak settings that v0.82.5 still had. When you switch back to v0.82.5 do you have any of these tweak settings enabled? I'm talking about the bottom most 3 options in the exclusive mode settings page. And about the D3D11 presentation option. Do you have any of them activated in v0.82.5? If so, try deactivating them one by one to find out which of them you need.

(2) In v0.82.5 the "delay playback start until render queue is full" option applied to seeks, too. In v0.83 and newer it does not. Instead there's a new sub option "delay playback start after seeking, too". Did you have "delay playback start until render queue is full" activated in v0.82.5? If so, try activating "delay playback start after seeking, too" in v0.84.2. Does that fix the problem?

A few notes.
I have 4 systems

1. 2 HTPC clients running AMD 6570/2GB DDR3 graphics, one using Windows 7 64 bit the other Windows 8 64 bit RTM
2. 1 system running AMD 4890/1GB DDR5 “legacy” graphics, Windows 7 64bit
3. 1 system running NVidia 560Ti/2GB DDR5, Windows 8 RTM

0.84.2 madVRblackjack test build

Initial test on systems listed in 1 with Windows 7 OR 8 RTM – all MKV container material for playback
(NOTE: This is not a Windows 8 issue. It is seen in identical systems, one running Windows 7 and one running windows 8)

MPC-HC 1.6.4.6052 or MPC-BE 1.0.3.1
Catalyst Driver ver 12.8
LAV Filters 51.3-118
madVR – all delay playback checked, GPU flush settings default

Windowed Mode or FSE:
With any interlaced content madVR causes an error and does not load at all, you can hear sound but see no video. All other content plays without issue – non-interlaced h264, VC1 and MPEG2 and there is no jumping around issues causing dropped frames and what appears to be rendering or buffering freezes.

The madVR crash report for the Windows 7 system is here:
http://sdrv.ms/VRKJ2h

System 2 above does not have any issues when using 0.84.2 std. … Another note that system 2 never worked correctly with interlaced material and in other areas until the 0.83.x updates … ? Was anything changed in the linking and handling of interlaced content with the new versions of madVR?

System 3 has dropped frame issues with 0.84.2, will load with the test build but still has dropped frame issues when jumping around. This system uses the latest NVidia drivers and CUVID with LAV.

I probably have more and broader material than many if not all, over 2100 files stored on over 48TB server array. Over 99% MKV content prepped from original materials. It is the interlaced content that is now causing problems. With this latest test build, madVR actually causes an error message and will not even load with this kind of material with the AMD Radeon systems …

I test all the time with:
"Life" - VC1 interlaced content (1080i)
"Our National Parks, Americas Best Idea" - h264 interlaced content (1080i)

These are the first files I look at as they have always been a tough test in the past. If these work then go to a number of other demanding BD conversions such as Avatar, Baraka and many others. All material converted from original with makeMKV and then remuxed with the latest version of mkvmerge.

Hope this may help.

[TheLion]

Originally Posted by NicolasRobidoux

Warning: Ginseng is a very lightly "tamed" tensor (standard orthogonal) Lanczos.
It does not have the "look and feel" of EWA Lanczos. But it's closer to it than standard Lanczos.
To get more sharpness out of EWA Lanczos without losing the organic feel, use the "knob" described in 2).

Thanks, I do understand that. What I meant was using "Ginseng" instead (or as another option) of tensor Lanczos in madVR (as you suggested in 1) Just because standard Lanczos can be a touch "harsh" at times.

Making "Jinc" a little sharper as you suggested in 2) is also probably a very good approach.

So in the end I guess I just completely agree with your suggestions ;-)

May I ask what is your preferred upsampling method for high quality content (pure luminance and chroma upsampling)? Thanks for your knowledgeable input!

[NicolasRobidoux]

Originally Posted by NicolasRobidoux

The rescaling factor is 3 over the radius of the "raw" Jinc 3-lobe disc, which is the third root of J_1(pi*x).

Correction: It has to do with the fourth root of J_1, which is its third nonzero root, which is the third root of Jinc.

[madshi]

Originally Posted by JarrettH

What I love about Jinc is the analogue feel, but with a good amount of sharpness. Works wonders with HD content and SD as long as it's not interlaced. What I found with DVDs is there was too much aliasing (line crawling) when using Jinc. Could that have to do with them needing to be upscaled more plus interlacing artifacts might get sharpened?

If it works well for you with progressive content then probably deinterlacing quality is simply not good enough.

Originally Posted by blackjack12

I have 4 systems

The original problem you were reporting, on which of those 4 systems did it occur? On all 4?

Did the original problem only occur with interlaced content, btw, or also with progressive content?

Originally Posted by blackjack12

Windowed Mode or FSE:
With any interlaced content madVR causes an error and does not load at all, you can hear sound but see no video. All other content plays without issue – non-interlaced h264, VC1 and MPEG2 and there is no jumping around issues causing dropped frames and what appears to be rendering or buffering freezes.

Not sure if I understand this correctly. So basically deinterlacing doesn't work, but progressive content plays perfectly. Did I get that right? Not sure why deinterlacing doesn't work. The test build was a quick hack of moving some v0.82.5 code back into the v0.84.2 source code. It's *really* difficult because there was a very big change between v0.82.5 and v0.83.0 in the source code. The change itself shouldn't do much, but it makes it hard for me to create versions that sit between v0.82.5 and v0.83.0.

Originally Posted by blackjack12

System 2 above does not have any issues

Did System 2 have issues with the official v0.84?

Originally Posted by blackjack12

Was anything changed in the linking and handling of interlaced content with the new versions of madVR?

Yes, there was a change in deinterlacing logic. Which is the code which I tried to revert in the best build I made for you.

Originally Posted by NicolasRobidoux

I've not read the whole thread, but I have 3 suggestions:
1) If you find tensor Lanczos (the standard one), which is "orthogonal 2-pass" Sinc-windowed Sinc 3-lobe, too jaggy near diagonals (it's the checkerboard mode rearing its ugly head) as well as too halo-y, substitute Jinc windowing for Sinc windowing. It "softens" the rough edges of standard Lanczos just a little.
(Informal name of this filter: "Ginseng", for "Jinc-Sinc".)
Methods Recommended by Nicolas Robidoux: Recommended Upsampling Methods (Enlarging)

Good to hear from you!

Yeah, I could try that, thanks for the suggestion. You do mean to keep it 2 pass, correct? One worry I have is that madVR already has sooo many scaling options right now. I'm a bit afraid of adding so many more. I don't want to frighten new users. So it's always a hard decision whether I should add a new scaling algorithm or not. But I'll give your Ginseng idea a try to see how it works.

Originally Posted by NicolasRobidoux

2) If you find EWA Lanczos (Jinc-windowed Jinc 3-lobe) too soft, you can sharpen it doing something which does not work so well with tensor Lanczos: rescale the filter extent, which is a fairly trivial change once any of them is programmed. In particular, you get an EWA filter which is about as sharp as the above tensor Ginseng (which itself is about as sharp as standard Lanczos) by rescaling the EWA disc so that it has radius exactly 3. A side effect of this rescaling is that any scanline of the enlargement only needs 6 scanlines of the original as data, just like for tensor Lanczos. This method is often called "EWA Lanczos Radius 3". The rescaling factor is 3 over the radius of the "raw" Jinc 3-lobe disc, which is the third root of J_1(pi*x). Specifically, it is .9264075766146068. It's not as free of artifacts as the "full width" EWA Lanczos. But it sure is sharper.
In any case, I don't recommend using "full width" EWA Jinc-windowed Jinc 3-lobes. At least, "tighten it" a little. With a rescaling factor of .99, .98, .95 or ???. But don't use it at full width. Maybe start with 0.9891028367558475 (I'm afraid this value may not be exact down to last full decimal because the library I used to compute it is not as accurate as I wish when dealing with Bessel functions), which minimizes worst case "cross-talk" between the original scan lines. This is one of two variants of a method called EWA LanczosSharp. (Which is not much sharper than the plain EWA Lanczos.)

I'm currently using 0.9812505644269356 in madVR. Got that number from somewhere when researching how to implement this algorithm. I had tried other values, like 1.0 or 0.88, but I ended up going back to 0.9812505644269356 cause it looked like a good compromise between aliasing and sharpness to me. Much lower than 0.9812... and too much aliasing crept back in for my taste.

Originally Posted by NicolasRobidoux

3) If you want to be a bit more adventurous, I suggest you sigmoidize. Given that I imagine that you have a luma or luminance channel at the ready, the idea is that you convert to a synthetic color space that pushes non-extreme pixel values toward the center of the gamut, do the upsampling using a linear or nonlinear filter on these values, and then undo the compression. What this does is that it minimizes the extreme halos that arise from mid-tones. Or you could do it with all three channels. If you use (which I'm sure you don't) sRGB as input and output colorspaces, you can fake this by computing the color negative, converting applying the transformation from linear RGB to sRGB (as if they are not already), resampling, and then applying the transformation from sRGB to linear RGB, and finally taking the color negative.

I did try your "RGB -> sRGB + negative + ..." trick, but the results didn't convince me to use it. I've added my own anti-ringing filter to the algorithm, though, which is quite effective. If you want to check for yourself:

parking original image -|- 400% with jinc (4 taps) -|- 400% with jinc (4 taps) with anti-ringing filter

If you've fun you can try yourself if sigmoidization can compete with my anti-ringing filter?

[Warlock]

Guys, what is the ideal setting for a GF 8600GT 512 DDR3? I am currently using the default madvr. What are the best filters for it: Jinc, Spline or Lanczos? 3, 4, or 8 taps?

[cyberbeing]

Originally Posted by TheLion

I have severe issues with DPC spikes using madVR together with my AMD/ATI 5870 board.

Originally Posted by TheLion

I have found a config which avoids the DPC spikes and brings the latency down to the level with EVR.

CPU/GPU queue size: 12/6
Frames in advance: 3
Flush, Don't Flush, Don't Flush, Flush&Wait (sleep)

does the trick.

Interesting, I was wondering why my ATI 5750 system was always showing extremely high DPC latency with madVR, while my NVIDIA systems never has such issues.

From my own testing, it looks like my ATI 5750 freaks out with constant +600µs high DPC latency if the GPU Queue is set to 8+, or if the the FSE present frames in advanced is set to 8+. The other settings you list seem to have no effect, but setting both GPU Queue and Present Frames in Advance to 6 resolves the high DPC problem I had with madVR on that system. I don't see any difference with the special build madshi created.

[JustinChase]

Originally Posted by Warlock

Guys, what is the ideal setting for a GF 8600GT 512 DDR3? I am currently using the default madvr. What are the best filters for it: Jinc, Spline or Lanczos? 3, 4, or 8 taps?

Unfortunately, that's like asking "which coffee is the best?"

Try searching this thread for "upscaling comparison", and you can get some personal opinions, but there is no "best" setting. Sorry

[Ver Greeneyes]

Originally Posted by madshi

I did try your "RGB -> sRGB + negative + ..." trick, but the results didn't convince me to use it.

Speaking of sRGB, have you ever considered doing the scaling in a perceptually uniform color space like CAM02-UCS J'a'b'? If you're interested I could probably supply (given a little time) a shader that implements the forward and inverse transforms.

[rahzel]

Hi madshi,

Question, earlier in this thread, you suggested to certain AMD/ATI owners to use 16-235 in madVR with AMD Vision set to RGB Full. Would you still recommend this config, even if your display has an option for 0-255 and 16-235? It seems to me that it would be better to avoid any unnecessary conversions and to output 0-255 (assuming your display supports it). Is the reason you recommended 16-235 because most TVs are setup this way, or is there another reason?

[madshi]

Originally Posted by Ver Greeneyes

Speaking of sRGB, have you ever considered doing the scaling in a perceptually uniform color space like CAM02-UCS J'a'b'? If you're interested I could probably supply (given a little time) a shader that implements the forward and inverse transforms.

I have some doubts whether it would improve image quality. But if you think it could help, I'd like to try, if you can provide the shader code for the conversions.

Originally Posted by rahzel

Question, earlier in this thread, you suggested to certain AMD/ATI owners to use 16-235 in madVR with AMD Vision set to RGB Full. Would you still recommend this config, even if your display has an option for 0-255 and 16-235? It seems to me that it would be better to avoid any unnecessary conversions and to output 0-255 (assuming your display supports it). Is the reason you recommended 16-235 because most TVs are setup this way, or is there another reason?

Actually I usually recommend to set everything to 0-255 (which is also what I'm using myself). But some displays don't support that.

[NicolasRobidoux]

Originally Posted by madshi

Good to hear from you!

Nice to see you're making great strides.

Originally Posted by madshi

You do mean to keep it 2 pass, correct?

Yes: Same everything, just swap the windowing function (sin(pi*x/3)/x -> Jinc(root*x/3)), where root is the first crossing of the Jinc function you use. When you plot your window function, it should look an awful lot like the first lobe of the Sinc function. which itself looks an awful lot like the first lobe of the Cosine function.
----
I understand the "frighten new users" business. Suggestions: Just keep "fancy options" hidden unless some sort of "Expert options" toggle is turned "on". Otherwise, the menus only contain reasonable defaults. Hide "expert options" late in the documentation (in an Appendix?).

Originally Posted by madshi

I'm currently using 0.9812505644269356 in madVR. Got that number from somewhere when researching how to implement this algorithm. I had tried other values, like 1.0 or 0.88, but I ended up going back to 0.9812505644269356 cause it looked like a good compromise between aliasing and sharpness to me. Much lower than 0.9812... and too much aliasing crept back in for my taste.

It's the usual tug-o'-war between aliasing and sharpness.

Let me explain, in simple termps, the value you currently use (which also is the built-in value in ImageMagick) VS the one I currently recommend, mostly based on mathematical principles, not "it's clear this one is better" (there is little visual difference between them).

0.9812... is defined by the following property: When you have a single scanline of colour A (I assume all colour channels sit at the same pixel locations) on a background of colour B and you enlarge in such a way that there is an output scanline either at the original scanline location just above the lone scanline or just below (or both), then the colour of this scanline in the output is B. (Of course the same applies to a single pixel wide vertical line of colour A...)

0.9891... is defined by the following property. If your input image is A up to a certain scanline and B below that, and you enlarge in such a way that there is an output scanline at the last A scanline in the input image, then the colour of this output scanline is A. And conversely: If there is an output scanline at the first input B scanline, it is also colour B in the output. (Of course the same applies to an image which is colour A left of some vertical boundary, and B thereafter.) It turns out that 0.9891... has some additional mathematical properties which are why I now prefer it.

Correction: The above "simple" characterizations only work "exactly" if you keep the same resolution in the "other direction".

This being said, these values were computed with a slightly innaccurate library for the Bessel functions, so they may be very slightly off. But they're already close to each other, and both of them are very close to 1.

Originally Posted by madshi

I did try your "RGB -> sRGB + negative + ..." trick, but the results didn't convince me to use it. I've added my own anti-ringing filter to the algorithm, though, which is quite effective. If you want to check for yourself:

parking original image -|- 400% with jinc (4 taps) -|- 400% with jinc (4 taps) with anti-ringing filter

If you've fun you can try yourself if sigmoidization can compete with my anti-ringing filter?

I certainly will. Sigmoidization is kind of a hack. (Although, IMHO, it works amazingly well: Enlarge with sRGB, RGB, LAB, LUV, XYZ, sigmoidal...?.)
This being said, my terse description assumed that your input was in a perceptual color space which is very roughtly described by a cube, like sRGB.
If you start and end at sRGB, the detail goes like this (but note that this is a hack meant to avoid programming reversible sigmoidal-contrast transformations, which is not hard to do, is fairly cheap, but is not universally implemented):
sRGB -> negate -> pretend it's linear RGB with sRGB primaries -> sRGB -> upsample -> linear RGB with sRGB primaries -> pretend it's sRGB -> RGB -> negate -> sRGB.
The negations can be moved inward by one or two operations.
Again, this is an approximating hack. But an easy to try approximating hack.

[Ver Greeneyes]

Originally Posted by madshi

I have some doubts whether it would improve image quality. But if you think it could help, I'd like to try, if you can provide the shader code for the conversions.

Cool, I'd be interested to find out myself I have about 90% of a C++ implementation done, so I'll get to work on finishing that and converting it to HLSL code.

[NicolasRobidoux]

A few quick comments so everybody knows where I'm coming from and where I may be going:
1) I know little about video processing. I'm a still image guy (ImageMagick/GEGL/VIPS/NIP2/GIMP plugin).
2) So far, everything I've stated relates to 3-lobe methods. I generally do not like 4-lobe methods. Although I remember liking a tweaked version of EWA Lanczos with 5 lobes at some point, and I suppose I could look again.
3) It is on my to-do list to provide high accuracy low flop approximations of the key Jinc functions (Sinc too. There is an outdated version called SincFast in ImageMagick). I know how. It's a matter of customizing the Boost C++ Minimax package, running it, and validating the results. I unfortunately have to balance labour of love with paid consultant work.
4) I don't know if you guys are halo haters. If so, another interesting method, besides Ginseng and EWA LanczosSharp and variants, is EWA quadratic B-spline windowed Jinc 3-lobe. It basically has no second halo, and it's decently sharp given that it is really good at moire suppression.
5) I do not recommend the same methods for upsampling, resampling (barely changing the sampling rate) and downsampling.
EWA LanczosSharp and tensor Ginseng and then EWA quadratic B-spline-windowed Jinc are at the top of my list for upsampling.
EWA LanczosSharp, EWA quadratic B-spline-windowed Jinc and then the very sharp (sharper than tensor Lanczos) tensor Cosine-windowed Sinc are at the top of my list for downsampling. The last method is recommended based on that digital photographers value sharpness a lot. I actually prefer tensor Ginseng.
All of them are 3-lobe methods.
6) The version of Methods Recommended by Nicolas Robidoux which currently is on the server is outdated. I don't have direct access to the server, and this is a work in progress.

[agustin9]

Originally Posted by TheLion

Sadly I don't have another card at my disposal. The latency peaks generally get worse when increasing GPU queue sizes. But it is not so easy because there are interactions with the other parameters (CPU queue, frames in advance, GPU flushing).

I am wondering if it would be a viable idea to include default profiles depending on the graphic card (nVidia/AMD/Intel, perhaps per generation) in madVR based on user feedback?!

Please try the catalyst 10.6 drivers, they worked fine for me. I have a 4850.

[NicolasRobidoux]

Mathias:
RE: what de-blur to use.
Although I have no mathematical basis for this recommendation, it appears to me that a value somewhere between .95 and .97 is probably the sweet spot, at least with EWA Lanczos 3. But I have not tried these values enough to be sure. And at this point, this would have to be based on the "eyeball metric".

[NicolasRobidoux]

Mathias:
Your overshoot suppression method appears to work impressively well.
-----
You are aware that such limiters are probably not desirable, or not as desirable, when downsampling, yes?