madVR - high quality video renderer (GPU assisted)

[n3w813]

It is, except when using an ArgyllCMS generated 3DLUT.

8bit 16-16-16 = 16bit 2056-2056-2056

For example, if the 3DLUT maps 16-16-16 (8bit) -> 2057-2057-2057 (16bit) you'll end up with 1-1-1 (16bit) after TV->PC expansion. When conversion back to 8bit occurs, you end up with a fractional 8bit value of ~0.008 which cannot exist. The only way to simulate an 8bit fractional value is by dithering. In many ways, it would be preferred if madVR did not perform dithering on 16bit values which end up as pure black when shifted to 8bit without dithering.

I'm also using an ArgyllCMS generated 3DLUT using DC3 with error diffusion enabled and do not see the dithering artifacts...I'm supposed to see this on 16-16-16 black correct? I know for sure my black point is raised after 3DLUT through verification measurement.

[cyberbeing]

Does anyone else with a 24p display get dropped frames when playing this file?

If the video has a higher framerate than your refresh rate, you'll have dropped frames in madVR. The one you linked is 29.97fps.

I know for sure my black point is raised after 3DLUT through verification measurement.

I'm unsure exactly what you are asking. If you've verified by measurements that your black point is higher when your 3DLUT is active, then it is. If you put your eyes close to a black screen, more pixels should be lit then when you've disabled that 3DLUT. From a distance it should all blend into a single shade, and simply appear brighter in a dark room.

[nx6]

Or I could add an undocumented feature to madVR to auto-load pixel shaders from a text file or from the registry or something. No big problem, really...

Better customization of MadVR for third-party developers sounds like a good thing to me.

[turbojet]

The original full file shows this in mediainfo:
Frame rate mode : Variable
Original frame rate : 23.976 fps

The cut version that's linked shows:
Frame rate mode : Constant
Frame rate : 29.970 fps
Original frame rate : 23.976 fps

Should madvr be detecting this as 24 fps like it is currently?

[James Freeman]

About 3DLUTs.

I calibrate to Gamma 2.2 Relative and custom white point (around 5900K),
Matrix+Curves (not LUT) which I find gives me a smoother and more correct colors.

Then I create the 3DLUT with BT.1886 2.2 Relative & Luminance Matched Appearance.
Anything else as suggested in the AVS thread resulting in big error in colors and gamma (lifted blacks, blue whites, and more...).

The settings suggested in the AVS thread work only with LUT profiling which I don't use.
I see "color steps" or gradients between colors with LUT, with Matrix its smooth for me.

No dithered blacks with these settings on all DirectComputing versions.

[Qaq]

The original full file shows this in mediainfo:
Frame rate mode : Variable
Original frame rate : 23.976 fps

The cut version that's linked shows:
Frame rate mode : Constant
Frame rate : 29.970 fps
Original frame rate : 23.976 fps

Should madvr be detecting this as 24 fps like it is currently?
I guess its telecined movie, so madVR should use IVTC 29>23. If set deinterlacing - movie, of course (check this out).

[turbojet]

Forcing video works but leaves a duplicate every sixth frame. Guess I'll encode it with tdecimate(cycle=6).

[wolfman2791]

what r u supposed to do with the "Intel Media SDK Software" file? Thanks.

[michkrol]

what r u supposed to do with the "Intel Media SDK Software" file? Thanks.

If you mean "The Intel Media SDK Software MPEG2, VC-1 and h264 Decoder DLL" from first post, you only need it to use madVR's internal decoding capabilities instead of your codecs (LAVFilters/ffdshow/?). It's not recommended anymore, better use LAVFilters, so generally you don't need them.

[pankov]

P.S: Or I could add an undocumented feature to madVR to auto-load pixel shaders from a text file or from the registry or something. No big problem, really...
madshi,
this will be a great feature for all ZoomPlayer users since we don't have pixel shaders support in our player and the development is pretty slow lately so I don't have high hopes for getting this without your help.

[wolfman2791]

If you mean "The Intel Media SDK Software MPEG2, VC-1 and h264 Decoder DLL" from first post, you only need it to use madVR's internal decoding capabilities instead of your codecs (LAVFilters/ffdshow/?). It's not recommended anymore, better use LAVFilters, so generally you don't need them. Thanks. So it's bypassed if you have LAV Filters turned on and it's used as a default if you don't... basically not needed.

[Qaq]

Forcing video works but leaves a duplicate every sixth frame.
Forcing "video"? You had to force "Movie" to let madVR IVTC it 29>23.

[madshi]

Is it still the case that your DirectCompute NNEDI3 tests show it to be 10 times slower than with OpenCL?

Would you elaborate on what was slower? Are you referring to the rendering ms speed? What was the hardware (Intel, AMD, Nvivida), and Madvr settings (including downscaling choice)?

Perhaps a different combination of settings would work better with the DirectCompute coding compared to OpenCL, or perhaps results would differ when tested with an Nvidia equipped system compared to an AMD.
I've not spent any further time on that yet. Overall rendering time was 10x slower. Tested on AMD, but I'm pretty sure that the same problem would occur with NVidia, too, cause the DirectCompute compiler comes from Microsoft, AFAIK. The GPU drivers just run an "optimizer" pass after that.

With the extreme amount of bugginess the Nvidia systems have with the OpenCL coding it may still be better off (even after Nvidia patches the problem) for Nvidia systems to use the DirectCompute version.
Would why any NVidia user choose to use a 10x slower version? Makes no sense to me. Anyway, I've no interest in discussing this now, I've not completed development yet, was just giving you guys a heads up on current status.

1. Is there a way to render JPEG files with madVR to improve/sharpen them as if they were just single film frames?
I think you can just drag them into MPC-HC? I don't know, this kind of stuff is the job of media player or splitter/source filter developers. If they support JPEG files, madVR will happily render them.

2. My Samsung LN40B550 supports full 4:4:4 only in 60Hz mode, which is not as smooth (even with Smooth Motion) as the 48Hz 4:2:2 judder-free mode that I prefer. However, the 48Hz mode has 2 versions - Movie and Standard. Movie 4:2:2 mode creates nasty text discoloration and on your 4:2:2/4:4:4 test image I can see 4:2:2 clearly, but I can also see 4:4:4 with similar nasty/ugly discolorated edges around it. Then there is the Standard 4:2:2 mode that I use because unlike Movie 4:2:2 mode, it actually displays text properly (even with sharpness set to 0)! Using this 4:2:2 Standard mode, the 4:2:2/4:4:4 test image shows both 4:2:2 and 4:4:4, but 4:4:4 edges have just a barely noticeable discoloration. Chroma upscaling/doubling, Luma doubling, image upscaling/downscaling are all targeting 4:2:0 - 4:4:4 chroma subsampling conversion. However, I can most definitely see a huge improvement in Standard 4:2:2 mode in video quality and sharpness when using error diffusion, NNEDI3 chroma and luma doubling/upscaling, etc. So, what exactly am I losing?
Just use what your eyes judge to be the best setting.

5. I know TotalMedia Theatre does not support madVR, but does PowerDVD 13 support it? Can it be used with madVR to render and playback 3D content?
No.

What do you think of something like this (http://i.imgur.com/PRJsczo.png)? This is a modified version of the Floyd-Steinberg weights combined with Madshi's weights.
Combined with how?

Better customization of MadVR for third-party developers sounds like a good thing to me.
Not sure what you mean. It's already dead easy for 3rd party developers to add support for custom pixel shaders with madVR. Really, it couldn't be any easier. All they have to do is to feed madVR with the custom shader source code. madVR already does all the rest. No other renderer does that.

The original full file shows this in mediainfo:
Frame rate mode : Variable
Original frame rate : 23.976 fps

The cut version that's linked shows:
Frame rate mode : Constant
Frame rate : 29.970 fps
Original frame rate : 23.976 fps

Should madvr be detecting this as 24 fps like it is currently?
madVR doesn't "detect" anything. The fps information is coming from upstream (splitter/decoder).

-------

For anybody interested in which Error Diffusion algorithm madVR should use, here are a couple of test builds:

http://madshi.net/madVRedtest.rar

There are 8 different builds included, based on ideas and suggestions from different users. I've intentionally *not* named them properly, so you can do a real blind test. Let me know which build number(s) you prefer. And ideally, try them in real time first, without using contrast/brightness boosting. This is for your own good, because that's what counts most. Feel free to double check afterwards with screenshots and contrast/brightness boosts.

Will be interesting to hear the results. 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.

All 8 test builds operate on 16x16 pixel blocks, using serpentine scanning. The algorithms used are the following, but in a different order than listed here:

(1) original test build 3 - madshi weights, no randomness
(2) same as (1), but with improved edge error spreading
(3) same as (2), plus adding noise before rounding
(4) original test build 5 - random weights
(5) Floyd-Steinberg, no randomness
(6) same as (5), plus adding noise before rounding
(7) Filter Lite with 0.97 weight sum, no randomness
(8) same as (7), plus adding noise before rounding

I'm really excited about hearing your preferences! I know that I have 2 clear favorites.

[huhn]

Forcing "video"? You had to force "Movie" to let madVR IVTC it 29>23.

the file is not telecine and a normal decimate shouldn't work too is repeats a frame every 5 frames it is definitive not 23p

madvr ivtc detracts it as 4:2:2:2:2 so 12i to 5p so 25 fps looks like 25 fps changed to 30 and with a playback info of 23 hz

madvr normally can't handle 4:2:2:2, but how to handle 4:2:2:2:2 ...

[bacondither]

Nevermind...

[Gagorian]

@madshi

Are you sure you haven't mixed up nr 7 and 8.

Number 7 look like it has added random thresholds and 8 not.

I've intentionally *not* named them properly, so you can do a real blind test.
....
The algorithms used are the following, but in a different order than listed here:


Read above?

[Shiandow]

Combined with how?

Sorry for being unclear, I was still testing how exactly to combine the two. The image I posted was generated by using the following weights 2/3 of the time:

((0,1/16),
(0,3/16),
(0,5/16),
(7/16,0))

And the following weights the other 1/3 of the time:

((0,0),
(0,0.0090),
(0,0.4861),
(0.7770,-0.3098))

For technical reasons these array are transposed, the rows correspond to the x direction and the columns correspond to the y direction. I also alternated scanning the image left to right and right to left.

Since then I've been testing it in various situations with various different levels of 'mixing'. And I think that this method might be superior even to just using one of both set of weights. It combines the good parts of Flloyd-Steinberg with the good parts of the weights from Build 3, and it adds at least some randomness which can avoid some unwanted patterns.

In the following image I use this method, where I used Build 3 weights 1/5 of the time, on the top part and I use the weights from Build 3 on the lower part:

comparison (http://i.imgur.com/Fh9Do1u.png)

The combined method seems to avoid some of the obvious horizontal bands. IMHO this makes the combined method seem smoother, while adding a minimal amount of noise.

[Mano]

Hi, for some files there are 2 audio stream
Audio: FLAC 48000Hz stereo 2304kbps [Japanese, Main - 2.0 FLAC (Audio 1) [Default]]
Audio: AAC 48000Hz stereo [Japanese, Commentary - 2.0 AAC (Audio 2)]

but i cannot switch the audio at all since the play>audio option is grayed.

[bacondither]

After som Quick and dirty enhanced black clipping patterns test(will do a longer test some time later).


Best to worst in the "noisy" artifact free ED category:

1st place(best). Shared by build 7 (http://s7.postimg.org/546l2dd2j/image.png) and build 5 (http://s7.postimg.org/4dduwlap7/image.png).

2nd place. Build 3 (http://s7.postimg.org/8jypbxaaz/image.png).

3rd place(worst). Build 1 (http://s7.postimg.org/6tfoafsrv/image.png). Ugly dots!


Best to worst in the lower noise and worms are acceptable ED category:

1st place(best). Build 6 (http://s7.postimg.org/bmuu1jzvv/image.png).

2nd place. Shared by Build 8 (http://s7.postimg.org/7msa31ysr/image.png) and Build 4 (http://s7.postimg.org/t2tlgzo8b/image.png).

3rd place(worst). Build 2 (http://s7.postimg.org/z2cr6wjmz/image.png). Ugly dots!

//edit

Build 5 gives me slightly lower rendering times then build 7 and looks identical too. For now i think build 5 is the best choice.

[leeperry]

I didn't read other posts but I think my favorites are 2 and 7, 2 giving the best depth impression as it would appear and 7 looking much less noisy and even better thanks to the lower subjective noise floor but phew...I'll do that again tomorrow morning with fresh eyes if you don't mind.

How about providing those 8 different options so OCD'ed end-users could have a ball and pick whichever one they like best depending on their taste and equipment? It seems only logical that ppl with 6bit TN might not have the same needs as those on real 10bit displays.

[huhn]

Hi, for some files there are 2 audio stream


but i cannot switch the audio at all since the play>audio option is grayed.

a audio stream has nothing to do with madvr check your player/splitter.

[n3w813]

I'm unsure exactly what you are asking. If you've verified by measurements that your black point is higher when your 3DLUT is active, then it is. If you put your eyes close to a black screen, more pixels should be lit then when you've disabled that 3DLUT. From a distance it should all blend into a single shade, and simply appear brighter in a dark room.

Sorry, I don't think I was clear in my post. 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? The problem I have is that I don't see ANY dots at all. I'm not trying to disprove what you see but trying to understand if there is something different going on with my set up. :D

[leeperry]

And anyway, you'll provide a user manual with mVR 1.0 so I don't see how it could be such a big deal to have 8 different ED algorithms if who does what is properly documented IMHO....especially if the ED algorithm is an optional sub-option only meant for power-users(read utterly OCD'ed videophiles ^^).

Better have too many options than not enough, you'll need to explain about Jinc & NNEDI so it can't get much worse and I believe mVR is meant to be the ultimate VR.

Many audio apps come with different dithering algorithms that you can pick and finetune depending on your needs: iZotope MBIT+ Dither (https://www.izotope.com/support/help/ozone/pages/modules_dithering.htm)

[drew_afx]

Just going by the looks here watching 422 prores hq trailer on 6bit+AFRC e-ips 23" monitor from 1m away

I liked 1, 4, 8

1 seemed to be most ordinary, nothing bad or good

4 showed the most detail and temporal resolution
(but could spot noise on source more easily as well)

8 gave me the pop effect
(but sometimes it seemed less detailed than 4 or 1)

It might not be balanced since I could point out the difference, so I'd say a compromise between 4 and 8 would be the best for me.
Then again I could be very wrong mind tricks me when watching same trailer 8times :confused:

[6233638]

For anybody interested in which Error Diffusion algorithm madVR should use, here are a couple of test builds:

http://madshi.net/madVRedtest.rar
From a limited amount of testing, looking at noise near black (where I find it most obvious)

1, 3, 5 all show noise on black for me, with 1 & 5 being very noisy.
5 has a tendency to show patterns in the noise.

6 & 7 seem to be very noisy (though not on black) and produce a much darker image near black than the other algorithms. (I've triple-checked this, and get the same results each time)

2 seems to be the best choice for low noise, and avoiding obvious patterns.
2 & 4 produce similarly low-noise images, but 4 seems more prone to introducing obvious patterns.
8 seems to be a bit noisier than 2 or 4.

So #2 seems to be a clear winner for me, at least from the testing I've done so far.

[XMonarchY]

Sorry, I don't think I was clear in my post. 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? The problem I have is that I don't see ANY dots at all. I'm not trying to disprove what you see but trying to understand if there is something different going on with my set up. :D

dispcalGUI now has an official workaround to fix your LUT black levels, but you're going to need to create a new 3DLUT for it to work.

[James Freeman]

I can't tell the difference between all of them with my own eyes.
They all look much smoother than the random dither colorful noise, which is very visible.
Funny how the answers from users are all over the place... it may very well be negligible.

After som Quick and dirty enhanced black clipping patterns test
Posted photoshop pictures in no time.
Did you even bother to take the visual test or you simply don't care?

[XMonarchY]

About 3DLUTs.

I calibrate to Gamma 2.2 Relative and custom white point (around 5900K),
Matrix+Curves (not LUT) which I find gives me a smoother and more correct colors.

Then I create the 3DLUT with BT.1886 2.2 Relative & Luminance Matched Appearance.
Anything else as suggested in the AVS thread resulting in big error in colors and gamma (lifted blacks, blue whites, and more...).

The settings suggested in the AVS thread work only with LUT profiling which I don't use.
I see "color steps" or gradients between colors with LUT, with Matrix its smooth for me.

No dithered blacks with these settings on all DirectComputing versions.

No. Everything is perfectly fine - no raised blacks what-so-ever using 1DLUTs or 3DLUTs. Period. I already explained there is a new feature in dispcalGUI that brings your black level to 0,0,0 RGB coordinates.

[James Freeman]

No. Everything is perfectly fine - no raised blacks what-so-ever using 1DLUTs or 3DLUTs. Period. I already explained there is a new feature in dispcalGUI that brings your black level to 0,0,0 RGB coordinates.

Does it also solve the blue whites problem?

[The 8472]

As promised earlier, I'm trying to make some more test patterns

Everything is encoded in 16bit yuv ffv1, i.e. lossless.

r, g, b and white light sources in each corner and a black in the center. stepping up intensity of the corner sources with each frame
1440p (http://www.filedropper.com/16bitrgbwspotgradients)
1080p (http://www74.zippyshare.com/v/82668553/file.html)

black-green only gradient:
1440p (http://www49.zippyshare.com/v/9410030/file.html)
1080p (http://www25.zippyshare.com/v/29106731/file.html)

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)

Best viewed with smooth motion off.

[madshi]

Sorry for being unclear, I was still testing how exactly to combine the two. The image I posted was generated by using the following weights 2/3 of the time:

And the following weights the other 1/3 of the time:

For technical reasons these array are transposed, the rows correspond to the x direction and the columns correspond to the y direction. I also alternated scanning the image left to right and right to left.

Since then I've been testing it in various situations with various different levels of 'mixing'. And I think that this method might be superior even to just using one of both set of weights. It combines the good parts of Flloyd-Steinberg with the good parts of the weights from Build 3, and it adds at least some randomness which can avoid some unwanted patterns.

In the following image I use this method, where I used Build 3 weights 1/5 of the time, on the top part and I use the weights from Build 3 on the lower part:

comparison (http://i.imgur.com/Fh9Do1u.png)

The combined method seems to avoid some of the obvious horizontal bands. IMHO this makes the combined method seem smoother, while adding a minimal amount of noise.
In that test image the top part looks clearly better. The problem is that the overall error diffusion results seem to vary a lot depending on which test image is used, and with 8bit error diffusion it even seems to depend a lot on slight changes to gray levels, like calibration processing, gamma processing etc. Also what looks better at 1bit can look overly noisy (although worm artifact free) at 8bit. Anyway, if you can describe your algorithm in such a way that I can reproduce it, I can add another madVR test build for comparison. You're saying you're using Floyd-Steinberg weights sometimes and sometimes my original weights. But when exactly are you using which? Randomly? Or do you use one set of weights for 4 pixels, then the other weights for 1 pixel? Or do you switch row by row? Also I don't understand the seperation in x and y direction of your weight tables. Serpentine scanning always progresses in x direction, either from left to right, or from right to left, so how does y come into this?

After som Quick and dirty enhanced black clipping patterns test(will do a longer test some time later).

Best to worst in the "noisy" artifact free ED category:

1st place(best). Shared by build 7 (http://s7.postimg.org/546l2dd2j/image.png) and build 5 (http://s7.postimg.org/4dduwlap7/image.png).

2nd place. Build 3 (http://s7.postimg.org/8jypbxaaz/image.png).

3rd place(worst). Build 1 (http://s7.postimg.org/6tfoafsrv/image.png). Ugly dots!
Build 1 is the noisiest of them all, without having obvious benefits over the others, so I can understand/agree that it's probably the worst of this bunch. However, I'm not sure I agree with the placement of builds 3, 5 and 7. Yes, build 3 it has slightly more pronounced patterns than builds 5 and 7, but it also has less noise than either 5 and 7 (see bar 22). So I'm not sure whether to prefer builds 5/7 or 3...

Best to worst in the lower noise and worms are acceptable ED category:

1st place(best). Build 6 (http://s7.postimg.org/bmuu1jzvv/image.png).

2nd place. Shared by Build 8 (http://s7.postimg.org/7msa31ysr/image.png) and Build 4 (http://s7.postimg.org/t2tlgzo8b/image.png).

3rd place(worst). Build 2 (http://s7.postimg.org/z2cr6wjmz/image.png). Ugly dots!
Where are those ugly dots in build 2? All of these have some artifacts. I don't think build 2 stands out negatively here. Besides, you're seemingly having slightly different shades of grey than I have on my development PC, because here the patterns are quite a bit different with the "even" build numbers. Are you using a 3dlut or gamma processing or something else which might modify the gray levels somewhat? Or maybe you're using 16-235 output? I'm using 0-255. Anyway, here are screenshots from my development PC, so you can compare to your own:

http://madshi.net/edtest.rar

If you look at my test images, I hope you'll agree that build 6 is pretty bad. With build 6 almost every gray bar clearly shows where the 16x16 pixel sized blocks are located. Which is a real problem. This is the kind of artifact that might also be visible in motion. We should definitely pick an algorithm which hides the 16x16 pixel block borders well, in order to avoid having those borders stand out in motion. IMHO both 6 and 8 suffer from this problem, and build 4, partially, too. I guess I just revealed my favorite low noise algorithm...

I didn't read other posts but I think my favorites are 2 and 7, 2 giving the best depth impression as it would appear and 7 looking much less noisy and even better thanks to the lower subjective noise floor but phew...I'll do that again tomorrow morning with fresh eyes if you don't mind.

How about providing those 8 different options so OCD'ed end-users could have a ball and pick whichever one they like best depending on their taste and equipment? It seems only logical that ppl with 6bit TN might not have the same needs as those on real 10bit displays.
Yes, please try again tomorrow morning. I think you may change your mind, at least about one of the two builds you mentioned. Please try to ignore my replies to other users, so you can make a go at this without prejudice.

And anyway, you'll provide a user manual with mVR 1.0 so I don't see how it could be such a big deal to have 8 different ED algorithms if who does what is properly documented IMHO....especially if the ED algorithm is an optional sub-option only meant for power-users(read utterly OCD'ed videophiles ^^).
I will most definitely NOT offer options for 8 different algorithms with infinitely small differences. There will be at most 2 error diffusion algorithms. Really, I would prefer only 1. But I can already see that some people prefer the low-noise worm artifact way, while others prefer the medium-noise random way, so I may have to offer 2 options for error diffusion. But there will be no more than 2, max.

Just going by the looks here watching 422 prores hq trailer on 6bit+AFRC e-ips 23" monitor from 1m away

I liked 1, 4, 8

1 seemed to be most ordinary, nothing bad or good

4 showed the most detail and temporal resolution
(but could spot noise on source more easily as well)

8 gave me the pop effect
(but sometimes it seemed less detailed than 4 or 1)

It might not be balanced since I could point out the difference, so I'd say a compromise between 4 and 8 would be the best for me.
Then again I could be very wrong mind tricks me when watching same trailer 8times :confused:
Hmmmm... Quite different from some of the other comments.

From a limited amount of testing, looking at noise near black (where I find it most obvious)

1, 3, 5 all show noise on black for me, with 1 & 5 being very noisy.
5 has a tendency to show patterns in the noise.

6 & 7 seem to be very noisy (though not on black) and produce a much darker image near black than the other algorithms. (I've triple-checked this, and get the same results each time)

2 seems to be the best choice for low noise, and avoiding obvious patterns.
2 & 4 produce similarly low-noise images, but 4 seems more prone to introducing obvious patterns.
8 seems to be a bit noisier than 2 or 4.

So #2 seems to be a clear winner for me, at least from the testing I've done so far.
I agree with your preference for #2 for the low noise algorithm. What is your preference for the medium noise algorithm? If I interpret your post correctly, would that be #3?

As promised earlier, I'm trying to make some more test patterns

Everything is encoded in 16bit yuv ffv1, i.e. lossless.

r, g, b and white light sources in each corner and a black in the center. stepping up intensity of the corner sources with each frame
1440p (http://www.filedropper.com/16bitrgbwspotgradients)
1080p (http://www74.zippyshare.com/v/82668553/file.html)

black-green only gradient:
1440p: todo
1080p: todo

flat tiles with steps of grey smaller than the 8bit quantum:
1440p: todo
1080p: todo

Best viewed with smooth motion off.
Thanks. Do you have a preference for one (or two) of those 8 test builds with your 16bit test patterns?

[nx6]

Not sure what you mean. It's already dead easy for 3rd party developers to add support for custom pixel shaders with madVR. Really, it couldn't be any easier. All they have to do is to feed madVR with the custom shader source code. madVR already does all the rest. No other renderer does that.

I meant I liked the idea of it accepting input via registry entries or a text file. Something like that might be easier for the user to manipulate from within their player's own settings, or in the case of a text file, write themselves.

[6233638]

I agree with your preference for #2 for the low noise algorithm. What is your preference for the medium noise algorithm? If I interpret your post correctly, would that be #3?
Assuming that:
Low Noise = 2, 4, 8
Med Noise = 1, 3, 5
High Noise = 6, 7

Then my preference would be #3 for medium noise. ("best" to me highlighted in red)

This is mostly from looking at test patterns near black and shadow details rather than 1-bit gradients etc.
I definitely prefer the "low noise" group to the med/high noise groups.

I'm not sure that 6/7 are working correctly on my system when 3DLUTs are enabled though. They're very noisy, and much darker than the other test builds near black.

[fairchild]

With all the focus currently on the dithering method used and low versus high noise etc., what is the consensus on MadVR's dithering while being displayed on a plasma TV, such as my 55VT60. Inherently dithering is done on plasma by the panel itself and the intensity of the dithering can also be adjusted on the TV itself with a Panel Brightness setting. (High = most dithering, Low = least dithering) I currently have my plasma calibrated with an accurate device (a spectrometer) and have noted that the added noise of the dithering from MadVR does affect the picture and introduces more noise in the picture vs a different device such as a set-top blu-ray player. (this doesn't affect the grayscale or color accuracy from my testing, but does affect the actual brightness setting, and possibly the measured gamma)

So added dithering from MadVR on plasma's yay or nay?

[nevcairiel]

So added dithering from MadVR on plasma's yay or nay?

If you don't dither in madVR you risk getting banding, so you should always dither.

If you suffer from noise that much, the low-noise Error Diffusion algorithm may be beneficial for you though.

[Shiandow]

In that test image the top part looks clearly better. The problem is that the overall error diffusion results seem to vary a lot depending on which test image is used, and with 8bit error diffusion it even seems to depend a lot on slight changes to gray levels, like calibration processing, gamma processing etc. Also what looks better at 1bit can look overly noisy (although worm artifact free) at 8bit. Anyway, if you can describe your algorithm in such a way that I can reproduce it, I can add another madVR test build for comparison. You're saying you're using Floyd-Steinberg weights sometimes and sometimes my original weights. But when exactly are you using which? Randomly? Or do you use one set of weights for 4 pixels, then the other weights for 1 pixel? Or do you switch row by row? Also I don't understand the seperation in x and y direction of your weight tables. Serpentine scanning always progresses in x direction, either from left to right, or from right to left, so how does y come into this?

For clarity I'll give the version that doesn't use gamma correction or serpentine scanning, I hope this will give you enough information to implement it. The following pseudo-code is adapted from the one on the Floyd-Steinberg wikipedia page.


for each y from top to bottom
for each x from left to right
oldpixel := pixel[x][y]
newpixel := find_closest_palette_color(oldpixel)
pixel[x][y] := newpixel
quant_error := oldpixel - newpixel
if random() > 0.2 then
pixel[x+1][y ] := pixel[x+1][y ] + 7/16 * quant_error
pixel[x-1][y+1] := pixel[x-1][y+1] + 3/16 * quant_error
pixel[x ][y+1] := pixel[x ][y+1] + 5/16 * quant_error
pixel[x-2][y+1] := pixel[x-2][y+1] + 1/16 * quant_error
else
pixel[x+1][y ] := pixel[x+1][y ] + 0.7770 * quant_error
pixel[x-1][y+1] := pixel[x-1][y+1] + 0.0090 * quant_error
pixel[x ][y+1] := pixel[x ][y+1] + 0.4861 * quant_error
pixel[x+1][y+1] := pixel[x+1][y+1] - 0.3098 * quant_error


Beware that the first set of weights changes pixel[x-2][y+1] not pixel[x+1][y+1]. The second set of weights should be the same as the one you used in test build 3.

[fairchild]

If you don't dither in madVR you risk getting banding, so you should always dither.

If you suffer from noise that much, the low-noise Error Diffusion algorithm may be beneficial for you though.

Duh, I forgot that part of it. I can easily see banding in a test pattern that I have which is 720p when scaling up to 1080p when dithering is disabled. (Banding_720p.rec709.mkv)

For now I'll just stick to random dithering until the experts decide on the best error diffusion low noise version is. :thanks:

[Asmodian]

I would say "yay" but you definitely want low noise dithering on a plasma.

edit: wow a lot happened while I was reading. ;)

[bacondither]

Besides, you're seemingly having slightly different shades of grey than I have on my development PC, because here the patterns are quite a bit different with the "even" build numbers. Are you using a 3dlut or gamma processing or something else which might modify the gray levels somewhat? Or maybe you're using 16-235 output? I'm using 0-255.

No gamma or 3dlut processing or any else of any kind, and 0-255 output.

You image 8 looks like the noise pattern of build 6 to me.

Can you post an unbrightened image of the black clipping pattern?

[bacondither]

//Additional information

I'm getting the same brightness levels on the grey bars using the black clipping testpattern on another partion with a fresh install of windows and madvr and the same levels on the grey bars using VLC!

So i dont think the problem is on my side. And if it is, i would like to know what is wrong!

//EVR custom presenter +full FP processing gives the same values as madvr with ED dither

[iSunrise]

//Additional information

I'm getting the same brightness levels on the grey bars using the black clipping testpattern on another partion with a fresh install of windows and madvr and the same levels on the grey bars using VLC!

So i dont think the problem is on my side. And if it is, i would like to know what is wrong!
In the past (there actually was a NV12 testing program for it that madshi had written specifically to test performance and output range) madshi recommended (e.x. if you have an NV) to manually set the dynamic range setting in the NV driver to 0-255 (which is under adjust video color settings -> with the NV settings). Just set it to 0-255 and then choose "with the video player settings" again. I´m not sure if that´s the same thing that madLevelsTweaker.exe is doing, too.

I´m not even a 100% sure if that´s still needed, though, but I´m still doing it as there wasn´t any indication that I remember, that this is no longer needed, anymore. Because after you do a clean install of the NV drivers it´s always set at the default 16-235, which - according to the past - wasn´t giving the correct results when you want full dynamic range on a PC monitor display or something else that expects full range.

[turbojet]

the file is not telecine and a normal decimate shouldn't work too is repeats a frame every 5 frames it is definitive not 23p

madvr ivtc detracts it as 4:2:2:2:2 so 12i to 5p so 25 fps looks like 25 fps changed to 30 and with a playback info of 23 hz

madvr normally can't handle 4:2:2:2, but how to handle 4:2:2:2:2 ...

madVR doesn't detect any cadence for me. The only differences between film and video mode in this case is 24 vs 60hz and deint off vs. on. With film mode on, using deint=video seems like the most appropriate way to play it without encoding and with smooth motion it might be good enough for me.

Originally Posted by turbojet View Post
The original full file shows this in mediainfo:
Frame rate mode : Variable
Original frame rate : 23.976 fps

The cut version that's linked shows:
Frame rate mode : Constant
Frame rate : 29.970 fps
Original frame rate : 23.976 fps

Should madvr be detecting this as 24 fps like it is currently?
madVR doesn't "detect" anything. The fps information is coming from upstream (splitter/decoder).

I should take it up with splitter/decoder devs but the few I've tried all handle it the same way, 24 fps, although none of the video is 24 fps. Remuxing the 29.97 cfr has no effect, might be a larger hassle then it's worth.

[bacondither]

I'm using a AMD card .

Can someone post an untoutched screenshot of the AVS HD 709 - Blu-ray & MP4 Calibration Black clipping pattern?

[The 8472]

Hah, mpc-hc crashes on the 16bit tiled samples I tried to generate. Fun...

[bacondither]

BTW this is how EVR custom pres with full FP processing (http://s18.postimg.org/62si2elt5/EVR.png) looks like.

[iSunrise]

I'm using a AMD card .

Can someone post an untoutched screenshot of the AVS HD 709 - Blu-ray & MP4 Calibration Black clipping pattern?
AVS HD - Black Clipping - untouched AVCHD (http://imgur.com/yRjWV0L) and MP4 (http://imgur.com/kKytz5g) (madVR ED dithering enabled, done with build2)
AVS HD - Black Clipping - untouched AVCHD (http://imgur.com/QN9oMsr) and MP4 (http://imgur.com/Apxum8b) (madVR dithering disabled)

[Ver Greeneyes]

As promised earlier, I'm trying to make some more test patterns

Everything is encoded in 16bit yuv ffv1, i.e. lossless.
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)

[XMonarchY]

madshi, thank you for the input!

I was wondering about another thing - ArgyllCMS (and other LUT generators) calibration and 3DLUTs often create mild to moderate grayscale ramp banding, which can be helped using "Reduce banding artifacts" feature. In my case, after playing Grayscale Ramp.mp4 pattern, I had to use high/high setting to completely get rid of banding. However, the rule of thumb AFAIK is to use that feature only on SD and low quality HD content because that feature can remove important details in high quality HD videos. I am not sure whether AVSHD Grayscale Ramp.mp4 is considered to be a high or a low quality video... How can I test to see whether the artifact removal feature on high/high settings is doing more good than harming the image by removing detail? It makes the Grayscale Ramp.mp4 look very nice and smooth, but may do more bad in other video content...

Is error diffusion supposed to help to reduce these banding artifacts? So far #2 of the latest testbuild package is not helping this issue, but #4 does help with banding quite a bit! Maybe there is no clear winner here because it depends on - presence of grayscale ramp banding from LUT/3DLUT/calibration, display type (noisy plasma, clean LCD), and the actual content. If you were to release an official update where #2, for example, is the default madVR.ax and current testbuild files are incompatible - it would suck for people like me, but may please others... In that case testbuild madVR.ax files could be updated to stay compatible with future versions and be offered as separate downloads to accommodate individual needs/preferences.

[madshi]

I was wondering about another thing - ArgyllCMS (and other LUT generators) calibration and 3DLUTs often create mild to moderate grayscale ramp banding, which can be helped using "Reduce banding artifacts" feature. In my case, after playing Grayscale Ramp.mp4 pattern, I had to use high/high setting to completely get rid of banding. However, the rule of thumb AFAIK is to use that feature only on SD and low quality HD content because that feature can remove important details in high quality HD videos. I am not sure whether AVSHD Grayscale Ramp.mp4 is considered to be a high or a low quality video... How can I test to see whether the artifact removal feature on high/high settings is doing more than harming the image by removing detail? It makes the Grayscale Ramp.mp4 look very nice and smooth, but may do more bad in other video content...

BTW, is error diffusion supposed to help to reduce these banding artifacts? So far #2 of the latest testbuild package is not helping this issue... I should try others and report.
First of all, debanding is performed *before* 3dlut processing. So debanding cannot fix what a 3dlut might break. However, debanding can improve banding problems in the source. I would not recommend to use anything other than "low/medium" for the default debanding settings. For bad sources you can choose a higher value, but for good quality sources "low/medium" should be the max you should use. Of course that's only my personal opinion, and other users may disagree.

Error Diffusion and random dithering are not supposed to fix source banding problems.

Assuming that:
Low Noise = 2, 4, 8
Med Noise = 1, 3, 5
High Noise = 6, 7

Then my preference would be #3 for medium noise. ("best" to me highlighted in red)

This is mostly from looking at test patterns near black and shadow details rather than 1-bit gradients etc.
I definitely prefer the "low noise" group to the med/high noise groups.

I'm not sure that 6/7 are working correctly on my system when 3DLUTs are enabled though. They're very noisy, and much darker than the other test builds near black.
The even ones are supposed to be low noise, the odd ones medium noise.

No gamma or 3dlut processing or any else of any kind, and 0-255 output.

I'm getting the same brightness levels on the grey bars using the black clipping testpattern on another partion with a fresh install of windows and madvr and the same levels on the grey bars using VLC!

So i dont think the problem is on my side. And if it is, i would like to know what is wrong!
Don't know how the difference can be explained, but in the end I think it doesn't matter too much. I had smooth motion FRC on and downscaled the image to fit to my screen resolution (1680x1050). Maybe that explains the differences - although neither of this should really change the gray levels. Anyway, it doesn't really matter much. The dithering should work with all kinds of gray levels well. So maybe it's good for testing that you seem to get slightly different results to me. So let's pick the algorithm which looks best, when looking at both your and my test images. Agreed?

BTW this is how EVR custom pres with full FP processing (http://s18.postimg.org/62si2elt5/EVR.png) looks like.
I'm confused. Your image clearly shows error diffusion. Since when does EVR custom with full FP processing apply error diffusion??

For clarity I'll give the version that doesn't use gamma correction or serpentine scanning, I hope this will give you enough information to implement it. The following pseudo-code is adapted from the one on the Floyd-Steinberg wikipedia page.


for each y from top to bottom
for each x from left to right
oldpixel := pixel[x][y]
newpixel := find_closest_palette_color(oldpixel)
pixel[x][y] := newpixel
quant_error := oldpixel - newpixel
if random() > 0.2 then
pixel[x+1][y ] := pixel[x+1][y ] + 7/16 * quant_error
pixel[x-1][y+1] := pixel[x-1][y+1] + 3/16 * quant_error
pixel[x ][y+1] := pixel[x ][y+1] + 5/16 * quant_error
pixel[x-2][y+1] := pixel[x-2][y+1] + 1/16 * quant_error
else
pixel[x+1][y ] := pixel[x+1][y ] + 0.7770 * quant_error
pixel[x-1][y+1] := pixel[x-1][y+1] + 0.0090 * quant_error
pixel[x ][y+1] := pixel[x ][y+1] + 0.4861 * quant_error
pixel[x+1][y+1] := pixel[x+1][y+1] - 0.3098 * quant_error


Beware that the first set of weights changes pixel[x-2][y+1] not pixel[x+1][y+1]. The second set of weights should be the same as the one you used in test build 3.
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?

[bacondither]

AVS HD - Black Clipping - untouched AVCHD (http://imgur.com/yRjWV0L) and MP4 (http://imgur.com/kKytz5g) (madVR ED dithering enabled, done with build2)
AVS HD - Black Clipping - untouched AVCHD (http://imgur.com/QN9oMsr) and MP4 (http://imgur.com/Apxum8b) (madVR dithering disabled)

I enhanced your images the same as i did with my other dither test images.(Clipping the histrogram at level 15) and i cropped madshis images from build2.

iSunrise and i have the same levels and almost the same dither pattern which could be explained by scaling or some other factor.
My white outlines around the boxes are caused by lanczos3 antiringing scaling.

iSunrise build number 2 (http://i.imgur.com/y3J2DG2.png)

bacondither build number 2 (http://i.imgur.com/udqxyOq.png)

madshi build number 2 (http://i.imgur.com/fyLRbOl.png)

madshi your dither pattern looks strange compared to ours!