madVR - high quality video renderer (GPU assisted)

[huhn]

Wouldn't the Nvidia be able to use CUVID for deinterlacing rather than yadif, while still being able to switch over to "film mode" deinterlacing for telecined stuff? I'm not really familiar with Nvidia cards, I've always owned AMD.
madvr(dxva) and CUVID use the same deinterlacer
CUVID was pretty good on old nvidia cards but in these days dxva is the better choice, it's not like is way fast or some thing both use the same decoder but you can use it native and it's not forcing your gpu in the highest powerstate.
I'm pretty sure the GT 630 is a rebranded GT 440, which might be cheaper to find. Don't expect to be able to use any high quality settings in MadVR with this kind of card. Bicubic75 AR chroma, Lanczos3 AR upscaling, and CR AR downscaling should be possible. Deinterlacing is good and you can get passive ones that are silent, which is nice for HTPCs.

I'd love to use all the great new MadVR features in my HTPC but (aside from having to change media centre software) it'd require a beefy GPU and I doubt any of them are quiet enough for an HTPC environment. :(

gt 630 gk108/gk 208 301 64 bit interface no passive or low profile (the fermi relabel) gddr5 version

gt 640 gk 107/gk208 400 a lot faster about x2

nvidia does an awful job on branding his cards you can get a fermi 630 with gddr5 or a kampler with ddr3. same problem with the 640 gk107/128 bit ddr3 or gk208 400 64 bit gddr5 the gddr5 version is a bit faster and takes less power.

and they can do plenty there is no need for jinc3 ar, it's nice but not a must have.

[peplegal]

Again I have a problem which could be an issue with MadVR or MPC-HC... With some files I can't go directly into exclusive mode. When I enable fullscreen with ALT + Return, in some files, the picture enlarges but the header from MPC-HC is still seen and exclusive mode isn't running.


Same here !

(Last MPC-HC / Last MadVR / HD6450 / Win 8)

[Thunderbolt8]

The question of upgrading is the same as it always has been, really. If you have a lot of money to throw around or it's an actual investment, get the newest offering whenever you can. Otherwise, just upgrade if you really need a new card (which is something only you can decide). If you're at the end of a graphics card cycle, the existing cards will be cheaper than the ones just around the corner - if you're at the start of a cycle, then there won't be anything new for a year anyway.yes, but thats not what Im aiming at. the thing is that currently only high end cards will be able to use everything with madvr smoothly meaning there will be more noise with cards operating at high end level. so if you wait a bit longer then the requirement might only be a then midrange level card which will most likely be quieter than using a highend card now. that would be a reason to wait for me, unrelated to money.

[drew_afx]

Even a 780GTX can't handle max setting...which means it's not the raw shader performance problem of mid-range cards,
but it lacks OpenCL support from driver and algorithm suitable for such bad compute architecture.
Nvidia dumped compute performance on its Kepler Geforce variants in favor of 3D game performance and later halved compute performance
compared to equivalent Quadro cards.
Should see if 800 series changes that for Nvidia....but for now latest AMD card is the only player in OpenCL arena.

[michkrol]

Again I have a problem which could be an issue with MadVR or MPC-HC... With some files I can't go directly into exclusive mode. When I enable fullscreen with ALT + Return, in some files, the picture enlarges but the header from MPC-HC is still seen and exclusive mode isn't running. Example: (IMG)
After that I have to press ALT so that the menu bar shows up like here -> (IMG)
If I press now outside the window on my first display, it finally goes in to the real exclusive mode... I have this problem since a few MPC-HC versions, so I guess it's more likely an MPC-HC error?
Same here !

(Last MPC-HC / Last MadVR / HD6450 / Win 8)

Doesn't happen here. It must be something with your MPC-HC config. Try changing the key shortcut for full screen: View->Options select Player->Keys and find full screen, also check if you don't have Alt+Enter set for some other action.
It might also have something to do with keyboard language settings, which would be hard to debug. It might sound stupid, but check if you get the same behavior with both of your Alt keys.

If this doesn't help please ask the MPC-HC's developers/community for help as it's not really related to madVR.

[iSunrise]

madshi, thanks for all the new ED builds.

Testing them right now.

yes, but thats not what Im aiming at. the thing is that currently only high end cards will be able to use everything with madvr smoothly meaning there will be more noise with cards operating at high end level. so if you wait a bit longer then the requirement might only be a then midrange level card which will most likely be quieter than using a highend card now. that would be a reason to wait for me, unrelated to money.
That may be true for reference cards, but definitely not for custom cards or self-customized models. It all depends on whether you absolutely need a card for a small case like a HTPC or if you have a typical desktop tower case and of course your airflow inside the case. Because you can always buy an Arctic Accelero Xtreme III, put it on the high-end card and there will barely be any noise at all. Even when I overclock my GTX580 like crazy, the Arctic cools it down without problems when at full load at the minimum fan speeds (800 UPM) possible. Even my RED hard drives are louder than that and they are extremely quiet. And I also am extremely picky about noise. If I would need a card now, I would either buy a 290 or a 780 and put the mentioned cooler on it. I will not settle for anything less, anymore, it´s a stunning combination.

Ideally, we would have a madVR benchmark that pre-selects (over the top) settings for NNEDI/ED, so we could rank the cards. In that case, maybe even some reviews sites would pick it up as a benchmark and IHVs would optimize their drivers. But I´m just thinking out loud, as I don´t think madshi is interested in that.

[Ver Greeneyes]

Hey guys, was wondering what you think of this test pattern (http://www.mediafire.com/?isug2xggj4dey0x) (and this one (http://www.mediafire.com/?nbp32easa8p3yr6), now with more colors). It shows a couple of identical (mirrored) gradients, perceptually spaced via the CAM02-UCS color adaptation model, that fade in and out again. The data was generated using 16 bits per color channel and encoded in yuv444p16le, and has 7*256 = 1792 steps (the video resolution is 1920x1080). I left a bit of space on the left and right so the ends aren't right on the edges of the screen.

I'm mostly looking for feedback from people who've used test patterns before. Is it useful this way? Should I adjust the fade in and out? Are there any features you'd like to see?

[leeperry]

you can always buy an Arctic Accelero Xtreme III, put it on the high-end card and there will barely be any noise at all.
But this will void your warranty...and I just read a review of that silent 270X MSI, they said that the GPU was reaching 83°C under normal load and that they didn't dare running FurMark. They also said that after a few hours, the GPU started to throttle down due to the excessive heat(TJ max would be 95°C).

As these GPU's can take the heat, I'll put the external apps invoking capabilities of mVR profiles to good use with this app (https://code.google.com/p/overdrive5/), forcing 24% during movies and 18% when my media player closes...the former is the most I can stand and the latter is barely audible, winning :)

[kasper93]

@Skwelcha @peplegal Could you provide more info in this ticket https://trac.mpc-hc.org/ticket/3956 so that we can reproduce the issue? It works fine here. Of course if floating menu is shown in windowed mode and you enter fullscreen it will still be shown and you can hide it by clicking ALT key. But menu shouldn't appear when switching to fullscreen mode or you have persistent menu in windowed mode enabled.

Sorry for OT.

[iSunrise]

But this will void your warranty...
Not if you buy from ASUS, EVGA, MSI or Zotac. They explicitly allow a cooler change (if you don´t damage the card, of course) and they also state that on every forum and they even answer you by e-mail. A relatively famous german site (http://ht4u.net/reviews/2014/grafikkarten-hersteller_zur_thematik_garantieverlust_beim_wechsel_des_kuehlers_oder_uebertakten/index3.php) did exactly that. EVGA if you want NV, ASUS if you want AMD and you should be fine.

For AMD, it´s still pretty uncommon, but since their reference coolers are usually very noisy, you need to go the alternative route. This is what AMD says: "We fully qualify both settings (Uber + Quiet), but warranties are between AIB and end users. AMD is not involved in that relationship.".

But you don´t even have to go that far if you don´t feel comfortable with it. Just buy a "better" (less noise, more cooling-headroom) custom model from the other AIBs and you shouldn´t need to worry much about noise at all, at least that´s true for NV. For AMD´s 290(x), this is a lot harder if you don´t want to mod yourself.

[MistahBonzai]

I'm mostly looking for feedback from people who've used test patterns before. Is it useful this way? Should I adjust the fade in and out? Are there any features you'd like to see?

Thanks..great idea. I've been bouncing between MP4-2c Black Clipping and Grayscale Ramp. This appears better suited for judging 'noise' performance.

[kstuart]

[Again, including details for future readers with HD6450]

I've found that with that card, I can use Chroma - Bicubic75 and Luma - Lanczos 3 with AR, for a distinct improvement on my 1080p HDTV over using EVR.

Using those scaling algorithms requires using software decoding, and random dithering rather than Error Diffusion. so adding hardware deinterlacing will cause problems.

Most of my viewing is progressive files, the interlaced files are recorded by my ATSC OTA tuner of local broadcasts in 1080i.

So, I tried enabling LAV software deinterlacing (as suggested by huhn, thanks) but the combination of software decoding and software deinterlacing was too much for my CPU.

Then I tried turning off deinterlacing in madVR, and adding 1080i59 to the available output formats for madVR. This is working quite well.

I suspect what is happening is that the interlaced video is being passed to my HDTV, which is doing the deinterlacing, thus allowing my CPU to do the decoding, and my GPU to do chroma upsampling.

[DragonQ]

What's more likely is that your GPU is deinterlacing to 1080p/60, then interlacing the video back to 1080i/30 before outputting the signal. GPUs really don't handle interlaced outputs well, you should just let your GPU do the deinterlacing and output a progressive signal, especially if your CPU is struggling with YADIF.

Remember that any resize operations necessitate deinterlacing anyway and you want to take the optimal path.

[kstuart]

What's more likely is that your GPU is deinterlacing to 1080p/60, then interlacing the video back to 1080i/30 before outputting the signal. GPUs really don't handle interlaced outputs well, you should just let your GPU do the deinterlacing and output a progressive signal, especially if your CPU is struggling with YADIF.

Remember that any resize operations necessitate deinterlacing anyway and you want to take the optimal path.

In your first sentence, can you be more precise? AFAIK, what occurs is:

VideoPlayer->LAV->madVR->Catalyst->HDTV

Any of the 3 middle steps can involve the GPU, and combining too many things will push the load (as reported by GPU-Z) to 95% or more, at which point, the playback begins to stutter.

Of all the various things that I can activate in madVR, deinterlacing produces the most increase in GPU load.

So, what you are describing in the first sentence is Catalyst deinterlacing it, and then re-interlacing it. Why would it do that? If the 1080i59 specified by madVR is passed on to Catalyst, then either it would deinterlace (because it thinks the monitor may not support interlaced), or else it would just keep it interlaced. The fact that the GPU load is still moderate, indicates that chroma upsampling is the only GPU load.

You state "any resize operations necessitate deinterlacing" but that cannot include chroma upsampling otherwise there would be no difference between activating and de-activating deinterlacing (because chroma upsampling is always occuring).

I appreciate any suggestions - just trying to understand the technical details.

[GREG1292]

It's interesting all the talk about specs
between Amd and Nvidia but actual
performance varies on the screen
between the to camps. Gtx770 is quiet with no lag while the 7870XT
Overheats and shuts down and stutters. Glad I have 2 good cards
to choose from. Testing was done with the same settings. Of course I was pushing both to the limit.

[Ver Greeneyes]

I made another test pattern that includes some more colors: get it here (http://www.mediafire.com/?nbp32easa8p3yr6). Feedback welcome ;) (also updated my post above)

[cyberbeing]

Yeah...get on it bacondither, please capture the same frame for each one :)

Elephants_Dream_madVR_noisy_dither (https://www.mediafire.com/?wnlcb2ecmat5etu)

Well I got bored, so I went ahead and made a madVR post-processing abuse comparison on a gradient heavy scene of Elephant's Dream. Includes some madVR debanding as well, since the 8bit lossless source had banding.

Source was frame 6999 png image from http://media.xiph.org/.

Decoding was performed by LAV Video 0.60.1

Settings I used for this test are below, which theoretically should allow the results in the zip to be reproducible without downloading it.

~Calibration~
This display is already calibrated
Gamut = BT.709
Gamma = BT.709 2.20 Curve

~Color & Gamma~
Brightness = +100
Contrast = +25
Saturation = -50
Hue = +10
Gamma Processing = BT.709 1.80 Curve

~Artifact Removal~
Custom
avgDif = 1.0
maxDif = 3.5
midDif = 2.0
angleBoost = 3.0
maxAngle = 0.08

~Image Upscaling~
N/A, no upscaling performed

~Image Downscaling~
N/A, no downscaling performed

~Chroma Upscaling~
N/A, no chroma upscaling performed, source was RGB

~Trade Quality for Performance~
store custom pixel shader results in 16bit buffer instead of 32bit = Disabled
don't analyze gradient angles for debanding = Disabled

~MPC-HC pre-resize Shader~

sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return tex2D(s0, tex) - 106.0 / 32768.0;
}

Good example of how my preferred Noisy2 (which I've abbreviated as n2) comes out the smoothest with the least amount of chunky noise. Some people may not like that smooth aspect though, but I do find n2 closest to ed7 in that regard on my GDM-F520 CRT. Other displays very well may behave differently. Maybe tomorrow I'll do another one of these with the other open source videos on Xiph. madshi said he wanted votes, so hopefully things like this make it a bit easier to decide.

[StinDaWg]

[Again, including details for future readers with HD6450]

I've found that with that card, I can use Chroma - Bicubic75 and Luma - Lanczos 3 with AR, for a distinct improvement on my 1080p HDTV over using EVR.
kstuart, can you tell me if the 6450 can play 720p/1080p 60fps videos smoothly, and if it can handle the debanding filter turned on? My 5450 can't do either. Just trying to figure out how high a card I need to step up to get both to work properly.

Do I need to step up to a 6570? At 480 stream processors it seems like it would be enough for some decent madVR settings. It's also available in low profile and fanless for >$60.

[ryrynz]

Well I got bored, so I went ahead and made a madVR post-processing abuse comparison

Wow, what an awesome comparison! So many areas to feast your eyes on..

N3 without a doubt. I can see why people like ed7 though.

N3 is just giving a nice touch of extra "detail" without being too noisy.

[MistahBonzai]

Elephants_Dream_madVR_noisy_dither (https://www.mediafire.com/?wnlcb2ecmat5etu)

Well I got bored, so I went ahead and made a madVR post-processing abuse comparison on a gradient heavy scene of Elephant's Dream.

Yup..without taking note of the png names I zoomed ~300%,got the images stacked in a perfect overlay and pixel peeped 'til I thought I was going blind. And I mean carefully considered all aspects near and far on my display (carefully calibrated 40" Bravia which is my personal 'monitor' - I sit at arms length from it).

In the end I was having a hard time declaring a clear winner between what turned out to be ED7 and N4 (choose N4 over N3 cuz the gradients blended a tad better - at least where I was peeping).

What amazed me was how difficult it was to spot differences while evaluating the native captures - let alone choose a definite 'winner'. What I did see was that all of the dithered images were far superior to the non-dithered image.

BTW: Just for grinz I adjusted MadVR and MPC-HC to the requested settings and watched some of my favorite short 'evaluation clips'. After returning the settings to 'normal' all I could say was wow! I've never seen this monitor look so good :-)

[Qaq]

Do I need to step up to a 6570?You better step up to a fanless 7750 GDDR5 like I did. Seems like best fanless option for madVR. NNEDI is not available (yet), but all other features are just fine.

[ryrynz]

In the end I was having a hard time declaring a clear winner between what turned out to be ED7 and N4

Personally I find N4 to look a little scattery, it does add a bit of extra pop though. Between N3 and ED7 it's a tough choice as I like them both. The thing is we're not trying to determine our preference here from what mode provides the least amount of banding (although this is a nice side effect) madshi has said that is entirely the role of the debanding algorithm and dithering is not meant to combat this.

I'd be happy with either ED7 or N3, but I prefer N3.

You better step up to a fanless 7750 GDDR5 like I did.

The GDDR5 is quite important..

[James Freeman]

Can someone fill me in with whats going on with error diffusion?

As I understood the two dominant versions are ED5 & ED7, then madshi created 4 variants of these two (Noisy 1-4)?
Has madshi been clear about how many options will be in the release (more than one)?

In any case, I will be happy with any of them, as I don't see much difference between them.

Thanks.

[cyberbeing]

Elephants_Dream_madVR_noisy_dither (https://www.mediafire.com/?wnlcb2ecmat5etu)
...

Here is part 2 with a scene from Big Buck Bunny, frame 9144:

Big_Buck_Bunny_madVR_noisy_dither (https://www.mediafire.com/?zjmdg13m610o1ze)

Noticeable effects of dithering take place on much smaller surface areas on this one. I'd consider this a more decent test then the previous for how well each retains source detail.

Settings are the same as before, with the exception of much lower debanding strength.


Here is part 3 with a scene from Sintel 2K, frame 5215:

Sintel_2K_madVR_noisy_dither (http://www.mediafire.com/?2eg3tpswe7d64ea)

This one has some bokah gradients the background, but otherwise highly detailed.

~Calibration~
This display is already calibrated
Gamut = BT.709
Gamma = BT.709 2.20 Curve

~Color & Gamma~
Brightness = +100
Contrast = +25
Saturation = -50
Hue = +10
Gamma Processing = BT.709 1.80 Curve

~Artifact Removal~
Custom
avgDif = 0.3
maxDif = 1.3
midDif = 0.6
angleBoost = 2.0
maxAngle = 0.08

~Image Upscaling~
N/A, no upscaling performed

~Image Downscaling~
N/A, no downscaling performed

~Chroma Upscaling~
N/A, no chroma upscaling performed, source was RGB

~Trade Quality for Performance~
store custom pixel shader results in 16bit buffer instead of 32bit = Disabled
don't analyze gradient angles for debanding = Disabled

~MPC-HC pre-resize Shader~

sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return tex2D(s0, tex) - 106.0 / 32768.0;
}


Can someone fill me in with whats going on with error diffusion?

As I understood the two dominant versions are ED5 & ED7, then madshi created 4 variants of these two (Noisy 1-4)?

Yes, essentially ED5 & ED7 as previously tested no longer exist. madshi changed the random noise method and now we have the four new 'Noisy' builds which need to be re-tested from scratch to decide which is preferred among them.

Has madshi been clear about how many options will be in the release (more than one)?

He has stated two possibilities.

Option 1 (keep things simple, let there be one):
madVR contains one and only one error diffusion dither method of the patternless 'Noisy' variety.

Option 2 (keep everyone happy, medium noise & low noise):
madVR contains two error diffusion dither methods, one of the patternless 'Noisy' variety, and another of the 'Low noise' variety with patterns.

[madshi]

1) My calibrator takes the average of a group of pixels, so it probably won't care about worm patterns - but if the pattern is the same every frame, could the average vary between one location and the next?
2) For the purposes of differentiating between patches, you'd want the least amount of randomness possible right? But I'd also probably want to measure under the same conditions as I use for viewing later on. Assuming we end up with two algorithms to choose from in the end, should I calibrate with the one I prefer or with the one that has the lowest amount of noise? (assuming they're not one and the same)
I don't think you need to worry about these things too much. Unless your meter really only looks at one separate pixel, there should be no problem. If it takes the average of a couple surrounding pixels (which I would very much expect), it shouldn't matter whether there are worm artifacts or whether random is being used or not.

3) Very near black, is it possible that the dithering will be clipped (causing a higher average)? If so, would this be worse for an algorithm with more randomness?
This should be less a problem with error diffusion than it was with the "old" random dithering. E.g. if we're talking about a value of e.g. 16.5, so every so slightly higher than black at 16.0, in this situation error diffusion should create a pattern alternating between 8bit values 16 and 17. Ok, error diffusion sometimes (rather rarely) might also throw in some 15 and 18 values, but these are very rare, so they shouldn't be a problem.

I am using a AMD 5870 board with latest 13.12 drivers. To get best possible Blu-Ray playback I wanted to experiment with the new NNEDI3 chroma upsampling option (no other scaling involved as output is native 1080p).
Looking at some chroma test pics I realized that no-matter the neuron setting it is actually always JINC3 been used. So I can select NNEDI, it doesn't give me any alert message, but internally seems to fallback to JINC3.
Is this to be expected with the 5870 (openCL support)? Would it be possible to give feedback to the user that NNEDI is in fact disabled and something else used?
Did you replace all the files, including mvrSettings.dll and madHcCtrl.exe etc? I could imagine that if you have an old version of one of those files lying around somewhere, they might interfere by not being able to store the new settings. E.g., I believe you're using J.River MC, right? Do you have a separate madVR installation on your harddisk for MPC-HC? Make sure you replace *both* madVR installations with the latest files.

I have this problem since a few MPC-HC versions, so I guess it's more likely an MPC-HC error?
If a newer MPC-HC version introduced this, then it's likely to be an MPC-HC error. Please try some older MPC-HC version. If you can identify which exact MPC-HC version introduced this problem, that could be helpful for the MPC-HC developers to figure out which change in the MPC-HC code causes this problem.

Lastly, I've found that checking Automatic Deinterlacing in madVR also significantly increases the GPU load (when the source is interlaced). If I uncheck it, then the OSD says it is off, but playback seems normal.

Does this mean AMD Catalyst is doing the deinterlacing ? Or is it passing the task all the way to my HD TV ?
Do you have your GPU configured to output interlaced? Only then your TV could do deinterlacing.

I rather think what you're seeing is probably soft-telecined movie content which can look perfectly alright without deinterlacing. But you could run into heavy combing artifacts if you try this with hard-telecined content or native video content (e.g. 1080i sports).

As long as we're talking about film content (movies, newer TV series) and not native video content (sports, some music concerts), you could try to enable forced film mode in madVR. It's probably faster than letting LAV do YADIF, should produce better image quality for film content, and it would also save GPU resources. However, it will only work correctly for real film content. So you'll have to manually turn it off, if you watch any other content.

I also noticed that madshi recently moved "... use half frame rate deinterlacing... " to a special "not recommended" section of "trade quality for performance". Are there any youtube videos that demonstrate the difference ? (And is anything other than madVR going to be using half frame rate deinterlacing by default?)
This setting is only for madVR. You should be able to see the difference if you play an SD or 1080i sports broadcast with fast movements.

Madshi, have you looked into this? Someone was developing a dithering algorithm mased on magic numbers rather than "pure random" numbers. The intended application is slightly different, but I figured it could be taken into account.

It could be faster to create psuedorandom outputs simply from a list of "random-looking" numbers rather than random-number generation, though I'm just throwing ideas around here.

http://pippin.gimp.org/a_dither/
If I read that correctly, it looks like an algorithm which tries to achieve something near to error diffusion quality (but not quite), while at the same time trying to make things better compressable, or something like that. I don't see how any of that would help madVR.

But I am curious why DirectCompute5 HLSL compiler results in 10x slower code than OpenCL one of madshi's NNEDI3 shader function. It is quite difficult to imagine that unless any of following reason:

- A lot of DRAM re-access per thread group's calculation processing.
- some NNEDI3 heavy math calculations are not directly translated to processor's FPU instruction -- but by emulation
- 8 UAV count per cycle restriction has very big impact.

Compiler -O0 vs -O2/-O3 does not often produce such big difference even on heavy pure math calculation code.
I was surprised, too. The key processing loop just consists of a lot of math stuff, like floating point multiplications, exp(), pow() etc instructions. I don't really understand why it's so much slower with DirectCompute(), either. Could be that DirectCompute doesn't understand the way the kernel uses shared memory. Anyway, I've not finished this yet. Maybe I'll find a way to bring this up to speed. But I'm not hopeful atm...

I wonder if madvr can calculate temporal dithering for the display?
24fps source to 120hz display with frc can simulate 10bit from 8bit output and work with 8bit native displays...
even 10bit displays will benefit from less artifacts since it'll be 16bits -> 10bits instead of 16 -> 8 spatial dithering.
one problem I see is the rendering time required for 120fps...about 8ms
I've thought about this, too. But then, I don't really see how this would be better than error diffusion, and it would probably be slower than error diffusion.

According to my implementation of the algorithm of ED10 it should be possible to solve this by changing the weights to the following:

modified Floyd-Steinberg (multiplied by 0.9623):
0.5172
0.0601
0.1804
0.3007
-0.0962

madshi (unchanged):
0.7770
0.0000
0.0090
0.4861
-0.3098


This should lower the response on very black colours without changing the result much on lighter colours. Although it does lose the ability to express the difference between total black and only slightly black, but currently that seems to be more of a problem than a feature.
Thanks. I'll look at the low noise alternative algorithm again once the medium noise algorithm has been finalized.

After reading up on Multiply-with-carry random number generators I also believe that your original algorithm should be alright. The main advantages of the algorithm I provided is that it has a slightly larger period (4294967296 instead of 589823999) and it also works if the seed is 0.

But I now no longer have an explanation for why the algorithm you used made the output periodic. It would be nice if it's solved now but I have no idea why.
On solid colors, I'm seeing still seeing periodic repetitions exactly every 256 pixels, just like the previous builds. It unfortunately does not appear this issue was resolved with the new random number method.
That's what I'm seeing as well. So since we've now completely ruled out the possibility that the algorithm was wrong I guess that the problem must lie with the seeds that are used by the algorithm.
Yeah, it was my fault, after all. I used a global index for seeding which was provided by DirectCompute, and I thought it would be unique for every pixel. But in fact it was only unique for every pixel in a thread block. Anyway, this was easy to fix.

That new random algorithm changed the behavior of these quite a bit.

My initial impressions via test patterns:

First place "madVR - noisy 2". (This build appears to have the most uniform noise distribution)

Second Place "madVR ED7"

Third Place "madVR ED5"

Forth place "madVR - noisy 4.

Fifth place "madVR - noisy 3"

Sixth place "madVR - noisy 1"

I'll need to do some more tests later, but so far "noisy 2" seems to be my preferred choice.
Interesting. You seem to be prefering the old random generator over the new one. So I'll go back to the old one, just to be safe.

I do wonder whether we're down to judging patterns produced by different random distributions, rather than which error diffusion algorithm has the best weight configuration. But this problem should be solved by the seed bug fix (see above), which should now make everything totally random, without any repeating patterns. This way it could happen that "noisy 2" looks better in some parts of the image and worse in other parts. Or maybe not. If it still looks better everywhere then it was the weight structure which is better and not the random distribution.

Well I got bored, so I went ahead and made a madVR post-processing abuse comparison on a gradient heavy scene of Elephant's Dream. Includes some madVR debanding as well, since the 8bit lossless source had banding.

Source was frame 6999 png image from http://media.xiph.org/.
Thanks, this looks like a great test image.

-------

Here's a new improved version of the "noisy 2" algorithm with the following changes:

(1) random seed bug fixed
(2) went back to old random generator
(3) improved 16x16 boundary behaviour
(4) added limiter to avoid out-of-range stray dots

The last new feature costs a bit extra performance. Basically what it does is it stops error diffusion from creating values that are too far away from the original pixel value. E.g. if the pixel value is 20.5, the limiter forces error diffusion to create a pattern with only 20 and 21 values. Without the limiter, some rare 19 and 22 values could occur.

Please let me know whether this new build is a visual improvement or not, how much it affects performance and whether the visual improvement is worth the performance hit. Thanks!

http://madshi.net/madVRnoisyLimited.rar

[James Freeman]

Thanks cyberbeing.
I'd probably choose Option 1 with only one option, the best of the noisy builds which is far less noisy compared to random dithering.


Another topic altogether.
Does anyone use "TV - Double Expanded" option then tweak the Range levels to to suit the display/content?
I set range to 14-238 to match TV (16-235), or 11-238 to hide some of the black artifacts (macro blocks).
Or lift the whites on some extremely "low value whites" movies like "The Amazing Spiderman" (peak white in the whole movie is at 210 instead of 235).

I wanted to go beyond the 0-255 levels [(-5)-260] like "Levels" in ffdshow, but I found its not possible.
So using the Double Expanded & Custom Rage is a perfect solution as you can go UP or DOWN without clipping the greyscale.
It works like Brightness & Contrast on a TV would, not like b&c the we had in madVR till now.
MadVR is 16-bit so no resulting banding like with ffdshow.

I am in calibration bliss after finding this is possible.
Hope its useful info.

[ryrynz]

Here is part 2 with a scene from Big Buck Bunny, frame 9144

Legend. I still prefer N3, there's some areas where ED7 tends to appear to "mess" things up a bit in comparison..

I just like how the pixels fall in N3, although at times it trades blows with ED7. I find ED7 is just a tad too soft and I think people might prefer the more "accurate" pixel layout and sharpness of N3.


Please let me know whether this new build is a visual improvement or not, how much it affects performance and whether the visual improvement is worth the performance hit. Thanks!


Cyberbeing could I ask that you continue your comparison with the previous two images with this new build? Ta.

[madshi]

Or lift the whites on some extremely "low value whites" movies like "The Amazing Spiderman" (peak white in the whole movie is at 210 instead of 235).
You can add a tag "white=+25" to the Amazing Spiderman movie file name. That will modify the *source* white level, not the display white level. I believe that's a better approach to take for badly encoded movies.

[James Freeman]

You can add a tag "white=+25" to the Amazing Spiderman movie file name. That will modify the *source* white level, not the display white level. I believe that's a better approach to take for badly encoded movies.

Thanks madshi.
Where can I see all the filename command options?
Do I add the commands in brackets or apostrophes?

I also just noticed that its possible to change the blacks & whites with keyboard shortcuts on the fly.

This is perfect!
Exactly what I was looking for.

[madshi]

Search the changelog for "tag". And try which syntax works intead of asking... ;)

[cyberbeing]

I do wonder whether we're down to judging patterns produced by different random distributions, rather than which error diffusion algorithm has the best weight configuration.

Honestly at this point, this is exactly what I felt was occurring with that last set of 'noisy' builds. The underlying effects of each error diffusion algorithm feels subtle once the random noise is added, and I was very surprised how much appearance changed when the random method changed. Though really, the appearance of Filter-Lite & Floyd-Steinberg are rather close in appearance in the first place, even without random noise.

But this problem should be solved by the seed bug fix (see above), which should now make everything totally random, without any repeating patterns. This way it could happen that "noisy 2" looks better in some parts of the image and worse in other parts. Or maybe not. If it still looks better everywhere then it was the weight structure which is better and not the random distribution.
...
Here's a new improved version of the "noisy 2" algorithm with the following changes:

(1) random seed bug fixed
(2) went back to old random generator
(3) improved 16x16 boundary behaviour
(4) added limiter to avoid out-of-range stray dots


Thanks, this sounds like it will be an interesting build to test.

[leeperry]

Good example of how my preferred Noisy2 (which I've abbreviated as n2) comes out the smoothest with the least amount of chunky noise. Some people may not like that smooth aspect though, but I do find n2 closest to ed7 in that regard on my GDM-F520 CRT. Other displays very well may behave differently. Maybe tomorrow I'll do another one of these with the other open source videos on Xiph. madshi said he wanted votes, so hopefully things like this make it a bit easier to decide.
Oh, so ED7 isn't quite perfectly identical to N3 after all.....I found ED7 fuzzy looking and N3 so much better, good to know that I'm not entirely prone to placebo :D

I still prefer N3, there's some areas where ED7 tends to appear to "mess" things up a bit in comparison..

I just like how the pixels fall in N3, although at times it trades blows with ED7. I find ED7 is just a tad too soft and I think people might prefer the more "accurate" pixel layout and sharpness of N3.
Yep, N3 is the very obvious "primera calidad" choice with real-world content IME. Still can't really believe how good this looks :scared:

Interesting. You seem to be prefering the old random generator over the new one. So I'll go back to the old one, just to be safe.
Does that imply that N3 is gonna go back to 7? :(

Please let me know whether this new build is a visual improvement or not, how much it affects performance and whether the visual improvement is worth the performance hit.
Sounds good, I'll run a shoot-out against N3 then :)

the 7870XT Overheats and shuts down and stutters.
There's a price to pay for silence as it would appear "the XFX R9 290 DD Editions power temperature goal is the 95 degrees that AMD has set as the default (http://lanoc.org/review/video-cards/6812-xfx-r9-290-double-dissipation-edition?showall=&start=4)".

They are actually targeting the TJ max as default OOTB in order to keep the board as silent as technically possible, they should have forced a 5/10° undershoot IMO.

Not if you buy from ASUS, EVGA, MSI or Zotac. They explicitly allow a cooler change (if you don´t damage the card, of course) and they also state that on every forum and they even answer you by e-mail.

Examples of voided warranty. (http://www.gainward.com/main/support_detail.php?id=3)
Modifying the cooling-solution in any way.

Hearsay written on one review website is one thing but at the end of the day what matters is what their official warranty terms tell....but good to know that with enough whining/blackmailing there might be a way to still be entitled to RMA with some manufacturers. Still wouldn't risk it, though.

[TheLion]

Did you replace all the files, including mvrSettings.dll and madHcCtrl.exe etc? I could imagine that if you have an old version of one of those files lying around somewhere, they might interfere by not being able to store the new settings. E.g., I believe you're using J.River MC, right? Do you have a separate madVR installation on your harddisk for MPC-HC? Make sure you replace *both* madVR installations with the latest files.



Thanks for the reply. Yes, I replaced all files, made a reset to default options and only have a single madVR installation on my system - the JRiver "internal" one.
Differences in chroma upsampling are rather difficult to spot and evaluate - so I generally use this chart at first: https://drive.google.com/file/d/0B9JsGIAbr0VAaV91VEpCME5wYVE/edit?usp=sharing
I know this is everything but a real case video example, so I checked the rendering times using Blu-ray content.

The chroma chart shows the exact same outcome with ANY of the NNEDI's (16 through 256 neurons) as Jinc3. That's why I speculate that it might fallback to Jinc3 for some reason.
The rendering times are also exactly the same for NNEDI 16-256 as Jinc3.
Thanks!

[madshi]

Might make more sense to check with image doubling instead of chroma upsampling. The difference in image quality will be much bigger, so it will be easier to see whether NNEDI3 is active or not. If it's working for image doubling then I see no reason why it wouldn't work for chroma upscaling. I've not done real image quality tests yet to check whether NNEDI3 brings a noticeable quality improvement over Jinc for chroma upscaling.

[noee]

Please let me know whether this new build is a visual improvement or not, how much it affects performance and whether the visual improvement is worth the performance hit. Thanks!

fwiw, this version gets my vote. Testing with 1080p24 content only so far....I would add that the perf hit does not appear to be that great.

I noticed that with 10-bit encodes, my card just cannot do ED + SM without drops, turning SM off and all is well with ED. For example (1080p24 -> 1080):

ED + SM = GPU 93% with drops
ED only = 50%
SM only = 30%

With 8bit rips/encodes:

ED + SM = GPU 90% with *no* drops

Is this expected? Again, low end HD6570 with GDDR3.

[DarkSpace]

Might make more sense to check with image doubling instead of chroma upsampling. The difference in image quality will be much bigger, so it will be easier to see whether NNEDI3 is active or not. If it's working for image doubling then I see no reason why it wouldn't work for chroma upscaling. I've not done real image quality tests yet to check whether NNEDI3 brings a noticeable quality improvement over Jinc for chroma upscaling.
Uhm, some time ago I already mentioned that NNEDI image doubling silently fails for me (post (http://forum.doom9.org/showthread.php?p=1665634#post1665634)), and it stands to reason that the rest of the OpenCL pipeline (Chroma doubling, old Error Diffusion) also didn't work. I'm on an AMD HD6970M with the newest drivers, and would be more than happy to provide a debug log, but so far I've been waiting, while now it seems you simply missed my post.

[leeperry]

FWIW I still find the pop-effect of N3 to be much higher than with that fixed N2 but that's on a REC709 calibrated 3.5K:1 LCD, things might change on CRT/SXRD/OLED...hopefully these can the final low/mid noise candidates :)

[TheLion]

Might make more sense to check with image doubling instead of chroma upsampling. The difference in image quality will be much bigger, so it will be easier to see whether NNEDI3 is active or not. If it's working for image doubling then I see no reason why it wouldn't work for chroma upscaling. I've not done real image quality tests yet to check whether NNEDI3 brings a noticeable quality improvement over Jinc for chroma upscaling.

Would you mind taking just a quick glimpse at

https://drive.google.com/file/d/0B9JsGIAbr0VAaV91VEpCME5wYVE/edit?usp=sharing

to check the chroma upsampling behavior of NNEDI versus Jinc3 - it might be that they simply (and coincidentally) give the very same result in that "artifical test" :confused:

I will try to find some "stoneage SD content" to check the image doubling in the meantime ;)

Thanks alot!

[cyberbeing]

Please let me know whether this new build is a visual improvement or not, how much it affects performance and whether the visual improvement is worth the performance hit. Thanks!

I think this NoisyLimited (nLtd) build is a winner.

Distortion went way down, which appears to have increased sharpness and accuracy around fine detail by an order of magnitude. Smoothness improved from n2 build. Quality still seems superior overall to ED7. Periodic repetitions appear resolved. It eliminated the noise on black with my 3DLUT. Performance difference is rather insignificant on my GTX 770 (+0.35ms render , <1% GPU load difference). All of which is actually rather impressive, especially when I see it actually improved lossless PNG compression.

[xabregas]

Hi

Can anyone tell me if Chroma upsampling option affect downscaling?? I say this because when i use NNEDI 32 neurons in a 1080p video downscaled to 1360x768 and NNEDi is selected in chroma upsampling i get a party of dropped frames, but if i select bicubic the dropped frames stop. same with 16 neurons. Nothing selected in image doubling and downscaling method is lanczo 4 AR.



something interesting is when use ctrl J to see the dropped frames with NNEDI selected the render and present queues doesnt rise, stay at 0-2 and 0-3, with bicubic it goes to 15-16 in both.

I have hd7770 1GB and phenom x4 965

Everything is fine with 720p videos upscaled to 1360x768 with NNEDI 32 neurons and lanczo 4 AR. Problems appear only with 1080p videos downscaled to 1360x768 with NNEDI selected in chroma upsampling which is weird i think, because i never knew madvr used chroma option when downscale a video...

TIA

[Ver Greeneyes]

FWIW I still the pop-effect of N3 to be much higher than with that fixed N2It seems like the pop effect is helped by adding some noise? But that should probably be separate from the actual dithering, which just aims to accurately reproduce fractional colors. Just wondering if we're not starting to conflate two different things here :) (like conflating debanding with deblocking)

[leeperry]

It seems like the pop effect is helped by adding some noise? But that should probably be separate from the actual dithering, which just aims to accurately reproduce fractional colors. Just wondering if we're not starting to conflate two different things here :) (like conflating debanding with deblocking)
N3 would appear to be a fixed ED7 and the latter was most everyone's favorite. All roads lead to Rome, at the end of the day what matters is the end-users's subjective experience and N3 looks out of this world IME.

madshi said that he would consider providing one low and one mid noise level algorithms and then possibly only ED7.......maybe that fixed N2 & original N3 would be the perfect candidates as cyberbeing seems to be using a CRT that comes with a very high native but low ANSI contrast and there are some ppl who like noise-free video and some who are willing to accept more noise if it looks more "popping" :)

If the original N3 isn't chosen for whatever reason, a debug registry key to force it would be most appreciated so I won't be stuck with an old beta forever :o

[Ver Greeneyes]

maybe that fixed N2 & original N3 would be the perfect candidates as cyberbeing seems to be using a CRT that comes with a very high native but low ANSI contrast and there are some ppl who like noise-free video and some who are willing to accept more noise if it looks more "popping" :)
Sure, I'm just wondering if dithering is the right or only place to achieve the extra popping :) Either way it would be nice to have a version of 7/N3 with the fixes from the fixed N2 so you can see what those do to the effect for you (for one thing, the random seed bug would have affected the random number algorithm from both 7 and N3).

[madshi]

Is this expected? Again, low end HD6570 with GDDR3.
Don't know, maybe.

Uhm, some time ago I already mentioned that NNEDI image doubling silently fails for me (post (http://forum.doom9.org/showthread.php?p=1665634#post1665634)), and it stands to reason that the rest of the OpenCL pipeline (Chroma doubling, old Error Diffusion) also didn't work. I'm on an AMD HD6970M with the newest drivers, and would be more than happy to provide a debug log, but so far I've been waiting, while now it seems you simply missed my post.
I'm not sure what to say or do about this. madVR tries to use OpenCL, and if it works, it works. If the OpenCL APIs error out, there's not much madVR can do about it.

I will try to find some "stoneage SD content" to check the image doubling in the meantime ;)
Stoneage SD is often very soft, which is not ideal test material for NNEDI3. What you need is rather sharp or aliased source content. Try a high quality Blu-Ray, upscaled to 4K. Or use a very sharp and detailed photo.

I think this NoisyLimited (nLtd) build is a winner.

Distortion went way down, which appears to have increased sharpness and accuracy around fine detail by an order of magnitude. Smoothness improved from n2 build. Quality still seems superior overall to ED7. Periodic repetitions appear resolved. It eliminated the noise on black with my 3DLUT. Performance difference is rather insignificant on my GTX 770 (+0.35ms render , <1% GPU load difference). All of which is actually rather impressive, especially when I see it actually improved lossless PNG compression.
Sounds good! So it seems my algorithm changes helped.

Now we still have 3 possible variations left:

(1) Floyd-Steinberg vs. Filter Lite.
(2) Weight sum 1.0 vs. weight sum 0.97.
(3) Old random generator vs. new random generator.

Every of these small differences will change the output. The old 4 noisy builds were all possible combinations of (1) and (2), using the new random generator. Should I create 8 builts now to cover all variances, so we can make a final decision? Or how can we decide which of the 8 possible variations is the best overall solution?

Can anyone tell me if Chroma upsampling option affect downscaling??
Yes. Chroma is always upscaled first. Then the image is converted to RGB. Then it's upscaled or downscaled to the final output resolution. Using NNEDI3 for chroma upscaling is a bit overkill if you don't have a monster GPU. I'd recommend using NNEDI3 only for luma doubling.

[cyberbeing]

Now we still have 3 possible variations left:

(1) Floyd-Steinberg vs. Filter Lite.
(2) Weight sum 1.0 vs. weight sum 0.97.
(3) Old random generator vs. new random generator.

Every of these small differences will change the output. The old 4 noisy builds were all possible combinations of (1) and (2), using the new random generator. Should I create 8 builts now to cover all variances, so we can make a final decision? Or how can we decide which of the 8 possible variations is the best overall solution?

Ugh... as much as I hate how time consuming it is, I'd say once again provide all combinations together in a blind test, and this time really keep all variables a secret till the end so people do not become biased. Reveal the answers to (1), (2), (3) only once the finalized decision is made and included in your next madVR release build.

It seems like the pop effect is helped by adding some noise? But that should probably be separate from the actual dithering, which just aims to accurately reproduce fractional colors. Just wondering if we're not starting to conflate two different things here :) (like conflating debanding with deblocking)

That's usually the case, and is why a lot of movie-quality anime actually add grain in post-production to give the everything more grit and perceived sharpness. I've even see one studio, instead of adding traditional high frequency grain, added low frequency grain which gave all the flat anime coloring and gradients a very pleasing texture.

An error diffusion build with amount of noise on the same level as 'random dither' would probably look quite nice on some noise-less content. Though overall, I think madVR gaining some kind of non-temporal luma-adaptive "add grain" control would suit this need better.

N3 would appear to be a fixed ED7

N3 wasn't a fixed ED7, it was only ED7 with different random method. The original hope was it would resolve the repetition, but it didn't. This latest noisyLimited is the first we've had with actual bug-fixes:

(1) random seed bug fixed
(3) improved 16x16 boundary behaviour
(4) added limiter to avoid out-of-range stray dots

[leeperry]

Should I create 8 builts now to cover all variances, so we can make a final decision?
I don't see how PQ could improve over N3 from a purely subjective point of view, but you've grown that habit of always forcing us to expect the unexpected so please bring the pain in the hope of finally getting it over with :devil:

[Shiandow]

(1) random seed bug fixed
(2) went back to old random generator
(3) improved 16x16 boundary behaviour
(4) added limiter to avoid out-of-range stray dots

The last new feature costs a bit extra performance. Basically what it does is it stops error diffusion from creating values that are too far away from the original pixel value. E.g. if the pixel value is 20.5, the limiter forces error diffusion to create a pattern with only 20 and 21 values. Without the limiter, some rare 19 and 22 values could occur.

Interestingly my code actually becomes faster by implementing (4). It saves me from having to do an inverse gamma correction when I add the error. You may not be able to do the same since we seem to use very different methods but I thought you might find it interesting.

Using the notation, 'x' for the original value, 'error' for the (gamma corrected) error that is being diffused to that pixel, 'f' for the gamma correction and 'finv' for the inverse gamma correction. The method I used was something like the following:


temp = finv(f(x) + error)
if (f(x) + error) < 0.5*(f(floor(temp)) + f(ceil(temp)))
{ result:= floor(temp);}
else
{ result:= ceil(temp);}
newerror = (f(x) + error) - f(result);


But if the final value must be either floor(x) or ceil(x) then I can just use:


if (f(x) + error) < 0.5*(f(floor(x)) + f(ceil(x)))
{ result:= floor(x);}
else
{ result:= ceil(x);}
newerror = (f(x) + error) - f(result);


This saves me the trouble of calculating the inverse gamma correction.

[madshi]

Interestingly my code actually becomes faster by implementing (4). It saves me from having to do an inverse gamma correction when I add the error. You may not be able to do the same since we seem to use very different methods but I thought you might find it interesting.
Yeah, quite interesting. Unfortunately it doesn't work this way for me. My code got more complicated and used more registers. Actually I'm a bit surprised that the performance hit is as small as it is with my code.

Anyway, does the change improve image quality in your tests, too?

Ugh... as much as I hate how time consuming it is, I'd say once again provide all combinations together in a blind test, and this time really keep all variables a secret till the end so people do not become biased. Reveal the answers to (1), (2), (3) only once the finalized decision is made and included in your next madVR release build.
Ok, will do. So here are the new test builds:

http://madshi.net/madVRnl.rar

I'd really like to finish the medium-noise error diffusion finding process now. So I hope you'll like one of these, and hopefully more than any of the older builds.

[James Freeman]

I'd really like to finish the medium-noise error diffusion finding process now. So I hope you'll like one of these, and hopefully more than any of the older builds.

What do you mean by "medium-noise" madshi?
Can we predict 3 levels (low, medium, high) of ED? :)

[nevcairiel]

high noise is random dithering. :p