madVR - high quality video renderer (GPU assisted)

[The 8472]

Could you comment on your workflow? I've made a simple gradient test pattern, but I don't know if I did it right. I used a small C++ program to create a raw file containing 16-bit r, g and b values, then used ffmpeg to turn the raw file into a movie, with the following commandline:ffmpeg -y -vcodec rawvideo -f rawvideo -pix_fmt rgb48le -s 1920x1080 -r 29.97 -i output.raw -vcodec ffv1 -pix_fmt yuv444p16le gradient.mkvThe test pattern movie is here: 1080p gradient test pattern (www.mediafire.com/?kf93wcysmmbzxjo)

I'm using a script that uses imagemagick in a loop to generate PNM-images and then passes them to ffmpeg


convert -depth 16 -size 2560x1440 xc: -sparse-color Shepards '%[fx:0.5*w], %[fx:0.5*h] rgb(0,0,0) %w, %h rgb(0.1,0.1,0.1) 0, %h rgb(0,0.1,0) 0, 0 rgb(0.1,0,0) %w, 0 rgb(0,0,0.1)' 0001.pnm
ffmpeg -threads 8 -r 1/2 -pattern_type glob -i '*.pnm' -pix_fmt yuv444p16le -vcodec ffv1 -g 1 -an out.mkv




Added flat tiles:

flat tiles with steps of grey smaller than the 8bit quantum (12bit quantum):
1440p (http://www49.zippyshare.com/v/84549698/file.html)
1080p (http://www49.zippyshare.com/v/70659149/file.html)


@madshi could you test those videos? They work fine with EVR-CP but mpc-hc crashes when i try to play them with madVR

[madshi]

@madshi could you test those videos? They work fine with EVR-CP but mpc-hc crashes when i try to play them with madVR
Tried the 1080p one, plays fine here.

[bacondither]

Filter Lite + random = build number 5?

Floyd-Steinberg + random = build number number 7?

PM me if you don't want to publish the correct answer :sly:

So let's pick the algorithm which looks best, when looking at both your and my test images. Agreed

Yes, robustness in the algorithm to small brightness changes is something to strive for.

Anyway, after looking at your images i think that 5 and 7 looked the best but may have to revaluate the low noise ones.

[nevcairiel]

I'm confused. Your image clearly shows error diffusion. Since when does EVR custom with full FP processing apply error diffusion??

It does not. It uses a simple pixel shader to dither using a huge pre-defined matrix. Looks like 32x32 ordered dithering.

[madshi]

Filter Lite + random = build number 5?

Floyd-Steinberg + random = build number number 7?
Almost. The other way round.

Anyway, after looking at your images i think that 5 and 7 looked the best but may have to revaluate the low noise ones.
And try the new build 9, based on Shiandow's new idea.

It does not. It uses a simple pixel shader to dither using a huge pre-defined matrix. Looks like 32x32 ordered dithering.
Oh, ok. Doesn't look bad at all, to be honest.

[Shiandow]

Hmmmm... It's interesting how you modified one of the Floyd-Steinberg weights to be applied on a different pixel! Had to modify my error diffusion kernel code to make that possible. After some testing I decided on using a random value of 0.5 instead of 0.2, though, for switching between the 2 different weight sets. A switch value of 0.2 resulted in visible 16x16 block edges. It seems that "my" weights are better at hiding the block edges. A value of 0.5 with your suggested algorithm produces nicely hidden block edges, and still has a very similar look to 0.2, from what I can see. Here's a test build using your suggestion:

http://madshi.net/madVRedtest2.rar

I like what I'm seeing here! Maybe it could even replace both the low-noise and medium-noise algorithms? I would like that, only having one error diffusion algorithm. Opinions?

It seems to perform as well as I'd hoped, maybe even better. Your weights do seem to be better at hiding boundary errors, I thought a value of 0.2 would be enough to have this effect without adding to much noise but it doesn't seem that raising it to 0.5 has introduce that much more noise.

From what I can see it seems to perform as well as build 2 but with some randomness, which seems ideal. Hopefully others will have the same result.

[6233638]

Here's a test build using your suggestion:

http://madshi.net/madVRedtest2.rar

I like what I'm seeing here! Maybe it could even replace both the low-noise and medium-noise algorithms? I would like that, only having one error diffusion algorithm. Opinions?This does look slightly better than #2 in some cases. In others, there's no meaningful difference.
While I know it's not a priority, it does introduce noise on black when used with 3DLUTs.

The black level being raised by this is an obvious difference on my display, the slight changes in dither pattern between #2 and #9 are marginal.

[Skankee]

I did a short test, from good to bad:
low noise:
4
2
6,8

high noise:
3
1
5
7


I like a low-noise picture, so my favourite is 4 and 2 (4 was only a little bit better)
with enhanced gamma you can see some square-pattern at 6 and 8 -depending on the grey-level.

Example:http://s7.directupload.net/images/user/140208/rgduj3ru.png

But even without this i like 4 and 2 more.


The "worm-artefacts" didnt bother me, they was not visible to me until i was extreme close to my monitor.



From the other ones i think 3 and 1 is ok; 5 and 7 looks too "rough". I cant see any benefit in high noise Dithering, so in general i would choose "low noise" > "high noise".

[The 8472]

Tried the 1080p one, plays fine here.

I can get it to work if I uncheck everything but NV12 in the Lav Video output formats - i.e. the same that EVR-CP consumes. But considering the input format it's clearly the wrong choice. So either LAV or madVR is choking on Y416.

[madshi]

I can get it to work if I uncheck everything but NV12 in the Lav Video output formats - i.e. the same that EVR-CP consumes. But considering the input format it's clearly the wrong choice. So either LAV or madVR is choking on Y416.
Works fine here with Y416!

It seems to perform as well as I'd hoped, maybe even better. Your weights do seem to be better at hiding boundary errors, I thought a value of 0.2 would be enough to have this effect without adding to much noise but it doesn't seem that raising it to 0.5 has introduce that much more noise.

From what I can see it seems to perform as well as build 2 but with some randomness, which seems ideal. Hopefully others will have the same result.
This does look slightly better than #2 in some cases. In others, there's no meaningful difference.
While I know it's not a priority, it does introduce noise on black when used with 3DLUTs.

The black level being raised by this is an obvious difference on my display, the slight changes in dither pattern between #2 and #9 are marginal.
Ok, I've done a minor change in the weights, which seems to reduce stray dots a little bit. Maybe that fixes the problem with the noise on black, without hurting the image quality? Can you guys try and confirm?

http://madshi.net/madVRedtest3.rar (build 10)

Weights used now are (changes compared to build 9 in brackets):

Floyd-Steinberg:
0.5375 (+ 0.1)
0.0625
0.1875
0.3125
-0.1000 (- 0.1)

madshi:
0.7770
0.0000
0.0090
0.4861
-0.3098

I did a short test, from good to bad:
low noise:
4
2
6,8

high noise:
3
1
5
7

I like a low-noise picture, so my favourite is 4 and 2 (4 was only a little bit better)
with enhanced gamma you can see some square-pattern at 6 and 8 -depending on the grey-level.

Example:http://s7.directupload.net/images/user/140208/rgduj3ru.png

But even without this i like 4 and 2 more.

The "worm-artefacts" didnt bother me, they was not visible to me until i was extreme close to my monitor.

From the other ones i think 3 and 1 is ok; 5 and 7 looks too "rough". I cant see any benefit in high noise Dithering, so in general i would choose "low noise" > "high noise".
Yes, I mostly agree with you, except that I prefer 2 over 4. Try the new build 10. I hope it could be the new best low-noise solution.

[nevcairiel]

Works fine here with Y416!

I get a null pointer crash in madVR when I play the 1080p file in MPC-HC with 0.87.4 release, just FWIW. :)
(also happens in the new build 10)

Edit:
Somehow related to the height. I hacked it to use 1032 as height instead (because thats a more aligned number), and the crash stops.

[madshi]

No crash here, using the latest test build, though. And rather old MPC-HC + LAV versions.

[6233638]

Ok, I've done a minor change in the weights, which seems to reduce stray dots a little bit. Maybe that fixes the problem with the noise on black, without hurting the image quality? Can you guys try and confirm?

http://madshi.net/madVRedtest3.rar (build 10)If anything, this is actually worse for noise on black.

If the problem is that the 3DLUT is clipping values at 16, is there some way to fix the yCMS 3DLUT generation so that it doesn't? (preferably without requiring recalibration - but that may be unavoidable)
There's no reason for values below 16 to be clipped in the LUT that I can see.


If it helps, these are the values I'm using:
red, Yxy, 0.2126, 0.640000, 0.330000
green, Yxy, 0.7152, 0.300000, 0.600000
blue, Yxy, 0.0722, 0.150000, 0.060000
white, Yxy, 1.0000, 0.312713, 0.329016

5, Yxy, 0.00105, 0.312713, 0.329016
10, Yxy, 0.00593, 0.312713, 0.329016
15, Yxy, 0.01535, 0.312713, 0.329016
20, Yxy, 0.02865, 0.312713, 0.329016
25, Yxy, 0.04665, 0.312713, 0.329016
30, Yxy, 0.07030, 0.312713, 0.329016
35, Yxy, 0.09950, 0.312713, 0.329016
40, Yxy, 0.13400, 0.312713, 0.329016
45, Yxy, 0.17480, 0.312713, 0.329016
50, Yxy, 0.22100, 0.312713, 0.329016
55, Yxy, 0.27800, 0.312713, 0.329016
60, Yxy, 0.33390, 0.312713, 0.329016
65, Yxy, 0.40280, 0.312713, 0.329016
70, Yxy, 0.48000, 0.312713, 0.329016
75, Yxy, 0.55800, 0.312713, 0.329016
80, Yxy, 0.64300, 0.312713, 0.329016
85, Yxy, 0.73200, 0.312713, 0.329016
90, Yxy, 0.82750, 0.312713, 0.329016
95, Yxy, 0.92500, 0.312713, 0.329016
100, Yxy, 1.00000, 0.312713, 0.329016

Obviously they won't look correct on your display, but should at least let you reproduce this.

I am only using the LUT for gamma correction (as grayscale/gamut corrections introduced banding) so perhaps there's another solution?

[The 8472]

Edit:
Somehow related to the height. I hacked it to use 1032 as height instead (because thats a more aligned number), and the crash stops.


Ah, I generated a 13x7 pattern and stretched it to the target resolution using NN to avoid making it being too "friendly" to madshi's 16x16 ED tiles.

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

[bacondither]

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

A lot of pictures of a bunny with different dithering methods (http://www.sendspace.com/file/hsqlwc)

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

[Shiandow]

Ok, I've done a minor change in the weights, which seems to reduce stray dots a little bit. Maybe that fixes the problem with the noise on black, without hurting the image quality? Can you guys try and confirm?

http://madshi.net/madVRedtest3.rar (build 10)



In my implementation this change seems to have a positive effect, although it is very subtle, it doesn't seem to change the response on near black colours.

Your original algorithm does seem to behave somewhat unusually on nearly black surfaces, it gives a pure black response in places where all other weights I tried have at least some lighter pixels.

Example. (http://i.imgur.com/9mMlzcc.png)

The top uses the weights from build 10 and the lower half uses the 'your' weights. The weights from build 10 clearly have more white pixels in almost black areas. The behaviour from the original algorithm seems to be unusual for error diffusion algorithms. You could do so by changing 0.5375 back to 0.4375 but this seems to cause the 'banding' I pointed out earlier. From what I understand error diffusion simply shouldn't activate on these areas so I think it would be better to solve that problem instead of trying to solve it by changing the weights.

Edit: If you must solve it by changing the weights then simply scaling the weights by a factor 16/17 seems to have a better effect.

[cyberbeing]

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

_____

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

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

_____

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

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

_____

Edit: Added 9 & 10

[Olivier C.]

Did you try ICM color managment and untick "Disable gamma ramp" ? I think it can work

[6233638]

7 has the most uniform distribution of noise out of all of them by far, which results in lowest distortion and sharpest resultTo me, 7 seems very noisy near black compared to some of the others. It also seems to display noise in horizontal bands with some shades.

Extremely brightened example of what's happening on black:
http://abload.de/img/bandshfif6.png

These "lines" can be noticeable at a distance, and have shown up in other shades near black.

9 & 10 seem similar to 3, but with larger checkerboard patternsI find that while there are "checkerboard patterns" visible when you zoom in, they are almost completely invisible when viewing normally - which cannot be said for some of the other dithering artifacts.

2 & 4 have vertical lines in their patterns.That's true, but it's very subtle with #2.

Ultimately, it seems to be a trade-off between "perfect" dithering which seems to be noisy, or making a slight trade-off when inspected at large magnifications, for a perceptually better image.

[cyberbeing]

Initial test on real-world (anime) content.

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

Notes:
7 remained the sharpest of the bunch, with lower distortion than 5
7 & 5 did not have any patterns, but were more noisy
3 has the smoothest result, with very few noticeable patterns
9 & 10 both had very noticeable patterns, and performed very poorly around source banding.


7 has the most uniform distribution of noise out of all of them by far, which results in lowest distortion and sharpest resultTo me, 7 seems very noisy near black compared to some of the others. It also seems to display noise in horizontal bands with some shades.

I cannot reproduce this. 7 is the most uniform out of the random ones, even on black. Though I do agree it is the most noisy of this 3,5,7,9,10 bunch near-black, but still a far cry from the extreme noise 1 and 'random dither'.

Video black brightened with Levels + Curves in Photoshop with my madVR 3DLUT active:
ED3 (http://i1.someimage.com/e7qfEfU.png) | ED5 (http://i1.someimage.com/LyViNjH.png) | ED7 (http://i1.someimage.com/i0dxYSP.png) | ED9 (http://i1.someimage.com/9gmnquY.png) | ED10 (http://i1.someimage.com/S0dXYu2.png)

ED10 produces vertical line clumps on black.
ED9 has clumps.
ED7 is relatively uniform, yet most noise because of this.
ED5 has clumps.
ED3 is very low noise with clumps.

I'm curious how you producing those "extremely brightened" images, and beginning to suspect your 3DLUT is compensating for a display which has erratic behavior near-black. Do some of your dither pixels on black and near-black have an Red, Green, or Blue value greater then +1 compared to the surrounding pixels?

[coolcat]

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

[Shiandow]

Video black brightened with Levels + Curves in Photoshop with my madVR 3DLUT active:
ED3 (http://i1.someimage.com/e7qfEfU.png) | ED5 (http://i1.someimage.com/LyViNjH.png) | ED7 (http://i1.someimage.com/i0dxYSP.png) | ED9 (http://i1.someimage.com/9gmnquY.png) | ED10 (http://i1.someimage.com/S0dXYu2.png)

ED10 produces vertical line clumps on black.
ED9 has clumps.
ED7 is relatively uniform, yet most noise because of this.
ED5 has clumps.
ED3 is very low noise with clumps.


For some reason those images seem to be periodic when they should be random. If that is fixed somehow the 'clumps' and 'lines' you see should really only occur once. I fear that right now you're just comparing the amount of noise on 'black' and how 'lucky' the algorithms are at avoiding obvious patterns.

[cyberbeing]

For some reason those images seem to be periodic when they should be random.

Since madVR is performing error diffusion dither on 16x16 blocks, I'd suspect that's is main reason why some of these periodic patterns form.

I fear that right now you're just comparing the amount of noise on 'black' and how 'lucky' the algorithms are at avoiding obvious patterns.

I'm not. Those images in response to 6233638 were my first tests I've done on black. I honestly care more about how they behaved on the other 254 shades which are actually visible... All conclusions about the dither algorithms I've posted before then, do not take pattern behavior on black into account.

I also don't believe it is possible for any of these algorithms to be 'lucky', since madshi stated he designed the random elements to produce identical results on identical content so there wouldn't be any temporal noise. All the algorithms seem to behave rather consistently. Those which show a high percentage of patterns like ED9 & ED10, always have a high distribution of patterns wherever dithering occurs. On low motion content like anime, these patterns can be noticeable. With ED3, the quantity and size of the patterns was small enough to be almost undetectable. The fact that I could detect patterns at all with ED3 is why I bumped it down below patternless ED5 & ED7 in my anime test.

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

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

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

[drew_afx]

are we comparing "quality" or PSNR?
the point of dithering is to make image "look" better at the cost of introducing noise...if I can't notice the noise in normal viewing conditions I'm all in for better color reproduction sharper image etc

[madshi]

Well, it should be said that the noise on black when using a 3dlut is not actually a "bug". The 3dlut black output seems to be a very very dark shade of gray. Almost black, but not completely. So proper error diffusion *should* throw in some stray dots. The reason why some algorithms do that more than others is that some of the algorithms don't spread 100% of the error to the surrounding pixels, but only ~97%. So if the gray is so near to black that the difference to black is smaller than those 3%, then there's a chance that there are no stray dots in the black, but it also depends on the exact weight configuration. I think we should mostly ignore this, and look for a different solution to the 3dlut problem.

So if we totally ignore stray dots on black, which algorithms do you prefer? And do you think I should only offer one algorithm? Or do you think I should offer two (one low noise, one higher noise)? Which two? FWIW, algorithms 9, 10 are somewhere between the low-noise and medium-noise algorithms, and 3 is somewhere between 9/10 and the medium-noise algorithms, in terms of noise level.

[cyberbeing]

I do use a 3DLUT in MadVR. When using the 3DLUT, my black point is raised just a bit from without a 3DLUT. So if I enable error diffusion (DC3 or DC5), I should be able to see the colored 'dots' on a 16-16-16 pattern right

Assuming you are in a pitch black room, then yes it should be possible to 'dots' with increased luminance when viewed in very close proximity, but it largely depends on your vision, and how well your display behaves near black. If near-black is being crushed with too little separation, then only a hardware instrument will likely be able to detect the changes.

As a simple test, can you see the single color channel noise on these images with your display?

Red (R1-G0-B0) uniform noise over black (http://i1.someimage.com/xo8U2aY.png)

Green (R0-G1-B0) uniform noise over black (http://i1.someimage.com/QNCM6Tk.png)

Blue (R0-G0-B1) uniform noise over black (http://i1.someimage.com/Ozxa5MW.png)

are we comparing "quality" or PSNR?
the point of dithering is to make image "look" better at the cost of introducing noise...if I can't notice the noise in normal viewing conditions I'm all in for better color reproduction sharper image etc

Well this is where subjective opinion about what is and isn't visible clash.

I'm one of those people who always notice dither patterns, while minor +/- 0.33% low level random noise is undetectable during playback. Considering I've never seen a dithering pattern on an untouched HDTV broadcast or Blu-ray release, I'd assume most professional post-production studios have come to a similar conclusion and also favor patternless dithers at the expense of noise and accuracy. IMHO, a dither needs to be impossible to identify from random noise to achieve peak subjective image quality.

The other view in this thread is from those who do not notice most dither patterns, and prefer noiseless with minimum error and peak accuracy via PSNR or similar metrics.

I am considering offering two different error diffusion variants: One with very low noise but with worm artifacts. And one without worm artifacts but slightly higher noise. So feel free to nominate either one or two builds. If you nominate two builds, one should be low-noise with worm artifacts, and one should be slightly higher noise without worm artifacts.

With madshi considering offering two variants in madVR, there is no reason why both views cannot be served. Though maybe we need three variants to make everyone happy...

Completely Patternless

Patterns Artifacts only

Patterns Artifacts + Worms

I'm of the opinion if we are having only two choices, one should be 'completely patternless' or we are just trading one type of artifact for another, considering 'worm' artifacts are just a side-effect of pattern layout. Similarly, the 'completely patternless' dither should have distortion less than 'random dither' or much of the benefit goes away.

[madshi]

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

A lot of pictures of a bunny with different dithering methods (http://www.sendspace.com/file/hsqlwc)

Build 10 looks good but with a minimal grid pattern. Build 7 is free from artifacts and have a slightly higer noise level, but still it is lightyears lower then fully random dither.
That looks like a good test. I wonder if this is a fair representation of a real world test? Maybe we need 2-3 more comparisons like this with real world material to draw a final conclusion. Looking at the bunny images I like build 7 quite a lot.

[cyberbeing]

So if we totally ignore stray dots on black, which algorithms do you prefer?

ED7, since it's patternless, sharp, and low distortion.

And do you think I should only offer one algorithm?

No, since it seems other people want a completely non-random noiseless dither with patterns. May as well offer such an option.

Or do you think I should offer two (one low noise, one higher noise)? Which two? FWIW, algorithms 9, 10 are somewhere between the low-noise and medium-noise algorithms, and 3 is somewhere between 9/10 and the medium-noise algorithms, in terms of noise level.

ED7, since it's patternless, sharp, and low distortion.

ED3, since it has minimal patterns, less noise than ED7, and appears to have the smoothest result of all the randoms.

While I do find it slightly worse, ED5 is similar enough to ED7 that it could be substituted in the patternless category. Beyond that, both ED9 & ED10 have around 2-3x the pattern size as ED3 which I find unacceptable. The non-random ones are obviously much worse, but as long as I have one choice I find acceptable, I could just ignore the second option.

[James Freeman]

And do you think I should only offer one algorithm?

No, since it seems other people want a completely non-random noiseless dither with patterns. May as well offer such an option.


I strongly agree.

x1 non-random.
x2 quality random.

build 7 & 5 looks nice.

[Plutotype]

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

A lot of pictures of a bunny with different dithering methods (http://www.sendspace.com/file/hsqlwc)

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

Thanks for those images. To me, all of the algorithms are still too agressive. Among these, case 5/7 for me, but I would still like to see a more grainy version, where black to gray transitions could appear smoother to human eyes. Optimum should be on a point, where noise will be minimized on blacker parts of the image and gradient transitions will be smooth - no apparent banding will occur ( I dont care about little noising here ).

[cyberbeing]

Optimum should be on a point, where noise will be minimized on blacker parts of the image and gradient transitions will be smooth - no apparent banding will occur ( I dont care about little noising here ).

At a certain point you go beyond preserving lost bitdepth, and begin to enter debanding territory. If you enable madVR debanding, you may achieve the result you desire, assuming madshi has it as the very last processing step before dithering down to 8bit with error diffusion.

[bacondither]

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

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

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

[Skankee]

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


@bacondither:

I cant reproduce your BBB-screenshots with those strong pattern, what did you change ?

When i look at Sample 6 (crf18@1080p) i cant see any pattern, and with enhanced brightness i can only see some minor pattern.
(Maybe this is source-dependent/better to see on low quality videos)

my untouched sample:http://s14.directupload.net/images/140209/jj8hgjtk.png
your sample:http://s7.directupload.net/images/140209/tled7muo.png

Maybe the tests should focus more on real world content. I cant see any pattern on my own samples without enhancing something, maybe someone can upload untouched samples where you can see pattern/worm artifacts ?

[NicolasRobidoux]

Well, it removes the obvious effects of ringing, but not all of them.

Using an old example, comparing Lanczos 3 AR with Lanczos 8 AR:
http://www.abload.de/img/u7wqvvosvv.jpg

You can see that the right of the red circle is still affected, even though the obvious signs of ringing disappear.

This is a really good example of how the most reasonable yet simple overall approach to AR (which I assume Mathias followed) will sometimes be fooled. I expect that if I programmed my own, the first pass would be "fooled" in exactly the same types of situations. Thank you, as often, for your informative posts.

-----

Crazy month at work with the release of the IQ250 camera http://www.phaseone.com/.

Will take me a while to catch up with the questions I raised myself. But I'll get there eventually.

[Shiandow]

Since madVR is performing error diffusion dither on 16x16 blocks, I'd suspect that's is main reason why some of these periodic patterns form.

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

[Shiandow]

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

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

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

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

[leeperry]

So here I am after some good sleep and a full REC709 recalibration, I wanted to postpone my final answer as I wasn't sure where 5 would stand exactly...differences take a lot of concentration and are easier to spot with fresh eyes. And my previous XP calibration was a major failure on W7, I had to rework it all duh..

I understand you're willing to keep one odd and one even build, I find 2 technically impressive but too "flat looking" to my taste, on a LCD it doesn't look very natural to me...not like an "open window" as HD should. This would be great for DLP or Plasma, though.

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

:thanks:

PS: I did try the 10 different builds.

[Seedmanc]

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

[6233638]

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

A lot of pictures of a bunny with different dithering methods (http://www.sendspace.com/file/hsqlwc)

Build 10 looks good but with a minimal grid pattern. Build 7 is free from artifacts and have a slightly higer noise level, but still it is lightyears lower then fully random dither.In real-world images like this, it does seem that 7 is producing better results than anything else, and the noise does not seem to be that much higher.

Thanks for those images. To me, all of the algorithms are still too agressive. Among these, case 5/7 for me, but I would still like to see a more grainy version, where black to gray transitions could appear smoother to human eyes. Optimum should be on a point, where noise will be minimized on blacker parts of the image and gradient transitions will be smooth - no apparent banding will occur ( I dont care about little noising here ).Keep in mind that these examples have been brightened significantly, and that the goal of dithering is not to eliminate banding in the source, but to convert 16-bit to 8-bit data.

[GREG1292]

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


Sent from my iPhone using Tapatalk

[madshi]

Hi, I have a question, Advise me anybody please.
I use 60Hz monitor.
madVR Smooth Motion is off.
When I enter the Full Screen Exclusive Mode, fps is changed to 60fps with Smooth Motion off.
Is it a normal situation?
Full Screen Exclusive Mode always changes fps?
If you don't activate the madVR display mode switching functionality then madVR asks Windows which refresh rate your GPU is currently outputting, and then madVR tells Direct3D to use that refresh rate for Fullscreen Exclusive Mode. It seems that either Windows is telling madVR that your desktop is using 60Hz. Or alternatively Windows is telling madVR the correct refresh rate, but Direct3D switches to use the correct refresh rate and insists on using 60Hz against madVR's wishes. Things like this could happen if you use 3rd party tools to modify the refresh rate, like e.g. PowerStrip or something like that...

Any way how I can narrow down who's the culprit here between lav, madvr and mpc-hc?
Maybe I could narrow that down - if I could reproduce the problem here. But currently I can't...

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

_____

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

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

_____

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

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

_____

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

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

To me, 7 seems very noisy near black compared to some of the others. It also seems to display noise in horizontal bands with some shades.
Please don't concentrate on "near black" too much. The key thing is overall looks. We'll have to look for a solution for your 3dlut black level problem elsewhere. This should not be the deciding factor for choosing the error diffusion algorithm.

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

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

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

The worst two are ED9 & ED10 (medium patterns, low noise, medium crosstalk), with ED10 seemingly producing more 'strange' artifacts then ED9.
(ED1 I'm no longer testing since it's too noisy.)
From what I can see, ED3 has lower noise than ED7, but a little bit more noise than ED9/10. Again, please don't group algorithms for randomness, but please group them for looks alone.

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

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

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

"The scan path goes outward for gray blocks, and inward for white
blocks. Note that during the processing of gray blocks, we diffuse errors from the gray blocks to the white blocks across block boundaries. To process each pixel, we first threshold the pixel value, then diffuse the quantizer error to its neighbors according to an error-weighting matrix..."
That would be a nice addition, but it seems like it would be hard to actually implement. Not to mention that using that method on the same 16x16 blocks would use half the amount of threads so this could make it twice as slow. Although if this allows a smaller block size then it might actually be faster. Any block size from 10x10 or lower should allow more threads to work in parallel.
I read that paper before writing my OpenCL error diffusion algorithm. I decided against using the idea in that paper for 2 reasons:

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

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

9 and 10:
i still prefer 4 and 2 because it is more smooth at my test-sample.
Please check with more than just one test sample.

They don't seem to repeat every 16x16 block. I suspect that it is more a limitation of the random number generator, for some reason the random number generator just repeats itself. This also seems to happen on non-black colours, in my case it seems to repeat every 224 pixels. I strongly suspect that the algorithm somehow uses the position as seed for the random number generator and this seems to cause it to repeat itself when presented with identical content.
The position is used as seed, but the position varies for every pixel, so this seed shouldn't cause repetitions. The random algorithm itself is extremely simple and probably not very good, but then it's very fast. Here's the code:

float random(inout uint randomHelper)
{
randomHelper = 18000 * (randomHelper & 0xffff) + (randomHelper >> 16);
return ((float) (randomHelper & 0xffff)) / 65535.0f;
}
Basically it's "multiply-with-carry" in 16bit. I'd love to use something better, but it would need to perform well, and I'm not really sure it would improve image quality much.

7 is interesting but it's too fuzzy, 5 is the perfect in-between the sterile picture of 2 and the noisy 7....It looks very natural and highly enjoyable. I dearly hope that 5 will be nomitated as I really like the look :)
Hmmmm... Yesterday you preferred 7 and said that it would have very low noise. From my tests it seems that 5 and 7 are very similar. And most other users seem to prefer 7 over 5.

So has the nnedi thing been fixed yet? Doesn't seem to work on my GTX 560.
It's not my problem to fix. It's an NVidia driver bug. NVidia is aware of the bug, hopefully it will get fixed soon. For now you have to downgrade to older drivers, where the problem doesn't occur.

In real-world images like this, it does seem that 7 is producing better results than anything else, and the noise does not seem to be that much higher.
Build 7 is best for my projector and has plenty of pop plus a very clean picture. Don't know if I can improve on my settings but I use needi3 64
and dxva2 for the other 2. Gpu and CPU Q are 24/32 all quality settings unticked and doubling 256 for both luma and chroma on a gtx770 with nvidia 327.43. Picture is amazing with no frame drops. Might look a little
over the top but that's the way I like it. Same settings on build 2 not
playable. Custom fan curve gpu never gets hotter than 60 Celsius.
My vote so far is for 7 and all I can say is wow!!!!!!!!!! Thanks for the awesome work 720p and 1080p movies are so real looking and no black
artifacts or noise seen in the image. Using a Mitsubishi Hc7900 on a 92"
screen sitting 12 ft back and gives the feeling of being inside the screen.
So I would say that build 7 is my favorite so far for a movie watcher enthusiast.
So it seems build 7 is a favorite of many people. So I'm wondering: Does anybody still need a lower-noise algorithm than 7? Or maybe I could use build 7 as the only error diffusion algorithm?

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

Thoughts?

[leeperry]

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

Yes, I fully agree that 7 gives the best pop effect but I personally far prefer the clearer look of 5...7 on my Sammy TV is fatiguing to look at compared to 5 as the picture is much fuzzier, I'm entirely willing to trade some pop for clarity but it depends on so many factors that :
maybe we need three variants to make everyone happy...
maybe 2/5/7 would be great to please everybody, calling them low/mid/high noise for instance.

Hmmmm... Yesterday you preferred 7 and said that it would have very low noise. From my tests it seems that 5 and 7 are very similar. And most other users seem to prefer 7 over 5.
I wanted to postpone because running this kind of test at 6 PM isn't the best idea and I suspected that my TV needed to be recalibrated anyway. It takes some time and a lot of attention to make a good opinion on real-world footage.

[madshi]

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

[madshi]

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

A lot of pictures of a bunny with different dithering methods (http://www.sendspace.com/file/hsqlwc)

Build 10 looks good but with a minimal grid pattern. Build 7 is free from artifacts and have a slightly higer noise level, but still it is lightyears lower then fully random dither.
Can you upload a small sample with this scene? It seems to be a good test case. Thx.

[Shiandow]

float random(inout uint randomHelper)
{
randomHelper = 18000 * (randomHelper & 0xffff) + (randomHelper >> 16);
return ((float) (randomHelper & 0xffff)) / 65535.0f;
}
Basically it's "multiply-with-carry" in 16bit. I'd love to use something better, but it would need to perform well, and I'm not really sure it would improve image quality much.

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

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

or just use any other set of numbers from this page (http://en.wikipedia.org/wiki/Linear_congruential_generator).

[GREG1292]

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


Sent from my iPhone using Tapatalk

[Anima123]

Madshi,

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

Regards,
Anima123

[madshi]

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

I think it would be better to use something like
The result of your multiplication needs more than 32bit, but your code doesn't reflect that. That's probably a simplification of the algorithm which could hurt the quality of the random numbers.

There's a very good PRNG Mersenne Twister, you can access it at *http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html, where there's a new variant for Graphic Processors (MTGP). You might want to take a look at it.
From what I can see I think this would be multitudes slower than the algorithm I'm using. I need something very simple and fast. It doesn't have to be encryption quality.

[Matthias Hutter]

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

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

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

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

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

[XMonarchY]

Does it also solve the blue whites problem?

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