madVR - high quality video renderer (GPU assisted)

[Shiandow]

Oh, and I wonder if you could tweak the amount of randomness between frames as opposed to the amount of randomness within frames? e.g. reuse the random number from the last frame, but add a random number to it within a tighter range* (clamping to the original limit). I don't know how well this lends itself to tweaking though :)

* something like: range1 = 0.5 / 255.0;
range2 = 0.25 / 255.0;
random_diff = 2.0 * range2 * rand() - range2;
random_new = clamp(random_old + random_diff, -range1, range1);

So basically you want to reduce temporal noise by making the noise vary slowly? In that case your method has several disadvantages. You'd probably need to recalculate the random numbers from the previous frame since saving them will probably be too slow. But more importantly that method doesn't give you a uniform distribution, especially clamping the result probably won't have a nice effect, but you also have the problem that adding two uniformly distributed numbers won't give you a uniformly distributed number.

I don't really know an easy way around that last part, the easiest method I could think of is to use the inverse cumulative distribution to somehow make it uniform again, which might be fast enough (since it's rather simple for uniformly distributed variables), but unfortunately doesn't give you a nice smooth way to interpolate them. The nicest method would probably be to convert them to normally distributed variables, add them, and convert the result back to a uniform variable again, but that will be far far too slow.

Edit: After some research it seems that converting to a Cauchy distribution instead of a normal distribution gives a nice way to do this, this would give you the following code to combine two uniform random numbers:


a = tan((rand1-.5)*pi);
b = tan((rand2-.5)*pi);
random_comb = (1/pi)*arctan(t*a + (1-t)*b) + .5;


this seems doable, but of course it will be slower.

[ttnuagmada]

Will MadVR's OpenCL features benefit from the DP performance of the Titan's over the 780's?

[leeperry]

The goal of dithering is to simulate a native higher bitdepth as well as possible.
Sure but adding random chroma noise makes the PQ fuzzy more than anything else IMHO. There's little point in nickpicking about ΔE and gamut mapping when the chroma comes with such tragic amounts of additional noise on purpose.

IME the more spot-on the colors, the higher the dynamics and the sense of depth as well as colors aren't smeared down anymore.

I don't see how making chroma so noisy could possibly help to "simulate a native higher bitdepth as well as possible", I rest my case that killing dynamics is the exact opposite of what we want. That's basically 3 veils of noise dancing around on top of your movie, yeeha...even worse than a VGA connection.

The multiColor builds seem to lower the luma noise a bit on the cost of having slightly higher chroma noise.
I'll take monochrome luma noise over this chroma triple mumbo-jumbo anytime. So much for J3AR/NNEDI chroma upscaling OCD'ness if it ends up randomly blown away in pieces afterwards :(

The dynamic builds make the image appear slightly more noisy
More than slightly IMHO as this is a complete showstopper to my eyes, all this said maybe at some point it will become relevant to allow the end-user to pick his own poison.

[MokrySedeS]

did you check "don't use "copyback" for dxva deinterlacing(intel, nvidia)?

Yes, I had it disabled but enabling it doesn't change anything.

i think you got this problem on the hole video right? so even if i missed the right frame this should do be ok?

Yes, the whole sample is stretched a little with dxva2 deinterlacing.

I asked a friend to check this on his system (he has an integrated gf9300) and he claims that it's working fine for him as well.
I don't know why only my system seems to be affected... :confused:

Looks like something that should be added to the madVR bug tracker.

Yes sir :)

[Ver Greeneyes]

The last line of each 16x16 block is somewhat at a disadvantage because it can't spread the error to the first line of the next 16x16 block. I'm trying to compensate for that a bit by spreading a larger portion of the error to the next pixels in the same line. But there's still a bit of the error lost. This may be responsible for the problem you're seeing. I'm not sure if I can fix this without causing other artifacts.
Here's an attempt at capturing the effect in an image: http://i.imgur.com/SoFzkvB.png
Edit: Hmm, that turned out darker than it should have. Let me upload a brightened version (not repeating the test itself unless I have to). Brightened version: http://i.imgur.com/jpzr04b.png

I made this by level-adjusting and blending together screenshots of 32 frames (monocolor dynamic build, 4-bit mode). So it looks like on average, the top half of each 16-pixel block is brighter than the bottom half. I don't see much left-right bias, perhaps because the exact value is always changing there? Each column of pixels should have the same value in the video file. Does this match what you said above? Another interesting thing is that blended together like this, the block boundaries show up fairly clearly in the brighter areas - I sure don't notice them normally though :)

[madshi]

Sure but adding random chroma noise makes the PQ fuzzy more than anything else IMHO. There's little point in nickpicking about ΔE and gamut mapping when the chroma comes with such tragic amounts of additional noise on purpose.
You're completely misinterpreting the technical facts. I do not (artificially) add any amount of chroma noise. The multiColor builds have lower luma noise but higher chroma noise compared to the monoColor builds. But that's not because I'm adding chroma noise (I'm not) but it's simply a consequence of using different dither structures per RGB channel. You're complaining about the higher chroma noise, but at the same time you *totally* ignore the fact that the luma noise is as much down as the chroma noise is up. Which means your judgement about this is very one-sided.

I understand that your eyes like the monoColor builds better than the multiColor builds, and I've no problem with that. But please stop posting misinformation about the technical side.

IME the more spot-on the colors, the higher the dynamics and the sense of depth as well as colors aren't smeared down anymore.
And the lower the luma noise the higher the dynamics and the sense of depth as well as luma isn't smeared down anymore.

I don't see how making chroma so noisy could possibly help to "simulate a native higher bitdepth as well as possible"
Because luma noise is as much down as chroma noise is up. You may not like the overall result/look of this trade, but totally ignoring the positive side of the trade does not make your opinion look very objective.

FWIW, I'd suggest you read this:

http://www.imaging-resource.com/news/2014/01/17/fujifilm-files-patent-for-sensor-with-enlarged-green-white-pixels

> Taking into account the fact that the human eye is
> more sensitive to luminance noise than color noise [...]

Fujifilm is basing a whole new digicam sensor technology on this. Maybe you should email them and let them know that they totally got this backwards? :p

Here's an attempt at capturing the effect in an image: http://i.imgur.com/SoFzkvB.png

I made this by level-adjusting and blending together screenshots of 32 frames (monocolor dynamic build, 4-bit mode). So it looks like on average, the top half of each 16-pixel block is brighter than the bottom half.
I don't see much difference between top and bottom half of each pixel block, but it does seem like the borders stand out quite noticeably... :(

Is this as noticeable in real life for you? Or did this effect get stronger through your editing/compositing? I don't think I can see any block structure on my PC. And I'm trying!

[Ver Greeneyes]

I don't see much difference between top and bottom half of each pixel block, but it does seem like the borders stand out quite noticeably... :(

Is this as noticeable in real life for you? Or did this effect get stronger through your editing/compositing? I don't think I can see any block structure on my PC. And I'm trying!
Don't look at the bright areas too closely, those square borders weren't visible to me at all before processing. I uploaded a brightened version of the image here (http://i.imgur.com/jpzr04b.png). Look at the top left or bottom right areas - don't the blocks look like they have vertical gradients in them to you? Looking at it from a distance it makes each row of blocks look like a separate band to me.

But! I only noticed this in 4-bit mode, and even there it's only visible on the darker side of the gradient, which itself tops out at RGB888(7,7,6) after dithering. We're talking values of less than 1/255 in all color channels here. So unless there's some obvious source of bias I wouldn't worry about it.

[James Freeman]

Mono-Color Dynamic for me.

EDIT:
I changed my mind later this day... to MultiColor Dynamic.
Continue reading...

Ver Greeneyes, Madshi,
Yes, on the Dark Color/Grey Pattern, the dark area look like long stripes...
I can see it clearly on my screen, with only the 4bit mode madshi provided.

[noee]

Alright, testing BD rips 1080p24, I definitely see detail loss/smearing on mono compared to multi, albeit <1m from the screen. That 4-bit trick is cool. For example, in Oblivion, at the beginning, there are these two triangle ships things floating, you can easily make out the numbers with multi-dyn/stat, much less sharp/clear with mono variants.

So, IMO...
multi-dyn > multi-stat > mono-stat > mono-dyn

[leeperry]

You're completely misinterpreting the technical facts. I do not (artificially) add any amount of chroma noise. The multiColor builds have lower luma noise but higher chroma noise compared to the monoColor builds. But that's not because I'm adding chroma noise (I'm not) but it's simply a consequence of using different dither structures per RGB channel.

Well yeah, you are using one different dithering structure per RGB channel, that's thrice more noise(triple dithering literally) and together they become the star of the show, killing clarity and dynamics. It gets even worse if each of this dancing noise veil becomes dynamic. I don't see how and where we could be misunderstanding each other here.

You're complaining about the higher chroma noise, but at the same time you *totally* ignore the fact that the luma noise is as much down as the chroma noise is up.

My point is that chroma already comes with half less resolution than luma so there'll already be inevitable artifacts due to the upscaling, don't hit a man on the floor, weakest link, etc.

And I absolutely don't see the point to bother calibrating and going batty with colorimetry if the R/G/B channels get their own little personal pattern of random'ish noise afterwards.

And the lower the luma noise the higher the dynamics and the sense of depth as well as luma isn't smeared down anymore.
Hah, sounds made up :D Especially when you previously said "The multiColor builds seem to lower the luma noise a bit on the cost of having slightly higher chroma noise" but that was a nice try :)

One less luma noise veil traded for literally 3 times more chroma noise that together will create new patterns literally becoming a noise feast? Not a good deal, not a good deal at all.

FWIW, I'd suggest you read this:

http://www.imaging-resource.com/news/2014/01/17/fujifilm-files-patent-for-sensor-with-enlarged-green-white-pixels
FWIW, I'd emphasize again on the fact that these ppl do not work in lossy YV12 with such poor chroma resolution and digital cameras usually run all kinds of internal post-processing to make the picture more "poppy".

Anyway, let's agree to disagree and If I have to stick with an old beta forever then alea jacta est ;)

[Ver Greeneyes]

I don't see much difference between top and bottom half of each pixel block, but it does seem like the borders stand out quite noticeably... :(

Is this as noticeable in real life for you? Or did this effect get stronger through your editing/compositing? I don't think I can see any block structure on my PC. And I'm trying!
Just to make sure I did the same test in 8-bit mode. I overlaid 36 frames as layers and added them together, then copied the area where it starts to become visible and expanded that from 0-3 to 0-255 (in other words, a ridiculous amount). This is the result: http://i.imgur.com/Z8phPqQ.png. So the effect is there even in 8-bit mode, but only so extremely close to black that the probability of getting even 1/255 is tiny (I added together 36 frames and expanded the range by a factor of 85, and these pixels still aren't white). So yeah, let's not get hung up about this ;) If I had to guess I'd say we're hitting up against the limits of the PRNG madVR uses. Simple PRNGs are notorious for their least significant bits not being very random, and maybe the way madVR is seeding it causes slightly higher results for pixels with y & 8 and slightly lower results for pixels with !(y & 8).

[madshi]

Don't look at the bright areas too closely, those square borders weren't visible to me at all before processing. I uploaded a brightened version of the image here (http://i.imgur.com/jpzr04b.png). Look at the top left or bottom right areas - don't the blocks look like they have vertical gradients in them to you? Looking at it from a distance it makes each row of blocks look like a separate band to me.

But! I only noticed this in 4-bit mode, and even there it's only visible on the darker side of the gradient, which itself tops out at RGB888(7,7,6) after dithering. We're talking values of less than 1/255 in all color channels here. So unless there's some obvious source of bias I wouldn't worry about it.
There's definitely no (intended) bias in the algorithm. I'm not sure where this effect is coming from. I'm relieved to hear that you didn't see the 16x16 borders in real time watching. That would have been a problem!

Mono-Color Dynamic for me.

Static looks like overlay of dirt on top of the picture, very unpleasant to watch.
The image moves while the dirt stays, this enhances the dirt effect even more.

EDIT:
I see LESS visible/subjective noise with the MonoColor compared to the MultiColor Dynamic build.
Definitely, it looks like MultiColor Dynamic dithering is "crazier"..... the dots appear to be bigger and more "jumpy" to me.
Interesting. Looks very different to my eyes.

Does your monitor support 4:4:4? Maybe it could have to do with 4:2:2 vs 4:4:4 or something like that?

Alright, testing BD rips 1080p24, I definitely see detail loss/smearing on mono compared to multi, albeit <1m from the screen. That 4-bit trick is cool. For example, in Oblivion, at the beginning, there are these two triangle ships things floating, you can easily make out the numbers with multi-dyn/stat, much less sharp/clear with mono variants.

So, IMO...
multi-dyn > multi-stat > mono-stat > mono-dyn
Cool, that triangle ship number thing sounds like a very objective test to me.

Well yeah, you are using one different dithering structure per RGB channel, that's thrice more noise
Incorrect. All 3 channels are dithered in any case, monoColor or multiColor. So all 3 channels get some noise in any case. The monoColor builds apply a similar noise structure to all 3 channels, the multiColor builds apply a different noise structure to all 3 channels. In both cases the amount of noise per channel is identical. The only difference is that the noise structure of the 3 channels is somewhat (but not totally) matching with the monoColor noise while it's totally different with the multiColor builds. What this does is that is subjectively raises the chroma noise level a bit (but not by a factor of 3!) and at the same time the luma noise level is lowered, because when e.g. the red pixel is one up, the green pixel could be one down, averaging the luma value nearer to the correct value.

As I said before, this is a trade, and whether this trade is a good idea or not might be a matter of taste. Let's hear more opinions from different people.

And leeperry, please don't go around sending PMs now.

And I absolutely don't see the point to bother calibrating and going batty with colorimetry if the R/G/B channels get their own little personal pattern of random'ish noise afterwards.
As I said above, they get a pattern of random'ish noise, in any case, regardless of whether it's monoColor or multiColor. And when you measure your display with a meter you will probably not measure a difference in either color or luma between the monoColor or multiColor builds, because a meter isn't measuring one pixel, but an average of multiple pixels, so both luma and chroma noise is automatically "blended together".

Hah, sounds made up
What you said sounded made up, too. Usually when talking about dynamics and sense of depth, people think more about luma than chroma.

One less luma noise veil traded for literally 3 times more chroma noise that together will create new patterns literally becoming a noise feast?
Incorrect, once again.

Just to make sure I did the same test in 8-bit mode. I overlaid 36 frames as layers and added them together, then copied the area where it starts to become visible and expanded that from 0-3 to 0-255 (in other words, a ridiculous amount). This is the result: http://i.imgur.com/Z8phPqQ.png. So the effect is there even in 8-bit mode, but only so extremely close to black that the probability of getting even 1/255 is tiny (I added together 36 frames and expanded the range by a factor of 85, and these pixels still aren't white). So yeah, let's not get hung up about this ;)
Ok... :)

[cyberbeing]

The static versions do not seem to adapt to the background at all, remaining completely stationary with the same dither patterns in the same locations on the screen during the entire movie. I would at the very least expect to see a new randomly generated static pattern whenever the contents of each 16x16 block changed more than a certain threshold or something. Find a half-way point where we have static dither on motionless objects, and dynamic dither on objects in motion.

Assuming no changes, I'd still vote for "monoColor Static" though. IMHO, static noise on objects in motion is the lesser evil compared to dynamic noise on stationary objects. The multiColor builds do seem to cause random color shifts on neutral colors, and they didn't appear to have any less luma noise than the monoColor builds.

[madshi]

Oh my gosh. leeperry and cyberbeing agree, and I disagree... :scared:

[James Freeman]

Mono-Color Dynamic for me.

Interesting. Looks very different to my eyes.

Does your monitor support 4:4:4? Maybe it could have to do with 4:2:2 vs 4:4:4 or something like that?


4:4:4, AMVA+, 2500:1 contrast ration, PC Monitor (Asus VN279QLB)
I'll give it another go then, and see.

The multiColor builds do seem to cause random color shifts on neutral colors, and they didn't appear to have any less luma noise than the monoColor builds.
I agree to this.
To second that, it appears to have MORE noise than the MonoColor build.

EDIT:
I changed my mind later this day... to MultiColor Dynamic.

[Ver Greeneyes]

The static versions do not seem to adapt to the background at all, remaining completely stationary with the same dither patterns in the same locations on the screen during the entire movie. I would at the very least expect to see a new randomly generated static pattern whenever the contents of each 16x16 block changed more than a certain threshold or something.That's an interesting point. So the way it works now, the result of the PRNG only depends on the pixel coordinates? Perhaps the result of the PRNG and the color of a pixel could be hashed together? I dunno how expensive that would be.

Edit: This article (http://briansharpe.wordpress.com/2011/11/15/a-fast-and-simple-32bit-floating-point-hash-function/) describes a fast 32-bit floating point hashing algorithm. Worth a shot?

[leeperry]

The only difference is that the noise structure of the 3 channels is somewhat (but not totally) matching with the monoColor noise while it's totally different with the multiColor builds. What this does is that is subjectively raises the chroma noise level a bit (but not by a factor of 3!) and at the same time the luma noise level is lowered, because when e.g. the red pixel is one up, the green pixel could be one down, averaging the luma value nearer to the correct value.
Well yeah, three *totally different* noise structures for the R/G/B channels is a no-go, abort the mission. I know what I see and I can read english but I'm starting to believe that my writting skills are out the window as you keep on misunderstanding what I'm trying to convey. I apologize and will try to improve this situation.

As I said before, this is a trade, and whether this trade is a good idea or not might be a matter of taste. Let's hear more opinions from different people.
That's fully understood, especially as +95% of computer monitors are uncalibrated 6bit TN's in 60Hz and the vast majority of TV's are IPS, I rest my case that it'd take more than two mere algorithms to make everyone happy.

And leeperry, please don't go around sending PMs now.
I'm not into washing my laundry in public but if you want me to stop testing your VR, two words will do. I didn't plan on PM'ing you for that matter, especially as even Stevie Wonder can see that "monoColor Static" looks better(j/k :D)

As I said above, they get a pattern of random'ish noise, in any case, regardless of whether it's monoColor or multiColor. And when you measure your display with a meter you will probably not measure a difference in either color or luma between the monoColor or multiColor builds, because a meter isn't measuring one pixel, but an average of multiple pixels, so both luma and chroma noise is automatically "blended together".
It's got nothing to do with measuring. The less noisy the chroma, the clearer the picture looks and the "truer to the source" colors appear. My brain likes colors to be as "pure" as possible, it's got a hard time dealing with artificial colors, to my colorblind brain either colors are "natural" or "artificial". Reason why I always calibrate my displays, it provides me with a much more enjoyable experience :)

Usually when talking about dynamics and sense of depth, people think more about luma than chroma.
Of course they do, you need as little noise as possible in order to keep the original "impression of depth"....the noisier it gets the fuzzier it looks as the noise veil on top of the movie only gets thicker.

Incorrect, once again.
Absolutely not. Three *totally different* noise structures for the R/G/B channels will together become a noise feast, it makes perfect sense.

I'd still vote for "monoColor Static" though. IMHO, static noise on objects in motion is the lesser evil compared to dynamic noise on stationary objects. The multiColor builds do seem to cause random color shifts on neutral colors, and they didn't appear to have any less luma noise than the monoColor builds.
Yep, it's a matter of picking your poison more than anything else.

Oh my gosh. leeperry and cyberbeing agree, and I disagree... :scared:
http://t1.gstatic.com/images?q=tbn:ANd9GcQCIX9jpGRwT2Wi2KZ6QkCoVXC3YfmfUwPVx7ALaDM9lM-1I1nHsof8Vo7r

[GREG1292]

You're completely misinterpreting the technical facts. I do not (artificially) add any amount of chroma noise. The multiColor builds have lower luma noise but higher chroma noise compared to the monoColor builds. But that's not because I'm adding chroma noise (I'm not) but it's simply a consequence of using different dither structures per RGB channel. You're complaining about the higher chroma noise, but at the same time you *totally* ignore the fact that the luma noise is as much down as the chroma noise is up. Which means your judgement about this is very one-sided.

madshi: I'm going to test tonight since I use needi32
upscaling and 32 Luma doubling. I notice the luma noise
in King Kong 720p upsclaed to 1080p and is distracting. Hopefully the chroma noise is not increased. A4 is going
to be tough to improve on but I agree 100% the lowering of the noise floor is on my wish list.

[DarkSpace]

I would at the very least expect to see a new randomly generated static pattern whenever the contents of each 16x16 block changed more than a certain threshold or something. Find a half-way point where we have static dither on motionless objects, and dynamic dither on objects in motion.
I think that might actually be a good idea.
Before I test and evaluate the results, I want to make sure I'm looking for the right thing. We're still discussing the medium-noise algorithm, and not the low-noise one, right?

[iSunrise]

The static versions do not seem to adapt to the background at all, remaining completely stationary with the same dither patterns in the same locations on the screen during the entire movie. I would at the very least expect to see a new randomly generated static pattern whenever the contents of each 16x16 block changed more than a certain threshold or something. Find a half-way point where we have static dither on motionless objects, and dynamic dither on objects in motion.
More or less, yes, I agree.

IMHO what we´re trying to achieve is to make dithering behave in such a way, that it tries to match the source as close as possible with the available bits there are and not show us an alternate version that adds something we don´t need for a higher perceived bit-depth.

Noise is not there because we want it, but because noise is only needed for the purpose to make up for the missing bits.

With that said, purely from a scientific POV, static noise is NOT good at all and should be dealt with, because static noise will not help us at all to approximate the source pixels in an actual movie. All it will do is approximate one frame and let that stay forever. The same for multiColored noise, which is also NOT what we want, because there´s no reason whatsoever to introduce colored noise into something which wasn´t there in the first place. Gray backgrounds with green/red dots? Makes no sense at all. That also was the reason why Random Dithering looks rather messy in comparison and why we wanted to get rid of that.

So, personally, I vote for monoColor_dynamic.

Another thing that comes to mind is that even static parts in movies are not really static. We are watching several frames, where the contents may change on a not so visible level. If we look at static images, static definitely is prefered of course, but not necessarily in actual movies.

IMHO, if we want to reach the optimum, we would need madVR to behave in such a way that for static content, it would activate the static algorithm and for moving content, it would activate the dynamic one.

The bolded part may be a good idea to make that happen (maybe madshi has an alternative idea), but it sounds rather computationally expensive to me.

@madshi:
It´s impressive that on some movies with your "4bit mode" I can´t see a difference between 8bit and 4bit. IMHO that speaks volumes about what kind of quality we already achieved with the dithering algorithm.

One thing I can easily recognize though, is it expected that your "4bit mode" has so much noise on black? Because I can see very visible elevated black levels, because of that. And it´s basically the same for all of the 4 new builds.

Also, the black bars outside of the actual movie content, which are pure black are also elevated about the same. I can see this easily when i watch 1080p on my 1920x1200 screen. I would expect madVR to draw 0 (meaning pure black) outside the actual movie area at the top and bottom. Or is this already planned to be adressed with the cropping feature you talked about?

[noee]

I have to change my opinion, fwiw. Just rolled these builds with some not-so-good SD material and monoColor_dynamic wins here.

[bacondither]

Testing is done in 4bit mode.

Multicolor dynamic seems to have the lowest subjective noise level. monocolor dynamic a bit higher noise level but are free from colored noise on grey parts.

Dynamic builds hides the noise better the static builds due to temporal smoothing.
The HVS averages fast changing pixels, similar to how a plasma or DLP works.

Static builds looks like some grey "dither-haze" permanently stuck on the screen.

The picture looks a bit brighter due to dithering in gamma light and dithering down to 4-bit exaggerates the differences a lot more.

[cyberbeing]

The risk with it being 16x16 blocks though, is it could theoretically be noticeable if you had a static and dynamic block next to each other. It would probably just be safer to just switch globally across the entire frame. Use dynamic when all 16x16 blocks on the frame are in motion, and static otherwise. Or something along those same lines. Just an idea, it just felt a bit odd watching anime in 4bit test mode, that the dither texture never moved.

This static dither is not really noticeable using normal 8bit mode on anime, but the dynamic dither was visible as temporal noise. With film content, I don't think 41.7ms changes are very suitable for dynamic dither to produce a perceptually flat appearance, but I don't think madVR is doing anything in these recent test builds to diffuse error in temporal fashion over a number of frames at the same time it is doing spatial error diffusion within each individual frame.

[James Freeman]

Testing is done in 4bit mode.

Multicolor dynamic seems to have the lowest subjective noise level. monocolor dynamic a bit higher noise level but are free from colored noise on grey parts.


Good observation.

I like the sterile (IMO more accurate) look of MonoColor Dynamic build even though it has a tad more noise in 4-bit.
In 8-bit, the difference in noise will be highly less noticeable to non-notceable at all.

EDIT:
I changed my mind later this day... to MultiColor Dynamic.

It´s impressive that on some movies with your "4bit mode" I can´t see a difference between 8bit and 4bit.
Yeah, Considering 4-bit is only 16 shades of grey & 4096 colors !!!!
Its amazing.

[Shiandow]

The risk with it being 16x16 blocks though, is it could theoretically be noticeable if you had a static and dynamic block next to each other. It would probably just be safer to just switch globally across the entire frame. Use dynamic when all 16x16 blocks on the frame are in motion, and static otherwise. Or something along those same lines. Just an idea, it just felt a bit odd watching anime in 4bit test mode, that the dither texture never moved.

If you want to do something where only changing parts of the image have temporal noise then it would probably be better to let the noise depend on the pixel. And preferably in such a way that this doesn't affect other pixels.

I think this can be achieved by hashing the pixel value and combining this with the result from the RNG. This shouldn't change the noise for any 'unchanged' pixels that come after it but it does mean that noise changes whenever a pixel changes.

It would be hard to have some sort of threshold to check if it changed 'much'. The only 'feasible' way I can think of is to use the pixel value itself to interpolate between several different noise patterns in the way I described a few pages back, it would be a bit tricky to make it random enough but I think it can be done if you combine it with the idea I gave above about hashing the pixel values.

[Ver Greeneyes]

I'm not into washing my laundry in public but if you want me to stop testing your VR, two words will do.You should really try not to get so worked up over this; it kind of hurts your case. I can see why madVR would be annoyed about people PMing others to influence the vote, and you should be able to see why too. Besides, this isn't exactly a poll - to most of us these differences are very minor, and I'm sure that influences how much weight madshi gives our choices. But I don't think constant hyperbole and threatening to stay with the same beta forever is going to help how much weight he gives yours.
The less noisy the chroma, the clearer the picture looks and the "truer to the source" colors appear. My brain likes colors to be as "pure" as possible, it's got a hard time dealing with artificial colors, to my colorblind brain either colors are "natural" or "artificial".I think this is perfectly valid - since your brain has to go off perceptual brightness alone, I can easily see small differences that a non-colorblind person wouldn't notice (mapping them onto a different axis) standing out to you. I also have no real problem going with what you prefer, but I do think we should explore all the technical details as objectively as possible.

[leeperry]

This is no threatening at all as ED4 blows me away and I would have no problem sticking with it. I realize that I'm colorblind(like 8% of the population) and I would appear to use a higher contrast LCD screen than most people. I also have BFI enabled so I don't suffer from the usual LCD motion blurriness as this will obviously change how noise is perceived.

I want colors to remain as untouched as possible as the color decoding of my eyes already starts with a lack of resolution and lossy YV12 chroma is already extremely low-res to begin with.

madshi made very clear that he doesn't want to provide zillion options for dithering in mVR and I am fully aware that for instance an uncalibrated 60Hz 6bit TN panel to a non-colorblind person might very well require completely different treatment. It's up to madshi to decide.

[MistahBonzai]

The my GTX 770 can do nnedi3 32 chroma upscaling. lanczos4AR luma upscaling, and ED without dropping frames. 73% GPU load, 13.3ms avg render time. Adding NNEDI3 doubling of any kind on top is a complete no-go...

About the same here with the HD-7850. Render time is ~15.5ms with the Max occasionally hitting 16.5ms (that short video seems to cause 'bounce' in the render times when rewinding - which is most of the time.) CPU is ~8-10% while GPU is ~79%.

Switch is any nnedi doubling (even 16 neurons) with luma and the render time jumps to ~38ms and peaks ~42ms while the frames start dropping like flies.

[MistahBonzai]

@MistahBonzai
What were your render times and GPU load % using NNEDI3 32 neurons luma doubling alone with that 720p60 -> 1080p60 test? 42.5 - 45ms all things being equal (chroma 32 nerons with ED enabled). Glad to here you have similar performance as I was about to tear into things despite the 'good' OpenCL benchmarks. I'll restate the obvious for those who may overlook the effect on rendering time that fps has on 'performance'. Rendering a '60' fps video versus a '24' fps one means that the individual rendering window 'availability' is only about 40% of what it was at 24 fps but the 'work time' remains the same...

[iSunrise]

-the good side of monoColor_dynamic is that it brings "life" to the original movie grain so it's pretty cool on low-bitrate movies but it's more of a special effect than dithering anymore to my eyes...I guess this is sort of what you would expect from a "movie grain" DSP but the flip side of the coin is that it also drastically kills clarity & the impression of depth.

-The nice thing about monoColor_static is that the dithering noise is as non-invasive as possible, my brain can easily get used to its pattern and it's the least harmful to the movie original grain. This also provides the best sense of depth by a very long shot as I'm not watching the dithering dancing around anymore.
The problem you describe seems very influenced by something I´m not sure about.

Just sit back for a moment and think about what you´re actually saying.

If there are movies with heavy grain, that grain will obviously be subjectively strengthened (since your brain compares to the static build) by the dithering algorithm, because it´s in the source. If with your tests of the static build the grain will be less intrusive, that would mean it´s actually less accurate in that case and I explain why.

Because if you watch a movie without heavy grain (mainly static backgrounds like Tron: Legacy) what you actually do is not approximate it, you introduce a pattern to the whole movie that acts exactly like the thing you described some pages ago, the "grid effect" on IPS panels. And now suddenly, you like that more than the other? I can´t understand your reasoning in this case at all.

Of course on bit-starved movies, the GIGO principle applies and monoColor_dynamic looks more realistic but this is not actual reel grain and the noisier the lower the dynamics. Definitely not what I expect from a dithering process.
Think about this one again please. If you want to be true to the source as your holy grail, you would expect a compressed source that is so badly compressed that you see block artifacts to show you the blocks and NOT artificially smooth them out. This has nothing to do with lowering the dynamics. And it doesn´t matter if it´s real grain, the grain needs to be on the screen if it´s in the source, otherwise we don´t increase the bit-depth, we would actually decrease it. If you want to smooth out something, that´s what artifact removal is about.

Regarding the latter, you said "resulting in gray ramps staying completely gray", that's exactly how I expect them to look like.
While I also think that gray bars should present themselves as grey bars and not colored bars, keep in mind that the gray bars are not real, they are artificially created. However, I also see no reason why we would have to introduce colors into the mix, because that would mean the result would basically be different from what is in the source ALL THE TIME. And that´s not an approximation at all, that´s just wrong.

BTW, not sure if everyone realizes that, but we are actually at a point now, where we may already have decided between our medium-noise and low-noise algorithm. At least I don´t see much potential for further improvements for a low-noise algorithm that is still true to the source without creating "a pattern" (like the static build does) or something along those lines.

So we could all be fine with the choice of the _dynamic and _static build. I´m not sure about the Multicolor stuff, no one has yet shown anything where that may be beneficial, instead of maybe a little lower noise floor.

[leeperry]

All I'm saying is that with mono static I can see and enjoy the original movie grain(and the silver grain chunks size changes depending on the shade) but with mono dynamic it's veiled by the dithering algorithm that's constantly changing. That's very distracting and it kills the "impression of depth" as the original movie grain is barely discernable anymore.

Gray bars matter very much, whatever for B&W movies or for D65 sake's. I do not want my gray bars to look ever so slightly tinted as I run a dead-on REC709 D65 calibration for a reason.

[James Freeman]

Hmm... After some more testing I'm beginning to gravitate toward the MultiColor Dynamic build instead the MonoColor Dynamic.

Looking at movies (especially skin tones) and test patterns,
MultiColor appears to be less noisy (smaller noise?) and make the image look a tad smoother (higher bit) compared to MonoColor.
The grey test pattern also looks smoother and less noisy.

The MonoColor does have a more sterile look but it also noisier and less smooth in transition between shades.
Taking into consideration that these observations are in 4-bit; in 8-bit these differences will be negligible,

To conclude I much prefer to know we have the smoothest & most noiseless (less noisy), "higher bit depth looking", dithering available.

MultiColor Dynamic it is.

[Shiandow]

Gray bars matter very much, whatever for B&W movies or for D65 sake's. I do not want my gray bars to look ever so slightly tinted as I run a dead-on REC709 D65 calibration for a reason.

You should be careful about that, the way the algorithm currently is it will only be gray if all the pixels in that 16x16 block are gray. Actually at this point I would rather call it a 'coincidence' then an actual feature of the algorithm. It can be 'fixed' by performing error diffusion in YCbCr, but this is hard.

Also for what it's worth, I have been able to verify your claim that using uniform noise on all 3 RGB channels causes 'more' noise. The mean 'amplitude' of the noise becomes slightly higher. In RGB the mean amplitude is 11% higher using 'multiColor' noise but in YUV this rises to 24%. I'm not exactly sure how closely 'distance' in YUV corresponds to visual differences in colour, because I think distances in UV are less important than those in Y, but I don't know which colour space I should use to fix that.

[lhan]

I had same problem with gigabyte p55ud4 (i7 860- and R9 280x GFX
I tried clean win7 install and it was still KO with 13.12.
I tried nvidia gtx560ti gfx and no problem
I tried R9 280x on other motherboard (asus Z77 i7 3770k) and no problem :angry:
I guess there is some issues with AMD - p55 - openGL - 7xxx series.
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.

[*Touche*]

Finally got around to doing some testing:

Panasonic ST60 plasma (calibrated)
4:4:4
720p24 BRRip (Thor 2)
4bit (very hard to see the differences otherwise)

multiColor_dynamic - BEST, none to barely visible noise, more stable picture

monoColor_dynamic - worse than multi, visible noise

both static bulds - terrible! noise all over, hard to watch

I've even done blind tests between multi and mono and could immediately spot the higher noise with mono.


BTW: Do these builds use OpenCL or DirectCompute, because the performance is about the same as v0.87.4 for me?

[The 8472]

I'm not exactly sure how closely 'distance' in YUV corresponds to visual differences in colour, because I think distances in UV are less important than those in Y, but I don't know which colour space I should use to fix that.

Just measure the Y error amplitude since it combines components of RGB anyway? So you're only measuring the visually most significent component and thus could potentially claim that if anything it even underrepresents the error?

[Skankee]

Panasonic ST60 plasma (calibrated)
4:4:4

From what i see on hdtvtest.co.uk the Panasonic Plasma TVs (GT/VT/ZT) can´t do full 4:4:4, so i don´t think the ST60 can do it?

edit: ok, ST60 can do 4:4:4, nice to know :)

[mithra66]

I think I've an inclination for the same image characteristics as Lepeery but I have to disagree here: according to me, MultiColorDynamic increases depth and clarity, image dynamics, whatever.

I'm surprised that you don't see the same progress, maybe because of your specific "colorless" view.

To be honest I'm no good to see the noise fest you are describing , not in in this build, but not in previous builds either.

I thought that A4 was great but before these last build I was about to write that I regretted that there was something "lost" on edges compared to "no dithering". Don't mistake me, I prefered by large dithered image which has a lot overbalancing qualities.

So that you know, I watch a Pioneer G9 60' from 8 feets distance: pristine sources such as Game of Throne S01e01 King's arrival, Avatar, Jon Carter, Alice In Wonderland, The Avengers and some noisy too: Aliens, Black Swann

Now I'll watch the other 3 builds.

[*Touche*]

From what i see on hdtvtest.co.uk the Panasonic Plasma TVs (GT/VT/ZT) can´t do full 4:4:4, so i don´t think the ST60 can do it?

ST60 can:
http://www.hdtvtest.co.uk/news/panasonic-tx-p42st60-201303312779.htm

And firmware upgrade fixed the Photo setting requirement.

[Shiandow]

Just measure the Y error amplitude since it combines components of RGB anyway? So you're only measuring the visually most significent component and thus could potentially claim that if anything it even underrepresents the error?

Well if you only look at the Y component then multiColor is clearly better, but whereas the monoColor algorithm has no UV noise the multiColor algorithm does have UV noise, so you need some way to compare UV noise to Y noise, and I haven't found that yet.

And the fact that it underrepresents the error isn't really helpful; that just means I only get a lower bound, but to prove that one is better than the other I need an upper bound as well.

Edit: FWIW I redid the calculations in CIELAB, this caused the multicolor noise 'amplitude' to be 2 times as high although it depends heavily on what the original colour was.

[madshi]

The static versions do not seem to adapt to the background at all, remaining completely stationary with the same dither patterns in the same locations on the screen during the entire movie. I would at the very least expect to see a new randomly generated static pattern whenever the contents of each 16x16 block changed more than a certain threshold or something. Find a half-way point where we have static dither on motionless objects, and dynamic dither on objects in motion.
This is out of my control. If I use the same (static) random numbers for every frame it's clear that there will be visible structures which won't easily change. There's nothing I can do about this. Except using a different seed for every frame, which the dynamic builds do.

Switching between dynamic and static per block (or per frame) would look weird IMHO. I don't think I even want to try that.

The multiColor builds do seem to cause random color shifts on neutral colors, and they didn't appear to have any less luma noise than the monoColor builds.
Color shifts you can see with your naked eye? In real life content without zooming in? Can you provide a small sample? Would like to see that here.

You may want to revisit the luma noise question. I think you'll find that the multiColor builds do have lower luma noise. Of course it might be more visible with some videos than others. Whether the lowered luma noise is worth the higher chroma noise is a question worth asking, though.

I'm not into washing my laundry in public but if you want me to stop testing your VR, two words will do. I didn't plan on PM'ing you for that matter
I meant you shouldn't go PMing *other users*, asking them to vote for your favorite algorithm, like you did last time.

The less noisy the chroma, the clearer the picture looks
That applies even more so to luma. Which you totally ignore, as always.

My brain likes colors to be as "pure" as possible, it's got a hard time dealing with artificial colors, to my colorblind brain either colors are "natural" or "artificial".
I can understand that. But I can't pick algorithms which look best only to colorblind people. I need to pick for the majority of people. And the majority of people are bothered by luma noise more than by chroma noise.

Absolutely not. Three *totally different* noise structures for the R/G/B channels will together become a noise feast, it makes perfect sense.
No, it does not. Have you heard of wave cancelling? Basically if you produce noise that is the "opposite" of already existing noise, you can cancel the original noise out. Some noise protection headphones work that way. If you have 3 channels with exactly the same noise, the overall noise level actually increases by 3x. If you have 3 channels with different noise structures, some of the noise will cancel each other out. This is from the view point of luma noise, though. The situation is different for chroma noise. But this is a complicated technical topic.

If I may friendly suggest: Stick to what you're good at. Look at the image, describe what you're seeing and be done with that. Don't try to explain things on a technical level. That often weakens your argument more than it helps.

The same for multiColored noise, which is also NOT what we want, because there´s no reason whatsoever to introduce colored noise into something which wasn´t there in the first place. Gray backgrounds with green/red dots? Makes no sense at all.
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?

It´s impressive that on some movies with your "4bit mode" I can´t see a difference between 8bit and 4bit. IMHO that speaks volumes about what kind of quality we already achieved with the dithering algorithm.
Yep, I was impressed with the results of the 4bit mode myself! :)

One thing I can easily recognize though, is it expected that your "4bit mode" has so much noise on black? Because I can see very visible elevated black levels, because of that. And it´s basically the same for all of the 4 new builds.
I don't know, but I don't think it matters. The 4bit mode is only for testing, for nothing else.

I have to change my opinion, fwiw. Just rolled these builds with some not-so-good SD material and monoColor_dynamic wins here.
JFMI: Why? In which way do they look better than with the multiColor_dynamic build?

Multicolor dynamic seems to have the lowest subjective noise level. monocolor dynamic a bit higher noise level but are free from colored noise on grey parts.
Agreed. So which do you prefer?

I also see no reason why we would have to introduce colors into the mix, because that would mean the result would basically be different from what is in the source ALL THE TIME. And that´s not an approximation at all, that´s just wrong.
Error diffusion (including multiColor_dynamic) does nothing if the source bitdepth and target bitdepth and the input and output levels match. If they don't match then you technically cannot display the source in its original form.

BTW, not sure if everyone realizes that, but we are actually at a point now, where we may already have decided between our medium-noise and low-noise algorithm. At least I don´t see much potential for further improvements for a low-noise algorithm that is still true to the source without creating "a pattern" (like the static build does) or something along those lines.
No, this is not decided yet. A low noise algorithm could still have less noise than any of the recent builds.

I do not want my gray bars to look ever so slightly tinted as I run a dead-on REC709 D65 calibration for a reason.
Why would they be tinted? The chroma noise should average itself out to pretty much perfect D65.

You should be careful about that, the way the algorithm currently is it will only be gray if all the pixels in that 16x16 block are gray. Actually at this point I would rather call it a 'coincidence' then an actual feature of the algorithm.
Yes. I've been wondering why so many of the test patterns stayed perfectly gray. I did expect some coloring to occur already with the monoColor build. Not sure. Maybe there's a small "safety margin" where the monoColor algorithm stays gray? But doesn't really matter too much, I guess...

Also for what it's worth, I have been able to verify your claim that using uniform noise on all 3 RGB channels causes 'more' noise. The mean 'amplitude' of the noise becomes slightly higher. In RGB the mean amplitude is 11% higher using 'multiColor' noise but in YUV this rises to 24%.
I'm not sure I understand this. leeperry claimed that uniform noise on all 3 RGB channels causes *LESS* noise, not more. And the 'multiColor' build does not use uniform noise. So I'm quite confused what you mean and what you tested and what your test results are?

I think I've an inclination for the same image characteristics as Lepeery but I have to disagree here: according to me, MultiColorDynamic increases depth and clarity, image dynamics, whatever.
Thanks for the feedback.

Hmm... After some more testing I'm beginning to gravitate toward the MultiColor Dynamic build instead the MonoColor Dynamic.

Looking at movies (especially skin tones) and test patterns,
MultiColor appears to be less noisy (smaller noise?) and make the image look a tad smoother (higher bit) compared to MonoColor.
The grey test pattern also looks smoother and less noisy.

The MonoColor does have a more sterile look but it also noisier and less smooth in transition between shades.
multiColor_dynamic - BEST, none to barely visible noise, more stable picture

monoColor_dynamic - worse than multi, visible noise

both static bulds - terrible! noise all over, hard to watch

I've even done blind tests between multi and mono and could immediately spot the higher noise with mono.
This is what I'm seeing here, too. But it seems not everybody agrees. Not sure yet how to solve this problem. I guess I should wait for more feedback before deciding which way to go.

Well if you only look at the Y component then multiColor is clearly better, but whereas the monoColor algorithm has no UV noise the multiColor algorithm does have UV noise, so you need some way to compare UV noise to Y noise, and I haven't found that yet.
Ah yes. This is exactly what I said all the time: The multiColor build should have lower luma noise, but higher chroma noise. FWIW, all the information I've seen suggests the luma noise is more critical than chroma noise. And my eyes seem to agree. However, I'm not sure how much lower the luma noise is and how much higher the chroma noise is in the multiColor build, so it's still to be decided whether it's a good tradeoff or not.

Do you have a favorite yet? Or are you not sure yet?

[leeperry]

Basically if you produce noise that is the "opposite" of already existing noise, you can cancel the original noise out. Some noise protection headphones work that way.
I fully understand your explanation but that definitely doesn't match what I'm seeing...figures.

Why would they be tinted? The chroma noise should average itself out to pretty much perfect D65.
You said yourself that static mono was "resulting in gray ramps staying completely gray" and that "mono-colored may look better for gray ramp", anyway I'm much against chroma noise due to personal taste and physiological limitations as it would appear. My brain color decoding sees it as wild interferences that kill the luma clarity and edges visibility.

I need to pick for the majority of people. And the majority of people are bothered by luma noise more than by chroma noise.
So I presume that cyberbeing ends up as a collateral casualty? Maybe he should consider running color blindness tests (http://www.colour-blindness.com/colour-blindness-tests/ishihara-colour-test-plates/) :D

So to be perfectly clear, mVR will come with two dithering algorithms and at least one of them will more than likely be completely unsuitable for at least 8% of the world population? Hopefully a registry key hack for the losing minority would be awesomtastic, we're people too :o

[nevcairiel]

I prefer the multicolor dynamic, it looks slightly smoother, even though the differences without enhancements are barely visible at all.
In 4bit, the advantage of multicolor dynamic is glaringly obvious, imho.

[Shiandow]

Switching between dynamic and static per block (or per frame) would look weird IMHO. I don't think I even want to try that.
Yes. I've been wondering why so many of the test patterns stayed perfectly gray. I did expect some coloring to occur already with the monoColor build. Not sure. Maybe there's a small "safety margin" where the monoColor algorithm stays gray? But doesn't really matter too much, I guess...


Most patterns I've seen were either entirely gray or didn't have any gray. There was one test with several coloured bars followed by a gray gradient, I'm pretty sure that those tests did have coloured noise. The problem is that it is hard to see if the RGB channels are only slightly misaligned, since pixels are supposed to be close enough that adjacent RGB values blend together (otherwise you'd just see red green blue dots).

I'm not sure I understand this. leeperry claimed that uniform noise on all 3 RGB channels causes *LESS* noise, not more. And the 'multiColor' build does not use uniform noise. So I'm quite confused what you mean and what you tested and what your test results are?


I basically calculated the expected value of the distance between some colour and that colour plus a random variable (i.e. noise). In one case I used the same uniform random variable for all 3 channels (monoColor), in the other I used 3 different uniform random variables (multiColor). If I calculated the distance in RGB then the value I got for the multiColor version was 11% higher than the one for monoColor. After that I've been trying to figure out how to factor in that Y noise is more noticeable than UV noise. I still haven't exactly succeeded but if I use the distance squared in YUV then I can at least say that the multiColor algorithm is better if Y noise is at least 2 times 'worse' than UV noise. And since I still prefer the multiColor dynamic algorithm it seems that Y noise is indeed more than 2 times worse than UV noise.

Oh and FWIW I'm pretty sure it should be possible to make noise which changes on changing parts of the image but remains static on static parts of the image, but I'm not sure if it's worth the trouble.

[Ver Greeneyes]

This is out of my control. If I use the same (static) random numbers for every frame it's clear that there will be visible structures which won't easily change. There's nothing I can do about this. Except using a different seed for every frame, which the dynamic builds do.madshi, did you see my post (http://forum.doom9.org/showthread.php?p=1669539#post1669539) on the subject? I don't know how expensive this would be, but I was thinking you could take a hash function from Brian Sharpe's GPU-Noise-Lib (https://github.com/BrianSharpe/GPU-Noise-Lib/blob/master/gpu_noise_lib.glsl) such as |vec4 FAST32_hash_3D_Cell( vec3 gridcell )|, use it on the color and multiply your random number for the pixel position by the result to get a random number that changes based on the color of the pixel. By the way, even if you don't do this, might be a good resource to keep in mind if you ever want to add a noise filter ;)

[Shiandow]

madshi, did you see my post (http://forum.doom9.org/showthread.php?p=1669539#post1669539) on the subject? I don't know how expensive this would be, but I was thinking you could take a hash function from Brian Sharpe's GPU-Noise-Lib (https://github.com/BrianSharpe/GPU-Noise-Lib/blob/master/gpu_noise_lib.glsl) such as |vec4 FAST32_hash_3D_Cell( vec3 gridcell )|, use it on the color and multiply your random number for the pixel position by the result to get a random number that changes based on the color of the pixel. By the way, even if you don't do this, might be a good resource to keep in mind if you ever want to add a noise filter ;)

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.

[madshi]

I fully understand your explanation but that definitely doesn't match what I'm seeing...figures.
It *may* have to do with the color blindness thing. I don't know for sure, though.

So I presume that cyberbeing ends up as a collateral casualty?
I think he might come around liking the "multiColor_dynamic" build (or the new "oppositeColor_dynamic" build, see below), after some more testing... :D

So to be perfectly clear, mVR will come with two dithering algorithms and at least one of them will more than likely be completely unsuitable for at least 8% of the world population? Hopefully a registry key hack for the losing minority would be awesomtastic, we're people too :o
Nothing is decided yet, so let's cross that bridge when we come to it.

I prefer the multicolor dynamic, it looks slightly smoother, even though the differences without enhancements are barely visible at all.
In 4bit, the advantage of multicolor dynamic is glaringly obvious, imho.
Thanks for the feedback!

I basically calculated the expected value of the distance between some colour and that colour plus a random variable (i.e. noise). In one case I used the same uniform random variable for all 3 channels (monoColor), in the other I used 3 different uniform random variables (multiColor). If I calculated the distance in RGB then the value I got for the multiColor version was 11% higher than the one for monoColor. After that I've been trying to figure out how to factor in that Y noise is more noticeable than UV noise. I still haven't exactly succeeded but if I use the distance squared in YUV then I can at least say that the multiColor algorithm is better if Y noise is at least 2 times 'worse' than UV noise. And since I still prefer the multiColor dynamic algorithm it seems that Y noise is indeed more than 2 times worse than UV noise.
Ok, I see. And the random numbers in your test had a 50% chance of being negative, correct? I'm wondering why the RGB distance was 11% higher. Well, anyway...

I've just had another idea, see bottom of this post.

Oh and FWIW I'm pretty sure it should be possible to make noise which changes on changing parts of the image but remains static on static parts of the image, but I'm not sure if it's worth the trouble.
The problem already starts when thinking about how to define "moving parts" and "static parts". E.g. does a 1bit change in one color component already qualify as a moving pixel? Such a change is almost invisible in 8bit. Or what happens if one pixel in a 16x16 block noticeably changes, but the other pixels are not? If I then change the random seed, *all* pixels will be affected by the change, not just the one "moving" pixel. This is getting complicated very fast...

madshi, did you see my post (http://forum.doom9.org/showthread.php?p=1669539#post1669539) on the subject? I don't know how expensive this would be, but I was thinking you could take a hash function from Brian Sharpe's GPU-Noise-Lib (https://github.com/BrianSharpe/GPU-Noise-Lib/blob/master/gpu_noise_lib.glsl) such as |vec4 FAST32_hash_3D_Cell( vec3 gridcell )|, use it on the color and multiply your random number for the pixel position by the result to get a random number that changes based on the color of the pixel. By the way, even if you don't do this, might be a good resource to keep in mind if you ever want to add a noise filter ;)
As Shiandow already hinted, just modifying (e.g. multiplying) the random value by using the pixel value is not that easy, if you still want the final result of the modification to still be white noise. Add to that the problems I mentioned above.

I don't think we'll find a good solution to make the dither patterns change only for moving parts of the image, without losing a lot of performance.

-------

I've just had another idea: Why not make better use of the "noise cancellation" technology I mentioned earlier? Practically, here's another test build (actually 2, one static, one dynamic) which is neither "monoColor" nor "multiColor", but instead it's "oppositeColor".

http://madshi.net/madVRopposite.rar

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?

Here's a small comparison which shows the difference quite nicely, I think:

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

[*Touche*]

Madshi, do these builds use OpenCL or DirectCompute, because the performance is about the same as v0.87.4 for me (A10-5800k)?

[madshi]

Madshi, do these builds use OpenCL or DirectCompute, because the performance is about the same as v0.87.4 for me (A10-5800k)?
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.

[6233638]

Well this is interesting - especially as I had done quite a bit of testing first before realizing there was a new 4bit mode. (hey, now my LCD looks like a plasma TV...)


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.


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.

So when you're actually using this to dither down to 8-bit rather than 4-bit, it's probably preferable. But watching videos in the 4-bit mode, the dynamic builds are so much noisier.


And using the 4-bit mode still suggests to me that ED6 may not have been the best choice as the basis for the newer builds - there are clear patterns showing up with some images.
But again, it probably doesn't matter so much when you're dithering to 8-bit rather than 4-bit.
I fully understand your explanation but that definitely doesn't match what I'm seeing...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?