madVR - high quality video renderer (GPU assisted)

[kstuart]

All feedback is appreciated, btw.

Originally Posted by 6233638

This should be handled by your player. (set it to 100% size)

It is already set to 100% size.

It is in full screen exclusive mode. If the video is 1280x720, then it would upscale it to 1920x1080 using chroma upscaling as you recommend.

So, when the video is 1916x1076, it would do likewise, unless there is some option to turn off scaling in madVR.

HD TVs usually have this, called "1:1 mode".

I'm using Jriver, btw. But I am using the display rate changer in madVR, not Jriver.

(When the source resolution is 1920x1080, then there is no upscaling at all and the GPU load is low. But when the source resolution is 1916x1076, upscaling occurs, but it seems actually a more difficult task for the GPU than upscaling from 720p, as it causes numerous dropped frames.)

[pie1394]

Originally Posted by QBhd

Tonight I decided to set it to "always - if upscaling is needed"... and I must say WOW! My 720p content has never looked better. I did have to tweak chroma upscaling back to 64 neurons, and set image doubling to 64 and 32 (luma and chroma resolutions) with lanczos 4 AR for image downscaling... again trying to push the DirectCU II TOP R9 270x to it's max.

So, is the 1280x720 (4:2:0) content being upscaled first to 1280x720 (4:4:4) with NNEDI3, then secondly to 1280x1440 with NNEDI3 image doubling and then back down to 1024x678 with lanczos??

I think so if madshi's design logic reflects to his wording.

Just curious why you don't use 1360x768 video output mode. A good PDP's video processor can easily handle the horizontal scaling smoothly. My 42" Hitachi PDP is with ALiS 1024x1080i panel. The video's horizontal resolution is actually better for feeding it native 1920x1080i content rather than feeding it the down-scaled 1024x1080i one. Thus I think this TV's video processor does some tricks, too.

About the vertical resolution, 1080i input signal always produces the best quality -- especially for those native 1080i contents.

[cyberbeing]

While I do have a clear preference from these latest madVRnl.rar builds, I think this time I'll abstain from making a vote, unless it's needed to reach a consensus quicker.

I will say that from a purely objective standpoint, nl builds 1,3,5,8 have measurably less distortion and more accurately represent the source compared to 2,4,6,7 which are more aggressive and leave fewer original pixels untouched. This objective observation of course means little for which people prefer on there display setups subjectively.

[kstuart]

... I did come up with a workaround... I had just implemented profiles for luma scaling, so I added:

If (srcHeight = 1076) "1076" else...

and then some experimenting showed that Bicubic 75 AR would work for the 1916x1076 to 1920x1080 luma scaling (just the lower GPU use than Lanczos was enough to prevent dropped frames), so I made a profile that did that called "1076".

But, only the recent addition of profiles made that possible, so thanks for that !

[madshi]

Originally Posted by Anime Viewer

I have an LG tv that can convert 2d to 3d, and it appears with nl6 it may have more 3d enhancement compared to when I originally watched the same 2d->3d converted video using MPC-HC with MadVR back in December.

I'm all for anything that enhances 2d -> 3d given my TV, and if that is NL6 then it gets my vote.

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

Originally Posted by XMonarchY

Is there a chance 3DLUT banding will be remedied some other way? Any one with grayscale calibration will have banding

There's no technical reason for that.

Originally Posted by kstuart

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 ?

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.

Originally Posted by QBhd

So, is the 1280x720 (4:2:0) content being upscaled first to 1280x720 (4:4:4) with NNEDI3, then secondly to 1280x1440 with NNEDI3 image doubling and then back down to 1024x678 with lanczos??

Yes.

Originally Posted by QBhd

Wouldn't it be better to do a quadruple chroma upscaling right from the start when NNEDI3 image doubling is being used?

No, why would it be?

Originally Posted by kstuart

It is already set to 100% size.

It is in full screen exclusive mode. If the video is 1280x720, then it would upscale it to 1920x1080 using chroma upscaling as you recommend.

So, when the video is 1916x1076, it would do likewise, unless there is some option to turn off scaling in madVR.

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.

Originally Posted by cyberbeing

While I do have a clear preference from these latest madVRnl.rar builds, I think this time I'll abstain from making a vote, unless it's needed to reach a consensus quicker.

I will say that from a purely objective standpoint, nl builds 1,3,5,8 have measurably less distortion and more accurately represent the source compared to 2,4,6,7 which are more aggressive and leave fewer original pixels untouched. This objective observation of course means little for which people prefer on there display setups subjectively.

Interesting. FWIW, have you checked the whole video frame, or only a specific sub-area of it? I'm asking because both random generators have visible "chunks", but they're at different places on the video frame.

[Asmodian]

Originally Posted by XMonarchY

Any one with grayscale calibration will have banding and yet 3DLUTs are so important! Banding cannot be fixed by ArgyllCMS or other calibration software so only madVR can do it...

I do not have banding and I have tested your suggested settings in dispcalgui & ArgyllCMS. I use slightly different ones now, it seems displays can vary and there really isn't an optimal setting for all, but your suggestions were a good start and I finally got rid of the slight increase in black level.

I have seen that banding before on my old monitor after using earlier versions of ArgyllCMS or yCMS in madVR but I am happy not to see it now. Maybe you need even more patches during profiling?

[QBhd]

Originally Posted by pie1394

I think so if madshi's design logic reflects to his wording.

Just curious why you don't use 1360x768 video output mode. A good PDP's video processor can easily handle the horizontal scaling smoothly. My 42" Hitachi PDP is with ALiS 1024x1080i panel. The video's horizontal resolution is actually better for feeding it native 1920x1080i content rather than feeding it the down-scaled 1024x1080i one. Thus I think this TV's video processor does some tricks, too.

About the vertical resolution, 1080i input signal always produces the best quality -- especially for those native 1080i contents.

I don't want my panel to do any work. I have played with all kinds of input and all kinds of custom resolutions. I find a 1024x768 @72Hz resolution is the best PQ when viewing 24p sources. The panel still does some work since it's only outputting 4:2:2, but it the best. madVR with ReClock is silky smooth and crystal clear.

@madshi: I only asked since chroma is doubled to get to 4:4:4 and then chroma is again doubled to get to 1280x1440... as I said above... I am not 100% sure how the internals of all this worked that's why I was curious. I have a good grasp of the basics (as confirmation of my first question shows), but the internal details are a bit fuzzy... anyway you don't have to follow up this line of thought. Keep focused on the important stuff. And as always, amazing work!

QB

[DarkSpace]

Originally Posted by madshi

It's not that I *want* to do it there. But frame blending creates new color mixes. So I have to apply the 3dlut after doing frame blending. So the order of processing is: frame blending -> 3dlut. So if you guys ask me to deband after the 3dlut, debanding automatically is moved to after frame blending. I intentionally mentioned this as a reason *NOT* to do debanding after 3dlut processing.

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...

Originally Posted by XMonarchY

Is there a chance 3DLUT banding will be remedied some other way? Any one with grayscale calibration will have banding and yet 3DLUTs are so important! Banding cannot be fixed by ArgyllCMS or other calibration software so only madVR can do it... Maybe some special debanding method after 3DLUT processing or maybe integrate debanding INTO 3DLUT processing?

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.

[Asmodian]

Originally Posted by QBhd

I only asked since chroma is doubled to get to 4:4:4 and then chroma is again doubled to get to 1280x1440... as I said above... I am not 100% sure how the internals of all this worked that's why I was curious.

NNEDI3 doubles in one direction per pass. It cannot do anything else. You can run it in both directions by rotating the video and running it again. 4x is simply running NNEDI3 twice in both X and Y (four NNEDI3 passes).

[cyberbeing]

Originally Posted by madshi

Interesting. FWIW, have you checked the whole video frame, or only a specific sub-area of it? I'm asking because both random generators have visible "chunks", but they're at different places on the video frame.

I checked around detail over the entire frame of a few different sources. The members of first group always behaved one way, and the members of the second group always behaved distinctly in another, even though there was a wide range of actual noise levels within each group. The first group had a higher tendency to dither between and within existing color and luminance detail in a source, with the dithering area matching the proportions of each detail rather exactly. The second group had a higher tendency to dither over and reconstruct color and luminance detail in a source, with the dithering area rarely matching the proportions of the actual source detail being dithered. What I'm talking about here, I guess you could call the pixel structure of the image.

This isn't the whole story though, since subjectively, there were ones which were rather poor in each of these groups. I'm finding it more interesting this time to just observe, and see which build people naturally lean towards. There is really no right or wrong answer here. It really is nothing more than an interesting observation, which says little for how they actually appear visually. That no one yet has voted for my preferred build says as much.

[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]

Originally Posted by madshi

...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]

Originally Posted by madshi

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]

Originally Posted by drew_afx

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]

Originally Posted by Ver Greeneyes

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]

Originally Posted by Anime Viewer

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]

Originally Posted by cyberbeing

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.