madVR - high quality video renderer (GPU assisted)

[6233638]

Originally Posted by 4h4h270

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

Originally Posted by huhn

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]

Originally Posted by NicolasRobidoux

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?

Originally Posted by GCRaistlin

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?

Originally Posted by GCRaistlin

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

Originally Posted by GCRaistlin

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.

Originally Posted by MaxPain

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.

Originally Posted by krille

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

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.

Originally Posted by scollaco

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

Originally Posted by dansrfe

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

https://drive.google.com/file/d/0B9i...zNfRE1JWTRMRW8

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?

Originally Posted by Sparktank

It's a good day to SIMMer down.

Originally Posted by 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.

Great - thanks for letting us know!

Originally Posted by ryrynz

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?

Originally Posted by ryrynz

Gamma light appears the most accurate with text on screen

Screenshots, please?

Originally Posted by ryrynz

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.

Originally Posted by 4h4h270

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?

Originally Posted by ryrynz

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?

Originally Posted by 6233638

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.

Originally Posted by 6233638

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.

Originally Posted by 6233638

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.

Originally Posted by Thunderbolt8

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.

Originally Posted by Trendle

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

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.

Originally Posted by aufkrawall

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.

Originally Posted by 6233638

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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.

Originally Posted by madshi

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.

Originally Posted by madshi

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)
• Default Settings
• Linear Light (2.2)

OSD: scale 0,0,01920,1080 -> 0,91,953,627

[madshi]

Originally Posted by aufkrawall

However, imho gamma 1.6 clearly looks better with fonts or differently said: LL looks very wrong with fonts.

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

[madshi]

Originally Posted by 6233638

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

• Source (may not be exact frame)
• Default Settings
• Linear Light (2.2)

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]

Originally Posted by madshi

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

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]

Originally Posted by madshi

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]

Originally Posted by aufkrawall

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:

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.

Originally Posted by nevcairiel

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

[aufkrawall]

Originally Posted by madshi

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]

Originally Posted by madshi

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:

1. 24 Hz is selected for this display in Windows.
2. 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.
3. 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

Originally Posted by madshi

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

Yes it does.

Originally Posted by madshi

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]

Originally Posted by madshi

Probably I used a too low bitdepth -texture format in order to save performance...

0o I though it was all about

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

[GCRaistlin]

Originally Posted by madshi

Does this one fix the problem, GCRaistlin?

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

[madshi]

Originally Posted by GCRaistlin

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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.