madVR - high quality video renderer (GPU assisted)

[scollaco]

madVR supports custom pixel shaders just fine. Just load them like you would for EVR, in MPC-HC at least. Needs to be supported in your player.

FineSharp is an avisynth plugin. It's probably the best sharpening algorithm out there but there's no way to use it post-resize with madVR due to ffdshow raw not being able to go after madVR in the processing chain.

I started playing with LumaSharpen 1.4.1 which can be added as a post resize filter. Anyone else using this or has any opinions about it? I don't have ffdshow....but using LAV instead. Any other sharpening filters considered subjectively better than lumasharpen?

[StinDaWg]

Then why would you quote a post about pixel shaders?
You're free to port it to a pixel shader though.
Did you even read madshi's response? The question I quoted was about using FineSharp. If I knew how to port it to a MPC-HC compatible shader I wouldn't be in here asking this question.

I started playing with LumaSharpen 1.4.1 which can be added as a post resize filter. Anyone else using this or has any opinions about it? I don't have ffdshow....but using LAV instead. Any other sharpening filters considered subjectively better than lumasharpen?
I'm using LamaSharpen right now as well, but from what I understand FineSharp is better because it doesn't mess with the contrast of the picture and give off that unsharp mask look where whites get brighter and everything has a bit of a glow effect to it.

[James Freeman]

IMO, nothing currently beats LumaSharpen 1.4.1.
Its the best looking sharpen algorithm, I use it myself.

I use:
#define sharp_strength 1.5
#define sharp_clamp 0.05
#define pattern 3

or

#define sharp_strength 0.7
#define sharp_clamp 0.05
#define pattern 8

[scollaco]

IMO, nothing currently beats LumaSharpen 1.4.1.
Its the best looking sharpen algorithm, I use it myself.

I use:
#define sharp_strength 0.7
#define sharp_clamp 0.05
#define pattern 3

Yes...I tried those settings as well...it's looking real good. Torn between the default and these ones. How did you arrive at these settings?

I've never tried FineSharp but my curiosity is piqued.

[James Freeman]

I edited my previous post.

[scollaco]

I edited my previous post.

Yes...both sets of numbers look good. Pretty happy with the image.

[sexus]

wait what , so you guys use pixel shaders as well , now im confused only one ive ever used was for pre-resize pixelshader > gamma conversion of video RGB to linear RGB for floating point surfaces

and for post-resize pixel shaders> gamma conversion of linear RGB to wide gamut RGB for floating point surfaces


hell apparently you can stack shaders as well , atleast in potplayer , not sure the use thou

what am i missing out on here and for debanding i use madshis default settings aka default debanding strength low and strength during fade in/out high < this replacing ffdshows excellent high quality default setting debanding as i understand , only reason why ive ever held onto it since it removed banding in black , most noticeable in animes displaying greys and blacks

[scollaco]

So after comparing the images it looks like sRGB was the closest match to the original for me. Power curve 2.2 being the next closest. I did output my nvidia card to PC (0-255) and my display is also set to accept full RGB levels.

|- gamma (http://madshi.net/avatar2bitGamma.png) -|- original (http://madshi.net/avatar8bit.png) -|- linear (pure power 2.22) (http://madshi.net/avatar2bitLinear.png) -|- linear (pure power 2.4) (http://madshi.net/avatar2bitPurePower24.png) -|- linear (sRGB 2.4) (http://madshi.net/avatar2bitSRGB.png) -|- linear (BT.709 2.22) (http://madshi.net/avatar2bit709.png) -|- linear (BT.709 2.4) (http://madshi.net/avatar2bit709_24.png) -|
So now that sRGB seemed to be the closest match...what do I put in the "calibrated to" and "desired gamma" settings?

I had another noob doubt question. If my display is calibrated to sRGB image and I was told that conforms to approx 2.2. Why does madshi's post say "linear(sRGB 2.4)"? That image was the closest match to the original on my projector. Should I set "calibrated to" to 2.2 or 2.4? and then adjust "desired gamma" to taste.

[scollaco]

wait what , so you guys use pixel shaders as well , now im confused only one ive ever used was for pre-resize pixelshader > gamma conversion of video RGB to linear RGB for floating point surfaces

and for post-resize pixel shaders> gamma conversion of linear RGB to wide gamut RGB for floating point surfaces


hell apparently you can stack shaders as well , atleast in potplayer , not sure the use thou

what am i missing out on here and for debanding i use madshis default settings aka default debanding strength low and strength during fade in/out high < this replacing ffdshows excellent high quality default setting debanding as i understand , only reason why ive ever held onto it since it removed banding in black , most noticeable in animes displaying greys and blacks

I never used to use filters since madVR is so excellent. But recently tried the LumaSharpen 1.4.1 and it subjectively makes the image have more crispness to me..especially for 720p stuff. 1080p looks good with/without it..again subjectively :)

For debanding...I just use madVR default (low) and the fade-in setting set ot high (Is there another suggestion for this that's better?

[James Freeman]

An sRGB curve is 2.4 but with a linear portion for the first black steps in its formula.
It averages (how it looks) to about 2.2 power curve, its well known.


I wonder what madshi is cooking, he hasn't said a word all day long...

[the_weirdo]

Did you even read madshi's response? The question I quoted was about using FineSharp.

Did you even read madshi's response? According to the response you quoted, madshi just said he's going to "add support for custom pixel shaders" for madVR, which he's already did in recent versions. He didn't say anything about making FineSharp works with madVR, but implied that if someone ports it to pixel shader then it'll be supported by madVR. IIRC, he's stated that he may add sharpening feature in a future version of madVR, though.

[scollaco]

An sRGB curve is 2.4 but with a linear portion for the first black steps in its formula.
It averages (how it looks) to about 2.2 power curve, its well known.


I wonder what madshi is cooking, he hasn't said a word all day long...

Thanks for the clarification!

[yok833]

Would you say that Lumasharpen is good to use with HD content or do you prefer finesharp? Actually I m using LSF and I m pretty happy with it but nobody seems to mention it as an option?

Envoyé de mon GT-I9300 en utilisant Tapatalk

[scollaco]

Did you even read madshi's response? The question I quoted was about using FineSharp. If I knew how to port it to a MPC-HC compatible shader I wouldn't be in here asking this question.


I'm using LamaSharpen right now as well, but from what I understand FineSharp is better because it doesn't mess with the contrast of the picture and give off that unsharp mask look where whites get brighter and everything has a bit of a glow effect to it.

hmm...I'm not noticing any unsharp effect or blooming glow effect with LumaSharpen. I've not tried FineSharp...so I'm curious how they differ.

[MSL_DK]

I want to take some screenshot with and without a 3DLUT applied to compare and prove the effect and quality. How is this done with an 3DLUT?

[huhn]

print screen. don't forget these screens only work right on the source screen!

[madshi]

Uuh, a lot of comments, not all of them madVR related. I'll skip most of them. Here just a few replies:

But I still have two questions regarding that. Where and how is the gamma correction (if any) applied? And what transfer function does smooth motion use to go to and from linear light?
Gamma "correction"? You mean gamma processing? That is done somewhere in the middle of the processing chain, IIRC. Gamma "correction" (as in fixing incorrect display gamma response) is done by the 3dlut or the 1dluts, which is done as the next to last step, right before dithering.

Smooth motion uses a pure power function of 1/0.45.

STEPS:
1) I cycle through the images using some kind of image viewer?. Whichever looks closet to the "original" image is the one that my projector uses.
Yeah, but *PLEASE* make sure you view the images in 100%. If your image viewer scales the images in any way, the results will get totally screwed.

I've said this before, but just as a reminder, ICC profiling is designed *precisely* to solve this very problem. ICC has one job and one job only: to describe the display's response. If madVR supported ICC color management (instead of manual 3DLUTs), this problem would go away entirely. madVR could achieve complete awareness of the display's transfer function.
That's nice. But this only solves one problem out of many. If I actually wanted to make use of this information from the ICC profile, I'd probably have to build 1dluts for all linear<->gamma conversions where I'd want to use the display's native transfer function. Which would slow processing down, and potentially lower accuracy (linear lut interpolation is not as accurate as math functions). Furthermore, there's still the headache of a hundred different setups which all use a different processing pipeline. E.g. GPU gamma ramps or not. Overlay mode or not. 3dlut or not. That alone makes 8 combinations, each of which probably has different consequences. Some things I don't even know how to properly evaluate: E.g. if my dither is using the exact native display transfer function, but the GPU applies 1d ramps *after* I've done the dithering, I've no idea what effect that would have. Maybe I could take this into account for dithering somehow, but then I'd have to know in which bitdepth the GPU applies the 1d ramps, and that differs depending on output port type (analog/digital) etc. This is all so complicated, and if I don't think every potential processing chain combination through perfectly without making any mistakes, I could screw things up more than I improve things. And if I *do* think everything through perfectly, it would probably cost me several 8-hour working days to implement this properly for all possible combinations, and make the code more difficult to understand and more complicated to handle in the future, too. And all of this for incredible small image quality benefits? No thanks, I think I'll rather stick to using a simple power function for linear <-> gamma light conversions.

I presume that the final LL build might yield different/better results so I'm really looking foward to trying it :)
It will be different for lower bitdepths, but not for 8bit.

On a completely different subject, might it be possible to increase the number of backbuffers in Windowed mode beyond 8?
They are some things on my PC which seem to "reset" the present/backbuffer queues (or drop a lot) and in FSE mode with 16 frames presented in advance it drops down to 1-15/16 or 0-15/16 but never seems to actually drop frames so playback remains smooth.
In Windowed mode where the limit is 8, this causes it to drop/repeat frames.
Offering more buffers shouldn't be much of a problem, but I doubt it will help. I'm not sure why the backbuffer/present queue drops down in FSE mode so much, but I think the reason why you still get smooth playback is not because of the higher number of backbuffers, but just because FSE mode is simply better. What happens if you reduce the number of pre-presented frames to 8? Do you then get the same problems as in windowed mode?

I believe in windowed mode the real bottleneck is not the number of backbuffers, but the natural limitations of windowed mode. I don't see much use in more backbuffers in windowed mode, due to the way it works internally.

Going above 16 in FSE mode might be nice too.
I've had serious playback problems when trying that. Ok, that was quite some time ago, maybe these were solved in the meanwhile. But I'm afraid some users will get really bad problems this way and then I might get flooded with complaints about audio/video desync, stuttering etc. I'd rather play it safe for now and stick with 16. Maybe some time in the future we can revisit this, but not now.

I've noticed that in the latest versions of madVR/madTPG it is no longer possible to enable both VideoLUTs and 3dlut calibrations at the same time, which I thought would be helpful to test the result of a 3dLut on top of GPU gamma ramps.

Is there a reason why this option is no longer offered?
madTPG doesn't allow you to "enable" these things. You can just disable them, or not disable them. So I'm not 100% sure what you mean. If you have GPU gamma ramps loaded, and haven't told either madVR nor madTPG to disable them, then they should stay active/installed - unless the software which remote controls madTPG tells madTPG to disable the GPU gamma ramps. ArgyllCMS does that, I think. But HCFR not, AFAIK.

Separately, as I've noticed that on a dual display system, Windows gets confused with loading the right ICC/gamma ramps for a given display (when switching between two calibrated displays, etc.)
This is already listed in the madVR bug tracker.

is generating a 3dlut via madTPG with both VideoLUTs and 3dlut disabled and setting madVR to disable GPU gamma ramps the right approach, or is there a better solution?
This is more a topic for the AVSForum "madVR / ArgyllCMS" thread, I think. I'm not really a big expert on calibration. You might get better help about this topics there.

I'm quoting this post from 2012. I've been playing around with FineSharp and I really like the look of it, but it kills me that I can only use this pre-resize due to the way ffdshow raw works. FineSharp is better used post-resize otherwise it just oversharpens the image. Is there just no way I can get this to work with madVR?
Yes, there is a way: You can scale with ffdshow/AviSynth, then apply FineSharp, then let madVR do the rest. Of course this way you can't use madVR's upscaling methods.

I want to take some screenshot with and without a 3DLUT applied to compare and prove the effect and quality. How is this done with an 3DLUT?
Use normal windowed mode, then press the PrintScreen key.

[madshi]

madVR v0.87.7 released

http://madshi.net/madVR.zip

* added linear light processing for ordered dithering and error diffusion
* added "trade quality for performance" option for linear light dithering
* fixed: #175: Banding appears if bitdepth is set to '7 bit'
* fixed: crash in MC19 when switching videos with native DXVA decoding
* random dithering doesn't round down to less than 8bit, anymore
* "present several frames in advance = off" now auto-disables error diffusion
* display bitdepth can be be set to as low as 1bit (just for testing)
* fixed rare overlay stability problems introduced in v0.87.5
* added silent exception handling for Intel OpenCL initialization crashes
* madTPG now optionally supports APL windows (gamma and linear light)
* madTPG now has a minimum image area of 4% instead of 10%
* madTPG now draws a 20 pixel black border around the measurement area
* madTPG now properly supports dynamic dithering (didn't before)
* madTPG dithering was optimized to not dither for integer test patterns
* madTPG headers and demo projects updated
* madVR in a media player no longer supports test pattern, only madTPG does
I'm now using an sRGB curve for dithering of bitdepths smaller than 8bit. For 8bit dithering I'm using a pure power 1/0.45 curve.

[turbojet]

madshi: Is overlay being at least 16 shades(?) darker than window and FSE mode over nvidia svideo an issue that can be corrected by madvr?

[6233638]

Offering more buffers shouldn't be much of a problem, but I doubt it will help. I'm not sure why the backbuffer/present queue drops down in FSE mode so much, but I think the reason why you still get smooth playback is not because of the higher number of backbuffers, but just because FSE mode is simply better. What happens if you reduce the number of pre-presented frames to 8? Do you then get the same problems as in windowed mode?

I believe in windowed mode the real bottleneck is not the number of backbuffers, but the natural limitations of windowed mode. I don't see much use in more backbuffers in windowed mode, due to the way it works internally.Unfortunately, it looks like you are correct. Windowed mode drops 30+ frames at a time, Windowed Overlay drops 1-2 at a time, and FSE doesn't drop frames even if I reduce it to only presenting two frames in advance.

Now that the refresh rate issues are fixed, I'm able to use FSE mode again, but I was so used to playback being seamless when using Windowed mode that I'll have to see if I can find another solution.

I'm now using an sRGB curve for dithering of bitdepths smaller than 8bit. For 8bit dithering I'm using a pure power 1/0.45 curve.Cue 10 pages of arguments...
(I'm OK with this)

[XMonarchY]

And yet another grand release
From mighty "mad" - my soul's caprice.
He's "mad" but also "shi", yes - "shi",
A great name combo for all times to be!

The above was written with assumption that madshi is pronounced like madshee, and not madshy/madshai


I'm now using an sRGB curve for dithering of bitdepths smaller than 8bit. For 8bit dithering I'm using a pure power 1/0.45 curve.

Does that mean the image will be darker if the display is set to use BT.1886 gamma via 3DLUT in contrast to the previous madVR release?

[hannes69]

2 short questions:
1. I have a 6bit + FRC LCD display. What is the "right" setting (I know you hate this kind of question:cool:) for "the native display bitdepth is:" ?
a) 6 bit
b) 8 bit
c) use test patterns and decide what´s looking best for you:p

2. Is there a workaround for using 23,976 and 24,000 Hz refresh rates side-by-side in Windows for use with the display switcher (I don´t want to use smoothmotion or Reclock and my projector only accepts refresh rates in the 30Hz - 60 Hz region so actually I want to use 47,952 and 48,000 Hz with the EDID override method, I have to lower both refresh rates because of the clock deviation, so I end up with two 47,xxx refresh rates, Windows can´t distinguish them...)

Thanks for your help ;)

[XMonarchY]

I apologize for off-topic, but how do I add this LumaSharpen 1.4.1 script or custom whatever-it-is to madVR? I use JRiver with madVR... I also have MPC-HC. I keep hearing people talk about it as something worth a try!

[JarrettH]

What is the 7-bit bitdepth option for anyway? :p

edit: Hannes69 asked the same question as me basically

Is linear light processing for dithering supposed to be better? In general, I'd be interested in a little blip about linear light processing. Thanks madshi

[turbojet]

I apologize for off-topic, but how do I add this LumaSharpen 1.4.1 script or custom whatever-it-is to madVR? I use JRiver with madVR... I also have MPC-HC. I keep hearing people talk about it as something worth a try!

You can't use it with jrmc until it or madvr adds pixel shader support. To use it with mpc-hc copy the script (check my sig) into a txt file, rename it .hlsl and put it in mpc-hc's shaders directory. In mpc-hc right click>shaders>select shaders.

The defaults are horrible, I'd suggest pattern 3 and adjusting strength between 0.5-2.0, increasing clamp improves really fine detail without artifacts if adjusted correctly, I use 0.5.

[noee]

madshi,
I think there's a problem with jRiver. If I start playback on my secondary monitor (FSE mode) all looks good, but then when I click on anything like an icon or a window on my primary, video goes to black, but it keeps playing and I still get audio. I can get it back by double-clicking (to display mode back to primary) and then going full screen again. No issues like this with any prev madVR versions...

CCC14.2B, jRiver MC19 b122

Lemme know if you want a log.

[Shiandow]

Gamma "correction"? You mean gamma processing? That is done somewhere in the middle of the processing chain, IIRC. Gamma "correction" (as in fixing incorrect display gamma response) is done by the 3dlut or the 1dluts, which is done as the next to last step, right before dithering.

Oh I see, I didn't expect gamma processing and gamma correction to be treated differently. I also expected both to come after smooth motion. Doing gamma processing before smooth motion makes it more or less impossible to do the linear light correction at the same time. I still think that doing the gamma processing 'implicitely' by using two different gamma curves for smooth motion is somewhat more elegant, since you can interpret it as displaying the source using an ideal monitor and then encoding the result using the gamma curve of the actual monitor (or an approximation thereof). This approach seems more intuitive and flexible, but I'd understand if you don't want to spend too much time on something which doesn't really improve picture quality.

[DigitalLF]

MadShi!!!! ESET Smart Security think your newest version is a virus.. "Probably unknown NewHeur_PE virus"... I'm just informing you even if there is no virus...

[JonnyRedHed]

MadShi!!!! ESET Smart Security think your newest version is a virus.. "Probably unknown NewHeur_PE virus"... I'm just informing you even if there is no virus...

I've reported it to ESET.

[XMonarchY]

I received an e-mail from nVidia regarding OpenCL <-> D3D9 interop problem. They are investigating it still, but at least we (or I) know they are aware of it.

[Eiffel]

madTPG doesn't allow you to "enable" these things. You can just disable them, or not disable them. So I'm not 100% sure what you mean. If you have GPU gamma ramps loaded, and haven't told either madVR nor madTPG to disable them, then they should stay active/installed - unless the software which remote controls madTPG tells madTPG to disable the GPU gamma ramps. ArgyllCMS does that, I think. But HCFR not, AFAIK.


What I meant is that with the latest versions of MadTPG (at least until today), it is no longer possible to 'not disable' both the VideoLUTs and 3dlut at the same time. In other words, at least one of the two buttons is "blue"

HCFR has options to disable the VideoLUT or 3dlut (under Measure - Generator - Configure), but it can't undo what is disabled by MadTPG

[seiyafan]

Sorry I missed the party, what visual improvement does "linear light processing for ordered dithering and error diffusion" do?

[sexus]

I received an e-mail from nVidia regarding OpenCL <-> D3D9 interop problem. They are investigating it still, but at least we (or I) know they are aware of it.

after all the money ive spent on that titan , they better get this fixed asap , but as said something tells me this is just theyre usual run o the mill automated email response they send out to all the other bugfix tickets they send out :mad:

[XMonarchY]

after all the money ive spent on that titan , they better get this fixed asap , but as said something tells me this is just theyre usual run o the mill automated email response they send out to all the other bugfix tickets they send out :mad:

This one was not automated - I am quite certain that a real person is really looking into, maybe even reading this exact post because I linked them to this thread.

[Asmodian]

What I meant is that with the latest versions of MadTPG (at least until today), it is no longer possible to 'not disable' both the VideoLUTs and 3dlut at the same time. In other words, at least one of the two buttons is "blue"

HCFR has options to disable the VideoLUT or 3dlut (under Measure - Generator - Configure), but it can't undo what is disabled by MadTPG

Do you have a a set of linear VidoeLUTs attached to your 3DLUT (collink option "-a")?

[James Freeman]

I'm now using an sRGB curve for dithering of bitdepths smaller than 8bit. For 8bit dithering I'm using a pure power 1/0.45 curve.
Good choice.
Thank you for another great build.

[ryrynz]

2 short questions:
1. I have a 6bit + FRC LCD display. What is the "right" setting (I know you hate this kind of question:cool:) for "the native display bitdepth is:" ?
a) 6 bit
b) 8 bit
c) use test patterns and decide what´s looking best for you:p


I would say a) and c) although you should always do c) anyway.

What is the 7-bit bitdepth option for anyway? :p



Less bitdepth will give you a "sharper" or noiser display, many people wouldn't be able to tell the difference between 8bit and 7bit, pick what you prefer.

Sorry I missed the party, what visual improvement does "linear light processing for ordered dithering and error diffusion" do?

I believe it's just to be more accurate, I did a comparison and the changes are so slight I doubt anyone could notice them, hey but I'm always down for more image quality/accuracy no matter how slight.
That's what makes MadVR what it is, no compromises. I do hope madshi updates the screenshots when 1.0 hits.. things have changed a bit now. Quite impressed how far things have come along since the early days, it's been fun.

[andybkma]

madshi, I am getting lots of "madVR reports: - Creating direct3d device failed (8876086a)" errors with this new build 87.7 when starting to play various vids. Cannot find a pattern but it is happening alot. I have to close and reopen Zoom Player then it works again.

With previous build 87.6 I didn't get these, not once.

[leeperry]

I'm also getting quite a lot of "this device doesn't support overlay" and I'm seeing tearing in windowed/FSW even though I'm quite sure that wasn't the case with older builds like 2 weeks ago. I've got Aero disabled BTW.

[madshi]

madshi: Is overlay being at least 16 shades(?) darker than window and FSE mode over nvidia svideo an issue that can be corrected by madvr?
You should fix it by creating custom resolutions in the NVidia control panel for all modes you're interested in. The key problem is that seemingly in windowed and FSE mode NVidia does violence to madVR's output. Of course it would be possible for me to offer different settings for Overlay mode compared to windowed/FSE mode, but that's not really a good idea. Because if you get different levels in Overlay mode that just proves that windowed/FSE modes are broken for you. And "broken" means you get suboptimal quality with banding artifacts etc.

The above was written with assumption that madshi is pronounced like madshee
Yes.

Does that mean the image will be darker if the display is set to use BT.1886 gamma via 3DLUT in contrast to the previous madVR release?
Linear light processing makes the dithered image ever so slightly darker, but at 8bit you will probably not be able to see a difference in brightness.

2 short questions:
1. I have a 6bit + FRC LCD display. What is the "right" setting (I know you hate this kind of question:cool:) for "the native display bitdepth is:" ?
a) 6 bit
b) 8 bit
c) use test patterns and decide what´s looking best for you:p
You already know the right answer, don't you? :p

2. Is there a workaround for using 23,976 and 24,000 Hz refresh rates side-by-side in Windows for use with the display switcher (I don´t want to use smoothmotion or Reclock and my projector only accepts refresh rates in the 30Hz - 60 Hz region so actually I want to use 47,952 and 48,000 Hz with the EDID override method, I have to lower both refresh rates because of the clock deviation, so I end up with two 47,xxx refresh rates, Windows can´t distinguish them...)
From what I can see, this got nothing to do with madVR. The problem is that the OS can't handle your EDID override. madVR is not involved there at all. I've no experience with EDID overrides, so I can't really help you there.

What is the 7-bit bitdepth option for anyway? :p
The internal processing of some displays can't properly display 8bit images without introducing banding artifacts. Setting madVR to 7bit or 6bit could help work around that, on the cost of a slightly higher noise floor.

Is linear light processing for dithering supposed to be better? In general, I'd be interested in a little blip about linear light processing.
Yes. Linear light processing is usually more accurate. Image upscaling is a noticeable exception to this, though. When using image upscaling I rather recommend turning linear light off.

I think there's a problem with jRiver. If I start playback on my secondary monitor (FSE mode) all looks good, but then when I click on anything like an icon or a window on my primary, video goes to black, but it keeps playing and I still get audio. I can get it back by double-clicking (to display mode back to primary) and then going full screen again. No issues like this with any prev madVR versions...
Which previous version were you using? v0.87.6? Or an older build? If it was an older build then please try to find out which build introduced this problem.

Oh I see, I didn't expect gamma processing and gamma correction to be treated differently. I also expected both to come after smooth motion. Doing gamma processing before smooth motion makes it more or less impossible to do the linear light correction at the same time. I still think that doing the gamma processing 'implicitely' by using two different gamma curves for smooth motion is somewhat more elegant, since you can interpret it as displaying the source using an ideal monitor and then encoding the result using the gamma curve of the actual monitor (or an approximation thereof). This approach seems more intuitive and flexible, but I'd understand if you don't want to spend too much time on something which doesn't really improve picture quality.
Yeah, I kinda want to leave this topic behind me for now. Thinking about all the complex complications makes my head hurt... :p

MadShi!!!! ESET Smart Security think your newest version is a virus.. "Probably unknown NewHeur_PE virus"... I'm just informing you even if there is no virus...
False positive.

I received an e-mail from nVidia regarding OpenCL <-> D3D9 interop problem. They are investigating it still, but at least we (or I) know they are aware of it.
Thanks.

What I meant is that with the latest versions of MadTPG (at least until today), it is no longer possible to 'not disable' both the VideoLUTs and 3dlut at the same time. In other words, at least one of the two buttons is "blue"
You mean you can't "unpress" both buttons at the same time? Works just fine on my PC. Are you talking about madTPG running on its own? Or while ArgyllCMS and/or HCFR are doing measurements through madTPG? In the moment when ArgyllCMS/HCFR take control of madTPG, they have the "power" to enforce these buttons to be pressed. However, as long as no other software is remote controlling madTPG, it should be possible to unpress both of those buttons at the same time.

Sorry I missed the party, what visual improvement does "linear light processing for ordered dithering and error diffusion" do?
Compare it at 2-4bit, and you'll see for yourself. Of course at 8bit the difference is very very small.

madshi, I am getting lots of "madVR reports: - Creating direct3d device failed (8876086a)" errors with this new build 87.7 when starting to play various vids. Cannot find a pattern but it is happening alot. I have to close and reopen Zoom Player then it works again.

With previous build 87.6 I didn't get these, not once.
:( Is this with Overlay mode on or off? Does it only happen in FSE mode, or also if you stay in windowed mode? How often is "alot"? How many times out of how many? Does it only occur on the secondary monitor or also on the primary? And how can I reproduce this on my PC? I need more details!!

[noee]

Which previous version were you using? v0.87.6? Or an older build? If it was an older build then please try to find out which build introduced this problem.

Yes, 87.6 with or without the 3 LLDither2 libs. I am currently on 87.6 with LLDither2 copied in and all is golden with jRiver MC19.

[madshi]

Hmmmm... I have my doubts, but does this one help?

http://madshi.net/madVR877b.rar

[noee]

Hmmmm... I have my doubts, but does this one help?

http://madshi.net/madVR877b.rar

Okay, so with just 87.7, everytime I click on a window on the primary, madVR seems to jump out of FSE to Windowed. Sometimes the secondary (where the video is playing) remains black, other times it comes back and switches back to FSE apparently.

With the "b" version above, it works as per 87.6

[leeperry]

does this one help?

http://madshi.net/madVR877b.rar
I'm still seeing tearing with this build and overlay in windowed/FSW(with Aero disabled), I was under the impression that it wasn't the case a few weeks ago.

[James Freeman]

leeperry, why don't you download an older version and check it again to not be "under impression"?

[madshi]

Okay, so with just 87.7, everytime I click on a window on the primary, madVR seems to jump out of FSE to Windowed. Sometimes the secondary (where the video is playing) remains black, other times it comes back and switches back to FSE apparently.

With the "b" version above, it works as per 87.6
Interesting. So this really did fix the problem?

@andybkma, does it fix your problem, too?

I'm still seeing tearing with this build and overlay in windowed/FSW(with Aero disabled), I was under the impression that it wasn't the case a few weeks ago.
leeperry, why don't you download an older version and check it again to not be "under impression"?
^ Agreed.

FWIW, I think Overlay should not have tearing, not totally sure right now, though. And Overlay only works for NVidia and Intel. Don't you have an AMD GPU atm? That one doesn't support Overlay. I'm sometimes seeing tearing with my AMD, after running several days/weeks without rebooting. Usually a power cycle fixes this issue.

[MSL_DK]

print screen. don't forget these screens only work right on the source screen!

Use normal windowed mode, then press the PrintScreen key.

Thanks

[leeperry]

Right, I've only been on W7 for like a month but I just tried with 0.876/875 & 874 and I can still see tearing.

This said I haven't restarted my box in weeks, the tearing is at the very bottom of the picture so it's invisible on anything smaller than 1.78 AR and it's only been a few days that I get the "overlay mode not supported" error message from time to time. I guess I can turn down the option altogether if overlay's a no-go on AMD.

[aufkrawall]

Odd, my presentation glitches and dropped frames issue have disappeared (with current and previous madVR version).
I haven't changed much recently, but at least the Nvidia driver (now 335.23).
The only thing I have to do now is raising GPU queue size to 16 (or at least a higher value than 8) for debanding and using non DX11 Compute dithering for 4k video (670 is too slow with expensive scaling algorithms).
One of the most amazing software installed on my PC, thanks. :)

Need a GK110 for Error Diffusion. :devil:

[jmonier]

madshi, I am getting lots of "madVR reports: - Creating direct3d device failed (8876086a)" errors with this new build 87.7 when starting to play various vids. Cannot find a pattern but it is happening alot. I have to close and reopen Zoom Player then it works again.

With previous build 87.6 I didn't get these, not once.

FWIW (and I have not yet tried 87.7), this happened to me on several test builds prior to 87.5 (I'm pretty sure that one of these builds was the last one prior to 87.5). It was fixed on 87.5 and 87.6.

It was very random (might only happen 1 time in 10 on any kind of material). It did not happen on random dithering, only ordered (and I did not get a chance to check error diffusion). I was exclusively in FSE. I'm afraid that I have no other info on reproducing the problem.

Hope this helps.