madVR - high quality video renderer (GPU assisted)

[leeperry]

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!

[Shiandow]

Yeah, quite interesting. Unfortunately it doesn't work this way for me. My code got more complicated and used more registers. Actually I'm a bit surprised that the performance hit is as small as it is with my code.

Anyway, does the change improve image quality in your tests, too?

The differences in image quality between the various versions are getting a bit too small for me to actually convincingly say which is better. I'm actually having trouble to tell them apart on some of the 'enhanced' images that were posted.

FWIW the new version does cause a 2%~3% increase in total GPU usage. Previously enabling error diffusion increased GPU usage by about 13%~14%, but with the new version this is closer to 16% so in my case the new error diffusion uses about 18% more GPU than the old one. This is on a Nvidia GTX560Ti.

[Ver Greeneyes]

N3 and NL2 are close cousins but NL6 blows both them both out of the waterGlad to see you have a strong preference again :D (I was wondering if the addition of the limiter would bring them closer together)

[leeperry]

Me too, who needs 3D when you got NL6 http://forum-images.hardware.fr/images/perso/3/chewee297.gif

[madshi]

newerror = (f(x) + error) - result;
Shouldn't it be: "newerror = (f(x) + error) - f(result);"?

high noise is random dithering. :p
Exactly!

The differences in image quality between the various versions are getting a bit too small for me to actually convincingly say which is better. I'm actually having trouble to tell them apart on some of the 'enhanced' images that were posted.
Same here. The "limiter" did bring a visible improvement for me, though. At least it reduces/removes stray dots (from gray bars and pure black surfaces etc).

[Shiandow]

Yeah that should indeed be f(result), thanks.

[bacondither]

So many builds... :scared:
I used the 16-bit "gradient-perceptual.mkv" at the specific frame of "59, 29.970" and clipped the histogram at 4.

Just to give a little perspective i tested the "old" DC3 build and the new NoisyLimited. The improvement is doubleplus good!

DirectCompute3 (http://i.imgur.com/bySNc5C.png)
NoisyLimited (http://i.imgur.com/XFJPFgO.png)

I'm perfectly satisfied with the NoisyLimited build but will test the new randomised builds sometime in the weekend.

[madshi]

So many builds... :scared:
Yeah, I know. And these are just the medium-noise builds. I still might offer a lower-noise option. But I'll work on that only after we've decided on the medium-noise builds.

Where can I get that MKV?

[bacondither]

Where can I get that MKV?
Ver Greeneyes posted it earlier, here is is:
gradient-perceptual.mkv (http://www.mediafire.com/?isug2xggj4dey0x)

[Ver Greeneyes]

Where can I get that MKV?It's one I made a couple of days ago, link in my signature :)

By the way madshi, could you try the colored gradient (http://www.mediafire.com/?nbp32easa8p3yr6) with debanding? Looking at the horizontal bars adjacent to black (blue and white), even with debanding set to low I see the bars noticeably bleeding over into black. I'm using NL6 from your latest package, although I don't expect that to matter - if I turn debanding off the 'mist' on the black regions goes away.

[XMonarchY]

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

I still see a lot of 3DLUT banding though - I guess that won't ever be helped...

[6233638]

I still see a lot of 3DLUT banding though - I guess that won't ever be helped...I wonder if an option to apply debanding after the 3DLUT is applied rather than beforehand might be useful for this.

[TheElix]

Harry Potter and the Deathly Hallows Part 1 on Optoma GT760 720p DLP projector (around 10:00). Sitting close to a 84" screen so I see every little detail. +_+
My finalists are: NL1 and NL6 (http://screenshotcomparison.com/comparison/62307). NL1 produces slightly cleaner image here in dynamic. I really can't tell be screenshots. But NL1 screenshot weights more. Does it mean it contains more information? :D

[iSunrise]

I was surprised, too. The key processing loop just consists of a lot of math stuff, like floating point multiplications, exp(), pow() etc instructions. I don't really understand why it's so much slower with DirectCompute(), either. Could be that DirectCompute doesn't understand the way the kernel uses shared memory. Anyway, I've not finished this yet. Maybe I'll find a way to bring this up to speed. But I'm not hopeful atm...
Would it make sense to write to AMD developer support and ask for help, providing them with the critical parts of your code (code snippets?)? Never done this myself, because I am still in the NV camp, but I´ve heard that some developers had success with it and AMD gave them some advices. Not sure if that would also help on NV hardware, though.

But there clearly is something either extremely non-optimized or unnecessarily slow (if you say it´s 10 times slower, that´s a bit too much IMHO) within their DirectCompute compiler vs. OpenCL.

[DarkSpace]

I'm not sure what to say or do about this. madVR tries to use OpenCL, and if it works, it works. If the OpenCL APIs error out, there's not much madVR can do about it.
I see, okay. It would be nice if there was a notice at least in the Debug OSD, though, so one can know without having to specifically test whether or not it fails.

[nevcairiel]

Debanding should probably only act on the source, and should in theory remove all kinds of banding before the 3DLUT is applied. It seems likely that the banding is caused by applying the 3DLUT after rounding the result to 8 bits, this could be solved by applying the 3DLUT before rounding to 8 bits but then you either need a Massive LUT (256 TiB) or you need to interpolate the 3DLUT, which is slow (and sort of defeats the point of using a LookUp Table in the first place).

IIRC, the 3DLUT is 8bit input and 16bit output through interpolation.

[Ver Greeneyes]

or you need to interpolate the 3DLUT, which is slow (and sort of defeats the point of using a LookUp Table in the first place).
Eight lookups and seven calls to lerp() I guess (assuming a HLSL shader)? I wonder how much of a difference it would make visually.

[Shiandow]

I wonder if an option to apply debanding after the 3DLUT is applied rather than beforehand might be useful for this.

I'm sort of confused on how this is done now, doesn't debanding increase the bitdepth of the original image? And if so how would you then use the 3DLUT? You'd either need a 16bit LUT which would be MASSIVE (256 TiB) or you'd need to interpolate the LUT, which sort of defeats the point of using a LookUp Table, or you'd need to round the image down to 8bits again which would make the debanding useless.

[Shiandow]

IIRC, the 3DLUT is 8bit input and 16bit output through interpolation.

Eight lookups and seven calls to lerp() I guess (assuming a HLSL shader)? I wonder how much of a difference it would make visually.

Sorry about that, I realized that I was probably mistaken about how the 3DLUT was used so I deleted that post, seems that I wasn't fast enough. Luckily your answers still make sense in the context of my other post.

[Anime Viewer]

Me too, who need 3D when you got NL6 http://forum-images.hardware.fr/images/perso/3/chewee297.gif

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.

[kstuart]

Originally Posted by kstuart
Lastly, I've found that checking Automatic Deinterlacing in madVR also significantly increases the GPU load (when the source is interlaced). If I uncheck it, then the OSD says it is off, but playback seems normal.

Does this mean AMD Catalyst is doing the deinterlacing ? Or is it passing the task all the way to my HD TV ?
Do you have your GPU configured to output interlaced? Only then your TV could do deinterlacing.


I don't see any place in Catalyst to configure it to output interlaced (or not).

Content is sports video (Sochi Olympics) in 1080i. Automatic deinterlacing is off in madVR settings.

I checked again, and if the madVR refresh rate changing specifications include 1080i59, 1080i60 then the final ms reported in the madVR stats, is about 20% less (and with zero dropped, etc) than the final ms if 1080i59, 1080i60 is removed from the list (and there are a few dropped, delayed, etc).

So, specifying 1080i59 is definitely making some sort of difference which appears to be less GPU use. This would seem to indicate that TV deinterlacing is being used instead of GPU - but I am no expert.

[madshi]

By the way madshi, could you try the colored gradient (http://www.mediafire.com/?nbp32easa8p3yr6) with debanding? Looking at the horizontal bars adjacent to black (blue and white), even with debanding set to low I see the bars noticeably bleeding over into black. I'm using NL6 from your latest package, although I don't expect that to matter - if I turn debanding off the 'mist' on the black regions goes away.
I don't seem to see that here. Can you post a screenshot? Please note that this is considered a fade in/out, so debanding might switch into the higher fade deband setting, which might explain some bleeding. But I don't seem to see much of that here. But maybe I'm looking at the wrong place or the wrong timecode?

I wonder if an option to apply debanding after the 3DLUT is applied rather than beforehand might be useful for this.
3dlut processing should not introduce banding. Of course I could apply debanding after 3dlut processing, but that also means it's done after scaling, which usually increases the GPU power consumption. And probably it would also have to be done after Smooth Motion FRC, so another 2.5x GPU usage increase for 24fps @ 60Hz playback.

Harry Potter and the Deathly Hallows Part 1 on Optoma GT760 720p DLP projector (around 10:00). Sitting close to a 84" screen so I see every little detail. +_+
My finalists are: NL1 and NL6 (http://screenshotcomparison.com/comparison/62307). NL1 produces slightly cleaner image here in dynamic.
Ok, thanks.

I see, okay. It would be nice if there was a notice at least in the Debug OSD, though, so one can know without having to specifically test whether or not it fails.
Different users want different information in the debug OSD, and they also want the debug OSD to be small and easy to read at the same time. I can't put everything into the debug OSD, or it will grow too big. That said, maybe I'll add something, but I don't know right now.

IIRC, the 3DLUT is 8bit input and 16bit output through interpolation.
Correct.

Eight lookups and seven calls to lerp() I guess
Nope. GPUs have texture units which do linear interpolation for free. Even for 3D textures. So I only have to do one simple 3D texture lookup with linear filtering activated in the texture sampler.

I'm sort of confused on how this is done now, doesn't debanding increase the bitdepth of the original image? And if so how would you then use the 3DLUT? You'd either need a 16bit LUT which would be MASSIVE (256 TiB) or you'd need to interpolate the LUT, which sort of defeats the point of using a LookUp Table, or you'd need to round the image down to 8bits again which would make the debanding useless.
LUT access is done by using trilinear interpolation. The same method is used e.g. to calibrate professional photo/video monitors. However, for that usually the 3dluts are only 17^3. Still, even with only 17^3 3dluts, there's no banding, thanks to interpolation. madVR's 3dluts are 256^3, so they should be really high quality. Of course the final 3dlut image quality depends on the application which creates the 3dluts.

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.
Cool. So it seems so far we have 3 votes for NL6 and one shared vote for NL1.

[madshi]

Content is sports video (Sochi Olympics) in 1080i. Automatic deinterlacing is off in madVR settings.

I checked again, and if the madVR refresh rate changing specifications include 1080i59, 1080i60 then the final ms reported in the madVR stats, is about 20% less (and with zero dropped, etc) than the final ms if 1080i59, 1080i60 is removed from the list (and there are a few dropped, delayed, etc).

So, specifying 1080i59 is definitely making some sort of difference which appears to be less GPU use. This would seem to indicate that TV deinterlacing is being used instead of GPU - but I am no expert.
If you do have 1080i59, 1080i60 in the list, that could make it possible for your TV to do the deinterlacing. It's a somewhat unusual setting, though, so I can't vouch for its quality. Also, make sure you don't scale the image, or you could get very bad combing artifacts. Or actually, you could try that to double check whether your TV does the deinterlacing. If you zoom the image in or out slightly, deinterlacing in your display should run into lots of trouble.

One thing I don't understand is that as long as you have deinterlacing totally disabled in madVR, it should not be applied, no matter what. So I don't understand why you would get higher rendering times with progressive output. Anyway, doesn't matter. If you have a good experience with your current settings, it might make sense to simply stick to them, no questions asked...

[kstuart]

@madshi - If madVR deinterlacing is turned off, and 1080i59 is specified in the madVR refresh rate list, is there a difference in what madVR passes on to the Catalyst drivers ? Is there some sort of interlaced flag that is not used when 1080p59 is specified ?

[kstuart]

kstuart, can you tell me if the 6450 can play 720p/1080p 60fps videos smoothly, and if it can handle the debanding filter turned on? My 5450 can't do either. Just trying to figure out how high a card I need to step up to get both to work properly.

I have never seen a 720p or 1080p file that is 30 or 60 fps (as opposed to 29.97 and 59.94). I think that is only used in professional video recording.

In fact, I haven't seen a 1080p file that is anything other than 23.976, 24.0 or 25.0.

I just tried a 720p 59.94fps file, and it does drop frames (because it is doing both chroma upscaling and luma upscaling). I'm going to see if I can implement a profile for just 720p 59.94fps, so that is uses better performance settings (maybe just turning off AR on luma).

I do have debanding turned on all the time, it did not make a significant difference in performance with my card.

In "trade quality..." I have "use random dithering..." " don't analyze... " and " don't rerender... " checked. Error Diffusion causes the GPU load to go too high, btw.

And I use Aero enabled and Fullscreen Exclusive mode. If you have not tried that with your 5450, it may make a difference (similar results reported a few posts up).

[Ver Greeneyes]

I don't seem to see that here. Can you post a screenshot? Please note that this is considered a fade in/out, so debanding might switch into the higher fade deband setting, which might explain some bleeding. But I don't seem to see much of that here. But maybe I'm looking at the wrong place or the wrong timecode?
Paused on frame 256, I see this:
no debanding (http://i.imgur.com/HCczyRx.png)
low debanding (http://i.imgur.com/7gO7snW.png)
high debanding (http://i.imgur.com/2f0X6x7.png)

Note the noise below the upper white band and above the lower blue band that starts as the band becomes less bright. It's more pronounced with high debanding, but there with low debanding as well (I set debanding during fadeouts to the same setting). Eventually (in the darkest areas) all bands lose their edges completely as I guess they become similar enough.

I got this using build NL6 on a GeForce GTX 580 with the 327.23 drivers, and all the options in the trade quality for performance tab disabled.

Edit: I guess this is doing what debanding is supposed to do, I'm just surprised a difference this big is being marked for debanding, and the 'haze' on black kinda stands out.

[XMonarchY]

Paused on frame 256, I see this:
no debanding (http://i.imgur.com/HCczyRx.png)
low debanding (http://i.imgur.com/7gO7snW.png)
high debanding (http://i.imgur.com/2f0X6x7.png)

Note the noise below the upper white band and above the lower blue band that starts as the band becomes less bright. It's more pronounced with high debanding, but there with low debanding as well (I set debanding during fadeouts to the same setting). Eventually (in the darkest areas) all bands lose their edges completely as I guess they become similar enough.

I got this using build NL6 on a GeForce GTX 580 with the 327.23 drivers, and all the options in the trade quality for performance tab disabled.

Edit: I guess this is doing what debanding is supposed to do, I'm just surprised a difference this big is being marked for debanding, and the 'haze' on black kinda stands out.

Nobody can see banding like that... Screenshots do not copy the LUT image you get when you use it. There is no banding anyone can see unless they apply a LUT too. You need to take a photo to show it. I also get banding and it is caused by the 3DLUT but specifically by the 1DLUT for grayscale that is applied to 3DLUT. It happens due to even good probes like i1D3 not being very accurate and also due to interpolation. I get banding even though HCFR reports very low dEs for grayscale using 33pt measurement. If I do not apply 1DLUT calibration during 3DLUT creation in dispcalGUI then there is no banding. Using 3DLUTs that contain no grayscale calibration done by ArgyllCMS or CalMAN or ANY software is the only way to get rid of banding. It really is the 1DLUT that is integrated into 3DLUT that causes banding... Make a 3DLUT but do not tick the box "Apply vcgt..." when you use 3DLUT making tool or just exclude your LUT.cal switch if you use collink.exe. Then test that 3DLUT - there will be no banding but your grayscale will not be as accurate.

I do not think its possible to get rid of banding. Even using 10pt controls for TV calibration can cause banding and so some people stick only to 2pt controls. I think using a profiled colorimeter or a good spectrometer will provide results with less banding.

If your bands differ in color then its a white balance inaccuracy but if they are neutral and its the darker and lighter bands then its deviations/inaccuracies in gamma, which is what I get. ArgyllCMS is way better at making LUTs than other apps.

Another recommended method on AVS forums is to use fewer calibration points. If you use 10pts then you will have very few bands but the LUT may be less accurate. Its what ConnecTED told me. But it is impossible to get an accurate BT.1886 gamma curve with 10 or even 20 pt calibration. ArgyllCMS goes through many pts and then through pts between them and so on, making over 200 reads but even then you will get banding.

If madshi could apply debanding after or to 3DLUT without killing performance then it would be making impossible possible, not something that I would expect, but maybe... just maybe... After all banding can destroy visual fidelity...

[Ver Greeneyes]

The effect I'm talking about is there in the images I posted. The same thing happens when I turn off the 3DLUT (though the screenshots might have different colors, I guess).

[DarkSpace]

Of course I could apply debanding after 3dlut processing, but that also means it's done after scaling, which usually increases the GPU power consumption. And probably it would also have to be done after Smooth Motion FRC, so another 2.5x GPU usage increase for 24fps @ 60Hz playback.
I may be missing something here, but while I think it might not be a bad idea to do debanding after scaling (with appropriate strength and so on, of course), I think doing it after SmoothMotion FRC has a lot of potential to create unwanted artifacts. After all, the point of SmoothMotion FRC is to blend together nicely debanded images, and not to have nicely debanded gradients in that one blended image (that sounds weird, but I hope you get my point).

Different users want different information in the debug OSD, and they also want the debug OSD to be small and easy to read at the same time. I can't put everything into the debug OSD, or it will grow too big. That said, maybe I'll add something, but I don't know right now.
I realize that, and all I'd like is some notice that OpenCL is not being used even though according to settings, it should be used. I was thinking of only displaying it when it actively failed or something...
Of course, it's of no consequence to me now, because I already found out another way, but it would have been nice. And there are probably other ways I overlooked also...

[madshi]

@madshi - If madVR deinterlacing is turned off, and 1080i59 is specified in the madVR refresh rate list, is there a difference in what madVR passes on to the Catalyst drivers ? Is there some sort of interlaced flag that is not used when 1080p59 is specified ?
No.

Note the noise below the upper white band and above the lower blue band that starts as the band becomes less bright. It's more pronounced with high debanding, but there with low debanding as well (I set debanding during fadeouts to the same setting). Eventually (in the darkest areas) all bands lose their edges completely as I guess they become similar enough.
I find this hard to see on my development computer monitor, even when zoomed in. I can clearly see that the green and cyan bands are "debanded". But black/blue? Yeah, some black pixels get blue values of 1 or 2. But I don't really see that with my eyes, I can only measure it. Could be cause my display is not properly calibrated (it doesn't show near black values very well). In any case, none of this looks like debanding would do something wrong.

I may be missing something here, but while I think it might not be a bad idea to do debanding after scaling (with appropriate strength and so on, of course), I think doing it after SmoothMotion FRC has a lot of potential to create unwanted artifacts.
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.

[XMonarchY]

The effect I'm talking about is there in the images I posted. The same thing happens when I turn off the 3DLUT (though the screenshots might have different colors, I guess).

I guess. I am not seeing the effect.. Do you have a 1DLUT applied to your display outside of 3DLUT?

[Ver Greeneyes]

I find this hard to see on my development computer monitor, even when zoomed in. I can clearly see that the green and cyan bands are "debanded". But black/blue? Yeah, some black pixels get blue values of 1 or 2. But I don't really see that with my eyes, I can only measure it. Could be cause my display is not properly calibrated (it doesn't show near black values very well). In any case, none of this looks like debanding would do something wrong.
Okay, I'm going to chalk this one up to "artificial testcases are bad" and "my monitor has a terrible black level so everything near black stands out" :P I'll recalibrate soon and if it still stands out to me I'll see if I can get some numbers on where the debanding starts (and see if it's an unreasonable threshold). The main thing that bothers me about this is that the hue is so different (and yet it still does debanding) - but maybe the brightness is low enough that it's detected as a gradient anyway.

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

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

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 ?

Thanks !

[ryrynz]

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


It does.


Is there a way to have it not bother, i.e. just output black bars for the 4 pixels ?


This is done through your media player, you want to select the video size to be normal. Using MPC you can do this by going into View -> Video Frame -> Normal Size, you'll find a similar setting on other media players.
This will need to be changed to suit each video.

[kstuart]

This is done through your media player, you want to select the video size to be normal. Using MPC you can do this by going into View -> Video Frame -> Normal Size, you'll find a similar setting on other media players.
This will need to be changed to suit each video.

Thanks.

But... madVR seems to do this by the target resolution requested by the Monitor, rather than by anything having to do with the media player.

If the monitor accepted "1076p" this would be no problem, as I would just add "1076p23, 1076p24, 1076p59, 1076p60" to the display modes in madVR. But that is not what the monitor is expecting.

[6233638]

3dlut processing should not introduce banding. Of course I could apply debanding after 3dlut processing, but that also means it's done after scaling, which usually increases the GPU power consumption.It definitely can introduce banding, which is why I've stuck to only adjusting gamma via the 3DLUTs rather than full calibration.
It's very possible that the LUT could be altered in a minor way to avoid banding, but I don't know that there are tools to really visualize the LUTs properly, or adjust the output values to fix this.
The 3DLUT system really works backwards to what I'm used to, as you give it input values and the output is calculated from that, rather than simply specifying the output values required to meet a specific target.

If moving the debanding step after the 3DLUT is applied would also mean it's done after scaling, I doubt the debanding would help much.
I did some testing a while back, scaling the video in ffdshow first and then debanding, and it was not nearly as effective as debanding prior to scaling - even with the debanding strength turned up.

I knew there would be trade-offs moving the debanding step to after applying the LUT, but if it could have been applied before scaling it may have helped. (and been a "trade performance for quality" option - or similar)


But none of this seems to be an area that you're focused on just now, so I'll wait until you decide to revisit LUTs/calibration.

Right now, I'm looking forward to seeing which of the new builds cyberbeing decides does the best dithering.

I'm using the "madVRnoisyLimited" build for now, and after watching a couple of films, it really is impressive how much lower the noise is compared to the old random dithering now.

Of course, that means I'm now much more aware of the grain structure/sensor noise that's encoded on the discs. :D

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 ?This should be handled by your player. (set it to 100% size)

If the monitor accepted "1076p" this would be no problem, as I would just add "1076p23, 1076p24, 1076p59, 1076p60" to the display modes in madVR. But that is not what the monitor is expecting.If you're using an Nvidia card, you could set up custom resolutions for that in the driver, and tell it to center the image rather than scaling it to fit - but setting the media player to 100% size seems a lot easier.

[Asmodian]

madVR outputs the target resolution requested by the media player (this is how you can mouse drag a corner of the player and have the video resized to fit), it is simply that media players usually request the resolution of the monitor when playing full screen.

[QBhd]

I output a target resolution of 1024x768 (rectangular pixel 720p Plasma)

When NNEDI3 was introduced I never changed any of the image doubling settings, thinking that it would not do much for me since almost everything I watch (720p/1080p/1080i) would still be "downscaled"... I just used NNEDI3 for chroma upscaling (even pushing it to 128 neurons, no sense having GPU power doing nothing right, LOL) and lanczos 4 AR for image downscaling

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

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

Second question is just a curiosity since I don't know exactly how all this works... but I would like some confirmation on the first question please

QB

[Ver Greeneyes]

The 3DLUT system really works backwards to what I'm used to, as you give it input values and the output is calculated from that, rather than simply specifying the output values required to meet a specific target.Actually, it does specify the output values required to meet a specific target. For 3-channel 8-bit input, each input value is simply an array index into each 3-channel output value. With higher bit depths the input values are coordinates instead, but the 3DLUT still directly maps/transforms each input value to the output value required to accurately display it.

If you think of a 3DLUT as a cube with a specific density at each point, an input color simply specifies a coordinate in the cube for which to get the density. A 3DLUT only specifies the density for each point - a given set of input coordinates refers to the same places in any 3DLUT, though the density in those places may be different. Of course the 'density' in this case is actually a 3-dimensional vector representing an output color, but the idea is the same.

The gaps between the output values may be larger than the gaps between the input values, which can produce additional banding, and it would be nice to see debanding working on those gaps as well.

[kstuart]

All feedback is appreciated, btw.


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]

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

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]

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?

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.

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.

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.

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?

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.

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]

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]

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

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]

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

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]

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]

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.