Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th May 2015, 21:15   #29901  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,882
Quote:
Originally Posted by Dogway View Post
How do you know that? shouldn't it be "chroma > nnedi16 > Mitchel..."?
the first chroma line is always the 4:2:0 to 4.4:4 part and nothing else.
and because there is no second chroma line image doubling is doing this.
Quote:
I never use smooth option (a gimmick IMO) but this is my PC monitor not my TV anyways.
why gimmick?

please don't compare it to frame interpolation like SVP or the interpolation from TVs.
but usually it is not needed on a TV anyway.
huhn is online now   Reply With Quote
Old 13th May 2015, 21:24   #29902  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 1,009
Quote:
Originally Posted by huhn View Post
the first chroma line is always the 4:2:0 to 4.4:4 part and nothing else.
and because there is no second chroma line image doubling is doing this.
I think I understand what you mean, first line is converting to 4:4:4, then it upscales the whole thing with nnedi (hence image >, and not luma >), but in my opinion it shouldn't be doing that... it's not a good idea to use a a scaler before nnedi because you are amplifying artifacts, also you are adding one more step to chroma.

chroma > mitchell > nnedi (double) > resizer (for up or downscale to 1080)

has the behavior changed in last version?

edit: btw I don't think what you say is right, I disabled chroma nnedi and I get the same OSD output.

Last edited by Dogway; 13th May 2015 at 21:28.
Dogway is offline   Reply With Quote
Old 13th May 2015, 21:32   #29903  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,683
Quote:
Originally Posted by Ver Greeneyes View Post
Changing the dithering pattern every frame is more effective because it adds a time-based element. Let's take Error Diffusion as an example with a hypothetical losslessly compressed test pattern showing large uniform patches of color. Without temporal dithering, each pixel is going to have a particular color all the time - rounded either up or down depending on its position. Only the patch taken as a whole will have the right color on average. With temporal dithering, each pixel will have the correctly rounded value on average.
I see the point, however this temporal effect isn't going to give "correct" pixels values because what value the pixel gets over time is random, not influenced by accumulated error. madVR's dithering is spacial dithering, not temporal, and the option does not change this.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 13th May 2015, 21:37   #29904  |  Link
Anime Viewer
Troubleshooter
 
Anime Viewer's Avatar
 
Join Date: Feb 2014
Posts: 333
jumping frames on pause

Quote:
Originally Posted by ibius View Post

Issues with D3D11:

3. Sometimes after seeking/stopping playback video gets stuck in a loop, jumping between few frames.
I noticed that too (when pausing videos), but wasn't sure how to word it. The best description I could think of at the time was it jumping back and forth between frames during pause. I've found that if you change scalers (up or down) it stops it and stabilizes the picture, so it may be a combination of D3D11 and scaler coding/changes.
__________________
System specs: Sager NP9150 SE with i7-3630QM 2.40GHz, 16 GB RAM, 64-bit Windows 10 Pro, NVidia GTX 680M/Intel 4000 HD optimus dual GPU system. Video viewed on LG notebook screen and LG 3D passive TV.
Anime Viewer is offline   Reply With Quote
Old 13th May 2015, 21:44   #29905  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 649
Quote:
Originally Posted by Asmodian View Post
I see the point, however this temporal effect isn't going to give "correct" pixels values because what value the pixel gets over time is random, not influenced by accumulated error. madVR's dithering is spacial dithering, not temporal, and the option does not change this.
It will, because the chance the pixel will be rounded up (or down) is proportional to it's remainder value.
The way it changes is random - so it's random temporal dithering. It might be possible to make it ordered (imagine 3D matrix for ordered dithering, which is "good" in all dimensions).

Ordered dithering works on probability too, the only difference from random is that it uses special "good" matrix. "Good" means that peaks and valleys are as far from each other as possible.

Last edited by vivan; 13th May 2015 at 21:53.
vivan is offline   Reply With Quote
Old 13th May 2015, 21:52   #29906  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,683
Quote:
Originally Posted by Dogway View Post
I think I understand what you mean, first line is converting to 4:4:4, then it upscales the whole thing with nnedi (hence image >, and not luma >), but in my opinion it shouldn't be doing that... it's not a good idea to use a a scaler before nnedi because you are amplifying artifacts, also you are adding one more step to chroma.

chroma > mitchell > nnedi (double) > resizer (for up or downscale to 1080)

has the behavior changed in last version?

edit: btw I don't think what you say is right, I disabled chroma nnedi and I get the same OSD output.
Remember the chroma is half the resolution of the luma so you need to upscale it before doubling somehow, an extra step for chroma is unavoidable. If you don't think it is a good idea to use mitchell before NNEDI3 don't tell madVR to do that. You can use NNEDI3 to do this first upscale as well (set it in 'chroma upscaling').

On my system with v0.87.21 if I disable chroma doubling I get a second chroma line below luma that says chroma is being upscaled with what is set in 'image upscaling' (and 'image' changes to 'luma'). I don't get the same OSD output if I disable chroma doubling.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 13th May 2015, 21:53   #29907  |  Link
Werewolfy
Registered User
 
Join Date: Feb 2013
Posts: 135
Quote:
Originally Posted by madshi View Post
Stupid me. I forgot that the refresh rate fix also needs new madHcNetXx.dlls. You'll find them here:

http://madshi.net/madVR885refreshRateFix2.zip

These files together with the modified madVR(64).ax should make the refresh rate work again.
Your fix never worked for me even before but this time it works! Thanks, great work.
__________________
Windows 8.1 x64 - Intel Core i5-4670K (4.2 GHz) - 8 GB DDR3 - MSI Geforce GTX 1080 8 GB - Sony KD-55A1
Werewolfy is offline   Reply With Quote
Old 13th May 2015, 22:07   #29908  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 1,009
Quote:
Originally Posted by Asmodian View Post
Remember the chroma is half the resolution of the luma so you need to upscale it before doubling somehow
I might be missing something but, can't you double chroma with nnedi3, then up to 4:4:4 target display resolution with the chroma upscaling kernel? Why do you need to do a mini-upscale first?
Dogway is offline   Reply With Quote
Old 13th May 2015, 22:09   #29909  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,882
Quote:
Originally Posted by Dogway View Post
I think I understand what you mean, first line is converting to 4:4:4, then it upscales the whole thing with nnedi (hence image >, and not luma >), but in my opinion it shouldn't be doing that... it's not a good idea to use a a scaler before nnedi because you are amplifying artifacts, also you are adding one more step to chroma.

chroma > mitchell > nnedi (double) > resizer (for up or downscale to 1080)

has the behavior changed in last version?

edit: btw I don't think what you say is right, I disabled chroma nnedi and I get the same OSD output.
make new screen with disabled nnedi3 chroma doubling. there should be a new chroma line.
huhn is online now   Reply With Quote
Old 13th May 2015, 22:15   #29910  |  Link
ibius
Registered User
 
Join Date: Jan 2005
Location: Germany
Posts: 52
Quote:
Originally Posted by ibius View Post
Issues with D3D11:
1. Going FSE is fine, but after first seek presentation glitches start piling up by the dozen every second during playback, enabling 'Present a frame for every v-sync' fixes it, but windowed FS mode works fine without. All queues apart from render queue (see below) are full at the time.
2. After going windowed FS or FSE, render queue is always only 3-5/8, other queues are full, and I get increased CPU usage, e.g. from ~7% to ~30% on my 3,6GHz Intel Core2Duo.
3. Sometimes after seeking/stopping playback video gets stuck in a loop, jumping between few frames.
4. Render times are better compared to D3D9, but present times are way worse, e.g. going from 0.12ms to 0.9x/1.xx ms in windowed mode, in windowed FS or FSE they are even higher (although only chroma is scaled).
I did more tests and figured out that disabling smooth motion fixes first issue.
Fun fact, without 'Present a frame for every v-sync' enabled, FSE starts piling up presentation glitches right after going into FSE, with smooth motion all was well until I tried to seek.
ibius is offline   Reply With Quote
Old 13th May 2015, 22:19   #29911  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 1,009
Quote:
Originally Posted by huhn View Post
make new screen with disabled nnedi3 chroma doubling. there should be a new chroma line.
yep, now chroma uses another scaler (third line), problem is it uses lanczos which I only set for luma upscaling... instead of mitchell
Dogway is offline   Reply With Quote
Old 13th May 2015, 22:34   #29912  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,882
Quote:
Originally Posted by Dogway View Post
yep, now chroma uses another scaler (third line), problem is it uses lanczos which I only set for luma upscaling... instead of mitchell
working as intended. the image upscaler was used in that version.
huhn is online now   Reply With Quote
Old 13th May 2015, 22:48   #29913  |  Link
XMonarchY
Registered User
 
Join Date: Jan 2014
Posts: 489
Quote:
madshi
Ok, good to hear. Is this with Jinc3 AR selected for image upscaling?

BTW, there's one difference between v0.87.x and v0.88.x that I forgot to mention: The setting for image quadrupling is now also applied for "octadrupling" and "hexadrupling". Meaning, NNEDI3 doubling is used as long as upscaling is needed. v0.87.x used NNEDI3 max twice, v0.88.x doesn't have this limit. Is it possible that NNEDI3 is used with v0.88.x on your PC more than twice? You can see that in the debug OS.
Yes, with Jinc 3 tap AR for Image Upscaling.

In OSD I just see this..:
Chroma>NNEDI32
Luma X>NNEDI32<Catmull-ROM AR
Chroma X> Catmull-ROM AR

I can even set Chroma Upscaling to NNEDI3 128 neurons and keep both Doubling and Quadrupling @ NNEDI3 32 neurons without any frame drops.

I have 2 separate questions:
- Is it worth disabling desktop composition?
- What is a good Shiandow's Deband setting for low/medium-low quality content? I know the original debanding settings for such content should be at least medium for strength and high for fade in/out
- I assume both algorithms can be used together (the original and Shiandow's?)

ALSO, 3DLUT organization is plain buggy. I have content specifically labeled SMPTE C In Ctrl+J menu is says SMPTE C), but if I place Rec.709 3DLUT into madVR Rec.709 line and place Rec.601 3DLUT into Rec.601 line, then madVR will actually use Rec.709 line and Rec.709 3DLUT to render content specifically labeled SMPTE C. The only way to use 3DLUT's accurately is to place all/any 3DLUT's into Rec.709 line in madVR, regardless of whether those 3DLUT's are Rec.601 or Rec.709. madVR will use Rec.709 line (and whichever 3DLUT in it) to render ANY content, regardless of whether that content is labeled Rec.709 or SMPTE C. I used the latest HCFR to test Rec.601 3DLUT in Rec.709 line and it came out just right - very accurate Rec.601 results. Someone stated that Rec.601 3DLUT in Rec.709 line in madVR would produce inaccurate/wrong results, but my HCFR testing proved otherwise. Its like madVR actually alters the 3DLUT in any way. It can only decide which 3DLUT to use, but that feature does not work.
__________________
8700K @ 5Ghz | ASUS Z370 Hero X | Corsair 16GB @ 3200Mhz | RTX 2080 Ti @ 2100Mhz | Samsung 970 NVMe 250GB | WD Black 2TB | Corsair AX 850W | LG 32GK850G-B @ 165Hz | Xonar DGX | Windows 10 LTSC 1809

Last edited by XMonarchY; 13th May 2015 at 23:28.
XMonarchY is offline   Reply With Quote
Old 14th May 2015, 00:01   #29914  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,683
Quote:
Originally Posted by Dogway View Post
I might be missing something but, can't you double chroma with nnedi3, then up to 4:4:4 target display resolution with the chroma upscaling kernel? Why do you need to do a mini-upscale first?
Isn't that the same thing?

1920x1080p 4:2:0 source.

step 1) 960x540 chroma to 1920x1080 using 'chroma upscaling'. This is the only step 'chroma upscaling' is used for. This converts the 4:2:0 to 4:4:4.
step 2) 1920x1080 chroma to 3840x2160 with NNEDI3 (chroma doubling) or, if not doubled, to the target resolution with 'image upscaling'.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 14th May 2015, 00:52   #29915  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by GCRaistlin View Post
Quote:
Originally Posted by madshi
I could list the modes which are in the edit fields for display mode switching
Yes, this would be great.
Well, to be honest, I don't think this is a good time to add this feature. The whole refresh rate changing will be rewritten sooner or later and work quite differently to how to works now. It makes more sense to wait until then.

Quote:
Originally Posted by vivan View Post
Btw, can we get dithering for every frame presented? With Dx11 path and "present every vsync" option that should beat any FRC.
For high quality junkies I would strongly recommend to match refresh rate to movie frame rate. If you do that, you already get a changing dithering for each frame right now. Of course it would be possible to change the dither pattern for repeated frames, too, if the refresh rate is higher than the movie framerate. But it would increase GPU power consumption, and to be honest, I have a *lot* of things to do which hopefully bring a bigger image quality improvement than that would bring. Just my 2cents, of course.

Quote:
Originally Posted by x7007 View Post
I guess it's a known issue with Madvr 88.4 and 88.5 because I have an issue watching any movie with some random presention error and Renderer queue and all others are not full.
I'm not sure what you mean. There are known issues with 88.4 and 88.5, but not those you're describing.

Quote:
Originally Posted by x7007 View Post
What is the differences between Font Renderer : Vector Text Renderer and Bitmap Text Renderer ?
I have no idea. madVR doesn't have any such options.

Quote:
Originally Posted by ibius View Post
1. Going FSE is fine, but after first seek presentation glitches start piling up by the dozen every second during playback, enabling 'Present a frame for every v-sync' fixes it, but windowed FS mode works fine without. All queues apart from render queue (see below) are full at the time.
You will have to use "present a frame for every v-sync" then. Driver bug or D3D11 bug, not my fault.

Quote:
Originally Posted by ibius View Post
2. After going windowed FS or FSE, render queue is always only 3-5/8, other queues are full, and I get increased CPU usage, e.g. from ~7% to ~30% on my 3,6GHz Intel Core2Duo.
This is exactly the effect you would get with "Nvidia control panel 'Max. pre-rendered frames'" set to a fixed low value. So my best guess is that either the GPU uses a different setting for this behind your back, or there are profiles active somehow which set a low value for this, or there's some GPU driver bug, or something.

Quote:
Originally Posted by ibius View Post
3. Sometimes after seeking/stopping playback video gets stuck in a loop, jumping between few frames.
Doesn't occur on my PC. Please try again with the next build.

Quote:
Originally Posted by ibius View Post
4. Render times are better compared to D3D9, but present times are way worse, e.g. going from 0.12ms to 0.9x/1.xx ms in windowed mode, in windowed FS or FSE they are even higher (although only chroma is scaled).
Again this points to "Max. pre-rendered frames" not being set correctly. Or the GPU ignoring that settings.

Quote:
Originally Posted by tobindac View Post
I noticed that ordered dithering is a very noisy process. I found it fun lately to turn on 1bit output and see very obviously some algorithmic patterns. It appears not dithering at all gives the most "stable" unnoisy picture while error diffusion is more stable and 'random' is a total mess.

I'm surprised, but it appears no dithering at all is a viable choice.
"No dithering" is not a viable choice *at all*. Testing with 1bit is not a good test for this. Try 2bit. See here:

http://madshi.net/2bitNoDithering.png
http://madshi.net/2bitOrderedDithering.png

(CAUTION: Please zoom the images in the browser to 100%, otherwise the dither pattern will look ugly.)

I think no sane human could possibly prefer the image with no dithering there.

Quote:
Originally Posted by nevcairiel View Post
You will *always* need dithering, because its about the mathematical process, not about the quality of the source. In fact, its entirely independent of that (although its going to be more obvious in some sources than in others, of course)
If such a perfect source would exist, then dithering also wouldn't add noise, since dithering, by definition and design, is only used to spread the rounding error to multiple pixels, instead of accumulating it all in one. If there wouldn't be a rounding error, there would be no "noise".

At the end of the day, movies are all going to be in YUV, and YUV needs to be converted to RGB. This conversion process (if done right) results in floating point values, which need to be converted to 8-bit (or recently, 10-bit) on output. If you don't use dithering, you will effectively cut off data. Thats also were your analogy goes wrong, dithering isn't about hiding flaws, its about preserving data when converting to a lower bitdepth (ie. from 16/32-bit float, to 8/10-bit integer for output)

Of course you are free to use whatever settings you like, but please don't spread them as advice.
QFT.

Quote:
Originally Posted by Dogway View Post
I'm a bit confused when you ask "what mode my PC is", where should I look that? Control panel just said (roughly) 1080 native, 60Hz.

Anyways I had a look and I don't find any video that turns my TV to 1080p60 mode, it stays always in PC mode which is fine and bad at the same time... I would expect a bit more consistency for these things (I should be able to treat 60fps sources as every other non-PC source, TV settings wise). 1080p59 is also defaulting to PC mode.

Then I played a 50fps video and screen turned to 50p mode, so here the story does apply.
Anyways I removed the 1080p50 entry and it defaulted to 1080p60 now seemingly and oddly enough "PC mode" (I still think passthrough should be a better idea?).
Sounds all good to me?

Quote:
Originally Posted by cvrkuth View Post
My playback is fine (no dropped frames, no glitches).

Anyway, just for info .. when I watch movie 24.000 and refresh rate fix is active, render queue and present queue are low (render queue 3-5/8 and present queue 2-3/8. Average stats present 31.00 ms which is abnormally high, usually 0.05 ms.)
Sounds like you have "Nvidia control panel 'Max. pre-rendered frames'" set to a fixed low value. Set it to "application control".

Quote:
Originally Posted by Werewolfy View Post
Your fix never worked for me even before but this time it works! Thanks, great work.
Cool! I did improve it a bit, hoped it might work better in some exotic cases now.

Quote:
Originally Posted by XMonarchY View Post
ALSO, 3DLUT organization is plain buggy. I have content specifically labeled SMPTE C In Ctrl+J menu is says SMPTE C), but if I place Rec.709 3DLUT into madVR Rec.709 line and place Rec.601 3DLUT into Rec.601 line, then madVR will actually use Rec.709 line and Rec.709 3DLUT to render content specifically labeled SMPTE C.
How do you know it uses the BT.709 3dlut? If that is really the case, it's a bug and then please enter it to the madVR bug tracker.
madshi is offline   Reply With Quote
Old 14th May 2015, 01:00   #29916  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
madVR v0.88.6 released

http://madshi.net/madVR.zip

Code:
* fixed: D3D11 rendering sometimes got stuck (e.g. when minimizing player)
* fixed: NNEDI3 quadrupling with SuperRes didn't work properly (NVidia only)
* fixed: refresh rate fix didn't work in 64bit
* added D3D11 refresh rate fix (proper support for 23p vs. 24p etc)
* added option "octuple luma/chroma resolution"
* re-added NNEDI3 chroma doubling options
* removed limitation to double chroma with Catmull-Rom
* updated Shiandow deband algorithm to latest version
* double clicking tray icon now opens the settings dialog
Please note that image/luma octupling is only applied if you use any of the "upscaling refinement" options. Otherwise this option will be ignored because without "upscaling refinement" the image becomes so soft after quadrupling that there's no use using expensive octupling at that point. Octupling can be useful for upscaling DVDs to 4K (640 > 1280 > 2560 > 5120 < 3840).

Shiandow's deband algorithm was updated to the latest version. Could everyone please re-test? Please note that the defaults have changed, but the settings dialog will remember your previous values. So please manually change the values to threshold 0.2 and detail level 1, and start testing with those values. Your vote counts in deciding whether I'll keep using the "old" debanding algorithms or whether I'll replace some or all of the old algos with the new one. If you're not sure which one you like better, please say just that, instead of randomly picking one. If you do like one clearly better than the other, please let me know - thanks!!

Edit: Shiandow has released yet another fine tuned version of his Deband algorithm. Please copy the code from the following post into the file "madVR\legal stuff\Shiandow\Deband.hlsl", then madVR will immediately use the new Deband version:

http://forum.doom9.org/showthread.ph...49#post1721949

Last edited by madshi; 14th May 2015 at 08:16.
madshi is offline   Reply With Quote
Old 14th May 2015, 01:54   #29917  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,716
Thanks a lot for these changes and fixes.

Could it be that Shiandow's deband doesn't work as intended with this version? I can't see any positive effect.
As a reminder, madVR's and Shiandow's old deband filters:
http://forum.doom9.org/showpost.php?...ostcount=29510

Shiandow new (new default values):


Threshold changed to 2.0:


Changing detail levels doesn't change much.

I also quickly benchmarked performance impact of Jinc3 chroma scaling over C-R (both AR) when doing NNEDI3 64 luma quadrupling.
GPU usage was pretty much totally identical (and clocks too):

Last edited by aufkrawall; 14th May 2015 at 03:11.
aufkrawall is offline   Reply With Quote
Old 14th May 2015, 02:26   #29918  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 752
Quote:
Originally Posted by aufkrawall View Post
Thanks a lot for these changes and fixes.

Could it be that Shiandow's deband doesn't work as intended with this version? I can't see any positive effect.
As a reminder, madVR's and Shiadow's old deband filters:
http://forum.doom9.org/showpost.php?...ostcount=29510

[...]
Hmm, that's not quite what's supposed to happen. For now could you try placing a file called "Deband.hlsl" in the MadVr/legal stuff/Shiandow folder, with the code below? Since madshi has been so kind to conform to the LGPL requirements this should replace the internal shader. In the code below I've removed one of the steps in the algorithm that may have been causing those problems.

Code:
// This file is a part of MPDN Extensions.
// https://github.com/zachsaw/MPDN_Extensions
//
// This library is free software; you can redistribute it and/or
// modify it under the terms of the GNU Lesser General Public
// License as published by the Free Software Foundation; either
// version 3.0 of the License, or (at your option) any later version.
// 
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
// Lesser General Public License for more details.
// 
// You should have received a copy of the GNU Lesser General Public
// License along with this library.
// 
sampler s0 : register(s0);
sampler s2 : register(s2);
float4 infoConsts1 : register(c0);
float4 infoConsts2 : register(c1);
#define size1 (infoConsts1)
#define ppx (infoConsts1[2])
#define ppy (infoConsts1[3])
#define acuity (infoConsts2[0])
#define threshold (infoConsts2[1])
#define sqr(x) dot(x,x)
#define norm(x) (rsqrt(rsqrt(sqr(sqr(x)))))
#define Get(x,y) (tex2D(s2,float2(ppx,ppy)*(pos + 0.5 + float2(x,y))).xyz)
static const float3x3 YUVtoRGB_709 =
{1.0,  0.0000000000000000,  1.5748000000000000,
 1.0, -0.1873242729306488, -0.4681242729306488,
 1.0,  1.8556000000000000,  0.0000000000000000};

float4 main(float2 tex : TEXCOORD0) : COLOR0
{
  float4 c0 = tex2D(s0, tex);
  float2 pos = tex * size1.xy - 0.5;
  float2 offset = frac(pos);
  pos -= offset;
  float4x3 X = {Get(0,0), Get(1,0), Get(0,1), Get(1,1)};
  float3x4 LinFit = {{-2, 2, -2, 2}, {-2, -2, 2, 2}, {1, 1, 1, 1}};
  float4 w = 0.25*mul(float1x3(offset-0.5,1), LinFit);
  float3 avg = mul(float1x4(w), X) / dot(w, 1);
  float3 diff = avg - c0;
  diff -= clamp(diff, -0.5 / acuity, 0.5 / acuity);
  float str = smoothstep(0, threshold, length(diff*acuity));
  c0.xyz = lerp(avg, c0, str);
  c0.rgb = mul(YUVtoRGB_709, c0.xyz - float3(0.0, 0.5, 0.5));
  return c0;
}

Last edited by Shiandow; 14th May 2015 at 03:37.
Shiandow is offline   Reply With Quote
Old 14th May 2015, 02:46   #29919  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,716
Yes, issue is gone. But the result is probably not better than with the previous madVR versions?
aufkrawall is offline   Reply With Quote
Old 14th May 2015, 02:58   #29920  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 752
Quote:
Originally Posted by aufkrawall View Post
Yes, issue is gone. But the result is probably not better than with the previous madVR versions?
Is that a question or are you not seeing any improvement? In theory it should still be better than the previous one.
Shiandow is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 22:36.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.