madVR - high quality video renderer (GPU assisted)

[GREG1292]

Dynamic color has a little more depth and texture than
the mono dynamic. Realism is amazing. Both are better than adaptive4.
chroma needi32
doubling needi 64 luma
upscaling lancos4
downscaling jinc4
GTX770
Can see the improvement right away. Nice job madshi:)

[madshi]

Multicolor dither clearly lowers the perceived amount of noise in the image compared to monochromatic dither in my opinion, even though one of the aspects of Error Diffusion that I liked was that a monochrome image stayed monochrome.
So you do prefer the multiColor dither over monoColor?

However, the dynamic builds add a huge amount of noise compared to the static builds when using the 4-bit mode.
But the trade-off is that the dither pattern itself is more visible with a static pattern.
Agreed. Although, try the new "oppositeColor_dynamic" build. I think the noise is not so bad with this build, even in 4bit mode.

I wonder if this is due to your color blindness. Certain colors which should appear to be "opposites" and cancel out in the dithering, may appear to be the same color to you and seem to add noise?
This does sound like a very reasonable/probable explanation!

[madshi]

Dynamic color has a little more depth and texture than
the mono dynamic. Realism is amazing. Both are better than adaptive4.
chroma needi32
doubling needi 64 luma
upscaling lancos4
downscaling jinc4
GTX770
Can see the improvement right away. Nice job madshi:)
Thanks! Please also try the new oppositeColor build.

[6233638]

So you do prefer the multiColor dither over monoColor?Definitely - there's a lot less noise using the multiColor dither rather than monoColor.

Agreed. Although, try the new "oppositeColor_dynamic" build. I think the noise is not so bad with this build, even in 4bit mode.I've only done some quick testing, but this build does seem to reduce the noise even further, compared to the multiColor build.
While it looks worse in the 4-bit mode, I do think that the dynamic build is the way to go when dithering to 8-bit.

[nautilus7]

Once, again an improvement, at least for me. Opposite Dynamic is better than everything else.

Is it normal that there are dither dots in the black bars on top and bottom of the video? The bars are art of the video, but should they ave dither dots? I think this has been discussed before?
Also, in full screen mode, the pop up progress bar has also dither dots. Is this normal? I see them in 4bit mode.

[leeperry]

I wonder if this is due to your color blindness. Certain colors which should appear to be "opposites" and cancel out in the dithering, may appear to be the same color to you and seem to add noise?
My brain likes its colors as close to primaries as possible, I cannot identify pastel colors for instance so yeah I don't want their tint to constantly roll :scared:

Anyway I just tried those two news builds and the picture looks much deeper, clearer and far more impressive with ED4...and without all that nasty headaches-prone chroma noise constantly dancing around, so I'll be waiting for you guys on the other side of that bridge ;)

[noee]

JFMI: Why? In which way do they look better than with the multiColor_dynamic build?

non-motion scenes with edges against dark background looked clearer. For example, humans in the foreground against a dark background, just standing there (Farscape: PeaceKeeper Wars, a terrible quality DVD).

[Ver Greeneyes]

If you want to do something like that then it'd be better to use a bitwise xor instead of a multiplication. If you multiply them then the result will no longer be uniform. For instance, the product of two random integers has a 3/4 chance to be even.We're talking floating point numbers here though. I don't think it really matters if the least significant bit happens to be 0 3/4 of the time. Anyway, I wanted to avoid bitwise operations since GPUs are more aimed at floating point, but I couldn't find any GPU-centric algorithms for hashing two values together. Multiplying with a hash of the color, while not truly random, seemed like it might still look good enough.

[Shiandow]

Basically this build uses the same random distribution for the red and blue channel, but the exact "opposite" (negative) random distribution for the green channel. This should further lower the luma noise level, and it might also lower the chroma noise level a bit (compared to multiColor), or at least make it slightly more predictable. Thoughts?

How exactly did you make the green channel "opposite"? I ask this because the most obvious solutions would mean that not every value with r+g+b=0 is equally likely. Basically whenever r has a high value this limits the 'amount' of values that g and b can have so high values of r should be less likely. I tried to do the math and got that the following should give you a 'uniform' distribution


if rand1<0 {r= 2*(rand1*(1+rand1))}
else {r= 2*(rand1*(1-rand1))}
g= (2*rand2)*(.5-abs(r));
b=-(r+g);


This assumes that rand1 and rand2 are random values between -0.5 and 0.5;

Edit: I seem to have fucked up somewhere, but I'll figure that out after I've had some sleep.

[*Touche*]

DirectCompute, and performance should be noticeably better than v0.87.4. At the moment I'm not looking at performance, though, but just at image quality.

Unfortunately, I don't seem to get a performance benefit. Strange.

Anyway, tried the Opposite_dynamic build. A slight improvement over multiColor_dynamic. Good job!

[cyberbeing]

Still don't like the dynamic builds at all on low-motion content. It makes the entire image feel energetic when it should be calm, making it difficult to pick out details from behind the dither. The 'oppositeColor' dynamic build seems to just make this worse for me. Oh well, I'll just go with the flow with whatever is decided.

madshi, could you try making a half-rate (every second frame) and third-rate (every third frame) dynamic dither builds, where the random seed updates less often? I'd be interested in seeing what that looks like. Curiosity only.

[iSunrise]

Are you talking about this from a theoretical point of view? Or have you actually tested the multiColor builds and found them not to your liking?
Yes, when I did my post, it was purely from a theoretical POV. I´ve since only done some fast comparisons, but I didn´t come to a conclusion, yet. I´m not sure how others are able to come to conclusions that fast, but I personally need some time, because we have to consider various different sources with all these new builds.

madshi, could you try making a half-rate (every second frame) and third-rate (every third frame) dynamic dither builds, where the random seed updates less often? I'd be interested in seeing what that looks like. Curiosity only.
I guess you would see some kind of "popping effect" if there´s no regular updates along with original frames of the video.

I must say that I´m still not sure about all these new builds, either, while I was really satisfied with ED4, I kind of fear that we go a bit overboard with this now and if I read of noise-cancellation (which is a method e.x. Apple uses for the iPhone for instance by utilizing 2 microphones at the speaker side and one at the back to make recordings and mathematically subtract the noise sample from the speaker side sample, so that only your voice will be left, which is actually quite intelligent) I fear a bit that we actually lose some original source noise with it. But I´m not sure of my fears are entirely warranted, yet.

Still not done with all my testing, though, it´s kinda hard to actually judge based on moving images, when static images tell you a different story.

Also, with all the dynamic builds, it is not possible to make exact screenshots anymore, since the noise even continues to move even in paused mode. And even if not paused, it would still be different everytime you seek to a certain keyframe, because they now seem completely random, so that also has a negative side to it. I noticed that after I jumped to the same keyframe several times in a row.

[GREG1292]

Thanks! Please also try the new oppositeColor build.

I prefer the dynamic color build. Both are good but more depth in the image. Opposite build is 2ms faster. Color
seemed the same on both. Thanks madshi

[mandarinka]

[bug report not related to the currently-tested stuff]

I found that when making a screenshot (using the screenshot fucntion of MPC-HC, not grabbing with printscreen) of a video that has merely mod2 height, MadVR seems to add black padding at the bottom. For example, with video that is 720x478, two black lines will get added at the bottom (like this (http://i.imgur.com/xzGWBes.png)).

I tried to make a shot with haali/VMR7w instead and those seem to work fine, so it should not be a bug in MPC-HC (at least I think).
I'm not sure when this got broken, because I only update from time to time, however screenshotting stuff with 478 height definitely worked fine in older versions of MadVR (I'm using it for over a year, thanks a lot for the great renderer :D).
Edit: version 0.84.2 I found on my HDD is unaffected by this, so the error was probably introduced sometimes after this version.

I use the iGPU in AMD A8-3850 (Llano, Radeon HD 6550D with WLIV5 architecture) with latest drivers from windows update: 13.251-131206a-166151E-ATI
madVR version: v0.87.4. This is on Windows 8.1 64 bit. OpenCL dither is disabled, chroma upscaling is set to lanczos3 AR (jinc3 AR for luma). I don't use deinterlacing, debanding, smooth motion or other postprocessing. I also only use windowed mode, not exclusive FS.

Here is a sample (4,3 MB, few seconds) video that triggers it for me (I hope it helps...): http://ulozto.net/xwvrz4Kw/andromedastories-sample-madvr-screenshot-padding-error-mkv

(At your service if more information or something is needed.)

[6233638]

Still don't like the dynamic builds at all on low-motion content. It makes the entire image feel energetic when it should be calm, making it difficult to pick out details from behind the dither.I agree, but I think this is only an issue due to the fact that you are (presumably) watching in 4-bit rather than 8-bit.

Also, with all the dynamic builds, it is not possible to make exact screenshots anymore, since the noise even continues to move even in paused mode. And even if not paused, it would still be different everytime you seek to a certain keyframe, because they now seem completely random, so that also has a negative side to it. I noticed that after I jumped to the same keyframe several times in a row.I use the static builds for comparing screenshots so that the results are repeatable.

I prefer the dynamic color build. Both are good but more depth in the image. Opposite build is 2ms faster. Color seemed the same on both. Thanks madshiI would say that there is more texture in the "color" builds compared to the "opposite" builds, due to the dither patterns being more obvious. (a bad thing)

[kazuya2k8]

Done some quick test (evaluated them while in motion, it looks noisy when paused, surface smooths out when playing). Watched it animes with slow slideshow/picture drama scenes since I can't see difference in fast motion scenes.

I like the multi-color builds better. It gives smoother texture to gradients and flat surfaces. The mono-color ones I feel like the surfaces have rough textures in it.

Now between the static and dynamic. Hardly can see difference. But in some instances I feel the dynamic builds feels a bit more busy on static scenes. So I tend to slightly favor the static build.

So in the end the multiColor-static gets my vote. Just so you know, I'm a mild color-blind person (yes, I've the color blind test). I have certain difficulty differentiating certain level shades of colors like light green from light yellow and dark brown from dark green. While a normal color vision person can tell them apart.

EDIT: I missed the opposite build. Will try next.

[StinDaWg]

Oh, that seems to be a bug in the settings dialog. Will be fixed in the next official build.

Thank you! I have been dealing with this issue for years but I never said anything. It's nice to be able to map functions to the number keys, so I don't need to reach for the keyboard to check OSD, change deinterlacing, scaling options ect.

[XMonarchY]

madshi, could you please link me to a good guide as to how dithering works because it doesn't make sense to me and I do not want to waste server space and brain cells lost while reading my senseless jabbering? There is a picture, 8bit, and dithering somehow makes it better - its obvious, I love ED, but the whole "finding the next best color" confuses me. If TV can reproduce 8bit per channel and video is encoded using 8bit per channel, then dithering simply attempts at providing the effect of making the video seem like its 10bit or more? Since TVs cannot do more than 8bit, dithering accomplishes its goals using the next best color approximation, which creates a perception of higher bit-depth? I'm with stupid - I know...

[GREG1292]

I prefer the dynamic color build. Both are good but more depth in the image. Opposite build is 2ms faster. Color
seemed the same on both. Thanks madshi

After further review opposite dynamic is more accurate
for example in Dark side of the moon Transformers I can
now see the cgi effects when they insert them or screw up. Way cool!
A level of clarity I have not seen before. Also less ringing or blurring.
Like a fine Scotch opposite dynamic get's better the more you view it. What's next for
an encore madshi?

[Asmodian]

madshi, could you please link me to a good guide as to how dithering works because it doesn't make sense to me and I do not want to waste server space and brain cells lost while reading my senseless jabbering? There is a picture, 8bit, and dithering somehow makes it better - its obvious, I love ED, but the whole "finding the next best color" confuses me. If TV can reproduce 8bit per channel and video is encoded using 8bit per channel, then dithering simply attempts at providing the effect of making the video seem like its 10bit or more? Since TVs cannot do more than 8bit, dithering accomplishes its goals using the next best color approximation, which creates a perception of higher bit-depth? I'm with stupid - I know...

I don't have a link but just know that for 8 bit source to 8 bit display you do not need (or want) to dither.

Resizing, converting YUV to RGB, using a 3DLUT, etc in madVR creates 16+ bit data which then needs to be converted to 8 bit. That is where dithering comes in.

[MistahBonzai]

Before commenting I would like to verify for the sake of my sanity that my MadVR installation is correct..all I need to do is use 87.4 and substitute the various MadVR.ax files..right?

That given I'm very surprised at how obvious the differences are between the members of the new mono/multi/opposite test releases. It's like I can name that ED in 5 seconds or less :-) So what do I think? Well...

I prefer multiColor_dymamic (8 bit). It seems as smooth as Adaptive4 but is certainly different. It's difficult to quantify other than it imparts a more 'diffuse' look to the video. I like that look (smooth and diffuse yet not blurry) especially on HQ monochrome (like that shot on the Epic-M Monochrome camera). I'm still up in that air on the oppositeColor_dynamic versus multiColor_dynamic although I'm leaning toward the oppositeColor - I have do do more critical viewing with similar color material.

Observation on the 4 bit variation..I don't suspect that the following is intentional but I like it (a lot) with _some_ monochrome sources - it creates a sort of 'Velvet Elvis' due to the pronounced texturing lending a somewhat 3D perspective to the video - especially those with dark backgrounds. From my perspective, based on the type of content I view, it would be great if the ability to somehow force 4 bit were maintained - assuming we go with a suitable ED.

Again, I'm amazed at how quickly the characteristics of the variations between them can be identified in light of the difficulties I encountered seeing effects in the prior batch of test builds. I beginning to think that a bit of leeperry is rubbing off on me :D

[agustin9]

madshi what happens with smooth motion if the rendering times go over the vsync interval but no frames are dropped? It works just fine? Thanks!

[Ver Greeneyes]

I was considering doing some monte carlo style testing on different weights for error diffusion, and that got me wondering: how do you quantify how good one set of weights is compared to the next? You can't just compare a dithered pixel to its unrounded state, because by that metric it's always the most accurate to just do rounding (i.e. set all weights to 0). It seems like you'd need some amount of spatial or temporal smoothing, but what kind of window function would you use (gaussian, like the phosphors on a CRT screen)? Another tactic that was mentioned earlier was to try to minimize low frequency noise (clumpiness). But that doesn't seem like it would make for a very good fitness metric all on its own. What do you guys think?

[turbojet]

Thanks for testing 720p60 guys! It's a minimum goal set for my next gpu but it'll have to wait for a new generation. Hoping for something less than $300 USD that will do it.

huhn: nevermind about virtumvp I read your post wrong.

[James Freeman]

OppositeColor Dynamic is excellent !

Madshi, you outdone yourself with this build.
I'm beginning to worry though, I like the 4-bit picture more than the original...:D

[huhn]

madshi what happens with smooth motion if the rendering times go over the vsync interval but no frames are dropped? It works just fine? Thanks!

like it always was.

with or without smooth motion the number of scaled frames is the same. so there is no need to be below the vsync. only the last steps are done about 50 times per sec when the video is 24 fps and the monitor 60 hz.

[jkauff]

I haven't been participating in the tests, and although I've followed the discussion closely most of it is over my head. Nonetheless, here goes a question:

I watch a lot of B&W SD movies from the 30s and 40s. I also watch a lot of color HD (Blu-ray) movies, especially older movies that have been restored. Is the same set of algorithms going to work for both these types of sources? If not, madshi should consider offering more than one set, with the appropriate ones going into profiles for different types of sources.

Am I misunderstanding (entirely possible), or is this a potential issue? Sounds like we already need a "Color-blind" profile.

[Aikibana]

Gigabyte P55UD3P + MSI R7970 + 14.1b Driver

When using NNEDI3 image doubling it eats all my gpu and frame lags. Tried setting other scaling algorithm to bilinear with no luck.

Same as just unchecking "use random dithering instead of OpenCL error diffusion" in trade quality for performance tab, it just lags and gpus in full usage.

Not trying revert to 13.12 though.

Does GPU-Z indicate that OpenCL is working correctly? (checkbox flagged)

On paper there's no obvious reason why this system config shouldn't work, right?

[ryrynz]

The 750 Ti looks fairly good on the madVR front, hopefully those driver issues can be sorted quickly.

[kazuya2k8]

On my last test I chose multiColor-static. In oppositeColor test, looks like dynamic is doing better in blending flat/gradient areas IMO. So I vote oppositeColor-dynamic this time.

[Shiandow]

We're talking floating point numbers here though. I don't think it really matters if the least significant bit happens to be 0 3/4 of the time. Anyway, I wanted to avoid bitwise operations since GPUs are more aimed at floating point, but I couldn't find any GPU-centric algorithms for hashing two values together. Multiplying with a hash of the color, while not truly random, seemed like it might still look good enough.

Doing so in floating point is even worse; it will completely skew the distribution. At least with integers you get some randomness because of the overflow. I can't see why just using a bitwise xor should be hard. Alternatively you can just use a 32 bit hash combining the 16bits random number and 16 bits that depend on the pixel value.

Anyway now that I've had some sleep I'd like to present the correct version of the algorithm for uniformly picking random numbers (r,g,b) such that r+g+b = 0 and all numbers are between -1/2 and 1/2.


if rand1>0 then {sign=+1} else {sign=-1};
r = sign*(1+1/sqrt(2))*(1-sqrt(1-abs(rand1)));
g = sign*((rand2+.5)*(1-abs(r))-.5);
b = -r-g;


Again this code assumes rand1 and rand2 to be random numbers between -.5 and .5. I tested this version and it works, although the difference with the 'naive' method isn't as large as I'd feared.

[cyberbeing]

I agree, but I think this is only an issue due to the fact that you are (presumably) watching in 4-bit rather than 8-bit.
No, this is when watching with normal 8-bit dithering. As mentioned earlier in the thread, I find the static builds invisible in 8-bit, while the dynamic builds not. The problem isn't the noise itself, but rather the dynamic build noise is so energetic and low intensity, it makes everything feel like it's been poorly encoded with mosquito noise. Film grain by comparison I find aesthetically pleasing, which is think in part is since it feels like an additional layer on top of, rather than part of, the source.

This is why I'm somewhat curious if lowering the random seed frequency of the dynamic builds to 1/2 rate or 1/3 rate, lessens this effect for me. Currently the majority of the time, a full rate dynamic build is running at a higher framerate than the motion in the video, but not high enough to be invisible. In the same way, I wouldn't be surprised if with a 24p video on a 120hz monitor, updating the random seed 5 times per frame at each refresh, rather than once per frame, would be a visual improvement.

Basically this build uses the same random distribution for the red and blue channel, but the exact "opposite" (negative) random distribution for the green channel. This should further lower the luma noise level, and it might also lower the chroma noise level a bit (compared to multiColor), or at least make it slightly more predictable. Thoughts?

Another interesting idea would be to take madshi's 'opposite' idea a step further, and do it globally in sync on all color channels. Display a 'unique random' position and then the 'exact opposite' position in pairs for all color channels (not only green), before generating a new shared unique random seed for the next pair displayed.

[madshi]

Anyway I just tried those two news builds and the picture looks much deeper, clearer and far more impressive with ED4...and without all that nasty headaches-prone chroma noise constantly dancing around
I'd still like to know whether multiColor or oppositeColor is better for your eyes. Or let's say which is less bad? :D You can test with the static versions, since you seem to like that better...

non-motion scenes with edges against dark background looked clearer. For example, humans in the foreground against a dark background, just standing there (Farscape: PeaceKeeper Wars, a terrible quality DVD).
Ok, thanks. How does oppositeColor compare with those DVDs? If you still prefer monoColor, could you upload a small sample where you prefer monoColor over oppositeColor? Thanks.

How exactly did you make the green channel "opposite"?
Very simply by doing this:

float rand = random(randomHelper);
float3 rand3 = float3(rand, -rand, rand);
rounded = round(pix + rand3 * ...);\
random(randomHelper) returns a random number in the -0.5..+0.5 range. This should pretty much "inverse" the green dithering pattern compared to the red/blue dithering pattern. Since green is the largest contributor to the luma channel, this way green, red and blue should offset each other so that the noise in the luma channel is consistently lowered for nearly every pixel.

Still don't like the dynamic builds at all on low-motion content. It makes the entire image feel energetic when it should be calm, making it difficult to pick out details from behind the dither. The 'oppositeColor' dynamic build seems to just make this worse for me.
Ok. What happens if you compare mono vs multi vs opposite with the static builds? Which do you prefer then?

madshi, could you try making a half-rate (every second frame) and third-rate (every third frame) dynamic dither builds, where the random seed updates less often? I'd be interested in seeing what that looks like. Curiosity only.
Will do, after you decide on a favorite static build (see above).

I must say that I´m still not sure about all these new builds, either, while I was really satisfied with ED4, I kind of fear that we go a bit overboard with this now and if I read of noise-cancellation (which is a method e.x. Apple uses for the iPhone for instance by utilizing 2 microphones at the speaker side and one at the back to make recordings and mathematically subtract the noise sample from the speaker side sample, so that only your voice will be left, which is actually quite intelligent) I fear a bit that we actually lose some original source noise with it.
The "noise cancellation" should only effect the dithering noise itself. The underlying image noise should be unaffected.

Still not done with all my testing, though, it´s kinda hard to actually judge based on moving images, when static images tell you a different story.
Have you tried with the 4bit mode? I think the difference is quite noticeable when using 4bit mode.

Also, with all the dynamic builds, it is not possible to make exact screenshots anymore, since the noise even continues to move even in paused mode. And even if not paused, it would still be different everytime you seek to a certain keyframe, because they now seem completely random, so that also has a negative side to it. I noticed that after I jumped to the same keyframe several times in a row.
In paused mode the dither pattern should not change. Even if the OSD is updated and the frame is rerendered, the dither pattern should still stay the same. This is because I've tied the random number generator to the "frame ID". However, if you seek, the frames get different frame IDs after the seek, depending on which location you seek to. If you, however, start the video paused and then always seek to the exact same frame, then the dithern pattern should still be identical.

[bug report not related to the currently-tested stuff]

I found that when making a screenshot (using the screenshot fucntion of MPC-HC, not grabbing with printscreen) of a video that has merely mod2 height, MadVR seems to add black padding at the bottom. For example, with video that is 720x478, two black lines will get added at the bottom (like this (http://i.imgur.com/xzGWBes.png)).

I tried to make a shot with haali/VMR7w instead and those seem to work fine, so it should not be a bug in MPC-HC (at least I think).
I'm not sure when this got broken, because I only update from time to time, however screenshotting stuff with 478 height definitely worked fine in older versions of MadVR (I'm using it for over a year, thanks a lot for the great renderer :D).
Edit: version 0.84.2 I found on my HDD is unaffected by this, so the error was probably introduced sometimes after this version.

I use the iGPU in AMD A8-3850 (Llano, Radeon HD 6550D with WLIV5 architecture) with latest drivers from windows update: 13.251-131206a-166151E-ATI
madVR version: v0.87.4. This is on Windows 8.1 64 bit. OpenCL dither is disabled, chroma upscaling is set to lanczos3 AR (jinc3 AR for luma). I don't use deinterlacing, debanding, smooth motion or other postprocessing. I also only use windowed mode, not exclusive FS.

Here is a sample (4,3 MB, few seconds) video that triggers it for me (I hope it helps...): http://ulozto.net/xwvrz4Kw/andromedastories-sample-madvr-screenshot-padding-error-mkv

(At your service if more information or something is needed.)
Thanks. Could you please enter this into the madVR bug tracker? That would be great!

Thank you! I have been dealing with this issue for years but I never said anything. It's nice to be able to map functions to the number keys, so I don't need to reach for the keyboard to check OSD, change deinterlacing, scaling options ect.
Well, reporting bugs does help... :D

madshi, could you please link me to a good guide as to how dithering works because it doesn't make sense to me and I do not want to waste server space and brain cells lost while reading my senseless jabbering? There is a picture, 8bit, and dithering somehow makes it better - its obvious, I love ED, but the whole "finding the next best color" confuses me. If TV can reproduce 8bit per channel and video is encoded using 8bit per channel, then dithering simply attempts at providing the effect of making the video seem like its 10bit or more? Since TVs cannot do more than 8bit, dithering accomplishes its goals using the next best color approximation, which creates a perception of higher bit-depth? I'm with stupid - I know...
I don't have a link but just know that for 8 bit source to 8 bit display you do not need (or want) to dither.

Resizing, converting YUV to RGB, using a 3DLUT, etc in madVR creates 16+ bit data which then needs to be converted to 8 bit. That is where dithering comes in.
^ Correct. Basically any sort of processing produces 16+ bit data. That includes YCbCr -> RGB color conversion, and also level conversions (e.g. 0..255 output).

Before commenting I would like to verify for the sake of my sanity that my MadVR installation is correct..all I need to do is use 87.4 and substitute the various MadVR.ax files..right?
Yes. When a test build only comes with a small number of files you're always expected to use the official build and just replace the changed files. No need to uninstall/reinstall.

Observation on the 4 bit variation..I don't suspect that the following is intentional but I like it (a lot) with _some_ monochrome sources - it creates a sort of 'Velvet Elvis' due to the pronounced texturing lending a somewhat 3D perspective to the video - especially those with dark backgrounds. From my perspective, based on the type of content I view, it would be great if the ability to somehow force 4 bit were maintained - assuming we go with a suitable ED.
I'm beginning to worry though, I like the 4-bit picture more than the original...:D
Haha! 4bit rules! Well, I guess I could allow you to lie about the native bitdepth of your display (e.g. 4bit). That would get you 4bit dithering again. But that does seem a bit weird way to activate this functionality. But unless there's big demand from many users I don't plan to offer a "rendering" setting to switch to 4bit dithering. I think most users wouldn't use such a feature.

madshi what happens with smooth motion if the rendering times go over the vsync interval but no frames are dropped? It works just fine? Thanks!
It should work just fine, as long as the rendering times are lower than the movie frame interval. Well, at least in FSE mode. In windowed mode in my experience sometimes it works fine, too. But sometimes there can be problems when your rendering times are higher than the vsync interval (with smooth motion FRC turned on). In any case, if no frame drops are reported and playback looks smooth to your eyes, it seems to work just fine on your PC.

I watch a lot of B&W SD movies from the 30s and 40s. I also watch a lot of color HD (Blu-ray) movies, especially older movies that have been restored. Is the same set of algorithms going to work for both these types of sources?
It should. Why don't you give it a try and report back?

I was considering doing some monte carlo style testing on different weights for error diffusion, and that got me wondering: how do you quantify how good one set of weights is compared to the next? You can't just compare a dithered pixel to its unrounded state, because by that metric it's always the most accurate to just do rounding (i.e. set all weights to 0). It seems like you'd need some amount of spatial or temporal smoothing, but what kind of window function would you use (gaussian, like the phosphors on a CRT screen)? Another tactic that was mentioned earlier was to try to minimize low frequency noise (clumpiness). But that doesn't seem like it would make for a very good fitness metric all on its own. What do you guys think?
If you average a large enough area together, I think all weights should produce more or less identical results, because the same amount of error is spread in any case, just to different pixels. So I don't think you can just average pixels together, then calculate the difference, and then hope to get a meaningful evaluation metric.

IMHO, when judging error diffusion algorithms, there are 2 meaningful things you can check:

(1) Noise levels. Both luma noise and chroma noise. Ideally the noise should be as low as possible. For most people luma noise is more important than chroma noise (except for leeperry :)).
(2) Noise distribution characteristics in frequency domain. Ideally what we want/need is blue noise characteristics. Worm artifacts produce bad artifacts in frequency domain.

Have a look at these papers to get some background information about this:

http://graphics.xmu.edu.cn/projects/VariationalBlueNoiseSampling/index.html
http://www.iro.umontreal.ca/~ostrom/SamplingWithPolyominoes/
http://graphics.uni-konstanz.de/publikationen/2009/capacityconstrainedpointdistributions/website/

Please note that these papers are about offline calculation of optimal point distributions. Basically it's a very slow alternative to error diffusion (much too slow to be used for real time rendering, and not suitable at all for GPU acceleration). But the scientific measurements about noise distribution properties of those point set distributions apply for error diffusion dithering patterns, too.

Once, again an improvement, at least for me. Opposite Dynamic is better than everything else.
Anyway, tried the Opposite_dynamic build. A slight improvement over multiColor_dynamic. Good job!
After further review opposite dynamic is more accurate
for example in Dark side of the moon Transformers I can
now see the cgi effects when they insert them or screw up. Way cool!
A level of clarity I have not seen before. Also less ringing or blurring.
Like a fine Scotch opposite dynamic get's better the more you view it.
I prefer multiColor_dymamic (8 bit). It seems as smooth as Adaptive4 but is certainly different. It's difficult to quantify other than it imparts a more 'diffuse' look to the video. I like that look (smooth and diffuse yet not blurry) especially on HQ monochrome (like that shot on the Epic-M Monochrome camera). I'm still up in that air on the oppositeColor_dynamic versus multiColor_dynamic although I'm leaning toward the oppositeColor - I have do do more critical viewing with similar color material.
OppositeColor Dynamic is excellent !

Madshi, you outdone yourself with this build.
On my last test I chose multiColor-static. In oppositeColor test, looks like dynamic is doing better in blending flat/gradient areas IMO. So I vote oppositeColor-dynamic this time.
Thanks for the feedback, guys! :)

Another interesting idea would be to take madshi's 'opposite' idea a step further, and do it globally in sync on all color channels. Display a 'unique random' position and then the 'exact opposite' position in pairs for all color channels (not only green), before generating a new shared unique random seed for the next pair displayed.
You mean apply normal monoColor on frame 1, then the reverse of monoColor on frame 2 as a sort of temporal dithering? Then what about frame 3?

[Ver Greeneyes]

Doing so in floating point is even worse; it will completely skew the distribution.I guess you're right. Math is hard :(

I can't see why just using a bitwise xor should be hard.GPUs aren't really made for bitwise maths, but I guess it might be okay nowadays (in terms of performance). madshi doesn't seem interested in the idea though.

[madshi]

It's not that I'm not interested, but as I said before, there are many unsolved problems. Furthermore, if you want me to compare the current frame to the previous one to check if a pixel has changed, you can expect a significant performance drop. Let's not even talk about the added complication of making two frames available to DirectCompute at the same time (which madVR currently doesn't do/support).

[6233638]

No, this is when watching with normal 8-bit dithering. As mentioned earlier in the thread, I find the static builds invisible in 8-bit, while the dynamic builds not.Do you have any samples for this? Every time I think I might be seeing it, it turns out to be the source.

This is why I'm somewhat curious if lowering the random seed frequency of the dynamic builds to 1/2 rate or 1/3 rate, lessens this effect for me. Currently the majority of the time, a full rate dynamic build is running at a higher framerate than the motion in the video, but not high enough to be invisible. In the same way, I wouldn't be surprised if with a 24p video on a 120hz monitor, updating the random seed 5 times per frame at each refresh, rather than once per frame, would be a visual improvement. Running at a lower update speed than the framerate probably won't look very good at all.
Running at the refresh rate rather than the framerate might be interesting to see, but I suspect it would be best to tie it into the framerate.


It's a shame that the 4-bit mode was not available in earlier test builds, as I wonder whether one of the other dither algorithms may look better with the dynamic builds.

[druneau]

Is there a quick way to switch between builds? (I'm currently closing down MPC-HC, renaming a build to madVR.ax, then relaunching.)

[Ver Greeneyes]

If you average a large enough area together, I think all weights should produce more or less identical results, because the same amount of error is spread in any case, just to different pixels. So I don't think you can just average pixels together, then calculate the difference, and then hope to get a meaningful evaluation metric.

IMHO, when judging error diffusion algorithms, there are 2 meaningful things you can check:

(1) Noise levels. Both luma noise and chroma noise. Ideally the noise should be as low as possible. For most people luma noise is more important than chroma noise (except for leeperry :)).
(2) Noise distribution characteristics in frequency domain. Ideally what we want/need is blue noise characteristics. Worm artifacts produce bad artifacts in frequency domain.

Have a look at these papers to get some background information about this:

http://graphics.xmu.edu.cn/projects/VariationalBlueNoiseSampling/index.html
http://www.iro.umontreal.ca/~ostrom/SamplingWithPolyominoes/
http://graphics.uni-konstanz.de/publikationen/2009/capacityconstrainedpointdistributions/website/

Please note that these papers are about offline calculation of optimal point distributions. Basically it's a very slow alternative to error diffusion (much too slow to be used for real time rendering, and not suitable at all for GPU acceleration). But the scientific measurements about noise distribution properties of those point set distributions apply for error diffusion dithering patterns, too.Thanks for the detailed reply! It'll take me a while to look through all that :scared:

Furthermore, if you want me to compare the current frame to the previous one to check if a pixel has changed, you can expect a significant performance drop. Let's not even talk about the added complication of making two frames available to DirectCompute at the same time (which madVR currently doesn't do/support).No, nothing like that. You already have the random number for each pixel (in the dynamic builds you even update it every frame ;) ), so I was thinking you could hash it together with the color each pixel happens to have that frame and use the result as the random number for dithering. Having three color channels but only one random number complicates things though. Here's a very simple hash function I found here (https://stackoverflow.com/questions/4200224/random-noise-functions-for-glsl), no idea if it's any good:// hash based 3d value noise
float hash( float n )
{
return fract(sin(n)*43758.5453);
}So hash each color channel, convert to integer, and xor them together with the random number for that pixel.

[cyberbeing]

You mean apply normal monoColor on frame 1, then the reverse of monoColor on frame 2 as a sort of temporal dithering? Then what about frame 3?

Yes, what I had in mind was something like the following, where each pair would have complimentary dither pixel positions. The hope would be this would avoid peaks and valleys of intensity within each 16x16 block, with each pair averaging out the other in temporal fashion:

Frame1 (random seed #1) -> Frame2 (random seed #1 opposite) -> Frame3 (random seed #2) -> Frame4 (random seed #2 opposite) -> ...

___

Though I guess re-using a static random seed and opposite would be an alternative:

Frame1 (random seed #1) -> Frame2 (random seed #1 opposite) -> Frame3 (random seed #1) -> Frame4 (random seed #1 opposite) -> ...

___

Yet another possibility, would be to combine both ideas and add rotations to it:

Frame1 (random seed #1 0°) -> Frame2 (random seed #1 opposite 0°) -> Frame3 (random seed #1 180°) -> Frame4 (random seed #1 opposite 180°) -> Frame5 (random seed #1 90°) -> Frame6 (random seed #1 opposite 90°) -> Frame7 (random seed #1 270°) -> Frame8 (random seed #1 opposite 270°) -> Frame9 (random seed #1 45°) -> Frame10 (random seed #1 opposite 45°) -> Frame11 (random seed #1 225°) -> Frame12 (random seed #1 opposite 225°) -> Frame13 (random seed #1 135°) -> Frame14 (random seed #1 opposite 135°) -> Frame15 (random seed #1 315°) -> Frame16 (random seed #1 opposite 315°) -> Frame17 (random seed #2 0°) -> Frame18 (random seed #2 opposite 0°) -> ...

___

Do you have any samples for this? Every time I think I might be seeing it, it turns out to be the source.

Anime content in general makes it visible to me as increased visual energy, which leaves the feeling of being out of place.

[StinDaWg]

madshi, I'm using bicubic 75 AR+lanczos 4 AR for upscaling. I'm also using ffdshow raw for post-processing. For 720p->1080p upscaling I prefer to use a light unsharp mask in ffdshow. I have it set to 10 (default is 40) and I think this makes the picture look much clearer and detailed for 720p content, without introducing any noticeable artifacts. In this scenario, do you know if ffdshow is doing the unsharp mask before or after madVR upscales, and does it matter as far as what is "correct"? I've always read that you should do unsharp mask on the final picture, but I'm pretty sure ffdshow is doing it first because of the way the raw filter inserts itself. Is Lanczos 4 too sharp if I am using a sharpen filter, should I switch to Lanczos 3 AR?

With ffdshow basically being a dead project, there is starting to become a void in updated post-processing options. Do you plan to add anything like unsharp mask or a sharpen filter to madVR at any point in the future? I'm liking your new deband filter, and would be interested to see what else you could come up with.

[leeperry]

the dynamic build noise is so energetic and low intensity, it makes everything feel like it's been poorly encoded with mosquito noise.
Exactly, I've got no idea how anyone could prefer dynamic tbh. It completely covers the original movie grain and the beautiful thing about silver halide grains is that their chunk size changes depending on the light intensity(it was so fun to use GrainFactory3() for that very reason), this is part of what gives the "impressions of depth"(dead obvious in the high iso 12 grams movie for instance) and this dynamic stuff turns it into a big noisy mush to my eyes. I'm big enough to use the "noise" filter of ffdshow if I want to, TYVM.

It's indeed probably even more obvious on slow motion scenes which is essentially what I've been using(in Oblivion for instance, I'm extremely impressed by its PQ with ED4, OMG).

I'd still like to know whether multiColor or oppositeColor is better for your eyes. Or let's say which is less bad? :D You can test with the static versions, since you seem to like that better...
Well, I'd rather pass if you don't mind. I really wasn't kidding when I mentioned headaches...when I use headphones without a crossfeed plugin my brain quickly starts wondering why it's hearing dual-mono instead of stereo and whether one of my ears would appear to be malfunctioning.

I suffer from a lack of red cones in my eyes and my brain has learned how to partly overcome this issue by running its own LUT and it's working very effectively tbh, I can now identify colors I wasn't able to as a kid(such as light yellow/light green, dark brown/dark green or navy/purple). I'm not bothered by my color blindness condition in my everyday life to the least. Either colors look natural or "funky" and in the latter case I can now very often identify them with a bit of concentration.

All this to say that this epileptic chroma noise is too much to bear for me, I'm more royalist than the king when it comes to display colorimetry for a good reason. My brain color decoding cannot bear all this bs chroma stray noise and once the test of those two latest builds was over, I watched my Sammy TV a bit and went to bed. I was extremely glad that Sammy wasn't doing the chroma chicken dance anymore, make it stop :D

[6233638]

Anime content in general makes it visible to me as increased visual energy, which leaves the feeling of being out of place.I'm still having a really difficult time finding a sample for this. Everything I find which shows this "energy" turns out to be encoded into the source. (just as visible, if not more, when dithering is disabled)

[Shiandow]

Very simply by doing this:

float rand = random(randomHelper);
float3 rand3 = float3(rand, -rand, rand);
rounded = round(pix + rand3 * ...);\
random(randomHelper) returns a random number in the -0.5..+0.5 range. This should pretty much "inverse" the green dithering pattern compared to the red/blue dithering pattern. Since green is the largest contributor to the luma channel, this way green, red and blue should offset each other so that the noise in the luma channel is consistently lowered for nearly every pixel.


Well I have to admit, that is far simpler than what I did. But in that case, why not make the luma noise completely 0? You could do that by simply setting:

g = 1.39782 (0.072 b + 0.2126 r);

Where r,g,b denote the values for the rgb channels of the noise. A slightly more general method would be:

g = -(Kb*b + Kr*r)/(1-Kb-Kr);

Where Kb = 0.072, Kr=0.2126 corresponds to BT.709. Since (Kb+Kr)/(1-Kb-Kr) is (usually) less than 1 you can be sure that the value for the green channel does not exceed the maximum value for the red and blue channels.

[GREG1292]

madshi: I was wondering if you tried neurons value of
24,48,72,96? I would like to have the option to have less or more. Is this a math issue or plain stupid to
think this on my part.

The other part is chroma doubling and why that can't be
adjusted with out luma checked.

Thanks for listening.

[huhn]

madshi: I was wondering if you tried neurons value of
24,48,72,96? I would like to have the option to have less or more. Is this a math issue or plain stupid to
think this on my part.

The other part is chroma doubling and why that can't be
adjusted with out luma checked.

Thanks for listening.

to double chroma with nnedi you can use it under chroma upscale. this matches the chroma from the source with the luma resolution. so there is no need to double the chroma resolution if you didn't double the luma resolution.

[madshi]

It's a shame that the 4-bit mode was not available in earlier test builds, as I wonder whether one of the other dither algorithms may look better with the dynamic builds.
I'm not sure it would have mattered. The adaptive solution (which all the new builds are based on) changed the dithering pattern quite a bit compared to the original NL builds, made it more random.

Is there a quick way to switch between builds? (I'm currently closing down MPC-HC, renaming a build to madVR.ax, then relaunching.)
No, you can only use the slow way. Oh well, you could leave MPC-HC running, rename madVR.ax, then start a 2nd MPC-HC instance. This way the old MPC-HC instance still uses the previous madVR build, while the new MPC-HC instance uses the new madVR build. Maybe that helps to compare better. However, if you open a new video file in the old instance, it might switch to the new madVR build (not sure, depends on what MPC-HC does internally).

No, nothing like that. You already have the random number for each pixel (in the dynamic builds you even update it every frame ;) ), so I was thinking you could hash it together with the color each pixel happens to have that frame and use the result as the random number for dithering. Having three color channels but only one random number complicates things though. Here's a very simple hash function I found here (https://stackoverflow.com/questions/4200224/random-noise-functions-for-glsl), no idea if it's any good:// hash based 3d value noise
float hash( float n )
{
return fract(sin(n)*43758.5453);
}So hash each color channel, convert to integer, and xor them together with the random number for that pixel.
Tried that. But it didn't look much different to the dynamic builds. It's one of the many problems I mentioned before: How do you define if a pixel changed? If you use a hash like that, even the smallest change will have a huge effect. And it will not only affect the current pixel, but the whole rest of the 16x16 block. I don't think this whole idea is going to work. And even if it does work, it will effect the whole 16x16 blocks, not single pixels, which could introduce new image artifacts (some blocks having more noise than others).

Yes, what I had in mind was something like the following, where each pair would have complimentary dither pixel positions. The hope would be this would avoid peaks and valleys of intensity within each 16x16 block, with each pair averaging out the other in temporal fashion:

Frame1 (random seed #1) -> Frame2 (random seed #1 opposite) -> Frame3 (random seed #2) -> Frame4 (random seed #2 opposite) -> ...

___

Though I guess re-using a static random seed and opposite would be an alternative:

Frame1 (random seed #1) -> Frame2 (random seed #1 opposite) -> Frame3 (random seed #1) -> Frame4 (random seed #1 opposite) -> ...
Tried that, but it doesn't look better than dymamic to me. Here are 2 test builds for you with this solution:

http://madshi.net/madVRtemporal.rar

Yet another possibility, would be to combine both ideas and add rotations to it
That would be difficult to do, and I believe it would look very similar to the simple dynamic solution.

You still haven't told us your opinion about the oppositeColor builds, btw. To my eyes it looks clearly lower noise than monoColor. See here:

| -- monoColor (http://madshi.net/monoColor.png) -- | -- multiColor (http://madshi.net/multiColor.png) -- | -- oppositeColor (http://madshi.net/oppositeColor.png) -- |

do you know if ffdshow is doing the unsharp mask before or after madVR upscales
Before.

and does it matter as far as what is "correct"? I've always read that you should do unsharp mask on the final picture
Sharpening looks better when applied after upscaling. That doesn't make it more "correct", it just usually looks better that way.

With ffdshow basically being a dead project, there is starting to become a void in updated post-processing options. Do you plan to add anything like unsharp mask or a sharpen filter to madVR at any point in the future?
At some point in the future, maybe.

Well, I'd rather pass if you don't mind. I really wasn't kidding when I mentioned headaches...
Makes no sense to me. You've been watching content with madVR's random dithering for years now, and madVR's random dithering has a much higher chroma noise level than any of the multiColor/oppositeColor builds. Basically what madVR's random dithering does is identical to "multiColor dynamic", just by using random dithering instead of error diffusion.

Well I have to admit, that is far simpler than what I did. But in that case, why not make the luma noise completely 0? You could do that by simply setting:

g = 1.39782 (0.072 b + 0.2126 r);

Where r,g,b denote the values for the rgb channels of the noise. A slightly more general method would be:

g = -(Kb*b + Kr*r)/(1-Kb-Kr);

Where Kb = 0.072, Kr=0.2126 corresponds to BT.709. Since (Kb+Kr)/(1-Kb-Kr) is (usually) less than 1 you can be sure that the value for the green channel does not exceed the maximum value for the red and blue channels.
I'm not sure I understand what you mean. Are you suggesting that I calculate the green random value from the red and blue random values? But doing "g = 1.39782 (0.072 b + 0.2126 r)" would have a much lower peak noise level for green than for red and blue. That means dithering for the green channel would not be very good. The lower noise level would reintroduce worm artifacts for the green ramp, maybe even some banding. I believe every channel needs exactly the full peak noise to make gradients reliably smooth and pattern-free.

I was wondering if you tried neurons value of
24,48,72,96? I would like to have the option to have less or more. Is this a math issue or plain stupid to
think this on my part.
I'm not sure if the NNEDI3 algorithm supports such neuron values. But even if it did, I don't think it's worth implementing this. The currently offered neuron options should suffice, IMHO. In order to get a visible increase in image quality, you do need to increase the neuron count quite noticeably. Increasing the neuron count only slightly won't do much good.

The other part is chroma doubling and why that can't be adjusted with out luma checked.
I believe luma doubling is *MUCH* more beneficial to image quality than chroma doubling. Because of that I'm not allowing chroma doubling to be activated if you disabled luma doubling. Just makes no sense to use such a configuration. And it would cost extra code to support such a configuration. Not willing to spend any time on something which doesn't make sense.

[noee]

Ok, thanks. How does oppositeColor compare with those DVDs? If you still prefer monoColor, could you upload a small sample where you prefer monoColor over oppositeColor? Thanks.

Ok, I've found an even uglier DVD (Jeremiah Johnson) and frankly I can't see much diff at 4bit and normal viewing between monoColorDyn and the two oppositeColor builds. I have an SD test clip I've been using, but my upload speeds are abysmal (<500Kbps) and the file is 25MB. Let me know if you still want it and I'll try MediaFire or some such....

[James Freeman]

noee,

I've tried the dynamic dithering builds with DVD's in 4-bit.
To me it appears that the resolution of the dvd's is so low, that the small pixels sized dithering dots/noise becomes perceptually invisible/insignificant.
In comparison to HD content in which the dithering dot size is the same size of the detail in the HD video, so the eye "finds" the noise better.

[Aikibana]

Need some advice on a famous topic: which hi-end GPU is best purely for Madvr?
R9 280x or GTX 770?

On one side, many prefer AMD's raw power for OpenCL.
On the other hand NVIDIA has no delay during OpenCL and D3D9 interop.

Which benefit or flaw outweighs the other?
Is either of them likely to be fixed with drivers?

Appreciate any insight.

[madshi]

Ok, I've found an even uglier DVD (Jeremiah Johnson) and frankly I can't see much diff at 4bit and normal viewing between monoColorDyn and the two oppositeColor builds. I have an SD test clip I've been using, but my upload speeds are abysmal (<500Kbps) and the file is 25MB. Let me know if you still want it and I'll try MediaFire or some such....
If you don't prefer the monoColor builds, anymore, then I don't need a sample... :)

Need some advice on a famous topic: which hi-end GPU is best purely for Madvr?
R9 280x or GTX 770?

On one side, many prefer AMD's raw power for OpenCL.
On the other hand NVIDIA has no delay during OpenCL and D3D9 interop.

Which benefit or flaw outweighs the other?
Is either of them likely to be fixed with drivers?
I think from a hardware point of view AMD probably has the better compute hardware atm, so I don't think this is something NVidia can easily fix with a new driver build. AMD OpenCL interop is costly. This is something that *could* be fixed with a new driver. But I would not count on that ever happening. FWIW, probably I'll use DirectCompute for most new compute features and DirectCompute has no interop cost for AMD hardware. However, it's possible that NNEDI3 may stay with OpenCL. In that case I don't really know whether a high-end NVidia GPU would be better or worse than an AMD GPU.