madVR - high quality video renderer (GPU assisted)

[madshi]

Originally Posted by coolcat

Hi, I have a question, Advise me anybody please.
I use 60Hz monitor.
madVR Smooth Motion is off.
When I enter the Full Screen Exclusive Mode, fps is changed to 60fps with Smooth Motion off.
Is it a normal situation?
Full Screen Exclusive Mode always changes fps?

If you don't activate the madVR display mode switching functionality then madVR asks Windows which refresh rate your GPU is currently outputting, and then madVR tells Direct3D to use that refresh rate for Fullscreen Exclusive Mode. It seems that either Windows is telling madVR that your desktop is using 60Hz. Or alternatively Windows is telling madVR the correct refresh rate, but Direct3D switches to use the correct refresh rate and insists on using 60Hz against madVR's wishes. Things like this could happen if you use 3rd party tools to modify the refresh rate, like e.g. PowerStrip or something like that...

Originally Posted by The 8472

Any way how I can narrow down who's the culprit here between lav, madvr and mpc-hc?

Maybe I could narrow that down - if I could reproduce the problem here. But currently I can't...

Originally Posted by cyberbeing

So far I've only done one test pattern test (next I'll need to do real content tests), but here are my initial results:

_____

Top 6 (best to worse) for the ones which appear random:
7
3
9
10
5
1

Notes for random set:
7 has the most uniform distribution of noise out of all of them by far, which results in lowest distortion and sharpest result
5 & 7 do not have any dithering artifacts, and have fine-grained noise
3 has the lowest noise on black, and has medium-grained noise
1 has large-grained noise, and bad crosstalk, and extreme amount of noise on black
9 & 10 seem similar to 3, but with larger checkerboard patterns

_____

Top 5 (best to worse) for the ones which have non-random patterns:
2
"directcompute test build 3"
6
8
4

Notes for non-random set:
6 is unique, as the only only which does not add even a single dot of noise to black with my 3DLUT.
8 has bad crosstalk, 2 & 4 have moderate crosstalk, 6 has the lowest crosstalk
6 & 8 produces rather distinct 16x16 blocks in its pattern.
2 & 4 have vertical lines in their patterns.
4 has chunky pattens
I've listed directcompute test build 3 here as well, since it has slightly different behavior then the others.

_____

Edit: Added 9 & 10

I don't like the categorizing into random and non-random. That's a technicality. The key difference should be looks, not technique. So please split the algorithms into "low noise" and "medium noise".

Into which category belong 9/10? Low-noise or medium noise? My eyes say low-noise. Do you disagree? If you agree with me, then it's unfair to expect 9/10 to be as artifact-free as the algorithms in the medium noise group.

Originally Posted by 6233638

To me, 7 seems very noisy near black compared to some of the others. It also seems to display noise in horizontal bands with some shades.

Please don't concentrate on "near black" too much. The key thing is overall looks. We'll have to look for a solution for your 3dlut black level problem elsewhere. This should not be the deciding factor for choosing the error diffusion algorithm.

So which algorithm do you prefer in the "low noise" group and in the "medium noise" group, when not looking at "near black" results, only?

Originally Posted by cyberbeing

So far, my top two are ED7 (patternless, medium-low noise, very low crosstalk) & ED3 (low pattens, very low noise, low crosstalk) for the 'error-diffusion + random' slot.

ED5 (patternless, medium-low noise, low crosstalk) sits in a middle, as it's not very memorable being similar yet worse than ED7.

The worst two are ED9 & ED10 (medium patterns, low noise, medium crosstalk), with ED10 seemingly producing more 'strange' artifacts then ED9.
(ED1 I'm no longer testing since it's too noisy.)

From what I can see, ED3 has lower noise than ED7, but a little bit more noise than ED9/10. Again, please don't group algorithms for randomness, but please group them for looks alone.

I need to think about end users. They won't like one option to be called "error diffusion with some random" and "error diffusion without random". That won't help them choose. They want "error diffusion, low noise, mild artifacts" and "error diffusion, medium noise, no artifacts" as options. So that's what we need to classify the algorithms in.

Originally Posted by bacondither

Madshi you said that you are using alternating direction inside every 16x16 block.
Mabe using a method like in http://www.idav.ucdavis.edu/func/return_pdf?pub_id=1049 would help to eliminate these 16x16 blocky clusters of dots.

"Block interlaced pinwheel error diffusion with spiral or serpentine scan path" and

"The scan path goes outward for gray blocks, and inward for white
blocks. Note that during the processing of gray blocks, we diffuse errors from the gray blocks to the white blocks across block boundaries. To process each pixel, we first threshold the pixel value, then diffuse the quantizer error to its neighbors according to an error-weighting matrix..."

Originally Posted by Shiandow

That would be a nice addition, but it seems like it would be hard to actually implement. Not to mention that using that method on the same 16x16 blocks would use half the amount of threads so this could make it twice as slow. Although if this allows a smaller block size then it might actually be faster. Any block size from 10x10 or lower should allow more threads to work in parallel.

I read that paper before writing my OpenCL error diffusion algorithm. I decided against using the idea in that paper for 2 reasons:

(1) It would be MUCH slower than my current algorithm. I don't know how much slower since I didn't test it. But my current algorithm gets along with only one memory read & write for each pixel. All the error spreading is done in registers, only. With the algorithm suggested in that paper I'd have to store errors in GPU RAM, which would require multiple memory reads & writes for every pixel, which would cause a big slowdown in the algorithm.

(2) The spiral scanning path produces patterns which don't look very nice, IMHO.

Originally Posted by Skankee

9 and 10:
i still prefer 4 and 2 because it is more smooth at my test-sample.

Please check with more than just one test sample.

Originally Posted by Shiandow

They don't seem to repeat every 16x16 block. I suspect that it is more a limitation of the random number generator, for some reason the random number generator just repeats itself. This also seems to happen on non-black colours, in my case it seems to repeat every 224 pixels. I strongly suspect that the algorithm somehow uses the position as seed for the random number generator and this seems to cause it to repeat itself when presented with identical content.

The position is used as seed, but the position varies for every pixel, so this seed shouldn't cause repetitions. The random algorithm itself is extremely simple and probably not very good, but then it's very fast. Here's the code:

float random(inout uint randomHelper)
{
  randomHelper = 18000 * (randomHelper & 0xffff) + (randomHelper >> 16);
  return ((float) (randomHelper & 0xffff)) / 65535.0f;
}

Basically it's "multiply-with-carry" in 16bit. I'd love to use something better, but it would need to perform well, and I'm not really sure it would improve image quality much.

Originally Posted by leeperry

7 is interesting but it's too fuzzy, 5 is the perfect in-between the sterile picture of 2 and the noisy 7....It looks very natural and highly enjoyable. I dearly hope that 5 will be nomitated as I really like the look

Hmmmm... Yesterday you preferred 7 and said that it would have very low noise. From my tests it seems that 5 and 7 are very similar. And most other users seem to prefer 7 over 5.

Originally Posted by Seedmanc

So has the nnedi thing been fixed yet? Doesn't seem to work on my GTX 560.

It's not my problem to fix. It's an NVidia driver bug. NVidia is aware of the bug, hopefully it will get fixed soon. For now you have to downgrade to older drivers, where the problem doesn't occur.

Originally Posted by 6233638

In real-world images like this, it does seem that 7 is producing better results than anything else, and the noise does not seem to be that much higher.

Originally Posted by GREG1292

Build 7 is best for my projector and has plenty of pop plus a very clean picture. Don't know if I can improve on my settings but I use needi3 64
and dxva2 for the other 2. Gpu and CPU Q are 24/32 all quality settings unticked and doubling 256 for both luma and chroma on a gtx770 with nvidia 327.43. Picture is amazing with no frame drops. Might look a little
over the top but that's the way I like it. Same settings on build 2 not
playable. Custom fan curve gpu never gets hotter than 60 Celsius.
My vote so far is for 7 and all I can say is wow!!!!!!!!!! Thanks for the awesome work 720p and 1080p movies are so real looking and no black
artifacts or noise seen in the image. Using a Mitsubishi Hc7900 on a 92"
screen sitting 12 ft back and gives the feeling of being inside the screen.
So I would say that build 7 is my favorite so far for a movie watcher enthusiast.

So it seems build 7 is a favorite of many people. So I'm wondering: Does anybody still need a lower-noise algorithm than 7? Or maybe I could use build 7 as the only error diffusion algorithm?

If a lower noise algorithm is still in demand, there doesn't seem to be any consensus about that yet. Earlier many people liked build 2. But, personally, I think build 10 is better than 2 (same noise level, less patterns).

Thoughts?

[leeperry]

Originally Posted by GREG1292

Build 7 is best for my projector and has plenty of pop

Yes, I fully agree that 7 gives the best pop effect but I personally far prefer the clearer look of 5...7 on my Sammy TV is fatiguing to look at compared to 5 as the picture is much fuzzier, I'm entirely willing to trade some pop for clarity but it depends on so many factors that :

Originally Posted by cyberbeing

maybe we need three variants to make everyone happy...

maybe 2/5/7 would be great to please everybody, calling them low/mid/high noise for instance.

Originally Posted by madshi

Hmmmm... Yesterday you preferred 7 and said that it would have very low noise. From my tests it seems that 5 and 7 are very similar. And most other users seem to prefer 7 over 5.

I wanted to postpone because running this kind of test at 6 PM isn't the best idea and I suspected that my TV needed to be recalibrated anyway. It takes some time and a lot of attention to make a good opinion on real-world footage.

[madshi]

Maybe you can retry tomorrow morning and compare 5 and 7 another time? I'm asking because everyone else seems to prefer 7 over 5. I will definitely not offer 3 options. Max 2. Actually I'm thinking about offering only 7 as the only option. Unless there are several users preferring some of the other algorithms over 7, but then we'd still need to find some sort of consensus about which algorithm to pick as an alternative to 7. My personal favorite would be 10, but other opinions on this are welcome.

[madshi]

Originally Posted by bacondither

Screenshots from big buck bunny with the brightness severly lowered in madvr to push many pixels to the low end of the 8 bit spectrum and then i brighten the image to reveal the dither noise in a image more realistic then solid grey bars...

A lot of pictures of a bunny with different dithering methods

Build 10 looks good but with a minimal grid pattern. Build 7 is free from artifacts and have a slightly higer noise level, but still it is lightyears lower then fully random dither.

Can you upload a small sample with this scene? It seems to be a good test case. Thx.

[Shiandow]

Originally Posted by madshi

float random(inout uint randomHelper)
{
  randomHelper = 18000 * (randomHelper & 0xffff) + (randomHelper >> 16);
  return ((float) (randomHelper & 0xffff)) / 65535.0f;
}

Basically it's "multiply-with-carry" in 16bit. I'd love to use something better, but it would need to perform well, and I'm not really sure it would improve image quality much.

It's probably not a good idea to multiply by 18000 since this will effectively shift the bits of randomHelper which has some weird consequences. I think it would be better to use something like:

float random(inout uint randomHelper)
{
  randomHelper = 1103515245 * randomHelper + 12345;
  return ((float) (randomHelper & 0x7fff8000)) / 2147450880.0f;
}

or just use any other set of numbers from this page.

[GREG1292]

Coming from SVP 7 is the best for my setup. Clarity is not an issue on a large screen maybe one for flat panels and one for projectors???


Sent from my iPhone using Tapatalk

[Anima123]

Madshi,

There's a very good PRNG Mersenne Twister, you can access it at *http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html, where there's a new variant for Graphic Processors (MTGP). You might want to take a look at it.

Regards,
Anima123

[madshi]

Originally Posted by Shiandow

It's probably not a good idea to multiply by 18000 since this will effectively shift the bits of randomHelper which has some weird consequences.

Why would it shift the bits of randomHelper? It is 18000, not 0x18000. This is the well-known multiply-with-carry algorithm. It's not perfect, but it should work reasonably well. Give it a try. You might be surprised by how well it works. The main limitation comes from using only 16bit math. It would be better to use 32bit math. But unlike OpenCL, DirectCompute doesn't have a "mul_hi" instruction. So I don't know how to get the upper 32bits of the 64bit multiplication result, when multiplying two 32bit numbers.

Originally Posted by Shiandow

I think it would be better to use something like

The result of your multiplication needs more than 32bit, but your code doesn't reflect that. That's probably a simplification of the algorithm which could hurt the quality of the random numbers.

Originally Posted by Anima123

There's a very good PRNG Mersenne Twister, you can access it at *http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html, where there's a new variant for Graphic Processors (MTGP). You might want to take a look at it.

From what I can see I think this would be multitudes slower than the algorithm I'm using. I need something very simple and fast. It doesn't have to be encryption quality.

[Matthias Hutter]

On 0.87.4:
Playing SD content at 200% (720x406 -> 1440x812)

Case 1: Using NNEDI3 color upscaling
* observed result: video plays, but missing chroma (green screen).

Case 2: Using NNEDI3 image doubling
* observed result: video freezes, 0% GPU usage, GPU down-clocks into fallback mode

setup: Quadro K2000M (~660M)
driver version 320.27 WHQL/ 331.82 WHQL

(So probably the same D3D9 interop issue, but downgrading drivers doesn't solve the issue for those GPUs)

Originally Posted by James Freeman

Does it also solve the blue whites problem?

I have never encountered that problem - I don't know, but it does fix black level rise perfectly.

[leeperry]

Originally Posted by madshi

Maybe you can retry tomorrow morning and compare 5 and 7 another time?

Well, I just tried again to roll 5 & 7 on many different kinds of movies as I wanted to ensure that it wasn't a bad case of teh placebo and 7 always looks noticeably fuzzier than 5 to me....which is a major bummer if you seriously plan on ditching 5 altogether

Originally Posted by madshi

Actually I'm thinking about offering only 7 as the only option.

Basing this kind of most crucial decision on the experiments of half a dozen users here on d9 seems pretty drastic to me...there's no worse, there's no better........it all depends on the end-user taste and equipment. He's the one watching the movies, he's allowed to make his own decision. Again, better have too many options than not enough.

I kinda fail comprehending how you can reasonably expect a single dithering algorithm to make everyone equally happy, mostly because all displays run their own internal dithering(best case scenario being 12 bit to 8bit, otherwise plain 8bit or worse 6bit TN)....you cannot seriously expect all displays to react identically to the type of dithering noise/pattern that's being fed to them. And some ppl like a noisy picture, others like it a bit noisy when OTOH others cannot stand any kind of noise in their video...and let's not mention colorblinds, for whom I'm more than likely the only rep here.

Originally Posted by madshi

My personal favorite would be 10

The "trade quality for performance" mVR tab currently has a section called "these should not be used, but you're the boss"...well, you don't say...I'm the boss of my PC and I like 5 far better than the others, I really don't see what the big deal would be to add another option for ED.

Can you imagine iZotope Ozone 5 Advanced coming with one single dithering algorithm?

Ozone provides the finest wordlength reduction algorithms available

You prefer 10, fine! You're the boss too

I'm sure there are some ppl who would prefer 2, especially on a noisy display....I'm quite sure I would hate 7 on a DLP tbh.

Anyway this wasn't a waste of my time as I'm extremely impressed by the PQ I'm getting with 5(Floyd–Steinberg FTW) and if I have to stick with this beta(hopefully not timebombed ^^) then be it, one less thing to worry about I guess

[peplegal]

Originally Posted by madshi

I need something very simple and fast. It doesn't have to be encryption quality.

My HD6450 really appreciates every single action you take of keeping this project lightweight.

Thank you.

[Shiandow]

Originally Posted by madshi

Why would it shift the bits of randomHelper? It is 18000, not 0x18000. This is the well-known multiply-with-carry algorithm. It's not perfect, but it should work reasonably well. Give it a try. You might be surprised by how well it works. The main limitation comes from using only 16bit math. It would be better to use 32bit math. But unlike OpenCL, DirectCompute doesn't have a "mul_hi" instruction. So I don't know how to get the upper 32bits of the 64bit multiplication result, when multiplying two 32bit numbers.


The result of your multiplication needs more than 32bit, but your code doesn't reflect that. That's probably a simplification of the algorithm which could hurt the quality of the random numbers.

The algorithm I gave is supposed to only use the last 32bits of the answer of the multiplication, I assumed this would be done automatic. From what I understand from the explanation of multiply with carry on wikipedia, your algorithm should work as well but for some reason it doesn't seem to. It might be that multiply with carry performs badly on some seeds, but it seems more likely that the seeds aren't different for some reason.

Edit: by the way you could get the upper 32 bits of the product of two 32 bit numbers x,y by calculating ((x >> 16)*(y & 0xffff) + (x & 0xffff)*(y >>16)) >> 16 + (x >> 16)*(y >> 16) but this might be too slow.

[fairchild]

where is the link to the latest ED dither pack so I can check out this version 7 to test on my plasma.

I tried searching but there were a few updates posted by madshi and not sure which has the pack in it.

Edit: found it http://madshi.net/madVRedtest.rar

[Shiandow]

@fairchild

You may also want to try http://madshi.net/madVRedtest3.rar.

[cyberbeing]

Originally Posted by madshi

I don't like the categorizing into random and non-random. That's a technicality. The key difference should be looks, not technique. So please split the algorithms into "low noise" and "medium noise".

Random vs non-random is more than a technicality. All of the non-random ones are essentially zero noise, and their end-to-end seamless patterns is their defining look. Which behaves best in the non-random category comes down to which one has the fewest artifacts. Personally I dislike the look of all of the non-randoms, but I believe that ED2 is the most well-behaved out of them.

Originally Posted by madshi

Into which category belong 9/10? Low-noise or medium noise? My eyes say low-noise. Do you disagree? If you agree with me, then it's unfair to expect 9/10 to be as artifact-free as the algorithms in the medium noise group.

From what I can see, ED3 has lower noise than ED7, but a little bit more noise than ED9/10. Again, please don't group algorithms for randomness, but please group them for looks alone.

ED9 & ED10, fall into the same noise level category as ED3. These are the ones which I'd consider the half-way points between low & medium noise. Personally since I dislike the appearance of the completely noiseless non-randoms, I'd classify them in the 'low-noise' category. ED7 & ED5 would then sit alone in the medium-noise category.

I personally find the appearance of ED9 superior to ED10. They both have near-identical pattern distribution and noise-level, but ED10 produces more artifacts in my tests.

Originally Posted by madshi

I need to think about end users. They won't like one option to be called "error diffusion with some random" and "error diffusion without random". That won't help them choose. They want "error diffusion, low noise, mild artifacts" and "error diffusion, medium noise, no artifacts" as options. So that's what we need to classify the algorithms in.

If I was really going to narrow it down, my top 3 combinations for a medium noise and low noise category would be the following from best to worse:

Medium Noise: ED7 | Low Noise: ED3

Medium Noise: ED7 | Low Noise: ED9

Medium Noise: ED7 | Low Noise: ED2

Edit: Though if leeperry, who is colorblind, really finds ED7 more fuzzy than ED5, I'd be okay with swapping that in instead.

[kerimcem]

my old video card 3650 ati dont work all test version,How to shut down d.c option?

[fairchild]

I just tried ED7 and ED10 and I honestly can't tell much of a difference even when looking at a very close distance 4-6 feet. I will leave it to madshi and the other's which seem to have a better grasp on things when it comes to dithering methods.

I will just be happy if the version that ends up being picked is a low noise version which is what will end up looking best on my plasma which inherently does dithering at different levels. Out of curiousity, where does the standard random dithering which has been used by madVR for years until it finally switched to the new ED version fares as far as noise level? Is it considered low-noise?

[Werewolfy]

Originally Posted by fairchild

Out of curiousity, where does the standard random dithering which has been used by madVR for years until it finally switched to the new ED version fares as far as noise level? Is it considered low-noise?

Very high noise level

Originally Posted by madshi

So it seems build 7 is a favorite of many people. So I'm wondering: Does anybody still need a lower-noise algorithm than 7? Or maybe I could use build 7 as the only error diffusion algorithm?

If a lower noise algorithm is still in demand, there doesn't seem to be any consensus about that yet. Earlier many people liked build 2. But, personally, I think build 10 is better than 2 (same noise level, less patterns).

Thoughts?

My favorite one is 7 too and I don't mind if you only use this one because I don't like low noise algorithm, it seems there is more banding when there is less noise and the picture appears to be less sharp. But if I had to pick one between 2 and 10, I'd choose 10.

[noee]

madshi, I (and my 7 year old with amazing eyes and ears) prefer 10 and then 7 in my viewing scenario. I tested (for what seems now like days on my older 1080p IPS panel) with *only* SD and 1080p24 material (no test patterns at all), so take it fwiw. I now get what leeperry and others say about "pop effect" now that I have spent so much time rolling these things.