madVR - high quality video renderer (GPU assisted)

[huhn]

Still have problems with downscaling. Madvr seems to choose the wrong alternative.

the reason should be that up and downscaling is used at the same time.

but lanczos is used to fix both in one scaling step. i guess this is working as intended.

[Ver Greeneyes]

* fixed: linear light SuperRes processing got broken in v0.90.5
Thanks for the quick fix!

[krille]

the reason should be that up and downscaling is used at the same time.

but lanczos is used to fix both in one scaling step. i guess this is working as intended.

It didn't use to be like this though, but maybe something in Madvr has changed?

[huhn]

i know there where some bugs with up and downscaling at the same time in the past not sure if this is the "fix" for it.

[Asmodian]

It didn't use to be like this though, but maybe something in Madvr has changed?

I remember this behavior as normal. Lanczos 3 has always been the fallback scaling method for Jinc when upscaling in one dimension and downscaling in another.

[scollaco]

If the vsync is not detected correctly that could cause a lot of issues. But playback getting totally stuck sounds weird. If you create a debug log I can have a look.




Hey madshi...thansk for helping take a look. Here is a debug log. It is the first time I made one..so I hope I did it right. Hope it helps solve my 3d freezing issue.

https://www.dropbox.com/s/jb6as0tg1jcv5lp/scollaco_3D_freezing_madVR%20-%20log.zip?dl=0

[NicolasRobidoux]

Hi Nicolas - long time no see! :)

I had an option in madVR to do upscaling in linear light, but it was never recommended to be used and I think nobody actually used it. Instead a user was asking for adding sigmoidization, and he had a video where it did look slightly better (anime with hard coded subtitles showed a bit less aliasing in the subs). So I simply replaced the linear light option with a sigmoization option. At the same time I also have test images where sigmoidization looks worse. So I'm not sure if I actually recommend using it or not, but it's there for users who want to experiment with it. I guess it's at least less bad than linear light upscaling... :)Hello Mathias :) Some years are more crazily busy than others.

Note: When I proposed sigmoidization to you, I had not realized clearly that video source is actually not quite friendly to conversion to RGB linear light.

The following is completely untested:

My gut feeling (which is why I added the link to an early version of this very suggestion) is that unless some sort of RGB is "sort of native", meaning for example that there are no "reasonable" negative values, sigmoidization should be used only on something that can be understood either as a luminance or a luma (yes, sigmoidize in a gamma space!), blending in resampled chroma afterwards.

Is this what you do already? Does this make any sense to you? Wanna try? :)

[dansrfe]

@madshi

I actually still get a crash on the v0.90.4+ builds related to OpenCL:

https://drive.google.com/file/d/0B9iVOLolmqxdXzNfRE1JWTRMRW8

Essentially, Overlay -> FSE -> Overlay and/or resizing triggers the crash. Sometimes, madVR won't crash but the player's render area will go black or freeze. This doesn't happen consistently though. I suppose something related to NNEDI3 and profile switching by resize causes the problem.

[Sparktank]

I am loving this SIMM business.
It's a good day to SIMMer down. ;)

Thanks for the updates!

[JarrettH]

Is anyone using SSIM to downscale 720p to 1080p after super-xbr doubling? Anyway, after I update madvr I'll find out how the performance is :scared:

[THEAST]

If anybody is wondering, the problem with madVR crashing in a Crossfire environment on windows 10, after pausing videos for a few seconds, has been resolved in AMD's Crimson driver v16.1 and above.

[ryrynz]

madVR v0.90.5 released

http://madshi.net/madVR.zip

* fixed: some SSIM downscaling related bugs
* added SSIM "detailed" and "clean" variants
* added Bicubic "sharpness: 125" option
* added "use 1.6 gamma instead of 2.2" option to linear light


Looks good! Nice to see Bicubic 125 in there.


1) Do you prefer SSIM "clean" or "detailed" downscaling?


Detailed as it brings out details that would be visible with a 4K screen that clean misses and given that's the nature of SSIM, the detailed setting suits it.


2)So which of those 3 options do you prefer and can I get rid of the other two?

Would need someone to look at the original 4K images to determine of gamma light was more or less accurate than linear light.
Gamma light appears the most accurate with text on screen so I'd prefer we just stuck with gamma light if we ditch two options but I suspect people will cry out over losing linear light so I think you'll probably need to have both.
I reckon linear light 2.2 appears too bright so if we're ditching a linear light option I think that should be the one to go.

[4h4h270]

downscale linear light now produce terrible banding.:(

[Thunderbolt8]

Detailed as it brings out details that would be visible with a 4K screen that clean misses and given that's the nature of SSIM, the detailed setting suits it.that would mean you have content bigger than 4k scaled down to 4k. Id guess there isnt really much content > 4k out there though yet.

in any case, imho then both options should be kept. because as I said in my case of 4k --> 1080p, there isnt really a difference in detail, it feels more like the additional aliasing makes watching a more unpleasant. so perhaps indeed detailed might be better for 4k while clean could be better for lower resolutions.

[ryrynz]

madshi I'm getting green crisscross patterns when enabling NNEDI3 quadrupling with SSIM detailed, all okay with the clean option though. Nvidia 960 W10 361.82

that would mean you have content bigger than 4k scaled down to 4k. Id guess there isnt really much content > 4k out there though yet.


I meant 4k content on a 1080 screen, I couldn't comment on anything else.

[6233638]

linear light downscaling which uses a 2.2 gamma valueShouldn't that be 2.4 for film?
Linear light still seems to get a little bit darker than the source in my tests, so that probably explains it.

It should come as no surprise that the 1.6 gamma option is darker than it should be, so if we're picking between the two, 2.2 gets my vote.
I don't see the point in trying to pick an intermediate value. Either you want linear light processing or you don't.

I'd suggest that, if it's possible, perhaps make the option a checkbox to enable linear light with a drop-down to set gamma. That consolidates the two options into a single preference.
This could also allow for a bit more flexibility if things don't look quite right on your display for whatever reason. Perhaps 2.0 or 2.6 would be a better match for the source on some displays.

Currently, all of my film sources are 1080p native, I'm viewing them on a 1080p display, and I never watch films in a window, so the linear light option does not apply to them.
The content that I do watch windowed is intended to be viewed at 2.2 gamma, so the current value works well.

However, I'm not planning on upgrading to a 4K TV for at least another year or two.
So it's likely that I will be downscaling 4K films, and for that, a value of 2.4 gamma should be used.
So I'd prefer to be able to control that with profiles, instead of settling on a single fixed value.

If we do have to pick a single value, then I'd pick 2.4 - because I care more about films looking correct than non-film sources.

[Thunderbolt8]

I meant 4k content on a 1080 screen, I couldn't comment on anything else.I made some comparison here. cant really tell if what I see is more detailed with the detailed setting or perhaps more aliasing (the anti ringing filter was activated in all four cases, scaling in linear light deactivated).


crowd run

original 4k image: https://www.sendspace.com/file/nisw4c

clean:
http://thumbnails113.imagebam.com/46399/dd8875463985252.jpg (http://www.imagebam.com/image/dd8875463985252)

detailed:
http://thumbnails105.imagebam.com/46399/dd65dc463985298.jpg (http://www.imagebam.com/image/dd65dc463985298)



ducks taking off

original 4k image: https://www.sendspace.com/file/yy7zka

clean:
http://thumbnails113.imagebam.com/46399/7dba83463985340.jpg (http://www.imagebam.com/image/7dba83463985340)

detailed:
http://thumbnails113.imagebam.com/46399/5dffd0463985384.jpg (http://www.imagebam.com/image/5dffd0463985384)


edit: screenshots were taken wrong.

[huhn]

Shouldn't that be 2.4 for film?
Linear light still seems to get a little bit darker than the source in my tests, so that probably explains it.

It should come as no surprise that the 1.6 gamma option is darker than it should be, so if we're picking between the two, 2.2 gets my vote.
I don't see the point in trying to pick an intermediate value. Either you want linear light processing or you don't.

I'd suggest that, if it's possible, perhaps make the option a checkbox to enable linear light with a drop-down to set gamma. That consolidates the two options into a single preference.
This could also allow for a bit more flexibility if things don't look quite right on your display for whatever reason. Perhaps 2.0 or 2.6 would be a better match for the source on some displays.

Currently, all of my film sources are 1080p native, I'm viewing them on a 1080p display, and I never watch films in a window, so the linear light option does not apply to them.
The content that I do watch windowed is intended to be viewed at 2.2 gamma, so the current value works well.

However, I'm not planning on upgrading to a 4K TV for at least another year or two.
So it's likely that I will be downscaling 4K films, and for that, a value of 2.4 gamma should be used.
So I'd prefer to be able to control that with profiles, instead of settling on a single fixed value.

If we do have to pick a single value, then I'd pick 2.4 - because I care more about films looking correct than non-film sources.

the mathematically correct gamma is 2.2.

and for film this gamma of 2.2 has to be displayed as 2.4 to look correct. the math was done on 2.2 only the display change it at the end that it.

[Trendle]

I got a question. Maybe it's already been answered, but I'm hoping for a straight forward answer.

Will madVR be able to benefit from Crossfire and/or SLI configurations in the foreseeable future, similar to the way video games benefit from it? What is holding it back? Drivers or something else..? :confused:

[aufkrawall]

I downscaled these images from 4k to 1080p (with gamma of 1.6):
http://www74.zippyshare.com/v/rCbbGh4v/file.html

SSIM detailed:
http://abload.de/thumb/detailedkzk23.png (http://abload.de/image.php?img=detailedkzk23.png)

SSIM clean:
http://abload.de/thumb/cleanisk9e.png (http://abload.de/image.php?img=cleanisk9e.png)

I think "detailed" looks too aliased.

Regarding scaling in gamma/linear light:
A gamma of 1.6 nicely seems to be in between GL & LL regarding brightness. So, if GL is mathematically considered to be too dark and LL to be too bright, I think the answer is clearly for gamma of 1.6.
I think this is also true for fonts: With LL, they look too thin/bright after downscaling and with GL, they become bold. They probably can be read better with GL, but to me they still look too bold. So I also think in this case gamma of 1.6 is most correct, they neither look too thin nor too bold with it.
With fonts downscaling, SSIM also is clearly superior to bicubic 150. Bicubic looks quite blurry with fonts.
With fonts, SSIM clean is again less aliased than SSIM detailed (and still much sharper than bicubic).
I simply tested by taking a screenshot of a website in Firefox with lots of text.

So, my vote clearly goes for:
SSIM clean instead of detailed
Gamma of 1.6. I personally don't see any reason with it to keep any other option, it should be a compromise everyone should be able to live with well, from what I've seen at least.

[6233638]

downscale linear light now produce terrible banding.:(
Just started to actually watch something, and you're right. I'm getting terrible banding with linear light downscaling enabled.
This was introduced in 0.90.5

the mathematically correct gamma is 2.2.
and for film this gamma of 2.2 has to be displayed as 2.4 to look correct. the math was done on 2.2 only the display change it at the end that it.I'm not saying that you're wrong, but where do you get that 2.2 gamma is "mathematically correct" for film?
If you're talking about the BT.709 transfer function, that's not 2.2 gamma. (more like 1.96 for the best-fit gamma)

[madshi]

My gut feeling (which is why I added the link to an early version of this very suggestion) is that unless some sort of RGB is "sort of native", meaning for example that there are no "reasonable" negative values, sigmoidization should be used only on something that can be understood either as a luminance or a luma (yes, sigmoidize in a gamma space!), blending in resampled chroma afterwards.

Is this what you do already? Does this make any sense to you? Wanna try? :)
There should be no negative RGB data. If there is, luma/luminance would be negative, too, in the same situation. I'm currently scaling in RGB. In all my tests I could rarely see a difference when scaling in RGB vs YCbCr. I'm currently doing sigmoidization in linear light RGB, and it does seem to help in some specific situations, and hurt in others, same as last time we tested this. I'm pretty sure that converting to YCbCr and only applying sigmoidization to Y wouldn't change anything at all. All that would do is to limit the effect of sigmoidization to the brightness information, while keeping color information unaffected. But brightness is where all the positive and negative sigmoidization changes are happening already right now, when doing all this in RGB. There's no effect on colors that I can see. So I don't think doing this in YCbCr instead of RGB would make any difference.

Or did I misunderstand your suggestion?

I'd rather say that indicate that the GPU outputs 24Hz.
The refresh rate is being displayed incorrectly if the video has been initialized while the player window was on the primary 60 Hz display and is being dropped then to the secondary 24 Hz display. If the player window has been dropped to the secondary display before the video has been initialized OSD displays the correct refresh rate.
Why are you so sure that the OSD is incorrect? Is it just a guess or do you have concrete evidence? Does the refresh rate in the OSD still fluctuate a bit after it shows the "wrong" refresh rate? Or is it fixed and never changes again?

I've enabled the release mode but still can't find the debug log (under the admin account).
You need to enable the debug mode, not the release mode. The log should then be on your desktop. If the batch file doesn't work, simply rename "madVR [debug].ax" to "madVR.ax" (rename the original file before that so you can undo the renaming later again).

BTW under what conditions madVR writes its settings to the file instead the registry?
madVR *always* writes to the registry. In addition it writes to the settings file if madVR has write access to the folder.

From my experience there are far more obvious changes when I am using the filters under image enhancements. But is it smart to use lets say the sharpen filter two times at prossesing and at upsaling at the same time or is it overkill?
The "image enhancements" are applied before upscaling, which means it shows bigger impact with the same settings, but the quality is also worse. You'll get better quality by sharpening after upscaling ("upscaling refinement"), but it will cost more GPU power, and you need to turn the dials up more to get a similar amount of sharpening.

Still have problems with downscaling. Madvr seems to choose the wrong alternative.http://s30.postimg.org/a0z6iry1p/Sk_rmklipp_MADVR.jpg (http://postimg.org/image/a0z6iry1p/)
As already mentioned by huhn and Asmodian, this is probably the consequence of trying to use Jinc upscaling while the image needs to be upscaled in one direction but downscaled in the other direction. In that situation madVR uses Lanczos3 AR for both up- and downscaling. Maybe I should revisit that. Might make sense to use the selected downscaling method instead for the downscaling part.

Hey madshi...thansk for helping take a look. Here is a debug log. It is the first time I made one..so I hope I did it right. Hope it helps solve my 3d freezing issue.

https://www.dropbox.com/s/jb6as0tg1jcv5lp/scollaco_3D_freezing_madVR%20-%20log.zip?dl=0
Ok, your log indicates that the decoder sends 3 frames, and then it just stops sending anything. The thread which usually delivers the frames just seems to stop doing anything at all for the rest of the log. I'm not sure why this problem occurs, but it seems to be outside of madVR's responsibility.

In addition to this there's also the problem that refresh rate measurement runs into big trouble. The first time the refresh rate measurement produces any useful information is about 7 seconds after playback started. This is a big problem. Your GPU (driver) seems to not report scanline information in any reliable way.

I'm not sure if the two problems are related. One thing to try would be this: Ask nevcairiel for a nightly LAV build with PDB debug symbols. Then when playback is stuck, press Ctrl+Alt+Shift+Pause/Break to create a freeze report, and upload it somewhere for us to look at. This only makes sense if you have LAV PDB debug symbols which perfectly match the LAV build you're using, though.

I actually still get a crash on the v0.90.4+ builds related to OpenCL:

https://drive.google.com/file/d/0B9iVOLolmqxdXzNfRE1JWTRMRW8

Essentially, Overlay -> FSE -> Overlay and/or resizing triggers the crash. Sometimes, madVR won't crash but the player's render area will go black or freeze. This doesn't happen consistently though. I suppose something related to NNEDI3 and profile switching by resize causes the problem.
And you're 100% sure that this does never ever occur on older madVR builds? Can you please also double check 32bit to make sure the problem is not specific to 64bit?

It's a good day to SIMMer down. ;)
:D

If anybody is wondering, the problem with madVR crashing in a Crossfire environment on windows 10, after pausing videos for a few seconds, has been resolved in AMD's Crimson driver v16.1 and above.
Great - thanks for letting us know!

Detailed as it brings out details that would be visible with a 4K screen that clean misses and given that's the nature of SSIM, the detailed setting suits it.
Screenshots, please?

Gamma light appears the most accurate with text on screen
Screenshots, please?

Would need someone to look at the original 4K images to determine of gamma light was more or less accurate than linear light.
Gamma light appears the most accurate with text on screen so I'd prefer we just stuck with gamma light if we ditch two options but I suspect people will cry out over losing linear light so I think you'll probably need to have both.
I reckon linear light 2.2 appears too bright so if we're ditching a linear light option I think that should be the one to go.
In theory linear light should produce the most accurate results. However, there may be stronger ringing and more aliasing. Other than that it *should* be superior.

downscale linear light now produce terrible banding.:(
How does "now" define exactly? Starting with which madVR build? And which previous build did not have the problem?

Can you provide me with screenshots of the banding, compared to how a previous working madVR build didn't have banding in the same frame? Please also provide a screenshot of the original unscaled frame, so that I can try to reproduce the problem on my own PC. Which downscaling algo are you using?

Do you have any non-default "trade quality for performance" options selected, like e.g. "use 10bit image/chroma buffer" or something like that?

madshi I'm getting green crisscross patterns when enabling NNEDI3 quadrupling with SSIM detailed, all okay with the clean option though.
Can't seem to reproduce this here. Can you please make a screenshot which shows the problem, with the Ctrl+J OSD turned on? Please also create an empty file named "ShowRenderSteps" in the madVR folder before creating the screenshot. Also, could you please upload your settings.bin file?

Shouldn't that be 2.4 for film?
We don't know which exact value studios used. Some may use 2.4, other 2.2, others something else. Using 2.2 is definitely a safer choice. It's better to stay a bit nearer to gamma downscaling than to overdo linear light.

It should come as no surprise that the 1.6 gamma option is darker than it should be, so if we're picking between the two, 2.2 gets my vote.
I don't see the point in trying to pick an intermediate value. Either you want linear light processing or you don't.
The key question is whether linear light scaling has any disadvantages? Possible side effects could be stronger ringing or stronger aliasing or something else. If there are such side effects then 1.6 gamma might be a reasonable compromise. If there are no obvious side effect for 2.2 gamma then I'm all for making it the default.

I'd suggest that, if it's possible, perhaps make the option a checkbox to enable linear light with a drop-down to set gamma. That consolidates the two options into a single preference.
I think you already know my answer to that. I want to REDUCE the number of options, not increase it.

I made some comparison here. cant really tell if what I see is more detailed with the detailed setting or perhaps more aliasing (the anti ringing filter was activated in all four cases, scaling in linear light deactivated).

crowd run

ducks taking off
On a quick check I don't see too much of a difference. To be fair, I suppose the difference between "detailed" and "clean" isn't that dramatic. But I wanted to give you guys the choice before I cut one of the two choices.

If you guys prefer, I can show two screenshot which demonstrate the difference between "detailed" and "clean" more clearly? But I want to give you the opportunity to test yourself without pushing you into any one specific direction myself.

Will madVR be able to benefit from Crossfire and/or SLI configurations in the foreseeable future, similar to the way video games benefit from it? What is holding it back? Drivers or something else..? :confused:
Making use of such a config would be quite a bit of work, especially when using features such a smooth motion FRC, which needs access to the preceding/succeeding frames. The key problem for me is that I don't have such a configuration myself. And in order to make it work well for both AMD and NVidia, I would probably need to have a setup for both here for development, and I'm not going to go there, even if money were no object. Simply too much work/hassle at this point.

I downscaled these images from 4k to 1080p (with gamma of 1.6):
http://www74.zippyshare.com/v/rCbbGh4v/file.html

SSIM detailed:
[url=http://abload.de/image.php?img=detailedkzk23.png]
SSIM clean:
[url=http://abload.de/image.php?img=cleanisk9e.png]
I think "detailed" looks too aliased.

Regarding scaling in gamma/linear light:
A gamma of 1.6 nicely seems to be in between GL & LL regarding brightness. So, if GL is mathematically considered to be too dark and LL to be too bright, I think the answer is clearly for gamma of 1.6.
I think this is also true for fonts: With LL, they look too thin/bright after downscaling and with GL, they become bold. They probably can be read better with GL, but to me they still look too bold. So I also think in this case gamma of 1.6 is most correct, they neither look too thin nor too bold with it.
With fonts downscaling, SSIM also is clearly superior to bicubic 150. Bicubic looks quite blurry with fonts.
With fonts, SSIM clean is again less aliased than SSIM detailed (and still much sharper than bicubic).
I simply tested by taking a screenshot of a website in Firefox with lots of text.

So, my vote clearly goes for:
SSIM clean instead of detailed
Gamma of 1.6. I personally don't see any reason with it to keep any other option, it should be a compromise everyone should be able to live with well, from what I've seen at least.
Ok, thanks for your feedback. FWIW, LL is not considered mathematically too bright, it should create the most accurate images.

Just started to actually watch something, and you're right. I'm getting terrible banding with linear light downscaling enabled.
Can you please help me reproduce this issue? Maybe a 4K source image which shows this clearly? Which exact downscaling settings and which scaling factor etc?

[aufkrawall]

Ok, thanks for your feedback. FWIW, LL is not considered mathematically too bright, it should create the most accurate images.

I'm lacking mathematical skill to judge this. When you and other experts here proclaim this, I adopt this view.
I once downscaled a game image in both LL and GL, and indeed, upscaled again, the once downscaled image in LL was much closer to "ground truth" than GL. GL was way too dark (even with LL upscaling).
However, imho gamma 1.6 clearly looks better with fonts or differently said: LL looks very wrong with fonts. So, in "practice" it might not be the best solution.

[Thunderbolt8]

On a quick check I don't see too much of a difference. To be fair, I suppose the difference between "detailed" and "clean" isn't that dramatic. But I wanted to give you guys the choice before I cut one of the two choices.yes please. from what Ive seen so far it just seems that the distracting difference in aliasing is bigger than that of detail.

[6233638]

We don't know which exact value studios used. Some may use 2.4, other 2.2, others something else. Using 2.2 is definitely a safer choice. It's better to stay a bit nearer to gamma downscaling than to overdo linear light.If it was mastered on a CRT (all old films) it will be ~2.4
If it was mastered today, there are now standards in place (BT.1886) which say that it should be 2.4 - which I think would apply to all 4K content.
There was perhaps an intermediate period between CRTs and BT.1886 (March 2011) where this was nebulous, but I can't imagine that it differed much, if at all.

The key question is whether linear light scaling has any disadvantages? Possible side effects could be stronger ringing or stronger aliasing or something else. If there are such side effects then 1.6 gamma might be a reasonable compromise. If there are no obvious side effect for 2.2 gamma then I'm all for making it the default.Well yes, ringing can be prominent with some of the scaling algorithms when linear light scaling is enabled. But if we're not going to have a choice, it should use the "correct" value.
If we're making it a "tweak" instead of making it "correct" then I'd go back to preferring a drop-down list for it.

Can you please help me reproduce this issue? Maybe a 4K source image which shows this clearly? Which exact downscaling settings and which scaling factor etc?I assumed that it was just a general issue with the option in those builds, as it was happening with everything.
I'll see if I can figure out what combination of settings is causing it.

EDIT: Nope, just enabling "scale in linear light" on a default config (reset settings) is causing this.

Source (may not be exact frame) (http://abload.de/img/source4mo9i.png)
Default Settings (http://abload.de/img/defaultvfpw0.jpg)
Linear Light (2.2) (http://abload.de/img/linear-light5brc5.jpg)
OSD: scale 0,0,01920,1080 -> 0,91,953,627

[madshi]

However, imho gamma 1.6 clearly looks better with fonts or differently said: LL looks very wrong with fonts.
Screenshots? :p Not sure if fonts are the best way to judge which algorithm should be used. After all we're talking about movie playback. Still, would like to see screenshots that show what you mean.

[JarrettH]

Let's not drive ourselves crazy settling on a gamma value. I remember that conversation :D

[madshi]

EDIT: Nope, just enabling "scale in linear light" on a default config (reset settings) is causing this.

Source (may not be exact frame) (http://abload.de/img/source4mo9i.png)
Default Settings (http://abload.de/img/defaultvfpw0.jpg)
Linear Light (2.2) (http://abload.de/img/linear-light5brc5.jpg)
OSD: scale 0,0,01920,1080 -> 0,91,953,627
I can't seem to reproduce this problem on my PC with your Source image. Can you reproduce it with the PNG image? Or only with the video sample? Did you change anything (e.g. downscaling algo or trade quality settings or anything) in addition to activating the linear light downscaling option?

[aufkrawall]

Screenshots? :p Not sure if fonts are the best way to judge which algorithm should be used. After all we're talking about movie playback. Still, would like to see screenshots that show what you mean.
I did some more tests and with downscaling 4k -> WQHD, it pretty much didn't make any difference if LL or GL was used. Weird.

Well, but this is one clear example:
http://abload.de/thumb/nvqisqa.png (http://abload.de/image.php?img=nvqisqa.png)
Simply downscale it by ~20%. The differences between LL and GL should be very obvious. The same goes for bicubic 150 vs. SSIM.

Edit: However, I must say that with SSIM, LL looks most correct to me.

[nevcairiel]

I can't seem to reproduce this problem on my PC with your Source image. Can you reproduce it with the PNG image? Or only with the video sample? Did you change anything (e.g. downscaling algo or trade quality settings or anything) in addition to activating the linear light downscaling option?

http://files.1f0.de/samples/Banding_720p.rec709.mkv

On 0.90.6, it bands terribly in the dark areas when LL downscale is turned on, everything else on a fresh default settings reset.

0.90.4 was fine, didn't try with 0.90.5 since I missed that one. :)

[madshi]

I did some more tests and with downscaling 4k -> WQHD, it pretty much didn't make any difference if LL or GL was used. Weird.

Well, but this is one clear example:
http://abload.de/thumb/nvqisqa.png (http://abload.de/image.php?img=nvqisqa.png)
Simply downscale it by ~20%. The differences between LL and GL should be very obvious. The same goes for bicubic 150 vs. SSIM.
Hmmm... Downscaling this one only slightly looks much nearer to the original with LL for me. With GL the fonts become much too dark/bold.

http://files.1f0.de/samples/Banding_720p.rec709.mkv

On 0.90.6, it bands terribly in the dark areas when LL downscale is turned on, everything else on a fresh default settings reset.

0.90.4 was fine, didn't try with 0.90.5 since I missed that one. :)
Thanks, I can reproduce the problem with this sample. Should be easy enough to fix. Probably I used a too low bitdepth texture format in order to save performance... :o

[aufkrawall]

Hmmm... Downscaling this one only slightly looks much nearer to the original with LL for me. With GL the fonts become much too dark/bold.
Yep, see my edit with SSIM.
The reason why I found 1.6 better for bicubic 150 might be that it's much blurrier than SSIM in this case.
With bicubic sharpness 50 aka C-R, the fonts become quite "outwashed" with LL.

[GCRaistlin]

Why are you so sure that the OSD is incorrect? Is it just a guess or do you have concrete evidence?

I'm pretty sure because:

24 Hz is selected for this display in Windows.
ReClock reports 24 Hz and is green, not yellow as in case when the display is 60 Hz and the currently played video is 23.976 fps.
All madVR versions up to 0.90.3 reports 24 Hz.

What is more, the bug is unstable: sometimes (~1 time of 10) when I drop the player window with the video paused to the secondary display it goes black for a sec, just like the old versions do, and then OSD displays the correct (~24 Hz) refresh rate (I succeeded to log this case, too).
Logs (http://mir.cr/RD3FAJZM)


Does the refresh rate in the OSD still fluctuate a bit after it shows the "wrong" refresh rate?

Yes it does.

The log should then be on your desktop.
I suppose that the batch file would better inform an user about it.

[madshi]

Does this one fix the problem, GCRaistlin?

http://madshi.net/madVR907rc1.rar

It should also fix the banding issues when downscaling with linear light.

[Thunderbolt8]

Probably I used a too low bitdepth -texture format in order to save performance... :o0o I though it was all about

"- no shortcuts, highest quality has priority over anything else"

:D

[GCRaistlin]

Does this one fix the problem, GCRaistlin?

Unfortunately no: http://mir.cr/BSOKEQFY

[madshi]

Unfortunately no: http://mir.cr/BSOKEQFY
That log is *not* from the test build, but from official v0.90.6. Good thing I already renamed the test build to v0.90.7, otherwise I might not have noticed.

[GCRaistlin]

That log is *not* from the test build, but from official v0.90.6. Good thing I already renamed the test build to v0.90.7, otherwise I might not have noticed.

Yes, my fault, sorry. But you should have warned me that this test build won't create any logs if placed and installed (debug version) in a separate directory.
Anyway, now it works OK. Thank you!

[QBhd]

I just watched a 1080p film downscaled to my 1024x768 plasma and NNEDI3 was not being used for chroma. madVR seems to be falling back to JINC AR for some reason. This was not an issue two builds ago since I watched two movies Saturday night with v0.90.4

QB

[krille]

As already mentioned by huhn and Asmodian, this is probably the consequence of trying to use Jinc upscaling while the image needs to be upscaled in one direction but downscaled in the other direction. In that situation madVR uses Lanczos3 AR for both up- and downscaling. Maybe I should revisit that. Might make sense to use the selected downscaling method instead for the downscaling part.
Jinc is not chosen as upscaler. The same downscaler as upscaler is always choosen if the image needs to be upscaled in one direction but downscaled in the other direction. If I choose softcubic as the upscaler, softcubic is also choosen as the downscaler etc.

[4h4h270]

How does "now" define exactly? Starting with which madVR build? And which previous build did not have the problem?

Can you provide me with screenshots of the banding, compared to how a previous working madVR build didn't have banding in the same frame? Please also provide a screenshot of the original unscaled frame, so that I can try to reproduce the problem on my own PC. Which downscaling algo are you using?

Do you have any non-default "trade quality for performance" options selected, like e.g. "use 10bit image/chroma buffer" or something like that?

It happens from 0.90.6, I've tried 0.90.4 nothing wrong. I turn off all
"trade quality for performance" options. This bug can not reproduce by scrshot pic, only when playing video. Any downscale with linear light on and chroma upscale with reconstruction & jinc.

RAW:
http://abload.de/img/rawc1prg.png
0.90.6:
http://abload.de/img/rawc1prg.png
0.90.4:
http://abload.de/img/rawc1prg.png

[leeperry]

thanks for the new builds, just ran a few tests:

-first time I updated from .4 to .6 I was greeted with major posterizing but I don't seem to be able to reproduce anymore
-I don't like the 1.6 gamma thingie as it kills picture depth, I believe I prefer LL enabled but I would need to run more tests
-I can't get either SSIM options in .6 to look anywhere near as natural as in .4, I regularly get that stunning "look through a window" feeling with the latter but both options in .6 look way oversharp & aliased(I do run a combination of full SR + NNEDI for luma & RS for chroma so I'm on a tightrope so to speak), one being even worse than the other :o

time for some lighthouse ground truth comparisons I guess? should I use CC AR LL for the original 1080p>720p downscale?

[madshi]

now it works OK. Thank you!
Good to hear.

I just watched a 1080p film downscaled to my 1024x768 plasma and NNEDI3 was not being used for chroma. madVR seems to be falling back to JINC AR for some reason. This was not an issue two builds ago since I watched two movies Saturday night with v0.90.4
I suppose you're using linear light downscaling? Earlier madVR builds first upscaled chroma in that situation and then converted the image to RGB and then downscaled. The latest build may opt to scale luma and chroma separately for performance reasons. In that situation madVR only uses NNEDI3 for chroma upscaling if the upscaling factor needed for chroma is at least 1.5x. In your case it's 768/540 = 1.42, so madVR decided not to use NNEDI3 because it probably wouldn't bring any visual benefit.

I guess that's probably not something you like to hear? It does make sense to limit NNEDI3 to be used only for certain upscaling factors, though, especially for chroma (where upscaling quality is much less important than for luma, anyway). E.g. if you upscale chroma by only 5%, using NNEDI3 instead of e.g. Jinc or Lanczos wouldn't really bring any visible benefits. So I gotta define some upscaling factor at which NNEDI3 starts to be used.

-first time I updated from .4 to .6 I was greeted with major posterizing but I don't seem to be able to reproduce anymore
See last couple of posts. Should be fixed in the next build.

-I don't like the 1.6 gamma thingie as it kills picture depth, I believe I prefer LL enabled but I would need to run more tests
Ok, thanks.

-I can't get either SSIM options in .6 to look anywhere as natural as in .4, I regularly get that stunning "look through a window" feeling with the latter but both options in .6 look way oversharp & aliased(I do run a combination of full SR + NNEDI for luma & RS for chroma so I'm on a tightrope so to speak), one being even worse than the other :o
SSIM in .4 was partially broken, at least when using gamma downscaling. It works as intended in .6 now.

time for some lighthouse ground truth comparisons I guess?
The problem with that is that for downscaling we don't really have an objective groundtruth. You could make comparison screenshots, but with downscaling we're back at subjective "what looks better to your vs my eyes" judgement calls. The only way to judge this objectively would be to display the image in the original resolution on display A, then move display A back until the image has the same size as the downscaled image on display B. Then you can compare whether the downscaled image on display B looks near to the original res image on display A or not. But it will still be difficult to compare because it will be two different focus depths.

It happens from 0.90.6, I've tried 0.90.4 nothing wrong.
Should be fixed in the next build.

[madshi]

madVR v0.90.7 released

http://madshi.net/madVR.zip

* fixed: banding when using linear light downscaling (introduced in v0.90.5)
* fixed: some problems when moving madVR to a different monitor
* fixed: OSD display bug when using different scaling algos for X and Y

[4h4h270]

no more banding now :D

[leeperry]

SSIM in .4 was partially broken, at least when using gamma downscaling. It works as intended in .6 now.
I far prefer SSIM LL AR in .4 than in .6 as either of the two new options in the latter are too sharp and aliased for my other settings(both SR/RS/NNEDI3/FRC/etc). I understand that you want to remove as many options as possible but they are all very much dependent on each other, I mean I personally already find strength 1 of both SR's too sharp so in the end a very sharp picture through an über-sharp downscaler ends up aliased and oversharpened :(

The problem with that is that for downscaling we don't really have an objective groundtruth. You could make comparison screenshots, but with downscaling we're back at subjective "what looks better to your vs my eyes" judgement calls. The only way to judge this objectively would be to display the image in the original resolution on display A, then move display A back until the image has the same size as the downscaled image. Then you can compare whether the downscaled image looks near to that or not. But it will still be different to compare because it will be two different focus depths.
Right and for instance a videoprojector with 3 discrete panels will always suffer from misconvergence and strongly benefit from being fed a very sharp picture, but a LCD screen is plenty sharp to begin with so at the end of the day mVR is going for extreme sharpness but real life and cinema reels don't come with this "surgical" and harsh digital look, it should be possible for end-users to choose how sharp they want their picture and it's not quite possible atm in mVR if you want to enable all its bells & whistles :o

You made clear that soon there will only be one single SSIM button, either of them in .6 are useless to me when .4 looks so great <sigh>. You're the boss and I fullly respect that but how about a "soft" SSIM setting that wouldn't be any sharper than it was in .4 and another one called "sharp"? SSIM is meant to be sharper than CC AR LL but a sharpening downscaler without a single strength knob and when all other options(SR/RS/NNEDI3) are already extremely sharp all together end up next to unusable :scared:

My point is that bicubic downscaling now comes with as many as six sharpness options so you are effectively allowing us to subjectively pick its sharpness depending on the rest of our post-processing, personal taste and video display but SSIM is meant to go the other way around, with you deciding what looks subjectively best™ to you on your gear and us trying to adapt the rest of our settings to it.....but the only knobs I have access to are SR's and 1 is already VERY sharp for both of them =/

Oh well, talk about a missed opportunity bleh, I'll just bite the bullet and play around with the bicubic sharpness then. A sharper CC AR LL would be right up my alley I guess, hopefully I'll get it to deliver.

:thanks:

[NicolasRobidoux]

There should be no negative RGB data. If there is, luma/luminance would be negative, too, in the same situation. I'm currently scaling in RGB. In all my tests I could rarely see a difference when scaling in RGB vs YCbCr. I'm currently doing sigmoidization in linear light RGB, and it does seem to help in some specific situations, and hurt in others, same as last time we tested this. I'm pretty sure that converting to YCbCr and only applying sigmoidization to Y wouldn't change anything at all. All that would do is to limit the effect of sigmoidization to the brightness information, while keeping color information unaffected. But brightness is where all the positive and negative sigmoidization changes are happening already right now, when doing all this in RGB. There's no effect on colors that I can see. So I don't think doing this in YCbCr instead of RGB would make any difference.

Or did I misunderstand your suggestion?
I indeed was suggesting that you only use sigmoidization with Y (or Y').

Here is something I don't understand. How do you manage to make sure that >>without clamping<< your RGB (or R'G'B') values are (for example) never negative when they are obtained by a conversion from something like >>destructively compressed<< YCbCr?

[Warner306]

Hi Nicolas - long time no see! :)
First of all, atm all 3D related functionality in madVR is limited to 3D content coming from a compatible decoder with left and right eye images being sent separately. The only compatible decoder atm is nightly LAV and the LAV splitter currently only supports 3D MVC MKVs. This will hopefully be improved by nevcairiel soon. If you play movies which have the left & right images interweaved somehow (e.g. hard encoded as side-by-side), madVR treats them as 2D.

Your wiki might be a bit confusing to an end user, I think. Your "auto" section is probably meant to reach from "auto" until "Force 3D format below"? But in the midst of this "auto" section there are two more bold lines starting with "Active/Passive 3D". It's not totally clear if these still belong to the "auto" section or if they are meant to be separate sections. I'd optimize the font size and styles to make it clearer which parts of the text are meant to be one section and has which title etc.

The "Active/Passive 3D" lines are not clear. Since they stand under "auto", the end user might understand it as if madVR would automatically detect active/passive 3D displays and treat them differently. That's not the case.

"auto": madVR sends frame packed, if HDMI 1.4+ is available, *and* if the display supports this format. This can be an active or passive 3D display. If frame packing is not supported by either the GPU, OS or display, madVR instead renders the 3D video into "Half SBS".

"side-by-side": madVR renders Half SBS.

"top-and-bottom": madVR renders Half Top-and-bottom.

"line alternative" is described incorrectly. I'm not sure, maybe there's an official "line alternative" communication protocol that works as you describe. But that's not how madVR renders. This mode is for passive 3D displays which have polarizing filters which change polarization for each pixel row. The polarization is fixed, though. So for each frame sent by madVR, the odd lines are always for the same eye, and the even lines for the other eye. Odd/even does NOT change the eye from frame to frame.

"column alternative": same as "line alternative", just columns instead of rows/lines.

"swap left/right eye": This option is (in the long run) *not* meant to be used to fix sources which have the eyes in the wrong order. The problem with such sources should be fixed automatically by reading this information from the video file, and then communicating it to madVR. This will be added to future LAV + madVR builds. For now you can misuse this option to fix problems with such sources, but in the future this option has a different purpose: Some 3D displays *always* draw the images in the wrong order. So this option fixes that. Also for line/column alternative passive 3D displays it's not clearly defined which line/column is for which eye. So this option allows you to set that up correctly for each display.


Thanks for the clarification. I think I am (mostly) up to speed on how 3D tech works.

[Warner306]

Could someone tell me the advantages of turning off 3D in the operating system during playback of 2D or 3D videos?

[Patrik G]

there is a dude that still thinks his PS4 is the ultimate player for blu ray.
i need to convince him that madvr passes every blu ray player out there for PQ if you starting to make use of the chroma upscaling settings.
but of course you need a fast graphics card to get the most out of it.

have anyone compared the picture quality from madvr with an PS4?
when and with what settings will madvr pass it?
it cant be that hard right :)?

all i know is that i sold my Pioneer BDP-LX58 blu ray player last year after comparing it to madvr.
the PS4 must be way behind even that player right?