madVR - high quality video renderer (GPU assisted)

[ryrynz]

The queues are frames yes, as for the extra details, someone else could offer better explainations as to their functions than I but usually you don't need to play with them.

I do know that as long the OSD shows the upload and rendering queues being over at least 4/8 you should be okay with your settings.

[michkrol]

Thank you ryrynz.

How about queues then?
Really short and really simplified summary, with things important from the user's point of view.

The queues are buffers holding video frames that are waiting to be processed or rather waiting for the next processing step(s).

CPU queue size setting changes size of madVR's buffers in your system memory (RAM).
GPU queue size setting changes size of madVR's buffers in your GPU's memory (VRAM). Setting it to high on low memory video card can cause problems.

In the debug OSD, the queues are displayed in processing order. The closer to bottom the queue is, the closer you are to actually displaying the image.
The x-y/z values in OSD are respectively:
x -> min value since last OSD refresh
y -> max value since last OSD refresh
z -> queue size
Optimally you'll want the queues to stabilize at x+1=y=z during playback, for example 7-8/8, since something like 8-8/8 is rather hard to get.

The main advantage of large queue is that you get smooth playback even if you get a short performance drop for some reason (tasks running in background, increase in video's bitrate, etc.).
The main disadvantages of large queue is that when you change setting, like scaling algorithms you need to empty the queue and fill it back and of course that you're using more memory (RAM and/or VRAM) with larger queues.
With large backbuffer/present queue you also get a delay between changing settings and seeing the new settings on screen. The OSD's info is also delayed.

PS. To folks more knowledgeable than me, please inform me about any mistakes in my understanding, so I can correct this post ;)

[leeperry]

But the dithering is being done in RGB, so viewing in 4:2:2 will blur it.
There's nothing wrong with using 4:2:2 for watching films, but I wouldn't use it when we are trying to judge the quality of pixel-level details.
Well, many ppl watch their movies on 4:2:2 TV's you know. Actually a wild guess would be +99% and it would appear that many TV's revert to 60Hz-only once you enable their 4:4:4 PC mode(Sammy sell 3 TV's per second BTW).

And AFAIK only madshi uses RGB dithering for video purposes, anyway on my 4:2:2 TV my left-handed colorblind brain doesn't like that headaches-prone rainbowish chroma noise....c'est la vie.

I really don't see why dithering the image would introduce motion blur.
You just said "the colored builds are using more pixels for dithering" and whatever I could reply would be paraphrasing of this quote:
Clarity is subjectively the best with the Adaptive 4 build for me, too. The other builds have the same effect on me that I described some pages ago, which is that added grain layer, which makes especially highly compressed movies look smoother. But that smoother appearance comes with the cost of sharpness and lost shadow details and I guess that´s what you´re describing as depth of the image. And that´s also what our eyes can see in the real world. [..]

I´m also not sure if that´s my panel specifically, but especially in fast camera pans, when using the multicolor_dynamic builds, it almost seems like there´s so much pixel change going on that I can barely focus the image at all.

Anyway, madshi made clear that all of these algorithms were of the mid-noise kind, maybe lowering the noise strength and/or tweak the weight sum would make monochrome more bearable to the screenshots scrutinizing crowd. All I know is that A4 makes my day and I still can't believe how massively it has improved my experience...hopefully at some point I'll be able to show my gratitude to madshi for his relentless expert work and patience.

Dlp all day long as Dila and LCD are not viewable for me.
Yeah, DLP is a real blast if you can cope with RBE's and fans/wheel noise.

With proper calibration & gamut mapping, the HC3100 was astounding....so bright, so clear looking & its 48Hz support was spot-on, here's a good example of how punchy PQ is on this thing (http://img717.imageshack.us/img717/7957/dsc2696resize.jpg). Black bars are invisible in bright scenes thanks to its high ANSI contrast & I was using a pinkish projection screen in order to improve both red saturation & black level. Good times :)

[James Freeman]

Thanks michkrol,

About Banding, Calibration & Dithering.
No other Software (that I've tried) uses Calibration Profiles & Dithering together like madVR does.

Dithering at the output (just before displaying) is CRUCIAL for smooth band-less picture after Calibration.

I have written about this in the AVS forums:My post at AVS Forums. (http://www.avsforum.com/t/1471169/madvr-argyllcms/1500#post_24396922)
It's about how MadTPG and MadVR is the only way to get truly accurate Calibration & Band-less picture throughout the whole chain.
In short: The whole chain should be 16-bit and at the end dithered to 8-bit, No less.
If a single step is scaled to 8-bit (without dithering) from higher bit depth (like every other software out there including Photoshop, and the internal VideoLUT), the result is banding.

Even the Contrast & Gamma in Nvidia Control Panel are pure 8-bit,
Any change there is resulting in banding to the Lagom Gradient test picture.

Now the question arises...
Why not keep the whole pipeline (Windows and everything) in 16-bit (or better: Floating point) and dither everything at the output of the video card? :D

EDIT:
Fixed to be more relevant.

[Shiandow]

It´s true of course, if I exaggerate my values, I will obviously get exaggerated results, but even without using GIMP (meaning no range/contrast adjustment at all), I can pick greenish pixels in the 1:1 shots that I did directly with madVR. Why only green? Do you have an explanation for that?

I viewed your oppositeColor image with +100 saturation, and indeed quite a lot of pixels are green(ish) but an equal amount of pixels are magenta. In theory these should cancel out and become gray. One possible explanation for why it doesn't exactly cancel out is that the human eye is far more sensitive for green than for other colours.

[iSunrise]

On neutral patterns, green and magenta seem to be prioritized in the opposite build, rather than RGBCMY as seen in the colored builds.
So you were able to confirm it? Or how did you arrive at that conclusion? Maybe green and magenta (especially green) isn´t "cancelled out" like the other colors as good or the greenish pixels are a corner case, because of the changes madshi did with the opposite build. That´s just a guess, though.

I viewed your oppositeColor image with +100 saturation, and indeed quite a lot of pixels are green(ish) but an equal amount of pixels are magenta. In theory these should cancel out and become gray. One possible explanation for why it doesn't exactly cancel out is that the human eye is far more sensitive for green than for other colours.
Wow, I had the exact same thoughts at the same time (look at my above answer to 6233638). What a coincidence.

So you think this is not a problem, right? I just want to make sure that this is not going to hurt us. If there´s no reason to be worried, I think we can safely ignore it.

[Boulotaur2024]

Madshi, I had to write something here : thank you so much for adding NNEDI3 to MadVR. The IQ is so amazing now.

I usually update MadVR twice a year and this is the best addition I've seen in a long while. I've always been a fan of NNEDI3.
I've been using it for years in Avisynth, turning stamp size videos into 1080p for Youtube (http://www.youtube.com/watch?v=8Apk08fgDNg&hd=1) and now I can use it realtime. A dream comes true, thank you again Madshi !

[cyberbeing]

So you think this is not a problem, right? I just want to make sure that this is not going to hurt us. If there´s no reason to be worried, I think we can safely ignore it.

I will say this characteristic of the oppositeColor, is the main reason I can't stand it, yet find the multiColor build somewhat acceptable. I almost made a post about exactly this problem last night, but ended up going to bed instead.

What make oppositeColor worse, is unlike multiColor, it doesn't use of primary and secondary colors in a balanced way. Take a 50% grayscale for example. With multiColor you'll have Red, Green, Blue, Cyan, Magenta, and Yellow noise, on the gray background. With oppositeColor you'll have dense Red and Green noise...and that's it, on the gray background. While both technically average to the same shade of gray, multiColor which makes use a balanced color distribution is more convincing to our brain. oppositeColor's dither has a much higher chance of appearing as what it actually is, muddy green and red on gray.

You can also see this phenomenon on madshi's oppositeColor (http://madshi.net/oppositeColor.png) image he keeps posting, since oppositeColor has a high tendency to use colors which our brains (or at least mine) does not blend well together, the closer it gets to the neutral axis. Aside from that, as I've mentioned before:

All of the noise you see with monoColor doesn't just disappear, it gets converted 1:1 into chroma noise with the oppositeColor build.

monoColor = noisy luma, smooth chroma
multiColor = semi-noisy luma, semi-noisy chroma
oppositeColor = smooth luma, noisy chroma

Anyone is fooling themselves if they think chroma noise is harmless to color clarity. If you ever get into Photography, Filmography, or Graphic Arts, I can guarantee you chroma noise as oppositeColor dither is adding, would be one of the first things you'd remove from the image during post-processing. When you consider how much abuse the chroma channel already with goes through with 4:2:0 subsampling and video compression, the goal should be to restore the chroma, not destroy it even more. The luma channel is almost always higher quality, and can withstand a bit of dithering noise without degrading.

The monoColor builds still apply error diffusion to each color channel separately, and can still produce dither in single level Red, Green, or Blue steps. The difference is, at least as far a I understand, it shares the same random seed with all channels and maintains color alignment as it exists in the source. One thing I've been wondering, is if making the monoColor dither biased towards negative level adjustment instead of positive level adjustment to help reduce appearance of luma noise slightly. I ask this, because I noticed on a 50% gray test pattern, multiColor and oppisiteColor average to 127-127-127, while monoColor averages to 128-128-128.

[*Touche*]

Most of the criticism of multi/oppositeColor builds come from artificial test patterns. I would like more real life examples of its defficiencies.

[Shiandow]

So you think this is not a problem, right? I just want to make sure that this is not going to hurt us. If there´s no reason to be worried, I think we can safely ignore it.

Well, it is a problem although it might not be a particularly big one but adding magenta/green noise isn't exactly ideal. I'm not sure if it's worth it to try and prevent this, if you want to prevent both Yuma noise and coloured noise then the only option you have left is not to use noise at all.

[leeperry]

Anyone is fooling themselves if they think chroma noise is harmless to color clarity. [..] When you consider how much abuse the chroma channel already goes through with 4:2:0 subsampling and video compression, the goal should be to restore the chroma, not destroy it even more. The luma channel is almost always higher quality, and can withstand a bit of dithering noise without degrading.
Hah, reads like déjà vu :D

For the past few days it seems that chroma noise has become the greatest thing since sliced bread, everybody's entitled to pick his own poison :)

[James Freeman]

All of the noise you see with monoColor doesn't just disappear, it gets converted 1:1 into chroma noise with the oppositeColor build.

monoColor = noisy luma, smooth chroma
multiColor = semi-noisy luma, semi-noisy chroma
oppositeColor = smooth luma, noisy chroma

Anyone is fooling themselves if they think chroma noise is harmless to color clarity....


Yes, But because you are a human being, Chroma can suffer some more without being noticed (quite sadistic I might say :D).
With Luma on the other hand, we should be more careful.

That is the simplest reason OppositeColor looks smoother to many people.

From 4-bit to 8-bit, the difference in shades is exponentially lessened, to almost indiscernible.
Take that into account !

I don't get it, You want Pristine Chroma in 4-bit?

[6233638]

All of the noise you see with monoColor doesn't just disappear, it gets converted 1:1 into chroma noise with the oppositeColor build.

monoColor = noisy luma, smooth chroma
multiColor = semi-noisy luma, semi-noisy chroma
oppositeColor = smooth luma, noisy chroma

Anyone is fooling themselves if they think chroma noise is harmless to color clarity. If you ever get into Photography, Filmography, or Graphic Arts, I can guarantee you chroma noise as oppositeColor dither is adding, would be one of the first things you'd remove from the image during post-processing. When you consider how much abuse the chroma channel already with goes through with 4:2:0 subsampling and video compression, the goal should be to restore the chroma, not destroy it even more. The luma channel is almost always higher quality, and can withstand a bit of dithering noise without degrading.Are you looking at this in 4-bit or 8-bit? At 100% size or magnified? Differences of a single point in 8-bit when dithering should be virtually imperceptible.

You should not be able to see anything that you would traditionally classify as "chroma noise" that needs to be removed from the image.

Using additional shades +/-1 on the individual R/G/B values means you can spread the error out over eight different values rather than two.

Perceptually, the oppositeColor builds seem to have the least amount of noise to me, even though it mostly seems to be alternating between four values rather than eight. I think it's because some colors stand out more. E.g. yellow on blue is a strong contrast and sticks out.

[MistahBonzai]

Assistance please: Having problems activating the "madTestPatternSource" utility. I can't seem to find the proper sequence of registrations needed to make the files display. After DL'ing a fresh copy of the folder I've run uninstall.bat in the "madTestPatternSource" folder as administrator and then again in MadVR. Then registering in the reverse order. No joy despite a positive acknowledgement in the status pop-up.

For the record..I now have it working. The "proper sequence" for me turned out to be running the uninstall.bat and then the install.bat in user mode and _not_ as administrator. Seems kinda odd but that's what it took.

[James Freeman]

MistahBonzai,

Turn off Error Diffusion in MadVR settings.
That what made MadTPG not work for me (black window).

I've already reported this in the Bug Tracking page.
Still waiting for a fix to calibrate with Error Diffusion.

EDIT:
Oops.. just noticed you talk about TestPatternSource not TestPatternGenerator.
Never mind, still good to know.

[yok833]

I agree with leepery (even if this is not always the case :) )... A4 is for me the best build so far... The picture is more sharp with less noise and a fantastic pop effect!!! Even if it is not the chosen one, a really hope that Madshi will keep a door open to let us use the one we prefer... By the way I really don't like the result with the opposite builds... For me far behind A4...
With A4, Madvr really give me a new experience even with the blu ray I have already seen a thousand times...

"Envoyé depuis mon GT-I9300 avec Tapatalk"

[leeperry]

A4 looks so real to my brain that I often find myself wondering whether a visual souvenir I am thinking of was real or displayed by mVR in 30/60fps crisp 1080p. I would happily try newer/better/badder luma noise builds, possibly with more diffuse and "thinner" grain :)

[MistahBonzai]

MistahBonzai,

I've already reported this in the Bug Tracking page.
Still waiting for a fix to calibrate with Error Diffusion.

'Twas that bug which lead me to try the test pattern utility. It had worked in the past and I recall I had a hard time getting it to respond at that time. Eventually I recalled the issue - needing _not_ to run the .bat files as administrator - unlike most .bat files in the MPC-HC/MadVR 'suite'.

[madshi]

Ps: Ehhmmmm, where is the "DONATE" button ?
I plan to accept donations when I've reached v1.0, not before. Thanks.

The only convincing alternative I can think of is the one I posted a few pages back where you simply pick a random color (r,g,b) such that r+g+b=0.
I'm not sure I understand that. You mean I should pick e.g. the noise added to g and b randomly, and then calculate the g noise by calculating "g = 0-r-b"? That would be pretty bad for 2 reasons: (1) If both r and b are e.g. 0.5, g would actually be -1.0, so it would have twice the current peak noise level. (2) This idea is not taking into account that noise in the green channel is more visible than noise in the red and blue channels.

Edit: I actually made a mistake when measuring the amount of Y noise, the oppositeColor method seems to be better than the alternative I proposed. I thought it was weird that there didn't seem to be much of a difference between oppositeColor and multiColor was so small, turns out that the numbers I used for oppositeColor weren't random. Anyway I now have a mathematical 'argument' that oppositeColor causes less Y noise than multiColor.
Good to hear.

On 4:2:2 TV's the colored dithering pixel will be TWICE as big horizontally, that may bias some users to falsely judge the Multi/Opposite Color builds.
Actually, madVR is always sending out 4:4:4. So if the TV (or GPU) converts this to 4:2:2, it should blend 2 chroma values together, which should smooth out the chroma noise.

Well, you are taking a 8bit source, processing it in all kinds of ways in 16bit and then outputting to 8bit again....there will obviously be some resolution lost?
Not sure what you mean. Of course the 8bit/original screenshot was made with error diffusion active at 8bit. There should be zero resolution lost.

So does that means that the softer look & motion blur of the color builds is by design and more "technically optimal"?
There should be no motion blur with the colored builds. And the colored builds are not softer compared to a higher bitdepth rendering (e.g. 10bit) of the original source.

Also, FWIR even the most optimal bluray 8bit encodes are always a compromise when it comes to movie grain...all this to say that subjectively speaking A4 does it all at once for me: deblocking, natural looking grain-based edge enhancement, analog look, reinforcing movie grain without changing its pattern/direction, etc etc..
So even when I add native 10bit output, you'd still prefer to use 8bit with A4? Because that's what your comment suggests. Error diffusion was never meant as a way to deblock, enhance edges or anything like that, and I do not plan to optimize error diffusion for that kind of stuff. At some point there might be extra algorithms for those things which will do a much better job at that than error diffusion ever could. We should always use the right tool for the right job. And the one and only job of error diffusion is to render high-bitdepth content to a lower-bitdepth display in such a way that it looks as near as possible to a higher-bitdepth display.

I guess that´s where our wording differs a bit and what we mean by it, so I´m trying to make it more clear. I´m not even talking about subjective noise floor/level or subjective noise perception, because these can clearly be fooled easily, as can our perception of depth (crisper image = better image). Because I actually agree, ED4 clearly gives a crisper image (not necessarily a good thing, but since you asked about subjective analysis, that´s what we did).

However, the images that were provided (e.x. by you and 6233638) clearly show that more noise is added, not less. There´s more noise dots and they also are closer together, meaning, it´s way thicker than with the ED4/mono_static build (that´s the smoothness you´re talking about), so basically, it´s filling way more gaps as before with the ED4/mono_static build.
This makes little sense to me. First of all, there is not any more noise added, from a technical point of view. Furthermore, you can't simply reject/ignore perception. The very purpose of error diffusion is to simulate a higher bitdepth, by spreading dither dots in such a way that the noise is as invisible as possible to our eyes. And that is exactly what I'm trying to achieve with the oppositeColor builds.

But how do we know that we are accurate? Shouldn´t the dithering algorithm only add noise where it is needed?
That's exactly what error diffusion does. It does not produce any dither patterns if the original color has no fractional part.

Now, comparing the builds, while the multicolor_dynamic build also makes that additional noise stand out quite a bit (that´s a bad thing), the opposite_dynamic build reduces the visibility of the noise by quite a lot. So, yes, the opposite build clearly has a lower perceived noise floor compared to the multi_dynamic build. But ED4 still has the least amount of noise (just look at the sky picture, provided by 6233638), even though it´s clearly more visible. Which is the trade-off with ED4.
The way you're talking about noise doesn't make much sense to me. You're saying ED4 (you really mean A4, though) has the least amount of noise, but looks noisiest. The first is technically not correct. The latter is correct. Technically, A4 has the highest amount of luma noise and the lowest amount of chroma noise. OppositeColor has a noticeably decreased luma noise, but has more chroma noise.

All those static screenshots are undeniable, especially as madshi made clear that the goal is softness.....too bad those colorful builds look blurry in motion to me
There's no technical reason why the color builds would look blurry in motion, when compared to a higher-bitdepth display/rendering. And *NO*, the goal is *not* softness. The goal is to simulate a higher bitdepth as well as possible. A higher bitdepth has neither added luma noise nor added chroma noise. The very way error diffusion works, I have to add some noise to avoid banding. But I do have the choice whether to prioritize luma noise or chroma noise. And the majority of humans seem to be bothered more by luma noise (as you can see by the number of votes in this thread). So that's what the oppositeColor build aims at.

OppositeColor looks much cleaner than others to me. I don't know why my opinions differ so much from others
It doesn't. Most users prefer OppositeColor, only a handful of users prefer MonoColor.

Hello madshi!

There's a crash with this file if I also use LAV video. Nevcairiel says (http://forum.doom9.org/showpost.php?p=1670015&postcount=17172) the crash is inside madVR. (v0.87.4)

https://drive.google.com/file/d/0ByfdfPvnoDuzSlZqY1JxeDdXNkU/edit?usp=sharing
Could you please create a bug entry in the madVR bug tracker? I'm currently too busy to look into this. Link see first post of this thread. Thanks.

Since the 4bit mode was dismissed as not giving an accurate representation of things
The 4bit mode is not dismissed at all. It does have its limitations, though. The trick is to interpret the results correctly. All artifacts you're seeing in 4bit mode will be much smaller in 8bit. That applies to gamma/brightness problems, and also to color artifacts. And also to noise levels, of course. Still, there are many things the 4bit test mode can be helpful for, e.g. judging which noise levels each build has perceptively. Or also seeing other problems, like color fringing. BUT, as said above, all artifacts have to be taken with a grain of salt, because they'll be much smaller in 8bit.

What I did:
(1) I took screenshots with no dithering, random dithering, the mono_dynamic and opposite_dynamic dithering builds
(2) I used GIMP to reduce the input range from 0-255 to 192-255 and the output range from 0-255 to 0-128 and applied the change
(3) In the next step I reduced the input color range from 0-255 to 0-32 and applied the change
(4) I opened every screenshot with Irfanview and cropped out the remaining range of the gradients
Such tests are very helpful to judge e.g. the way dither dots are positioned (worm artifacts etc). But obviously the manipulations are so strong that the screenshots can't really be used to judge how e.g. brightness, gamma, contrast, colors etc will look perceptively, when watching them in motion without these manipulations in madVR.

If you look at mono_dynamic and opposite_dynamic from a distance, you will see that opposite_dynamic has an even smoother appearance than mono_dynamic. However, if you look closely (side by side) at both of them, you can see coloring in the opposite_dynamic shot. The amount of the coloring is high enough that on a calibrated monitor, my eyes can see it, side by side after one another.
Yes, but can you see the colored dithering dots in motion in madVR, when displaying moving video content? That's the key question. It is quite clear that perceptively, the oppositeColor build has a lower (luma) noise floor. Even when watching things in motion in madVR, this is still very visible. It is a valid question whether the oppositeColor colored dither dots are visible in motion in madVR. If they are, that could be reason enough to drop the whole idea. But I really doubt anybody can see the separate colored dither dots in motion with real video content.

So, when looking at movies, when it comes to pure smoothness, I would say the opposite_dynamic build wins here. When it comes to clarity and color accuracy, I still prefer the mono builds.
Have you measured color accuracy? Or can you see a difference in color accuracy, when watching movies in madVR? I can not. And I think there should be no measureable color accuracy difference. The color noise should average out to neutral. *Especially* in motion.

[madshi]

The dithering in madVR is currently mainly used to counter the additional processing steps madVR needs to do for it´s magic to work, to arrive at the highest possible resulting bitdepth, before it sends the RGB data to the display. Since the majority only really watches 8bit movies on an 8bit display with not too much processing, this will probably not be visible. However, if the bit-differences are getting bigger (more general processing, 3DLUTs, higher input bit-depth than output bit-depth, 6bit displays, etc.) this could eventually already be a problem.
No, give me 16bit sources right now. I don't see any potential problems with that at all.

even without using GIMP (meaning no range/contrast adjustment at all), I can pick greenish pixels in the 1:1 shots that I did directly with madVR. Why only green? Do you have an explanation for that?
I viewed your oppositeColor image with +100 saturation, and indeed quite a lot of pixels are green(ish) but an equal amount of pixels are magenta.
^

The pixels should average each other out to pretty much perfect gray. Of course if you stare at screenshots of a oppositeColor 4bit gray ramp, you may be able to see single slightly colored pixels. But we're talking about 3 things that are very far from movie watching: (1) static screenshot (2) 4bit error diffusion (3) gray ramp. Change only one of these 3 things and you'll probably not be able to see the separate colored dither dots, anymore. Change all three, and you'll definitely not see them, anymore. What still remains, is a subjectively lower luma noise floor, and a higher chroma noise floor.

In theory these should cancel out and become gray. One possible explanation for why it doesn't exactly cancel out is that the human eye is far more sensitive for green than for other colours.
Do they not cancel out?

The error diffusion is performed totally separately for each color channel. If you remove the blue/red channels, the green channel alone will still be rendered as optimal as possible. When only showing the green channel alone, you would see zero difference between monoColor and oppositeColor. Only when mixing in the blue and red channels, there is a visible difference. So I see no reason why the resulting RGB colors with the oppositeColor build should not cancel each other out. They should. Well, ok, there's one small technical problem: Mixing colors in gamma light is not correct. Mixing should be done in linear light to get correct results. The error introduced by mixing colors in gamma light is of course *MUCH* *MUCH* bigger in 4bit compared to 8bit. This is one of the things where the 4bit test mode does not properly reflect how things behave in 8bit. The error by mixing colors with +/- 1 value difference in 8bit gamma light is so low that it can safely be ignored. That might not be true in 4bit.

FWIW my vote goes to opposite color static.
I like how I perceive the least amount of noise, even temporally, and I kind of dig the 'dirty screen' effect - maybe because it makes me feel that I'm looking at frames closer to how they are coming out of the decoder.
Thanks for your feedback.

madshi made clear that all of these algorithms were of the mid-noise kind, maybe lowering the noise strength and/or tweak the weight sum would make monochrome more bearable to the screenshots scrutinizing crowd.
This got nothing to do with screenshot scrutinizing crowd. The difference in perceptive luma noise levels is quite noticeable in real time watching, too.

Why not keep the whole pipeline (Windows and everything) in 16-bit (or better: Floating point) and dither everything at the output of the video card? :D
Well, I'd like that. Not sure why Microsoft didn't introduce something like this when they implemented desktop composition. Would have been a good opportunity.

Madshi, I had to write something here : thank you so much for adding NNEDI3 to MadVR. The IQ is so amazing now.
Glad you like it!

oppositeColor has a high tendency to use colors which our brains (or at least mine) does not blend well together, the closer it gets to the neutral axis.
That's not what I'm seeing here.

Anyone is fooling themselves if they think chroma noise is harmless to color clarity. If you ever get into Photography, Filmography, or Graphic Arts, I can guarantee you chroma noise as oppositeColor dither is adding, would be one of the first things you'd remove from the image during post-processing. When you consider how much abuse the chroma channel already with goes through with 4:2:0 subsampling and video compression, the goal should be to restore the chroma, not destroy it even more. The luma channel is almost always higher quality, and can withstand a bit of dithering noise without degrading.
As said somewhere above, I do not have the option to not apply any noise at all, unless you want to get loads of banding artifacts. The very way error diffusion (or any kind of dithering) works is by adding a certain amount of noise. So the only question remaining is whether to prioritize luma or chroma noise. It's clear that you (and leeperry) prefer luma noise over chroma noise. But it's also clear by the feedback of the other users that the majority of users prefer the oppositeColor builds.

I think your argument about the chroma channel being already damaged and thus deserving extra care is a little bit backwards. You know the term "garbabe in, garbage out". So since the chroma channel is already damaged to begin with, it hurts less "hiding" the noise there, compared to damaging the pristine luma channel with it. After all, we're talking about a low resolution chroma channel, which was already upscaled 2x, and to which the human eye is less sensitive to start with. So the chroma channel is already very soft. Which means that adding some (+-1 value in 8bit) noise to the chroma channel shouldn't be much of a problem, IMHO.

Yes, I do see that this seems to be a matter of taste. So maybe I will have to add options to let you choose (although I would really *really* like not to). But I will definitely go with the majority vote for the default option, especially if it's as clear as the one in this case.

One thing I've been wondering, is if making the monoColor dither biased towards negative level adjustment instead of positive level adjustment to help reduce appearance of luma noise slightly. I ask this, because I noticed on a 50% gray test pattern, multiColor and oppisiteColor average to 127-127-127, while monoColor averages to 128-128-128.
A negative bias would probably introduce problems elsewhere. I'm pretty sure there would be zero change to the perceived noise level. I don't think there's currently a positive bias. The random numbers should be evenly spread in the -0.5 .. +0.5 range, and since they're fractional, the fact that "round" has a bias for the exact 0.5000000 value should not matter because it should pretty much never ever be hit. Due to the random noise being added before rounding, the to-be-rounded value will pretty much always have some sort of fractional value.

Most of the criticism of multi/oppositeColor builds come from artificial test patterns. I would like more real life examples of its defficiencies.
Agreed.

Are you looking at this in 4-bit or 8-bit? At 100% size or magnified? Differences of a single point in 8-bit when dithering should be virtually imperceptible.

You should not be able to see anything that you would traditionally classify as "chroma noise" that needs to be removed from the image.

Using additional shades +/-1 on the individual R/G/B values means you can spread the error out over eight different values rather than two.

Perceptually, the oppositeColor builds seem to have the least amount of noise to me, even though it mostly seems to be alternating between four values rather than eight. I think it's because some colors stand out more. E.g. yellow on blue is a strong contrast and sticks out.
Since red and blue share the same random value, the red and blue dither patterns will tend to match, while the green dither pattern should tend to be "the other way round". This effectively should result in green/purple tinted pixels happening more often than other color mixes. But since we're talking about +-1 value changes in a guiding 8bit dithering pattern, it should really be pretty much invisible to the human eye. At least the noise level should not be a higher than the luma noise level would otherwise be, and the human eye usually is more sensitive to luma noise than chroma noise.

I agree with leepery (even if this is not always the case :) )... A4 is for me the best build so far... The picture is more sharp with less noise and a fantastic pop effect!!!
Thanks for the feedback. Hmmm, "less noise" compared to what? You probably mean the dynamic builds? Ok, I can see that. But the noise level of the oppositeColor static build should be perceptively lower than the noise level of the A4 build.

[iSunrise]

No, give me 16bit sources right now. I don't see any potential problems with that at all.
Believe me, I wish I had some myself, I wouldn´t need to use gradients or other artificial tests, then. Because the differences (without artificially limiting the bit-depth or if we don´t have a bit-depth difference to simulate additional processing losses) are almost invisible already. And I´m on a very accurate setup already. That´s why the 4bit mode (not taking account certain shortcomings with it) still looks so accurate, after all. Therefore it´s extremely hard to even see differences, anymore. What I am taking into account is future madVR processing options, most of all, so that we have the most headroom possible.

But if you see no problem, I´m perfectly fine with that.

Like I said, I really like the smoothness of the opposite_dynamic, but it would be nice if there was a way to improve it, like what you wrote next:

...Well, ok, there's one small technical problem: Mixing colors in gamma light is not correct. Mixing should be done in linear light to get correct results. The error introduced by mixing colors in gamma light is of course *MUCH* *MUCH* bigger in 4bit compared to 8bit. This is one of the things where the 4bit test mode does not properly reflect how things behave in 8bit. The error by mixing colors with +/- 1 value difference in 8bit gamma light is so low that it can safely be ignored. That might not be true in 4bit.
That sounds like if you do the mixing with the new opposite_dynamic build in LL, it would probably improve the end result.

IMHO we too quickly dismissed LL anyway or at least, it would probably make more sense now.

[yok833]

Thanks for the feedback. Hmmm, "less noise" compared to what? You probably mean the dynamic builds? Ok, I can see that. But the noise level of the oppositeColor static build should be perceptively lower than the noise level of the A4 build.

Yes you are right if I compare with oppositeColor static... However the sharpness and the pop effect of A4 are now "a must have" for me.... I really have the impression to have a new TV with a natural 3d effect (without glasses :) ) and especially without all the bad sides that I could have when I was using avisynth to reach the same effect (the effect was there but it was not natural)...
Now, it is only my feeling based from what I see on my TV with 1080p content (also shared with some friends..) as I did not proceed to any "scientific" tests :)

Update : I have a clear preference for the opposite static vs the opposite dynamic... Even if it seems that most of the people here prefer the opposite dynamic... my preference between the 2 is clearly for the static as in my opinion it gives more "texture" to the picture and less noise... The result is much more clean


"Envoyé depuis mon GT-I9300 avec Tapatalk"

[madshi]

That sounds like if you do the mixing with the new opposite_dynamic build in LL, it would probably improve the end result.

IMHO we too quickly dismissed LL anyway or at least, it would probably make more sense now.
Well, I can't do full LL because the output is gamma. It's only a tricky half-LL, and it didn't work well last time we tested it. So I'm not sure if I want to try again...

Yes you are right if I compare with oppositeColor static... However the sharpness and the pop effect of A4 are now "a must have" for me.... I really have the impression to have a new TV with a natural 3d effect (without glasses :) ) and especially without all the bad sides that I could have when I was using avisynth to reach the same effect (the effect was there but it was not natural)...
Now, it is only my feeling based from what I see on my TV with 1080p content (also shared with some friends..) as I did not proceed to any "scientific" tests :)

Update : I have a clear preference for the opposite static vs the opposite dynamic... Even if it seems that most of the people here prefer the opposite dynamic... my preference between the 2 is clearly for the static as in my opinion it gives more "texture" to the picture and less noise... The result is much more clean
So you prefer A4 (which is the same as "monoColor_static") over opposite_static, and you prefer opposite_static over opposite_dynamic, correct?

[yok833]

So you prefer A4 (which is the same as "monoColor_static") over opposite_static, and you prefer opposite_static over opposite_dynamic, correct?

yes... A4 shortly over opposite_static (due to the better sharpeness and better pop effect) but the both are much better for me than opposite-dynamic...
opposite_dynamic give me a bad impression, I cannot really describe why but I dont like how it looks compare to the 1st 2

[leeperry]

So even when I add native 10bit output, you'd still prefer to use 8bit with A4? Because that's what your comment suggests. Error diffusion was never meant as a way to deblock, enhance edges or anything like that, and I do not plan to optimize error diffusion for that kind of stuff. At some point there might be extra algorithms for those things which will do a much better job at that than error diffusion ever could. We should always use the right tool for the right job. And the one and only job of error diffusion is to render high-bitdepth content to a lower-bitdepth display in such a way that it looks as near as possible to a higher-bitdepth display.
I dunno, you let us try all kinds of luma noise builds asking for subjective impressions and one day you show screenshots claiming that luma noise looks like 4bit......what do you want me to say?

You previously made clear that these all were mid-noise luma algorithms and that you would have a go at low noise later on.

I've got no clue as to what the weight sum would exactly refer to IRL but I'd very much fancy the ability to try a luma buid using 0.97 sum(as this figure kept coming back) and same randomized figures that A4 & NL6 share, but with less coarse noise that would ultimately look better in screenshots? Basically keeping the same look/pop as A4 but with a thinner and more diffuse noise?

This is all new to me and the goal is subjective enjoyment, A4 does all that and then some.

The very way error diffusion (or any kind of dithering) works is by adding a certain amount of noise. So the only question remaining is whether to prioritize luma or chroma noise. It's clear that you (and leeperry) prefer luma noise over chroma noise. But it's also clear by the feedback of the other users that the majority of users prefer the oppositeColor builds.
As cyberbeing explained in his case, my brain doesn't quite null out your wave cancelling chroma noise so hell breaks loose for me either way. Do not expect colorblinds to be able to stand it IMHO, there might be a very good reason why no current commercial video equipment uses this nasty(to my eyes) trick IMHO. 8% of the population is still very much relevant and if cyberbeing is not colorblind then this figure could drastically increase to possibly +10/20% or more. So far more or less 15 ppl have claimed that their brain was fine with it(most of them using 4:4:4 TV's and others 27" or smaller computer screens), this is far from sufficient as a sample group to make such an important decision IMO.

I think your argument about the chroma channel being already damaged and thus deserving extra care is a little bit backwards. You know the term "garbabe in, garbage out". So since the chroma channel is already damaged to begin with, it hurts less "hiding" the noise there, compared to damaging the pristine luma channel with it. After all, we're talking about a low resolution chroma channel, which was already upscaled 2x, and to which the human eye is less sensitive to start with. So the chroma channel is already very soft. Which means that adding some (+-1 value in 8bit) noise to the chroma channel shouldn't be much of a problem, IMHO.
I really don't agree, chroma is already damaged enough as it...I'm not seeking constantly rolling RGB noise making it even dirtier and unbearable, looking like constant rainbowish color fringing should your brain not react like the chosen ones.

There should be no motion blur with the colored builds. And the colored builds are not softer compared to a higher bitdepth rendering (e.g. 10bit) of the original source.
I would have to compare against RD but quite frankly I'd much rather steer clear from that constantly rolling RGB noise.

[jkauff]

I haven't tested all the builds, but I did test A4 and both opposite color builds. To my unprofessional eyes, A4 creates a more pleasing movie-watching experience than even its close cousin opposite color static. I tested with Blu-ray color, Blu-ray b&w, and both b&w and color in SD.

Could be because I'm watching on an IPS computer monitor and not a TV, but anyway I've backed up the A4 build just in case it doesn't win in the end. ;)

[Ver Greeneyes]

Yes, I do see that this seems to be a matter of taste. So maybe I will have to add options to let you choose (although I would really *really* like not to). But I will definitely go with the majority vote for the default option, especially if it's as clear as the one in this case.
From what I've seen you should be able to cover all bases with two checkboxes:
1) "Dithering: Use a static pattern"
2) "Dithering: Use luma noise"

(take the descriptions with a grain of salt) That doesn't seem like the end of the world to me, though I'm not sure in what section they would belong ;)

Speaking of which though, have you considered modifying random dithering in the same way? That is, adding a static version or a luma noise version, or changing the current chroma noise to work like the 'opposite color' ED build. The first two are only relevant if you do decide to add options, but they all seem like relatively simple changes and would unify things a bit between random dithering and error diffusion.

[cyberbeing]

Are you looking at this in 4-bit or 8-bit? At 100% size or magnified? Differences of a single point in 8-bit when dithering should be virtually imperceptible.

You should not be able to see anything that you would traditionally classify as "chroma noise" that needs to be removed from the image.
That's not what I'm seeing here.

I've been doing most all my testing with 8-bit @100%, and mostly on real videos not screenshots. What can I say, other then I must be sensitive to it? The combination of my eyes, display setup, and viewing distance enhances it? It's great that so many people seem unable to notice chroma noise, but it seems there are at least at least a few like me who are bothered by the particular type of chroma noise from the oppositeColor build.

Do they not cancel out?
To my eyes they only partially cancel out, and I can still sense the dithering colors used by the oppositeColor build on normal videos. With the multiColor build, this is hardly an issue except on grayscale test patterns. With the monoColor build it goes away completely.

Yes, I do see that this seems to be a matter of taste. So maybe I will have to add options to let you choose (although I would really *really* like not to).
I get that, and ultimately do whatever you feel most comfortable with for the future of madVR. I'm getting rather worn out by all these dither discussions and builds. We've had 40(!) or so dither test builds at this point, and I'm just still in shock everything took a 180° turn in the final stretch to something I found unacceptable. I felt I needed to give one last attempt at getting my view out there, but I think this will be the last, as there definitely seems to be a strong difference of opinion about this. Oh well, that's how life goes sometimes. Bad come to worse I'll just go back to random dither and lower my power bill. ;)

[Asmodian]

From what I've seen you should be able to cover all bases with two checkboxes:
1) "Dithering: Use a static pattern"
2) "Dithering: Use luma noise"

(take the descriptions with a grain of salt) That doesn't seem like the end of the world to me, though I'm not sure in what section they would belong ;)

Speaking of which though, have you considered modifying random dithering in the same way? That is, adding a static version or a luma noise version, or changing the current chroma noise to work like the 'opposite color' ED build. The first two are only relevant if you do decide to add options, but they all seem like relatively simple changes and would unify things a bit between random dithering and error diffusion.

I was thinking of suggesting something similar. Does anyone believe we would need a "low" noise option if we had the four combinations of mono+static, mono+dynamic, opposite+static, and opposite+dynamic?

Though I can forsee a lot of "Which dithering options should I use? They all look the same to me." questions. ;)

[AngelGraves13]

I watch mostly Blu-ray remuxes that I create myself, mainly because I hate watching films from disc.

I've also remuxed a lot of DVDs, such as my Batman: The Animated Series, which is 480i NTSC. I've tried using the deinterlacing in MadVR, but it just can't seem to detect it and deinterlace it properly, so I enabled deinterlacing in LAV with CUVID with the aggressive option. I ran into the same problem with Smallville's first 2 seasons. They don't properly deinterlace unless it's set to Aggressive in LAV. Would enabling "if unsure, turn on deinterlacing" do the same thing in MadVR? I wouldn't want it to enable it for 24p content.

[XMonarchY]

So Opposite color is the next ED step from the previous ED builds? Is it based on the Noisy2Limited or some other one?

Also, as far as 3DLUTs go, how am I to arrange them for content that uses SMPTE C primaries and Rec601 matrix?

I have 2 3DLUTs, one for Rec709 and one for Rec601. When I place Rec601 3DLUT on the Rec709 line in madVR, HCFR reads proper Rec601 primaries, but I am not sure whether madVR does the same for content that uses Rec601 when a Rec601 3DLUT is placed on the SMPTE C line. It does use Rec601 3DLUT when it is placed on the Rec709 line because placing Rec601 3DLUT on the Rec709 line creates a huge difference vs no 3DLUT at all.

All in all, would placing Rec709 3DLUT on Rec709 line and placing Rec601 3DLUT on SMPTE C line allow madVR to switch between the two color gamuts based on the content?

Also, what would happen if I were to use HCFR (too tired today) and measure patterns with madTPG when both 3DLUTs are placed on the appropriate lines? Which one would it read?

[dansrfe]

I have 2 3DLUTs, one for Rec709 and one for Rec601.

madVR only needs one 3DLUT for processing which it uses to map to other gamuts if required.

[tickled_pink]

I prefer A4 (monocolor_static).
I agree that the 4-bit stills show OCD to be most like the original but with live 8-bit video I prefer the pop/sharpness(?) and overall perceived pq of A4. OCD appears softer/washed out by comparison.

I'm not affected by the increased chroma noise of OCD nor can I see issues with incorrect colors. I don't hate it, I just prefer A4 by enough of a margin that I decided to post this comment.

[James Freeman]

So maybe I will have to add options to let you choose (although I would really *really* like not to).

From what I've seen you should be able to cover all bases with two checkboxes:
1) "Dithering: Use a static pattern"
2) "Dithering: Use luma noise"


madshi,
As much as you don't like the idea of over complicating the the final build, and endless questions about this on the forum,
the growing votes for the MonoColor Static (A4) build should not be ignored.
I think Ver Greeneyes is right, this is the only way to cover the whole ground without compromising Quality or "Democracy". :D

OppositeColor Dynamic should be the base setting, but also have the options to go "Mono" and/or "Static".
I think a single Dropdown Box with four options will be ideal.

Another option will be to have "External/Custom" selection in the dropdown box, that will have an option to load a Code from a file.
Then the really techie guys can write/share ANY dithering code they think loosk best or not (Algorithm, Different Patterns, Noise Floor, Randomness, Gamma, Floyd, Steinberg, Pink Floyd, Whatever)...
Or, have one basic ED dithering (OppositeColor Dynamic) built in, and have the rest (Mono, Static, Custom) with external files (codes).
Did I go to far into the "feature request" territory? ;)

[madshi]

yes... A4 shortly over opposite_static (due to the better sharpeness and better pop effect) but the both are much better for me than opposite-dynamic...
opposite_dynamic give me a bad impression, I cannot really describe why but I dont like how it looks compare to the 1st 2
Ok, thanks.

I dunno, you let us try all kinds of luma noise builds asking for subjective impressions and one day you show screenshots claiming that luma noise looks like 4bit......
Ehm, those screenshots were meant to show the subjective luma noise level differences between the monoColor and multi/oppositeColor builds, using 4bit mode to make things more obvious.

I haven't tested all the builds, but I did test A4 and both opposite color builds. To my unprofessional eyes, A4 creates a more pleasing movie-watching experience than even its close cousin opposite color static. I tested with Blu-ray color, Blu-ray b&w, and both b&w and color in SD.
Ok, thanks.

From what I've seen you should be able to cover all bases with two checkboxes:
1) "Dithering: Use a static pattern"
2) "Dithering: Use luma noise"

(take the descriptions with a grain of salt) That doesn't seem like the end of the world to me, though I'm not sure in what section they would belong ;)
Yes, that's what I've been thinking, as well. I think in the long run I'll hide these settings somewhere (e.g. in a "nerdy tweaks" page, or in an "expert" settings dialog mode). In the short run we'll have to live with some more options that 99% of all users won't be able to see a difference with. :(

Speaking of which though, have you considered modifying random dithering in the same way?
Actually, that was my plan, yes. If I do add those options (and it seems I will have to) then they will apply to random dithering, too.

I've been doing most all my testing with 8-bit @100%, and mostly on real videos not screenshots. What can I say, other then I must be sensitive to it? The combination of my eyes, display setup, and viewing distance enhances it? It's great that so many people seem unable to notice chroma noise, but it seems there are at least at least a few like me who are bothered by the particular type of chroma noise from the oppositeColor build.
Yes, seems that way.

To my eyes they only partially cancel out, and I can still sense the dithering colors used by the oppositeColor build on normal videos. With the multiColor build, this is hardly an issue except on grayscale test patterns. With the monoColor build it goes away completely.

I get that, and ultimately do whatever you feel most comfortable with for the future of madVR. I'm getting rather worn out by all these dither discussions and builds. We've had 40(!) or so dither test builds at this point, and I'm just still in shock everything took a 180° turn in the final stretch to something I found unacceptable. I felt I needed to give one last attempt at getting my view out there, but I think this will be the last, as there definitely seems to be a strong difference of opinion about this. Oh well, that's how life goes sometimes. Bad come to worse I'll just go back to random dither and lower my power bill. ;)
As said before, I guess I'll have to add options for this. It's an unfortunate situation that the majority of users prefers option A and a minority totally hates A.

I agree that there have been too many test builds. But then, most test build sets came with noticeable improvements. So I think in the end it was worth it. If you compare the first OpenCL error diffusion build to either monoColor or oppositeColor, the progress has been significant, IMHO.

FWIW, I plan on releasing one more test build set in 1-2 days, probably containing 3 (very different) new test builds. One of them is going to be "simple" ordered dithering (based on a modified/improved version of "void-and-cluster"). The 2nd one is going to be a combination of ordered dithering and error diffusion. The 3rd one is going to be an updated low-noise error diffusion algorithm. Straight ordered dithering should perform faster than error diffusion. The combination of ordered dithering and error diffusion could maybe bring another quality improvement to dither dot placement. The low-noise-alternative might be another option to select for users. These test builds will probably only be monoColor, to make testing simpler. This final test build set will decide which algorithms are going to be offered as options in madVR.

Does anyone believe we would need a "low" noise option if we had the four combinations of mono+static, mono+dynamic, opposite+static, and opposite+dynamic?
I'm not sure myself. See my reply to cyberbeing above.

Though I can forsee a lot of "Which dithering options should I use? They all look the same to me." questions. ;)
Yes, I'm quite sure that is going to happen... :(

I watch mostly Blu-ray remuxes that I create myself, mainly because I hate watching films from disc.

I've also remuxed a lot of DVDs, such as my Batman: The Animated Series, which is 480i NTSC. I've tried using the deinterlacing in MadVR, but it just can't seem to detect it and deinterlace it properly, so I enabled deinterlacing in LAV with CUVID with the aggressive option. I ran into the same problem with Smallville's first 2 seasons. They don't properly deinterlace unless it's set to Aggressive in LAV. Would enabling "if unsure, turn on deinterlacing" do the same thing in MadVR? I wouldn't want it to enable it for 24p content.
I'm not sure on what the problem is. Is it just that deinterlacing doesn't get automatically enabled? If you manually enable it in madVR (you can use the keyboard shortcut for that), does it work correctly then?

I don't know for sure what the "Agressive" mode in LAV does exactly. The "if unsure, turn on deinterlacing" should not affect true progressive 24p Blu-Ray content. You can at any time check whether madVR turned deinterlacing on/off by looking at the debug OSD (Ctrl+J) to make sure deinterlacing doesn't get turned on for Blu-Rays.

So Opposite color is the next ED step from the previous ED builds? Is it based on the Noisy2Limited or some other one?
MonoColor_static is identical to Adaptive4. OppositeColor_static is a modification of Adaptive4. And Adaptive4 is an improvement over NoisyLimited6.

Also, as far as 3DLUTs go, how am I to arrange them for content that uses SMPTE C primaries and Rec601 matrix?

I have 2 3DLUTs, one for Rec709 and one for Rec601. When I place Rec601 3DLUT on the Rec709 line in madVR, HCFR reads proper Rec601 primaries, but I am not sure whether madVR does the same for content that uses Rec601 when a Rec601 3DLUT is placed on the SMPTE C line. It does use Rec601 3DLUT when it is placed on the Rec709 line because placing Rec601 3DLUT on the Rec709 line creates a huge difference vs no 3DLUT at all.

All in all, would placing Rec709 3DLUT on Rec709 line and placing Rec601 3DLUT on SMPTE C line allow madVR to switch between the two color gamuts based on the content?
Rec601 applies to both NTSC SD content and to PAL SD content, both of which use different framerates and different gamuts. So using "Rec601" for a 3dlut isn't clear. Because of that madVR allows you to set both SMPTE-C (= NTSC SD) and EBU/PAL (= PAL SD) 3dluts. Both of which use the Rec601 color decoding matrix and transfer function.

Also, what would happen if I were to use HCFR (too tired today) and measure patterns with madTPG when both 3DLUTs are placed on the appropriate lines? Which one would it read?
The purpose of the multiple 3dlut options in madVR is that you can specify one 3dlut for every source gamut. madVR will then automatically use the 3dlut which matches the gamut of the video file you're playing.

madVR only needs one 3DLUT for processing which it uses to map to other gamuts if required.
What madVR "needs" is relative. madVR does not "need" any 3dlut. madVR is happy with no 3dlut, it's also happy with just one 3dlut, or it can happily automatically switch between multiple 3dluts, depending on which video you're playing. Graeme (the ArgyllCMS developer) said that using specific 3dluts for each source gamut might produce slightly better results. So madVR allows you to do that. If you just specify one 3dlut for all video gamuts, madVR will do the necessary conversions, of course, so it should still work fine. But you may gain a small quality improvement (according to Graeme) when using specific 3dlut files for specific gamuts.

I prefer A4 (monocolor_static).
I agree that the 4-bit stills show OCD to be most like the original but with live 8-bit video I prefer the pop/sharpness(?) and overall perceived pq of A4. OCD appears softer/washed out by comparison.

I'm not affected by the increased chroma noise of OCD nor can I see issues with incorrect colors. I don't hate it, I just prefer A4 by enough of a margin that I decided to post this comment.
Ok, thanks for your feedback!

Another option will be to have "External/Custom" selection in the dropdown box, that will have an option to load a Code from a file.
Then the really techie guys can write/share ANY dithering code they think loosk best or not (Algorithm, Different Patterns, Noise Floor, Randomness, Gamma, Floyd, Steinberg, Pink Floyd, Whatever)...
Or, have one basic ED dithering (OppositeColor Dynamic) built in, and have the rest (Mono, Static, Custom) with external files (codes).
Did I go to far into the "feature request" territory? ;)
That would not be impossible, but to be honest, I don't think it's worth the effort and complexity at this point in time.

[James Freeman]

Though I can foresee a lot of "Which dithering options should I use? They all look the same to me." questions.

In the short run we'll have to live with some more options that 99% of all users won't be able to see a difference with. :(
Yes, I'm quite sure that is going to happen... :(

That is where a simple Help file or guide would solve all you nightmares madshi...
A "MadVR Guide" on your website linked to the first post will do just fine.

MadVR does not have millions of options, so writing a guide will be quite easy.

[madshi]

If I write a help/guide now, I'll have to change it all the time for each new build, which will cost additional time. And then I'll have to totally rewrite it when v1 is released (which will probably come with a cleanup/restructuring of the settings dialog). It makes more sense to wait for v1 before writing any help/guide.

[James Freeman]

Makes sense.

You should not worry about over cluttering or adding (quality) features to the pre 1.0 builds.
MadVR is already not a "simple" or "user friendly" renderer technically speaking, its has a learning curve.

A few questions like "What this button does?" is not the end of the world.

[6233638]

I've been doing most all my testing with 8-bit @100%, and mostly on real videos not screenshots. What can I say, other then I must be sensitive to it? The combination of my eyes, display setup, and viewing distance enhances it? It's great that so many people seem unable to notice chroma noise, but it seems there are at least at least a few like me who are bothered by the particular type of chroma noise from the oppositeColor build.I just don't see why it would be so obvious when we're looking at a single +/-1 difference in 8-bit, that is a single pixel in size.

In 4-bit it's certainly going to be noticeable as +/-1 is a 6% difference when you only have 16 values per channel.
In 8-bit, the difference should be less than 0.4%.

I'm not saying you won't be able to see it at all if you have your nose to the screen, but it shouldn't be noticeable when looking at a calibrated 1080p display, from a regular distance. (<60° FoV)
That means neutral sharpness, a 2.2-2.4 gamma, and BT.709 gamut, not a sharpened image with boosted saturation.

To my eyes they only partially cancel out, and I can still sense the dithering colors used by the oppositeColor build on normal videos.Do you "sense" them, or do you actually see them? This is where "blind" testing is useful, without knowing what build you're looking at before you start testing - which is what I've been doing for each build.

With the multiColor build, this is hardly an issue except on grayscale test patterns. With the monoColor build it goes away completely.Strange, I definitely notice more noise in the multicolor build. There are more colors used, so it creates a more noisy texture. The blue channel in particular seems to have a lot less noise when using the oppositeColor builds.

As I said before, you're essentially only using two shades for dithering rather than a potential eight.

and I'm just still in shock everything took a 180° turn in the final stretch to something I found unacceptable.I guess we will need to have a "monochrome dither" option then, if you really find it so bad.

Do you at least find the dynamic builds acceptable?
I've still not seen any samples posted where the additional noise from these is visible.

Bad come to worse I'll just go back to random ditherAre you saying that these builds look worse than random dithering?

Does anyone believe we would need a "low" noise option if we had the four combinations of mono+static, mono+dynamic, opposite+static, and opposite+dynamic?No - the previous "low noise" builds were less random and based on static patterns. I think most (all?) of us now agree that they were too prone to introducing artifacts, and the new builds show a lot less noise now anyway.


I'm not sure on what the problem is. Is it just that deinterlacing doesn't get automatically enabled? If you manually enable it in madVR (you can use the keyboard shortcut for that), does it work correctly then?

I don't know for sure what the "Agressive" mode in LAV does exactly. The "if unsure, turn on deinterlacing" should not affect true progressive 24p Blu-Ray content. You can at any time check whether madVR turned deinterlacing on/off by looking at the debug OSD (Ctrl+J) to make sure deinterlacing doesn't get turned on for Blu-Rays.

On the subject of deinterlacing, I seem to be getting a green image when I force video-mode deinterlacing in the 87.x test builds now. (I guess this is an OpenCL related bug?)

[Vyral]

That is where a simple Help file or guide would solve all you nightmares madshi...
A "MadVR Guide" on your website linked to the first post will do just fine.

MadVR does not have millions of options, so writing a guide will be quite easy.
There already are guides for madVR here and there. IMHO, this one (http://imouto.my/madvr/) is the best at the moment because everything is explained and there are some good advices for inexperienced users.

[James Freeman]

I just don't see why it would be so obvious when we're looking at a single +/-1 difference in 8-bit, that is a single pixel in size.

In 4-bit it's certainly going to be noticeable as +/-1 is a 6% difference when you only have 16 values per channel.
In 8-bit, the difference should be less than 0.04%.

On the subject of deinterlacing, I seem to be getting a green image when I force video-mode deinterlacing in the 87.x test builds now. (I guess this is an OpenCL related bug?)

3-bit 12.5% (100/8)
4-bit 6.25% (100/16)
8-bit 0.4% (100/256)
10-bit 0.1% (100/1024)
12-bit 0.024% (100/4096)
16-bit 0.0015% (100/65536)

Definitely exponential.
More than 10-bit at the output is a waste of processing power, for the human eye.

Deinterlacing, looks fine here.
Nvidia.

There already are guides for madVR here and there. IMHO, this one (http://imouto.my/madvr/) is the best at the moment because everything is explained and there are some good advices for inexperienced users.

Thanks, I am well aware of the available (very good) 3rd party guides.

What I was calling for is an official guide with the latest changes and options.
But that would be another time consuming event for madshi, so no guide till v1.0.

[6233638]

4-bit 6.25% (100/16)
8-bit 0.4% (100/256)
10-bit 0.1% (100/1024)
12-bit 0.024% (100/4096)
16-bit 0.0015% (100/65536)

Definitely exponential.Thanks for the correction.
More than 10-bit is a waste of processing power.12-bit seems to be ideal when you are looking at flat boxes side-by-side; that's the point at which most people cannot tell the difference between shades.

But when you are looking at a moving image with a single pixel-sized change, one difference in 8-bit should not really be visible at all.

[yok833]

I really think that this is a good idea to have an "expert mode" in the future to allow more flexibility and keep everything plug and play for beginners :)... The very good "pop effect" introduced with A4 is easily noticeable even for "99% of the users" ( my girl friend saw it by herself :) )... after it is only a question of taste...

"Envoyé depuis mon GT-I9300 avec Tapatalk"

[James Freeman]

12-bit seems to be ideal when you are looking at flat boxes side-by-side; that's the point at which most people cannot tell the difference between shades.

But when you are looking at a moving image with a single pixel-sized change, one difference in 8-bit should not really be visible at all.

I agree.

"Box by Box" is not "Pixel by Pixel".
I can't even see the transition of shades in the Lagom Greyscale (0-256 greyscale) in 1:1 scaling (27" monitor).


I really think that this is a good idea to have an "expert mode" in the future to allow more flexibility and keep everything plug and play for beginners :)...
The very good "pop effect" introduced with A4 is easily noticeable even for "99% of the users" ( my girl friend saw it by herself :) )... after it is only a question of taste...


You don't say...

[madshi]

On the subject of deinterlacing, I seem to be getting a green image when I force video-mode deinterlacing in the 87.x test builds now. (I guess this is an OpenCL related bug?)
Doesn't seem to happen here. What happens if you toggle the related trade quality for performance option? Can you please create a bug entry in the bug tracker for this? Thanks.

[leeperry]

Ehm, those screenshots were meant to show the subjective luma noise level differences between the monoColor and multi/oppositeColor builds, using 4bit mode to make things more obvious.
I'm talking about this one:
http://madshi.net/edClock.png

To my eyes this looks something like 4bit, 4.5bit, 5bit and 8bit. Please note how the images with error diffusion look "crisper" than the original. This is why I'm saying that when judging the error diffusion algorithms we shouldn't aim for crispness, but for the smoothest result with the lowest noise level. That should actually bring out the original source detail the best, even though it doesn't look as crisp.
Right, I didn't pay attention to the fact that these came from the previous screenshots you posted....anyway, I'd still love to try new luma builds based on 0.97 & the NL6 random numbers that would look better in 4bit then.

I agree that there have been too many test builds. But then, most test build sets came with noticeable improvements. So I think in the end it was worth it. If you compare the first OpenCL error diffusion build to either monoColor or oppositeColor, the progress has been significant, IMHO.
The progress has been tremendous and it was more than worth it, I was happy to try them and will be happy to try any new luma build :)

FWIW, I plan on releasing one more test build set in 1-2 days, probably containing 3 (very different) new test builds. One of them is going to be "simple" ordered dithering (based on a modified/improved version of "void-and-cluster"). The 2nd one is going to be a combination of ordered dithering and error diffusion. The 3rd one is going to be an updated low-noise error diffusion algorithm. Straight ordered dithering should perform faster than error diffusion. The combination of ordered dithering and error diffusion could maybe bring another quality improvement to dither dot placement. The low-noise-alternative might be another option to select for users. These test builds will probably only be monoColor, to make testing simpler. This final test build set will decide which algorithms are going to be offered as options in madVR.
Hopefully you won't give up on 0.97 & the A4/NL6 numbers :scared:

You don't say...
I'm sure you know what he sees better than he does himself. Maybe your 2.5K:1 non-BFI monitor is the reason why no pop seems to be occuring on your rig.

[James Freeman]

I'm sure you know what he sees better than he does himself.
Maybe your 2.5K:1 non-BFI monitor is the reason why no pop seems to be occuring on your rig.

1. Stop with the "POP", "3D", "Girlfriend Approved" stuff because it makes you/others appear less reasonable that you/others may actually be.

2. Contrast Ratio is exponential (unsurprisingly) to the human eye.
2.5k:1 to 3.5k:1 is NOT a big jump.
Not that I care, I was fine with my 850:1 Dell U2410 IPS monitor.

3. BFI (without backlight strobing) creates overshoot, especially in a slow AMVA panel (like you and I have).
Disable it when you judge anything with color (especially when your color blind).
Yes, even though you have calibrated your TV with it.

So stop being noisy about your 3.5k:1 CR & BFI, its not a privilege.

4. Get a proper 4:4:4 panel.

Then I may take your comments about detail seriously.

Hopefully you won't give up on 0.97 & the A4/NL6 numbers.

I don't think so, madshi said "new test builds".
I think it'll be among, not instead the old ones.

[Asmodian]

I finally got some time to put my computer back together to be able to test the Mono/Colored/Opposite builds myself. (I moved while working 60h weeks :( )

I did my testing with very clean anime in 8-bit mode. I went into testing expecting to not be able to notice the difference or to like opposite-static because of what I have read so far and the screenshots as I think I like low noise. (no offence leeperry) :)

To my surprise I really do think the mono builds look better while I barely notice the noise difference between dynamic and static. I like "madVR_monoColor_static.ax" the most with "madVR_monoColor_dynamic.ax" a close second. I like Colored more than Opposite too. Weather this is due to my HVS system liking a small amount of almost invisible noise or something else I am not sure but in my subjective tests I really did like monocolor dithering more when watching the same videos over. I tried switching madVR versions in different orders and watching a few different scenes as I wasn't expecting the results. :o

[6233638]

Doesn't seem to happen here. What happens if you toggle the related trade quality for performance option? Can you please create a bug entry in the bug tracker for this? Thanks.Done. (and marked it as a "major" bug by mistake - sorry)

Turns out it's the combination of NNEDI3 chroma upscaling (not doubling) + video mode deinterlacing that is causing it.

[leeperry]

I think I like low noise. (no offence leeperry) :)
I'd love to see a low noise A4 if that's technically possible :)

So stop being noisy about your 3.5k:1 CR & BFI, its not a privilege.

4. Get a proper 4:4:4 panel.

Then I may take your comments about detail seriously.
Long story short, a 27" monitor is too small for seriously evaluating video processing. Joe Kane has made this very clear several times.

FIY, here's what BFI does: http://www.tftcentral.co.uk/reviews/eizo_fg2421.htm
significant improvement in the clarity of the moving image .. The moving object is noticeably sharper and easier to track across the screen with the eye. It appears sharper and nearly all the motion blur you saw before is eliminated.
I'd suggest you go try BFI somewhere because boasting about 4:4:4 being superior when IRL movies are 4:2:0 to begin with and LCD is utterly sluggish without BFI...so much that both the picture itself and the dithering noise will be smeared all over in a big pixely jelly mess.

I can understand why you have seemingly never been able to see any pop out of that 27" Asus monitor, the rabbit hole goes a whole lot deeper than you seem willing to believe. You can expect the same PQ improvement that you experienced by recently moving from IPS IIRC ;)