madVR - high quality video renderer (GPU assisted)

[madshi]

Ok, maybe you can tell me which builds you found to be poor via PM, if you don't want to officially vote? I'd like to know. I do plan to go with the majority vote. But I fear not many people are going to vote, so it might be a hard decision.

[noee]

...But I fear not many people are going to vote, so it might be a hard decision.

For someone like me, with performance right at the edge and with older IPS tech, using only real-world material, it's not only time-consuming, but very difficult to see. Frankly, at my normal viewing distance (~8ft to a 37" panel), I can quite clearly make out a difference when falling back to Random, but the differences between these builds (nl1-nl8) is really hard to discern.

It might be easier to "vote" for the ones that aren't as "striking" rather than to pick a "best".

[madshi]

Sure, any kind "vote" is welcome. You can say something like "I like builds x, y and z" or "I didn't like builds a, b and c". Personally, I can't see a difference between these builds, unless I contrast boost and even then I'm not sure which one is best. But some of the votes so far have been consistent enough to show that they not just random votes. So I do believe some users are able to see a difference.

[drew_afx]

Looks like I've been setting up my display wrong the entire time...
setting native display bitdepth to 6bit in madvr results in cleaner gradient (less banding artifacts) than setting it to 8bit!
e-ips is 6bit native yet I thought the monitor would handle 8 bit madvr output with its own dithering method :(

[Anime Viewer]

Hmmmm... Did you test the other NL builds, too, or just NL6? How about e.g. NL1?




I hadn't tried nl1. I had only tried nl6 since there was talk about it popping quite a bit, and I wanted to see if I noticed any additional seperation (either foreground or background) compared to what I remember seeing in video played through MPC-HC with MadVR. I tested nl1, and it seemed to look pretty good too. I have to work in ~1 hour, but when I get off work and return in ~7-8 hours I can do further testing of different builds and their relation to 3d effect. If there is certain ones you want me to test from that perspective let me know.

[Ver Greeneyes]

setting native display bitdepth to 6bit in madvr results in cleaner gradient (less banding artifacts) than setting it to 8bit!
I believe using a setting other than 8-bit also disables error diffusion (you'll get random dithering instead), so that's something to keep in mind. It would be nice if ED worked for 6-bit as well considering that should benefit even more.. I can't remember if madshi has said whether it would be feasible to offer 6-bit and 7-bit versions of ED.

[drew_afx]

I believe using a setting other than 8-bit also disables error diffusion (you'll get random dithering instead), so that's something to keep in mind. It would be nice if ED worked for 6-bit as well considering that should benefit even more.. I can't remember if madshi has said whether it would be feasible to offer 6-bit and 7-bit versions of ED.

Nope I tested with "random dithering" checked, 6bit definitely seem much smoother than 7bit or 8bit settings.
It's that banding artifact which is much more noticeable than error diffusion dithering artifact.
Even with "no dithering" checked I can spot more banding artifact in 8bit than 6bit

[madshi]

I hadn't tried nl1. I had only tried nl6 since there was talk about it popping quite a bit, and I wanted to see if I noticed any additional seperation (either foreground or background) compared to what I remember seeing in video played through MPC-HC with MadVR. I tested nl1, and it seemed to look pretty good too. I have to work in ~1 hour, but when I get off work and return in ~7-8 hours I can do further testing of different builds and their relation to 3d effect. If there is certain ones you want me to test from that perspective let me know.
It would be nice if you could try all the builds. If you can't see a difference, that's fine. Maybe some builds stand out positively or negatively. Or maybe not. Just let me know what your eyes tell you. Thanks.

[Matching_Mole]

Yesterday evening, I watched an upscaled DVD to 720p48hz (old projector) using Jinc 3 AR either for Luma and Chroma.

NL6 made video noise really stronger and so less pleasant that DC3 ED version that I used previously. However NL1 was far much better than DC3 (and so NL6) because the video noise was not increased but the picture looked sharper. So I vote personally for NL1 at least in case of DVD upscale.

I will check this result using a blu-ray.

[6233638]

I'm finding it more interesting this time to just observe, and see which build people naturally lean towards.I'd rather you did post which build from each type was your favorite.

Not that there is anything wrong with it, but most people seem to be picking with their gut rather than doing the extensive testing and comparisons that you have done so far.

This is the approach I would have taken (see all my previous posts on scaling algorithms etc.) but analyzing the dither patterns just isn't my thing really, and I've not had the time spare to do proper testing lately.

[clsid]

What does madVR do when the "movie resolution" is close to the "target resolution", e.g. 1916 x 1076 and 1920 x 1080, due to cropping ?

Does it still do luma upscaling as if it were a big change like 720p to 1080p ?

Is there a way to have it not bother, i.e. just output black bars for the 4 pixels ?I think this is a valid suggestion.

madVR should of course still respect the size requested by the player. Doing padding instead of resizing could be beneficial for quality (and performance). It could be a "Trade quality for performance" option to do padding when size difference is <16 pixels in both dimensions.

[DarkSpace]

madVR should of course still respect the size requested by the player. Doing padding instead of resizing could be beneficial for quality (and performance). It could be a "Trade quality for performance" option to do padding when size difference is <16 pixels in both dimensions.
What if you want to zoom into the picture by a bit (e.g. pressing NUMPAD-6 in MPC-HC) and that happens to fall into these 16 pixels? I foresee complications...

[madshi]

setting native display bitdepth to 6bit in madvr results in cleaner gradient (less banding artifacts) than setting it to 8bit!
e-ips is 6bit native yet I thought the monitor would handle 8 bit madvr output with its own dithering method :(
I think the same may happen some time in the future (probably not soon) when madVR gets native 10bit output: With some displays it will look worse than letting madVR dither down to 8bit. So basically every user will have to test which produces the better overall quality.

Yesterday evening, I watched an upscaled DVD to 720p48hz (old projector) using Jinc 3 AR either for Luma and Chroma.

NL6 made video noise really stronger and so less pleasant that DC3 ED version that I used previously. However NL1 was far much better than DC3 (and so NL6) because the video noise was not increased but the picture looked sharper. So I vote personally for NL1 at least in case of DVD upscale.

I will check this result using a blu-ray.
Thanks, appreciated.

I think this is a valid suggestion.

madVR should of course still respect the size requested by the player. Doing padding instead of resizing could be beneficial for quality (and performance). It could be a "Trade quality for performance" option to do padding when size difference is <16 pixels in both dimensions.
I haven't said this yet, but I did already plan to support something like this in a future version, together with some other related changes.

I've not had the time spare to do proper testing lately.
Would still like to hear your feedback. If you don't have time to test all the builds, at least I'd love to hear your opinion about how nl1 and nl6 compare, because those are the 2 builds mentioned most often by other users.

[clsid]

What if you want to zoom into the picture by a bit (e.g. pressing NUMPAD-6 in MPC-HC) and that happens to fall into these 16 pixels? I foresee complications...It will work just fine. The size of the video surface will be exactly the same, it is just filled differently.

I haven't said this yet, but I did already plan to support something like this in a future version, together with some other related changes.Cool.

[trip_let]

Looks like I've been setting up my display wrong the entire time...
setting native display bitdepth to 6bit in madvr results in cleaner gradient (less banding artifacts) than setting it to 8bit!
e-ips is 6bit native yet I thought the monitor would handle 8 bit madvr output with its own dithering method :(

Looks like if you set 6 bits, madVR dithers down to 6 bits, which should make gradients better at the expense of definitely noticeable extra noise. Just because banding is lower doesn't mean overall quality is better.

Maybe setting 7 bits is a good compromise? In any case, it might be worth a try as well for those on 6 bits + AFRC displays. At least, try all the options.

edit: I tried it and setting 6 bits and 7 bits looks worse at least on the display I used. There's just too much difference between the pixels. Maybe the more appropriate solution would be dithering with even higher noise, allowing values like 10.4 -> 12 sometimes? I don't know if that's of much interest in general.

[Shiandow]

I believe using a setting other than 8-bit also disables error diffusion (you'll get random dithering instead), so that's something to keep in mind. It would be nice if ED worked for 6-bit as well considering that should benefit even more.. I can't remember if madshi has said whether it would be feasible to offer 6-bit and 7-bit versions of ED.

FWIW since it is now impossible for error diffusion to round something like 127.81 to 129 it should be possible to achieve this by simply dividing all pixel values by 2 or 4. As far as I know error diffusion uses pure power gamma correction which would mean that relative distances are still correct.

Edit: After thinking about it you may need to divide by a value slightly larger than 2 or 4 to completely prevent 'out of range' values like 128 or 64 but it should still be quite easy to do error diffusion for 6 and 7 bits.

[MistahBonzai]

...NL6 made video noise really stronger and so less pleasant that DC3 ED version that I used previously. However NL1 was far much better than DC3 (and so NL6) because the video noise was not increased but the picture looked sharper...

I had settled on NL6 while viewing a HBR monochrome 720p video shot with a "RED M". steven_sebring_-_emily_-__for_wolf_magazine_1280x720.mov (https://vimeo.com/51795418)

All AVIsynth off. MadVR at default settings except Chrome Upscaling=Jinc 3 tap, Image Upscaling=Jinc 3 tap.

Play video full screen (with NL1 and NL6) and navigate to frame 1420 of each. Full screen capture (Alt+Printscreen). Open in editor, 200% zoom and cropped the upper left corners (1920-1440, 0-405). Performed this twice to insure conformity of process.

What I discovered was that NL6 is noticeably sharper while NL1 provides 'smoother' dithering. See attachments (hopefully). edit: Darn..second capture runs 225KB. Using smaller crop.

nl1a-frame1420 (https://www.mediafire.com/?fawq82b1t6hiffo)
nl6a-frame1420 (https://www.mediafire.com/?fawq82b1t6hiffo)

[iSunrise]

@MistahBonzai
Just FYI, attaching something to this forum does take a really long time to get approval, so even the people in say usually recommend to use an external image host.

[madshi]

FWIW since it is now impossible for error diffusion to round something like 127.81 to 129 it should be possible to achieve this by simply dividing all pixel values by 2 or 4. As far as I know error diffusion uses pure power gamma correction which would mean that relative distances are still correct.

Edit: After thinking about it you may need to divide by a value slightly larger than 2 or 4 to completely prevent 'out of range' values like 128 or 64 but it should still be quite easy to do error diffusion for 6 and 7 bits.
The problem is that with 6bit or 7bit panels I'm not sure where the exact "border" is when a pixel is displayed as different. E.g. for 6bit should I output 8bit values 0, 4, 8? Or should I output 2, 6, 10? And is this identical over the whole gamma range? I'm not really sure about all this, that's why I'm currently simply using random dithering instead of error diffusion if the user selects 6bit or 7bit.

I had settled on NL6 while viewing a HBR monochrome 720p video shot with a "RED M". steven_sebring_-_emily_-__for_wolf_magazine_1280x720.mov (https://vimeo.com/51795418)

All AVIsynth off. MadVR at default settings except Chrome Upscaling=Jinc 3 tap, Image Upscaling=Jinc 3 tap.

Play video full screen (with NL1 and NL6) and navigate to frame 1420 of each. Full screen capture (Alt+Printscreen). Open in editor, 200% zoom and cropped the upper left corners (1920-1440, 0-405). Performed this twice to insure conformity of process.

What I discovered was that NL6 is noticeably sharper while NL1 provides 'smoother' dithering. See attachments (hopefully). edit: Darn..second capture runs 225KB. Using smaller crop.
Hmmm... Did you try the other test builds, too? Or just NL1 and NL6? Thanks...

[MistahBonzai]

Hmmm... Did you try the other test builds, too? Or just NL1 and NL6? Thanks...

Commencing to do so.. :D

[kstuart]

As always, all input is appreciated.


As the other users have already said, madVR does what the media player tells it to do. madVR reports to the media player which resolution the video has and the media player tell madVR which target resolution to use.

It would be helpful if someone (not a developer, since they have better uses of their time) creates a flow chart of exactly which piece of software and hardware asks for which piece of information.

(I certainly understand that it is a kludge based on what giant corporations have decided they are willing to do.)

Between the monitor, the GPU, the GPU driver, GPU software package, other Windows drivers & APIs, media player, video filters, audio filters, video renderer, you really need a pre-existing "scorecard" to know what asks for what (and that is without extra complications like Reclock).

If a 1280x720 video is upscaled to 1920x1080 then your media player is *NOT* set to 100% zoom. With 100% zoom 1280x720 video would play letterboxed in 1280x720 resolution in the middle of your 1920x1080 screen.

Actually, if I play a 1280x720 video and then click on the "100%" setting, it does just that.
It turns out that Jriver has a bug whereby it displays a checkmark next to "100%" when "Fit Window" is also checked, so a casual glance indicates that the former is in effect, when it is actually the latter.
But, actually, I don't want to manually set it to "100%" only for these corner cases, so it is a moot point. (In fact, manually checking each file with MediaInfo before playing, and then manually changing settings during playback, is contrary to the whole point of profiles - and software in general - which is to automate complex tasks.)

Doing padding instead of resizing could be beneficial for quality (and performance). It could be a "Trade quality for performance" option to do padding when size difference is <16 pixels in both dimensions.

I haven't said this yet, but I did already plan to support something like this in a future version, together with some other related changes.
That would be appreciated, and I can use my workaround in the meantime.

[bacondither]

I used the 16-bit "gradient-perceptual.mkv" at the specific frame of "59, 29.970" and clipped the histogram at 4.
A random dither and a non dither version is included as comparison.

nl? testbuilds (http://www.sendspace.com/file/ngvu1x)

The blurred version is blurred by paint.net, gaussian blur, radius 2.

nl? testbuilds blurred (http://www.sendspace.com/file/37462f)

I vote for NL6.

[huhn]

It would be helpful if someone (not a developer, since they have better uses of their time) creates a flow chart of exactly which piece of software and hardware asks for which piece of information.

think like this change with decoder not all decoder giving all informations and dxva runs on gpu like other decoder. render types overlay fullscreen exclusive, adding deinterlacing change a lot too. thinigs change with content codecs and a lot more... and this is a very very short list.

just take things as they are or you have to read a lot...

[Shiandow]

The problem is that with 6bit or 7bit panels I'm not sure where the exact "border" is when a pixel is displayed as different. E.g. for 6bit should I output 8bit values 0, 4, 8? Or should I output 2, 6, 10? And is this identical over the whole gamma range? I'm not really sure about all this, that's why I'm currently simply using random dithering instead of error diffusion if the user selects 6bit or 7bit.

Intuitively you'd think that at the very least 0 should still correspond to black and just use increments of 4, which suggests that MadVR should output values of 0,4,8 over the whole gamma range. But I can't figure out how it would then handle values above 252. In the worst case each channel has a separate list of possible levels and these differ per manufacturer.

I think it's worth a try to see if dividing all values by 4, performing error dithering, and then multiplying all values by 4, improves the image for people with 6-bit panels.

[DarkSpace]

I used the 16-bit "gradient-perceptual.mkv" at the specific frame of "59, 29.970" and clipped the histogram at 4.
A random dither and a non dither version is included as comparison.

nl? testbuilds (http://www.sendspace.com/file/ngvu1x)

The blurred version is blurred by paint.net, gaussian blur, radius 2.

nl? testbuilds blurred (http://www.sendspace.com/file/37462f)

I vote for NL6.
I did some tests today, but those tests were far from extensive. As such I was a bit hesitant about giving my vote (my screen isn't calibrated and such either), but thanks to your more extensive tests, I now believe it is justified if I also vote for NL6 as the medium-noise algorithm. Thank you!

P.S. Just to clarify: Before, I would also have chosen NL6, I just wasn't too certain if it was objective enough.

[leeperry]

Now the big question is whether madshi could work his magic once again and improve on NL6 to infinity...and beyond!

I'm getting kinda hooked to my pretty much daily "free lunch" drastic PQ improvement http://forum-images.hardware.fr/images/perso/vhalairy.gif

[Shiandow]

By the way I was wondering, in the random number generator:


float random(inout uint randomHelper)
{
randomHelper = 18000 * (randomHelper & 0xffff) + (randomHelper >> 16);
return ((float) (randomHelper & 0xffff)) / 65535.0f;
}


Shouldn't you divide by 65536.0f instead of 65535.0f? I don't think it will change the outcome much but dividing by 65536.0f doesn't cause rounding errors and as far as I know the convention is to generate random numbers strictly less than 1.

The random number generator I wrote has the same 'bug' by the way, I divided by 2147450880.0f (0x7fff8000) which should be 2147483648.0f (0x80000000).

[The 8472]

Intuitively you'd think that at the very least 0 should still correspond to black and just use increments of 4, which suggests that MadVR should output values of 0,4,8 over the whole gamma range. But I can't figure out how it would then handle values above 252. In the worst case each channel has a separate list of possible levels and these differ per manufacturer.

I think it's worth a try to see if dividing all values by 4, performing error dithering, and then multiplying all values by 4, improves the image for people with 6-bit panels.

I think the only correct answer is to measure it. Worst case is that they always FRC on all colors, no matter which you pick.

[kstuart]

* added IMadVRSettings2 interface to enumerate settings and manage profiles
* settings can now be edited without madVR running (only on local PC)

Any more information on how to do this (edit of settings) ? Edit of madVR settings on Jriver in exclusive mode is a bit of a pain.

Thanks !

[MistahBonzai]

I had settled on NL6 while viewing a HBR monochrome 720p video shot with a "RED M". steven_sebring_-_emily_-__for_wolf_magazine_1280x720.mov (https://vimeo.com/51795418)

All AVIsynth off. MadVR at default settings except Chrome Upscaling=Jinc 3 tap, Image Upscaling=Jinc 3 tap.

Play video full screen (with NL1 and NL6) and navigate to frame 1420 of each. Full screen capture (Alt+Printscreen). Open in editor, 200% zoom and cropped the upper left corners (1920-1440, 0-405). Performed this twice to insure conformity of process.

What I discovered was that NL6 is noticeably sharper while NL1 provides 'smoother' dithering. See attachments (hopefully). edit: Darn..second capture runs 225KB. Using smaller crop.

nl1a-frame1420 (https://www.mediafire.com/?fawq82b1t6hiffo)
nl6a-frame1420 (https://www.mediafire.com/?fawq82b1t6hiffo)

I'm very sorry to have posted invalid test results. Please disregard the comparison between NL1a and NL6a. No idea what I did but the results after testing NL1 through NL8 didn't agree with that of the previous tests.

The odd thing was that I performed the tests twice - once cropping a 480*405 of each of the 2 and again with 282*405 and both exhibited the same size and sharpness differences.

What appears to have happened is that avisynth in ffdshow raw was activated. but I can't believe it did so 2x during the tests.

After performing the retest I discovered that avisynth was active..so I suspect all the retest was done with avisynth active. However I see the file sizes (and appearances) are a far better match than the 1st 2 images (NL1a and NL6a).

Once again my sincere apologize.

[noee]

Any more information on how to do this (edit of settings) ? Edit of madVR settings on Jriver in exclusive mode is a bit of a pain.

Thanks !

Are you wanting to do so with code? I have a semi-complete C# def for the interfaces, sort of up-to-date.

@madshi:

720p24/1080p24 test material. Not 8, 7 or 3. My eagle-eye progeny says 6, 1, 4. On the 720p24 material, 6 wins. On 1080p material 1 or 6.

[kstuart]

Are you saying that the new settings editing feature in V0.87.0 is just a software hook (like an API) ? So, at the moment, you still have to run a player and pause it to edit madVR settings ?

[6233638]

Would still like to hear your feedback. If you don't have time to test all the builds, at least I'd love to hear your opinion about how nl1 and nl6 compare, because those are the 2 builds mentioned most often by other users.OK, I got some testing done tonight, and for me, NL4 and NL5 are the ones which stand out.

NL4 seems to have slightly better defined edges than NL5, but from other tests, the ones with better defined edges seem to be more likely to introduce patterns, so perhaps NL5 would be a better choice?


I seem to recall you mentioning a grain filter being a possibility in the future, which might be useful - some of the patterns I was using would show banding in all the builds, even when using debanding. In those cases, random dither helped mask it at the cost of having higher noise.

[noee]

Are you saying that the new settings editing feature in V0.87.0 is just a software hook (like an API) ? So, at the moment, you still have to run a player and pause it to edit madVR settings ?

Sorry, yeah, this is probably what you're looking for:


"C:\Program Files (x86)\madVR\madHcCtrl.exe editLocalSettingsDontWait"

[madshi]

I used the 16-bit "gradient-perceptual.mkv" at the specific frame of "59, 29.970" and clipped the histogram at 4.
A random dither and a non dither version is included as comparison.

nl? testbuilds (http://www.sendspace.com/file/ngvu1x)

The blurred version is blurred by paint.net, gaussian blur, radius 2.

nl? testbuilds blurred (http://www.sendspace.com/file/37462f)

I vote for NL6.
Thanks! Hmmmm... Looking at your screenshots it seems that NL4 and NL8 reach down to the darkest gray, while all other builds stop earlier. However, I guess dither dots which are so far away from each other are not very helpful, so probably that's not really important.

Intuitively you'd think that at the very least 0 should still correspond to black and just use increments of 4, which suggests that MadVR should output values of 0,4,8 over the whole gamma range. But I can't figure out how it would then handle values above 252. In the worst case each channel has a separate list of possible levels and these differ per manufacturer.

I think it's worth a try to see if dividing all values by 4, performing error dithering, and then multiplying all values by 4, improves the image for people with 6-bit panels.
I think the only correct answer is to measure it. Worst case is that they always FRC on all colors, no matter which you pick.
I guess I could make a couple of test builds (oh no) for people with 6bit panels and then we can simply try which way works best. However, I wonder if it's the same for every display.

I did some tests today, but those tests were far from extensive. As such I was a bit hesitant about giving my vote (my screen isn't calibrated and such either), but thanks to your more extensive tests, I now believe it is justified if I also vote for NL6 as the medium-noise algorithm. Thank you!

P.S. Just to clarify: Before, I would also have chosen NL6, I just wasn't too certain if it was objective enough.
Thanks!

Shouldn't you divide by 65536.0f instead of 65535.0f? I don't think it will change the outcome much but dividing by 65536.0f doesn't cause rounding errors and as far as I know the convention is to generate random numbers strictly less than 1.
I'm using a factor of 0.625 when adding the random value to the pixel value before rounding. Dividing by 65536.0f instead of 65535.0f would change this factor from 0.625 to 0.62499. I don't think this is something we need to worry about.

Any more information on how to do this (edit of settings) ? Edit of madVR settings on Jriver in exclusive mode is a bit of a pain.
Play a video. Then right click the madVR tray icon. Edit the tray icon settings. Select "always show tray icon". Now the madVR tray icon will always be visible and you can always use it to modify madVR settings, even when no video is running.

I'm very sorry to have posted invalid test results. Please disregard the comparison between NL1a and NL6a. No idea what I did but the results after testing NL1 through NL8 didn't agree with that of the previous tests.
No problem at all. So do you have a new favorite now after redoing the tests?

720p24/1080p24 test material. Not 8, 7 or 3. My eagle-eye progeny says 6, 1, 4. On the 720p24 material, 6 wins. On 1080p material 1 or 6.
OK, I got some testing done tonight, and for me, NL4 and NL5 are the ones which stand out.

NL4 seems to have slightly better defined edges than NL5, but from other tests, the ones with better defined edges seem to be more likely to introduce patterns, so perhaps NL5 would be a better choice?
Thanks, guys!

[kstuart]

Play a video. Then right click the madVR tray icon. Edit the tray icon settings. Select "always show tray icon". Now the madVR tray icon will always be visible and you can always use it to modify madVR settings, even when no video is running.

Aha ! Really helpful, thanks !

Okay, a small request - and one which nevcairiel also thought would be helpful:

Please - if at all possible - add to the madVR tray icon menu:

Toggle Stats

The reason is that (at least with Jriver MediaCenter), there are a lot of things that interfere with reception of keyboard shortcuts. For example, in my case, I have to pause a video, right-click, select Standard View, change focus to something else (like Windows Explorer) and THEN Ctrl-J works.

Other people have the experience that Ctrl-J only works for them if the madVR settings dialog has focus.

Either way, being able to toggle stats OSD with the tray icon would be a big help, especially if it can also be done with the media player stopped.

Thanks !

[XMonarchY]

I understand. And it seems I didn't understand that you mentioned it to discourage people from this line of thought, I thought you were just stating a fact... :o


I don't know, but from what you've said, it seems like you're using the 3 1D LUTs that regular Windows Color Management loads into the GPU and then use the 3D LUT on top of that. I may be wrong here, though, but if that's what you're doing, you should try out the "disable GPU gamma ramps" option in devices -> (your display) -> calibration.

What difference would that make? I apply 1D LUT on top of 3D LUT because that 3D LUT does not contain any grayscale calibration. I do for a specific reason - I can switch 1D LUTs on the fly to test different gamma curves. Since madVR does not apply any de-banding to 3D LUTs, then having that 1D LUT being integrated into 3D LUT would not create a difference. I hope I am wrong... I'll test it out right now!

[cyberbeing]

Latest votes are somewhat interesting, since my testing tells me 1 & 8, 2 & 7, 3 & 5, 4 & 6 are the pairs which are closest related to each other. I'd be curious which variable is responsible for that once the testing is over.

[GREG1292]

N3 and NL2 are close cousins but NL6 blows them both out of the water, the former are like watching through a window but the latter is opening the darn window and getting your head out http://forum-images.hardware.fr/images/perso/ayuluna.gif

It's even more striking on 720p60 content than 1080p24, yay!

Good call I like this one as well:goodpost:

[n3w813]

My vote is for NL6
I only watch real world shows and movies. NL6 provides the most realistic picture (IMO). :)

[Xaurus]

Another vote for NL6.

[XMonarchY]

OK, this is utter BS but I am getting PMs asking me to vote for NL6. Is NL6 = ED7? I don't want to be a rat but WTF? I did not like ED7 and builds with much noise - beats the purpose.

How many of the people who voted for NL6 actually wanted to vote for it or even tested it? At this point I am just keeping the latest "noise-less" build with that random dithering that was released before the blind-test package. It was AFAIK the original DC3, which then was improved ED2/4, then improved ED9/10, and then whatever it was before the blind-test package.

I can only hope that the version with least noise (the one preferred by madshi AFAIK) will included in the final release or at LEAST be supported as a side-thing... But I am not playing this rigged game. I will probably be hated and called a rat for saying this, but whatever... plenty of NL6 votes without my contribution.

[6233638]

Latest votes are somewhat interesting, since my testing tells me 1 & 8, 2 & 7, 3 & 5, 4 & 6 are the pairs which are closest related to each other. I'd be curious which variable is responsible for that once the testing is over.Interesting. That might explain why there are so many votes for 6, and yet I like 4 - similar, but not the same.
4 did seem better than 6 in my testing though.
Some of the test builds were easily eliminated, and of the remaining ones, 4 seemed to keep the cleanest edges and most defined details right near black, with 5 being a close second.

Edit: Revisiting my tests, I still think it's between nl4 and nl5.
5 has more sparse dithering which means that edges are less defined, but gradients would potentially be smoother.
4 seemed to have the best defined edges of any of the builds (thus has the sharpest appearance) but that property may mean banding in the source is slightly more visible. (less random?)

[cyberbeing]

OK, this is utter BS but I am getting PMs asking me to vote for NL6. Is NL6 = ED7? I don't want to be a rat but WTF? I did not like ED7 and builds with much noise - beats the purpose.

lol, bad leeperry. :devil:

Here's a new improved version of the "noisy 2" algorithm with the following changes:

(1) random seed bug fixed
(2) went back to old random generator
(3) improved 16x16 boundary behaviour
(4) added limiter to avoid out-of-range stray dots

http://madshi.net/madVRnoisyLimited.rarYey! I like the latest "Noisy 2" ! I find it better than the old DC3, old ED2, and old ED4. I do see just a small amount of black dithering, but its acceptable.

I still dislike ED7 though...

If your opinion hasn't changed about this, that could count as your vote. madshi knows which build of latest nl builds is equivalent to that one.

[MistahBonzai]

NL6 is is then. After repeatedly scanning through the test builds posted by Bacondither it was a toss-up between NL6 and NL1. Nl1 seemed less prone to patterns, especially in the 'fade to black' area and I preferred the tapper in general. However NL6 has a nice 'dither'. To be honest I couldn't tell the difference between then with screen shots of 'normal' video. And believe me I really tried. I'm at a the point where I seriously doubt that various MadVR*.ax files have any effect on my set-up.

I reset MadVR to default and uninstalled it before re-installing 87.4. Then I carefully checked each setting to insure they were at default settings (including "Trade Quality for Performance" with random dither enabled). With that setting at OpenCL error diffusion I had no trouble seeing low-level pixel shift - they danced and shifted like crazy. Of-course I was 'nose to pixel' on my 40" carefully calibrated Bravia - and I used to write video display service procedures so I'm well versed in proper calibration techniques.

The method I used for testing the various MadVR*.ax files was to replace them one at a time renaming each to MadVR.ax before replacing the current MadVR.ax in the top level of the MadVR folder. I know it works because MadVR doesn't start with out a valid copy of that file and ignores others which have names such as MadVR1.ax (even if it is the only variant in the MadVR folder). Even while evaluating .bmp screen captures (and MadVR .bmp image saves) I fail to see any obvious dither shift. The kicker is that all the 480*405 .png crops are the same size (187KB). This was not the case the last time around... It's like I have improperly configured MadVR and it's not using the dither algorithms in the .ax files.

[cyberbeing]

Even while evaluating .bmp screen captures (and MadVR .bmp image saves) I fail to see any obvious dither shift.
FWIW, madVR's screenshot function (Save image...) grabs frames from much earlier in the processing chain, and are dithered from 16bit->8bit via a CPU-based Floyd-Steinberg error diffusion not available elsewhere. I'm sure you and everybody knows this, but in order to capture madVR's GPU-based dithering as seen during playback in a screenshot, you need to use PrtScn from Windowed mode.

@madshi
On that note, do you think you're going to change the routine used for the CPU-based screenshot dither after all this, or just keep it as-is?

The kicker is that all the 480*405 .png crops are the same size (187KB). This was not the case the last time around... It's like I have improperly configured MadVR and it's not using the dither algorithms in the .ax files.

I wouldn't concern yourself much over this, unless all your png crops had 100% identical noise patterns. This is why I always double check to ensure the image actually changed from my previous screenshot before moving onto the next build. Sometimes PrtScn can behave oddly with madVR, and produce an identical or blurry screenshot.

[ryrynz]

lol, bad leeperry. :devil:


http://s11.postimg.org/56be2q2xr/6we0n.jpg (http://postimg.org/image/56be2q2xr/)

[madshi]

Please - if at all possible - add to the madVR tray icon menu:

Toggle Stats

The reason is that (at least with Jriver MediaCenter), there are a lot of things that interfere with reception of keyboard shortcuts. For example, in my case, I have to pause a video, right-click, select Standard View, change focus to something else (like Windows Explorer) and THEN Ctrl-J works.

Other people have the experience that Ctrl-J only works for them if the madVR settings dialog has focus.

Either way, being able to toggle stats OSD with the tray icon would be a big help, especially if it can also be done with the media player stopped.
I don't know. I'm always careful not to add too many things to the settings dialog and tray icon menu. Yes, some people might it useful to toggle the debug OSD there, but for most people the keyboard shortcut works just fine. I think it would make more sense to figure out why the keyboard shortcuts don't seem to work with J.River MC and fix that, instead of cluttering the tray menu with things like this.

FWIW, you can manually edit "HKCU\Software\madshi\madVR\ShowOsd_" to enable/disable the debug OSD while madVR is not running.

What difference would that make? I apply 1D LUT on top of 3D LUT because that 3D LUT does not contain any grayscale calibration. I do for a specific reason - I can switch 1D LUTs on the fly to test different gamma curves. Since madVR does not apply any de-banding to 3D LUTs, then having that 1D LUT being integrated into 3D LUT would not create a difference. I hope I am wrong... I'll test it out right now!
Integrating the 1dlut into the 3dlut means all the math can be done in high bitdepth floating point. madVR will process everything in 16bit+ per component, and dither the final result down to 8bit. ArgyllCMS measures madVR's dithered output to be somewhere between 11-12 bits. If you load the 1dlut into the GPU, the GPU will apply the 1dlut *after* madVR's dithering, and the GPU usually only uses 8bit for the processing, without dithering, when using a digital connection, which can introduce banding artifacts. So for best image quality you should integrate the 1dlut into the 3dlut. Of course doing so means that the GPU must be reset to linear 1dlut while madVR is playing a video.

Good call I like this one as well:goodpost:
My vote is for NL6
I only watch real world shows and movies. NL6 provides the most realistic picture (IMO). :)
Another vote for NL6.
NL6 is is then. After repeatedly scanning through the test builds posted by Bacondither it was a toss-up between NL6 and NL1. Nl1 seemed less prone to patterns, especially in the 'fade to black' area and I preferred the tapper in general. However NL6 has a nice 'dither'.
Thanks, guys!

OK, this is utter BS but I am getting PMs asking me to vote for NL6.
:( That is not good.

That said, I believe there are more than enough people here who think for themselves, so even if the vote is somewhat influenced, I will still listen to the majority vote - and that seems to be NL6.

Is NL6 = ED7? I don't want to be a rat but WTF? I did not like ED7 and builds with much noise - beats the purpose.

How many of the people who voted for NL6 actually wanted to vote for it or even tested it? At this point I am just keeping the latest "noise-less" build with that random dithering that was released before the blind-test package. It was AFAIK the original DC3, which then was improved ED2/4, then improved ED9/10, and then whatever it was before the blind-test package.
I was concentrating on the medium-noise algorithm for now. And it seems we've decided on that algorithm now. So the next thing will be to look again at the low-noise algorithm (ED9/10 etc) and maybe improve it a bit further, too.

lol, bad leeperry. :devil:http://s11.postimg.org/56be2q2xr/6we0n.jpg (http://postimg.org/image/56be2q2xr/)
You guys are funny... :D

Interesting. That might explain why there are so many votes for 6, and yet I like 4 - similar, but not the same.
4 did seem better than 6 in my testing though.
Some of the test builds were easily eliminated, and of the remaining ones, 4 seemed to keep the cleanest edges and most defined details right near black, with 5 being a close second.
Argh, that makes it harder for me. But thanks for taking the time to test this! Ok, both cyberbeing and you like 5 a lot, while your alternative/second choices don't match at all. It seems both of you consider 6 acceptable, though, and most other votes prefer 6, so I guess 6 is what it'll have to be. I can't ignore the clear majority vote.

So here comes the explanation of which releases did what:

ED5: floyd-stein, weight sum 1.00, old random generator
ED7: filter lite, weight sum 0.97, old random generator

noisy 1: floyd-stein, weight sum 1.00, new random generator
noisy 2: floyd-stein, weight sum 0.97, new random generator
noisy 3: filter lite, weight sum 0.97, new random generator
noisy 4: filter lite, weight sum 1.00, new random generator

nl1: filter lite, 0.97, old random generator
nl2: floyd-stein, 0.97, new random generator
nl3: floyd-stein, 1.00, old random generator
nl4: filter lite, 1.00, new random generator
nl5: floyd-stein, 0.97, old random generator
nl6: filter lite, 0.97, new random generator
nl7: floyd-stein, 1.00, new random generator
nl8: filter lite, 1.00, old random generator
And the NL builds also contained some algorithm improvements.

[jmac698]

Having a terrible time using MadVR v0.87.4 + mpc-hc 1.7.3x86. Been getting dropped frames, black luma with only color info, and frozen color "shadows" overlayed on live video content, not to mention hard crashes at certain places in the file. No problems occur with vlc.

-under chroma upscaling, as soon as I pick nedi3 and hit apply, a freeze-frame of pure green and purple video is overlayed on top of the live video. Only the live luma is shown under the frozen chroma. GPU-Z reports 83% gpu load, 279MB video memory.
-under image doubling, enabling nnedi3 for luma, shows a black screen with live chroma, mostly dim satured red colors.
-GPU is GF108, sm5
-win7 x64
-I've had several hard crashes, but I can recall the exact circumstances. There seems to be a certain spot that always crashes the player.
-Just a note, plain bicubic looked best to me. I had high hopes for jinc, but there's halos around edges, which are too distracting to me. Only a quick test, this is the first time I've ever had a discrete GPU :)

p.s.
haven't caught up on these dither tests, but have you looked into varying probability density functions? You would implement it by adding 3 separate random numbers, for example, for a very rough gassian. In the audio world it makes a big difference, a trade-off between noise and pulsing. In video terms, it would be between noise and regular pattern artefacts. The triangular density function is somewhat noisy but no artefacts. You can do even better with noise-shaping, that makes more of the noise higher spatial frequency. There's a fast way to do this but, if you have enough pre-computed noise, you don't have to worry about it. Floyd-steinberg is by far the worst dither to use though :(

filtered lite sounds like filtered error diffusion. That's where pdf's come into play.

[madshi]

Having a terrible time using MadVR v0.87.4 + mpc-hc 1.7.3x86. Been getting dropped frames, black luma with only color info, and frozen color "shadows" overlayed on live video content, not to mention hard crashes at certain places in the file. No problems occur with vlc.

-under chroma upscaling, as soon as I pick nedi3 and hit apply, a freeze-frame of pure green and purple video is overlayed on top of the live video. Only the live luma is shown under the frozen chroma. GPU-Z reports 83% gpu load, 279MB video memory.
-under image doubling, enabling nnedi3 for luma, shows a black screen with live chroma, mostly dim satured red colors.
-GPU is GF108, sm5
I suppose you're using latest drivers? If you read the v0.87.4 announcement you'll see that the OpenCL features only work with NVidia GPUs if you downgrade to older drivers because the latest drivers are buggy. Not sure if that explains the crashes, though. In any case, we're waiting for new fixed NVidia drivers to make the OpenCL features work properly.

ust a note, plain bicubic looked best to me. I had high hopes for jinc, but there's halos around edges, which are too distracting to me.
Did you enable the anti-ringing filter? There should be no halos around edges when using Jinc3 with the AR filter enabled.