madVR - high quality video renderer (GPU assisted)

[toniash]

What you may want to do is use a filter that's strongly smoothing, and post-sharpen.
How can we do this with MadVR?

[sunnah]

Is there any other quality difference between FSE mode and FSE mode turned off?
I know that it helps putting the focus on the player, but does it do anything other than that? I have encountered that when I turn off the FSE mode, that the rendering times of the "average stats" & the "max stats" are lowered from 15ms to like 1~3ms. (Using jinc luma scaling)

[NicolasRobidoux]

How can we do this with MadVR?TTBOMK, you can't, yet.

[nevcairiel]

Is there any other quality difference between FSE mode and FSE mode turned off?

Pure image quality should be the same. The only "quality" difference you may see is that FSE is more stable and less prone to small rendering glitches, but Windowed mode can have the exact same experience.

Usually FSE mode is considered faster/more efficient, i don't think the numbers on the OSD are always 100% accurate, and depend somewhat on flushing settings.

[sunnah]

Usually FSE mode is considered faster/more efficient, i don't think the numbers on the OSD are always 100% accurate, and depend somewhat on flushing settings.

Thanks.

[Blight]

The biggest image quality enhancement with FSE is that it reduces jitters, providing smoother horizontal camera panning.

[dansrfe]

We need a auto-tuner for flush settings. I honestly can't make informed and fully thought out decisions on what to set them to. :(

[Motenai Yoda]

Maybe there's a misunderstanding. You should not use 2 different display mode switchers at the same time! That won't work. In the worst case MPC-HC will switch to mode A, madVR's switcher will detect the change and switch to mode B. MPC-HC will switch back to mode A, madVR back to mode B. They might change modes all the time without pause. Please always only use one display mode switcher. Either MPC-HC or madVR, but not both switchers at the same time.
Nope, as I said, without Mpc-hc switcher, doesn't switch, even with madvr switcher too.

[6233638]

We need a auto-tuner for flush settings. I honestly can't make informed and fully thought out decisions on what to set them to. :(Unless you are experiencing problems, they should be left at the defaults.

With the latest Nvidia drivers, there should be no reason to change them. AMD users may still experience problems though?

[blackjack12]

Wow - been away for a few weeks so have just had a chance to play with the new Jinc / Anti Ring algorithm but it is too much for my 550ti in the desktop with heaps of dropped frames (96%+ GPU usage, spiking temp and fan ramps up on VC-1 1080(i) content) and is way to taxing for the iGPU on the i7-2600K in my HTPC with most material. While it looks great, what HTPC friendly GPU are people using?

Just a note:

I am seeing the same issue on all of my systems with jinc processing.

Works great until you look at real interlaced material. With interlaced content and using madVR deinterlacing, jinc brings processing to its knees when up-scaling. Even with the 560Ti Nvidia card.

[TheLion]

We need a auto-tuner for flush settings. I honestly can't make informed and fully thought out decisions on what to set them to. :(

I "suggested" such a few pages back when I was dealing with my DPC spikes. My suggestion was to use user feedback in order to come up with a best practice approach per AMD/nVidia/Intel chip generation - which then sets the default flushing settings accordingly.
But I fear the driver revision might also make a difference.

[Asmodian]

Works great until you look at real interlaced material. With interlaced content and using madVR deinterlacing, jinc brings processing to its knees when up-scaling. Even with the 560Ti Nvidia card.

Jinc is quite hard for the video card, 8-tap brings processing to it's knees even with a GTX 680. When resizing to 2650x1440 even 4-tap Jinc uses ~30% GPU with the GTX680 at full power. Nvidia's deinterlacing is quite good but also takes quite a bit of GPU so I am not at all surprised the HTPC friendly cards cannot handle it and Jinc at the same time. Would love to try these on a GK-110 card. :D

[6233638]

I "suggested" such a few pages back when I was dealing with my DPC spikes. My suggestion was to use user feedback in order to come up with a best practice approach per AMD/nVidia/Intel chip generation - which then sets the default flushing settings accordingly.
But I fear the driver revision might also make a difference.
Did you ever run LatencyMon (http://www.resplendence.com/latencymon) to find out which driver was causing the DPC spikes? I suspect it's your AMD drivers, as it doesn't seem to be an issue with Nvidia.


Jinc is quite hard for the video card, 8-tap brings processing to it's knees even with a GTX 680. When resizing to 2650x1440 even 4-tap Jinc uses ~30% GPU with the GTX680 at full power. Nvidia's deinterlacing is quite good but also takes quite a bit of GPU so I am not at all surprised the HTPC friendly cards cannot handle it and Jinc at the same time. Would love to try these on a GK-110 card. :DWith pretty much all the scaling algorithms in madVR, going above 3-tap is detrimental to image quality. Jinc is the only possible exception, with 4-tap being slightly sharper than 3-tap without introducing that much more ringing. I am still leaning towards 3-tap Jinc now after spending more time with it, however.

8-tap Jinc (or Lanczos) are completely unusable no matter whether the GPU can handle them or not - they look terrible! More ≠ better.

[Pat357]

The strange thing is that I have basically the same filter chain as 6233638. Even the video decoder is the same (LAV). The only things that are different are the audio renderer, the graphics card drivers and the media player.
Like I said in my previous post : LAV + MadVR + MS-DVD-navigator works in (till now *only* in) -PotPlayer-.
I'm sure it'll work for 6233638 too, since I've have an almost identical setup as him, based on GTX-570 and i7-9xx CPU on W7 x64.
I wonder if somehow the PotPlayer author found a work around the Macrovision thing, or PotPlayer did work "out the box" with LAV + MadVR for DVD playback.
If the first, then I would be *very* interested in what he did to make it work.:D

[Asmodian]

8-tap Jinc (or Lanczos) are completely unusable no matter whether the GPU can handle them or not - they look terrible! More ≠ better.

But then you think SoftCubic 80 is sometimes good for the Luma resize. ;)

I know you really hate ringing, no need to go over it yet again. lol

[NicolasRobidoux]

I find 6233638's observations interesting.

[Asmodian]

So do I, 6233638 thinks about this in a more rigorous way and probably has a better eye for details than I do.

I have learned a lot from all of you, it is wonderful being able to look over the shoulders of people who know what they are doing and then play with the some of results myself. :)

[leeperry]

Hi madshi, I finally pulled the trigger on a 399€ 1080p 46" TV set and it's flawless for mVR use: 3200:1 native CR calibrated at D65/2.5, it supports 24/25/29.97/48/50/59.94Hz and has a 3 levels noise reduction filter(processed in 10bit?) that does wonders on noisy SD so my endless headaches have finally paid off :D
Black level = 0.05 cd/m^2
White level = 163.31 cd/m^2
Aprox. gamma = 2.39
Contrast ratio = 3182:1

This said, you made very clear that 8bit YV12 contains more data than 8bit RGB32 and I would very much prefer the RGB conversion to be processed in mVR now that I got a pretty big 8bit screen ^^

So I'm now feeding YV12 and so far the SD upscale autodection from ffdshow seems to work flawlessly but I was wondering if you could slightly polish the gamut mapping part please?

1) 25fps SD is guessed as SMPTE-C, it very much is EBU. Could you please fix that?

2) My display is calibrated via an 11kb 3x1DLUT .cal file (http://pastebin.com/nK4czRk6) generated by ArgyllCMS, I guess it would be quite a bit of work for you but would that make any sense to be able to import it into mVR and have it processed at the RGB conversion stage in 16bit? Of course you would need to bypass the graphic card's CLUT, but when outputting TMDS24 it might very much improve the PQ :)

3) ATM, it's not possible to input custom display primaries for a display, and my TV set is pretty much dead on the HDTV gamut: http://thumbnails104.imagebam.com/21587/08abed215867332.jpg (http://www.imagebam.com/image/08abed215867332)

If I were able to input its exact RGBW coordinates and have a "best guess" primaries detection for EBU/SMPTE-C/HDTV gamuts, that'd be too awesome for words! I might also fancy a rule for 23.976/25/29.97 HD so I can force SMPTE-C/EBU/HDTV in this order if any possible, and possibly a quick access option to switch between them when I don't have a keyboard easily reachable.

Hardcore example: I've got a SD 29.97fps video that needs REC.709 primaries and HDTV gamut, it's an endless keyboard shortcut madness atm....if you could add two simple "toggle matrix" and "toggle gamut" buttons under "edit settings" and "show tray icon", this would be sooo convenient :cool:

:thanks:

[pie1394]

Jinc is quite hard for the video card, 8-tap brings processing to it's knees even with a GTX 680. When resizing to 2650x1440 even 4-tap Jinc uses ~30% GPU with the GTX680 at full power. Nvidia's deinterlacing is quite good but also takes quite a bit of GPU so I am not at all surprised the HTPC friendly cards cannot handle it and Jinc at the same time. Would love to try these on a GK-110 card. :D

There will be 2000 ~ 2500 cuda cores in the GK110 chipset, just 30% more than GK104's 1536. GK110's memory bandwidth is doubled due to 512-bit external GDDR5 interface if compared to GK104's.

The major difference is about FP64 calculation performance for Tesla product line. For scientific math calculation purpose, FP64 precision is often required. GK104 is weak at this part (about 1/6 of FP32 throughput) and even slower than Fermi-based GF110.

The retina hand-held and 4Kx2K TV display devices will become more and more common. But the content's resolution will not catch up so fast. Thus I think these real-time high-quality scaling algorithm with reasonable gate-count cost + power-consumption is always needed.

[Asmodian]

3) ATM, it's not possible to input custom display primaries for a display

Isn't this what yCMS calibration is for? It does wonders for my wide gamut display. I use hcfr with my i1 Display3 to measure both the primaries and gamma curve after calibration, this way I don't have to bypass the video card's LUT.

Hardcore example: I've got a SD 29.97fps video that needs REC.709 primaries and HDTV gamut, it's an endless keyboard shortcut madness atm....if you could add two simple "toggle matrix" and "toggle gamut" buttons under "edit settings" and "show tray icon", this would be sooo convenient :cool:

I don't think you want to try to change the display gamut; that is just whatever your screen is. In this context primaries (RGBW) = gamut, right? A setting for the video's color space if the video uses a different one like your SMPTE-C vs EBU example would be nice though. Does there need to be four options, BT.709, BT.470-M, BT.470-B (EBU), and SMPTE-C?

Not sure how a normal user would like seeing those options though, maybe only if madshi implements an "advanced user" mode. :D

Thus I think these real-time high-quality scaling algorithm with reasonable gate-count cost + power-consumption is always needed.

I vote for high-quality over gate-count cost + power-consumption myself but I would be interested in what method the iPad 3 uses as it has to resize everything. I think NicolasRobidoux and madshi are showing how it can be done better, getting their ideas into hardware is another step. ;)

[agustin9]

Did you ever run LatencyMon (http://www.resplendence.com/latencymon) to find out which driver was causing the DPC spikes? I suspect it's your AMD drivers, as it doesn't seem to be an issue with Nvidia.

They are, in my tests the catalyst 10.6 didn't have the problem

[TheLion]

They are, in my tests the catalyst 10.6 didn't have the problem

Sadly I run Win 8 and therefor cannot use older Catalyst releases. But thanks for the information. I will simply make sure that my next graphic card is nVidia :sly: It seems to be a better choice for madVR.

[leeperry]

Isn't this what yCMS calibration is for?
Well, the idea of 16bit 96MB 3DLUT's originally came up because tritical's gamut mapping Avisynth plugins were too CPU hungry, then madshi decided to support them because he wanted to delegate all the CMS work to someone else.

The thing is that gamut mapping is a trivial job for a PS script: http://www.avsforum.com/t/912720/

These days, 96MB 3DLUT's only really make sense if you wanna convert YUY2 to RGB for instance IMHO. They are way overkill for something as simple as gamut mapping and madshi finally took the bull by the horns and added PS-based gamut mapping in mVR. The only problem is that it doesn't allow custom RGBW coordinates and as you can see my 46" LCD is only a few ΔE's away from the REC.709 gamut:
REC.709: 0.640 0.330 / 0.300 0.600 / 0.150 0.060 / 0.313 0.329
my TV: 0.639 0.328 / 0.293 0.602 / 0.145 0.058 / 0.312 0.331
I presume that it would be rather trivial for madshi to allow this...and maybe I can actually get away with REC.709 gamut mapping after all, OCD'ness must end :D

I would also appreciate an option to leave the display gamma curve untouched because FWIU video content is encoded in 2.2 but there is no hard rule about the display gamma itself. A good rule of thumb seems to go 2.2 if your display has a poor native CR or 2.4/2.5 if you can afford it.

I don't have to bypass the video card's CLUT.
Well, it's processed in 8bit when outputting TMDS24, on top of mVR's dithered output so it will potentially induce banding and noise. I would very much fancy the idea of being able to import a 11kb .cal file instead of a 96MB 3DLUT: you get PS-based gamut mapping(which already exists in mVR) and 1D LUT text based color correction. No need to wait for a 96MB LUT to be loaded or the endless headaches that go along with building and storing 3DLUT's :rolleyes:

And you can't merge a .cal file into a 3DLUT anyway AFAIK.

Besides yCMS hasn't been updated in a while, yRGB is not a finalized standard and Graeme Gill(Argyll's coder) has all the time and experience to assist madshi if need be.

I don't think you want to try to change the display gamut; that is just whatever your screen is. In this context primaries (RGBW) = gamut, right? A setting for the video's color space if the video uses a different one like your SMPTE-C vs EBU example would be nice though. Does there need to be four options, BT.709, BT.470-M, BT.470-B (EBU), and SMPTE-C?
I'm talking about the source primaries of course, so mVR can map them to your display.

There's really only 3 gamuts we care for:

http://www.homecinema-fr.com/forum/download/file.php?id=54227

-EBU for PAL SD
-SMPTE-C for NTSC SD
-REC709/HDTV/sRGB for HD and FRAPS videos

Of course, some ppl claim that HD mastered in the US still uses SMPTE-C due to the fact that it's calibrated on CRT's and that HD done in the EU runs EBU.....everyone has his own opinion and this is out of the scope: http://www.avsforum.com/t/1038602/

The cherry on the cake would be the ability to choose the source gamut for HD depending on its framerate, for the conspiracy theory believers amongst us :p

It's currently a crazy keyboard shortcuts story(that won't even work with the m$ virtual keyboard) when you want to cycle through decoding matrixes and gamuts, so some quick access buttons would be highly appreciated. But well, I recently got ahold of one of these (http://www.techradar.com/reviews/pc-mac/peripherals/input-devices/keyboards/logitech-nulooq-53423/review) on ebay for 20 bucks, so I could always assign its top buttons for matrix/gamut/levels toggling et voilà :)

What I would really need at this point is SD PAL from ffdshow to be recognized as EBU and the ability to input the actual RGBW coordinates of my display....so mVR could do its magic for me all over again!

The additional noise of my gamut mapping Avisynth scripts was OK'ish on CRT/DLP because those two technologies are a noise/mosquito feast but a crisp LCD screen connected in TMDS24 is merciless with noise...so I'm afraid I can't afford ffdshow/avisynth 8bit processing anymore :scared:

[Asmodian]

Check out the yCMS section, I just write my RGBW primaries into madVR and it takes care of the rest.

Red,Yxy,33.035683,0.654655,0.341453
Green,Yxy,86.717087,0.267918,0.663321
Blue,Yxy,13.308223,0.148377,0.064612
White,Yxy,42.328707,0.314018,0.326278

I leave the gamma section blank on my TV. It seems to use 2.2.

It isn't a performance hit, at least on my system.

[leeperry]

Nice! but it's asking to download yCMS so I presume that it will build a 96MB yRGB 16bit 3DLUT when I could easily get away with PS-based gamut mapping. I guess I'm so close to REC.709 that I'll just stick to it if allowing custom coordinates isn't to be considered without the use of a 96MB 3DLUT file :o

[madshi]

Suggestion:
Because you are effectively dealing with the most offensive common problem with a linear light toolchain, namely dark halos (your'e dealing with the light ones too, of course, but they are not the main issue with linear light resampling that uses negative lobe filters), and you are starting to do rather complicated things in the AR toolchain, including Gaussian blur, I suggest that you try your favorite AR toolchain through linear light (into linear light before the resampling filter, out of linear light after the final Gaussian blur) because this will restore, among other things, light <-> dark symmetry, and in particular would prevent the most annoying artifact of sRGB resampling (besides light halos), which is the "thinning" of light on dark features, which AR, I'm sure, can't do anything about.
I have the foolish hope that this may reduce the size of the worst gremlins, as well. (This being said, I still have not read your overall description of how AR works, so everything is based on "I bet it works more or less like this...")
I've tried linear light scaling and while AR takes care of the biggest problems, it still doesn't look so good to my eyes. I still prefer resampling in gamma corrected light.

Also, unless you have "fudge factors" in your AR algorithm, I also suggest that you see if you can see a difference when you use a LUT which has more points than what you use now.
Have tried that, but I can't see any difference. FWIW, I'm using linear interpolation when reading the LUT. That probably helps.

When you have time to waste, I suggest that you try EWA Robidoux. Not perfect. But good-cheap-solid.
But is it better than any of the tensor algorithm? Any of the EWA Cubic variations would run as slow as Lanczos4, when using my current pixel shader code. So I'm wondering whether there'd be an improvement in image quality that offsets the performance loss compared to the tensor based methods? E.g. is EWA Robidoux noticeably better than tensor Mitchell or SoftCubic?

os win xp 64 win 7 64 win 8 64
mpc hc atm 6086

aero tested with both on and off
double checked on win 7 64
And it occurs on all of these systems? I can't reproduce it on my XP32 system. Haven't tried XP64, but it should be the same there. I could imagine that Aero makes a difference, but XP64 doesn't have Aero.

For example, at locations where there is some ambiguity RE: whether to "chop", blend instead.
AR looks overly eager to me. You can leave some halo. The first halo, in particular, can be argued to increase acutance, so it's not all bad.
Sometimes, "better" is better than "perfect".
FWIW, the original version of the AR filter detects situations where removing ringing could result in problems and turns itself off for those pixels. That works quite well in avoiding gremlins. The problem is that with computer type content, this "auto turn off" feature fires quite often and results in a lot of visible ringing artifacts left in the image. So the "fix" I implemented for 6233638's computer type image was simply to turn the "auto turn off" part of the AR filter off, so that AR is always activate and for all pixels. This fixed all the nasty ringing, but introduced those nasty gremlins. For natural images the "auto turn off" feature sometimes results in some ringing being left in the image, but on the positive side it avoids gremlins and similar artifacts very well. So I'll probably simply have to improve the "auto turn off" detection.

To keep noobs out of trouble and the interface clean, have some options only accessible through config files. Emphasis on "only".
Then, your documentation can have a section called "Expert Configuration Options" with a blinking neon sign that says: "You are likely to break things if you mess with this stuff, which caters to the "needs" of the minority that eats bandwidth for breakfast, lunch and dinner on madVR forums. Not to forget the midnight snack."
That's all nice and fine. But I'd first have to have a documentation to start with (there is none at all now). And adding support for config files costs time, too. A day only has 24 hours and I have to put priority on important things. Which means: No time left currently for creating a documentation/help or for adding support for custom config files or other things like that. Such things will hopefully come sooner or later, but now is not the right time for that. I've still not reached v1.0.

When I calibrate through mpc/madVR would it be most optimal to choose 'this display is already calibrated' choose BT.709 select pure power curve 2.20 and 'disable GPU gamma ramps'?

I calibrate using X-Rite i1Display Pro, ColorHCFR and AVS HD 709 - Blu-ray & MP4 Calibration
What do you mean with "calibrate through mpc/madVR"? Do you mean you want to use yCMS to calibrate your display? Or what? Or do you want to use mpc/madVR just to show test patterns and calibrate your display by using the options in your display's setup menu?

I will try and find some more samples.

As I said, it's difficult outside of artificial tests, or recorded game footage.
I guess that's good.

most of the game footage I use has gone through an analogue video chain and is quite compressed, so it's not the same as an "artificial" screenshot
Screenshots of compressed game footage would be interesting, too.

What I would really find useful is to have like 2 different upscaling setups, where either madVR can automatically choose between them (e.x. source: movie resolution) or/and the user can toggle (override) between them if needed.
Something like that is already on my to do list. For later...

While it's probably not what you were looking for, as it's still relatively artificial, here are a couple of samples that show ringing around the edge of subtitles that the current anti-ringing filter doesn't catch. (Munich (http://www.imdb.com/title/tt0408306/) DVD)

http://www.abload.de/thumb/screenshot179sap.png (http://www.abload.de/img/screenshot179sap.png) http://www.abload.de/thumb/screenshot280s67.png (http://www.abload.de/img/screenshot280s67.png)

I would say that Spline 3 AR exhibits slightly less ringing in these samples compared to Jinc 3 AR.
It's not really artificial because this can happen during normal movie playback.

Regarding the graphics card reporting it as bad, that's probably because my projector doesn't support it or do AMD cards have issues with it?
Your GPU does not care much whether the display supports it or not. Your AMD card simply doesn't seem to support 1080p25. And most display probably don't support it, either. It's a rather unusual mode.

Any idea why madVR switches to TV levels output with certain SD/AVC files, regardless of decoder? All monitors in madVR are set to PC levels.
I don't think madVR switches the *output* levels. Press Ctrl+Alt+Shift+Y to double check. It probably switches *input* levels. Some h264/AVC files claim they are encoded as fullrange and madVR honors that. If you don't want madVR to do that, just press Ctrl+Alt+Shift+I multiple times to force madVR to "TV" input levels, then press F2 to store that. Afterwards madVR will ignore the "fullrange" flag in h264 files.

Crash with madVR v0.84.3 & MPC-HC ISR r6086
http://www.mediafire.com/?a9698iv9rucvr6r

Doesn't seem easily reproducible, so this could be a MPC-HC ISR bug and not a madVR bug. It crashed when the MPC-HC ISR was trying to display a line right after a chapter point. The line in question specified a missing font, so the MPC-HC ISR probably crashed when attempting to load or render the gdi fallback font.
Yeah, from the stack trace it looks like a crash in the ISR. Probably not much I can do about it.

IMHO, this is exactly the kind of image where EWA Quadratic B-spline smoothing shines. It's cheap (radius=1.5), it smooths out ringing, and it's not offensively blurry: http://web.cs.laurentian.ca/nrobidoux/misc/madVR/screenshot179sapEWAQuadratic.png
(http://web.cs.laurentian.ca/nrobidoux/misc/madVR/screenshot179sapEWAQuadratic.png)
On the other hand, I imagine that Mathias has something else to do than add such a "special purpose" filter: Unless the image is pixelated and/or full or ringing/halo almost to the point of being considered "defective", this filter is too soft, at least for luma.
I actually have programmed a relative of EWA quadratic B-spline smoothing, called VSQBS (Vertex Split with Quadratic B-Spline Smoothing) which is an unbelievably cheap scheme (my guess is would be screamingly fast on a GPU), in a different library than ImageMagick, namely VIPS (Virtual Image Processing System) and its GUI NIP2 (New Image Processor 2). It has slightly better jaggy reduction, at the cost of a touch more blur. http://web.cs.laurentian.ca/nrobidoux/misc/madVR/screenshot179sapVSQBS.png
(http://web.cs.laurentian.ca/nrobidoux/misc/madVR/screenshot179sapVSQBS.png)
VSQBS is not for downsampling. To get a similar scheme for downsampling, you should switch to EWA or tensor quadratic B-spline smoothing.

When enlarging, VSQBS uses the 8 input pixel values closest to the output pixel location to produce its value, and it's really easy to determine these 8.

(Note: Neither with ImageMagick nor VIPS did I do careful import and export of the png. This is why there is a slight difference in colouring in some browsers.)

P.S. Despite the reduced jaggies, I actually like EWA quadratic B-spline smoothing better than VSQBS.
But I like Jinc AR much better with these images. Look here:

Jinc3 AR (http://madshi.net/jinc-subtitle.png)

Ok, there's a tiny bit of ringing left in the image, but it's really not much, and the image is oh so much sharper than EWA quadratic and VSQBS and also less aliased than EWQ quadatric.

P.S. I managed to get alignment. They're so close one could almost say they're clones. EWA Quadratic is a minuscule amount sharper and jaggier. I think SoftCubic wins by a whisker.
No "normal viewer" would see the difference, though. Even zooming in with a high quality image viewer (I use NIP2, of course: it's really fast, and I'm a dev).
P.S.2 Scrutinizing some more, SoftCubic 80 wins: less jaggies, without significant additional blur, and with very little additional halo.
FWIW, SoftCubic80 is simple tensor Cubic with B=0.8 and C=0.2. All the "SoftCubic" variants in madVR have B+C=1.0.

[madshi]

It's probably the adaptive vsync option, it's enabled.
Yes, that sounds like a very likely explanation.

I have an random issue with all the version of Madvr... I have an ATI 6850 with a X4 925, 8 GB Ram and W7 64. The problem is after a certain period the screen is divided in 2 with a lot of artifacts.
Do you have an idea of the reason and how to fix??? At the moment the only solution is to reboot the system (close the session is not enough and the image is still splited in 2)
Could be overheating, or failing hardware. Not sure what else it could be. Never heard of anything like this before.

Wow - been away for a few weeks so have just had a chance to play with the new Jinc / Anti Ring algorithm but it is too much for my 550ti in the desktop with heaps of dropped frames (96%+ GPU usage, spiking temp and fan ramps up on VC-1 1080(i) content) and is way to taxing for the iGPU on the i7-2600K in my HTPC with most material. While it looks great, what HTPC friendly GPU are people using?
I'm also surprised that the 550ti can't handle it. Are we talking Jinc3 AR for Luma and maybe some SoftCubic or Bicubic variant for Chroma? And the 550ti can't handle it when deinterlacing is activated? That would mean that deinterlacing must eat a lot of performance, I would say, more than I thought it would. Have you tried disabling IVTC/pulldown detection in the NVidia drivers? That's probably not a good solution, but it would be interesting to see whether that brings the 550ti up to speed. (Not even sure if NVidia has such a setting, AMD does.)

And it tackles anything you throw at it
For now... :D

(And no, that does not necessarily mean that there's more demanding stuff coming *soon*. But some day...)

What you may want to do is use a filter that's strongly smoothing, and post-sharpen.
I think using de-haloing and de-banding before resizing, then using something like Jinc AR for resizing, should be a better solution. Using a filter which is strongly smoothing would probably remove some detail which you might never fully get back. Also post-sharpen will likely bring halos back which were only weakened through smoothing. The halos must be totally eliminated for sharpening to not bring them back, I believe. I haven't really actually tested any of this, though. This is just what I "think" at the moment. It might be wrong...

We need a auto-tuner for flush settings. I honestly can't make informed and fully thought out decisions on what to set them to. :(
Unless you are experiencing problems, they should be left at the defaults.

With the latest Nvidia drivers, there should be no reason to change them.
Exactly.

I am seeing the same issue on all of my systems with jinc processing.

Works great until you look at real interlaced material. With interlaced content and using madVR deinterlacing, jinc brings processing to its knees when up-scaling. Even with the 560Ti Nvidia card.
Your 560Ti can't handle Jinc3 AR + Deinterlacing? That's a real surprise to me. I guess you could try letting LAV do Yadif deinterlacing. But then, I'm not sure how Yadif quality compares to NVidia DXVA deinterlacing.

With pretty much all the scaling algorithms in madVR, going above 3-tap is detrimental to image quality. Jinc is the only possible exception, with 4-tap being slightly sharper than 3-tap without introducing that much more ringing. I am still leaning towards 3-tap Jinc now after spending more time with it, however.

8-tap Jinc (or Lanczos) are completely unusable no matter whether the GPU can handle them or not - they look terrible! More ≠ better.
I agree on 8-tap. However, I do think that Lanczos4 does bring a nice improvement in sharpness and aliasing. Yes, it some situations Lanczos4 has a bit more ringing than Lanczos3, despite the AR filter. But that's just in some situations. I believe it's a matter of taste whether you prefer Lanczos4 AR (sharper, less aliasing, more ringing) or Lanczos3 AR. The differences aren't that big, from my point of view, except maybe in some special situations.

Hi madshi, I finally pulled the trigger on a 399€ 1080p 46" TV set and it's flawless for mVR use
Which one is it?

1) 25fps SD is guessed as SMPTE-C, it very much is EBU. Could you please fix that?
25fps SD is not *generally* guessed as SMPTE-C. Actually, for sources with a height of 576 pixels (which is normally what 25fps SD is) the primaries are guessed as EBU/PAL. So the big question is: Why does madVR end up with SMTPE-C in your case? Maybe these sources don't have 576 pixels, anymore? That would be weird, though, a custom encoding with stripped black bars maybe? Or alternatively, maybe the video bitstream claims that the source has SMPTE-C primaries?

2) My display is calibrated via an 11kb 3x1DLUT .cal file (http://pastebin.com/nK4czRk6) generated by ArgyllCMS, I guess it would be quite a bit of work for you but would that make any sense to be able to import it into mVR and have it processed at the RGB conversion stage in 16bit? Of course you would need to bypass the graphic card's CLUT, but when outputting TMDS24 it might very much improve the PQ :)
I've no clue how to interpret .cal files. And while I'm sure that it would be possible to find out how they work and it would surely also be possible for me to implement that kind of stuff in madVR, I have a lot of other things on my to do list, and frankly, supporting .cal files is not what a lot of madVR users have asked so far, so it's rather low on my priority list. I only have so much development time available, and of course I have to spend it first and foremost on things which I find most important. And .cal support is not as important as several other things I still have to do, from my point of view.

3) ATM, it's not possible to input custom display primaries for a display, and my TV set is pretty much dead on the HDTV gamut: http://thumbnails104.imagebam.com/21587/08abed215867332.jpg (http://www.imagebam.com/image/08abed215867332)

If I were able to input its exact RGBW coordinates
Maybe some time in the future, but not too soon. For now, please use yCMS or just live with the slightly inaccuracy. FWIW, one of the features on my to do list, which I find more important than your current wishes is custom pixel shader support. And as it so happens, once I implement custom pixel shader support, you could fix that small inaccuracy in your gamut yourself, couldn't you? ;)

... and have a "best guess" primaries detection for EBU/SMPTE-C/HDTV gamuts, that'd be too awesome for words! I might also fancy a rule for 23.976/25/29.97 HD so I can force SMPTE-C/EBU/HDTV in this order if any possible, and possibly a quick access option to switch between them when I don't have a keyboard easily reachable.
All these fall under settings tweaks, and those are scheduled for closer to madVR v1.0 release. And for the record, madVR v1.0 will not necessary come after v0.99. Maybe after v0.99 there might be v0.100. Or maybe v1.0 will already come after v0.95. I simply don't know yet. v1.0 will come when all key features are implemented and everything is somewhat polished.

if you could add two simple "toggle matrix" and "toggle gamut" buttons under "edit settings" and "show tray icon", this would be sooo convenient
That settings page with those two buttons was just meant to be a helper page to get access to the full madExcept settings dialog in case you have the tray icon disabled. I don't plan to add any more buttons to that settings page.

[NicolasRobidoux]

Mathias:
I am often wrong.
But I am occasionally right.

[NicolasRobidoux]

Jinc3 with AR often looks really good.

[madshi]

Mathias:
I am often wrong.
But I am occasionally right.
Can I get that in percentages? :D

Jinc3 with AR often looks really good.
Yes, I really like it.

[NicolasRobidoux]

EWA Robidoux may, or may not, be better than tensor Mitchell or some well-chosen SoftCubic.
I myself often prefer tensor Mitchell.
And EWA Robidoux is actually kind of an EWA near clone of tensor Mitchell.
This being said, it is qualitatively different: Tensor schemes have halos in a "checkerboard pattern". EWA-Robidoux (and other EWA schemes) have halos in a more isotropic ("circular") pattern. This is particularly obvious near corners.
And EWA-Robidoux was chosen over tensor Mitchell as a downsampling method by a panel of top web designers. Over EWA LanczosSharp too, by a nose. Which shocked me at the time. But a lot of their images have terrible quality, and I think the tie was broken by processing speed.
This is why I suggest you give it a look as a "time waster" (as if you have time to waste).
Also: Yes, it's an EWA method, and consequently, it will be slower than a comparable tensor cubic.
-----
Nothing to add to your other comments, except that I agree.

[NicolasRobidoux]

My baseball card would not trade for much.

[JarrettH]

Any preference with Jinc3 or Jinc4? Has someone compared performance differences? :thanks:

[NicolasRobidoux]

Mathias:
Another strike? Enlarge though LAB.

[huhn]

is a problem on all "systems"(same pc) and only happen when:

you start play back, pause playback stop playback, resize it to fullscreen (control enter) and then start playback again.

when u resize it 1 time to the fullscreen resolution then u have to restart the player before it can happens again

i can do this all day and is works every time

looks like this:
http://s3.imgimg.de/uploads/retangle15ef6fbapng.png
the player was running while i took the screen so duno why all queues are empty
like u can see madvr thinks it should be 1280x720

[madshi]

Mathias:
Another strike? Enlarge though LAB.
You mean it's good? Or it's bad? If you say it's good, how does conversion between gamma corrected light <-> LAV work? Is there a simple formula available somewhere?

is a problem on all "systems"(same pc) and only happen when:

you start play back, pause playback stop playback, resize it to fullscreen (control enter) and then start playback again.

when u resize it 1 time to the fullscreen resolution then u have to restart the player before it can happens again

i can do this all day and is works every time

looks like this:
http://s3.imgimg.de/uploads/retangle15ef6fbapng.png
the player was running while i took the screen so duno why all queues are empty
like u can see madvr thinks it should be 1280x720
Can you make the same screenshot with XP64, please? I still can't reproduce it in XP32.

Does that image stay still? Or does anything move at all? I mean does the OSD change in any way? Playback is still stopped at the moment you made that screenshot, correct?

[NicolasRobidoux]

You mean it's good? Or it's bad? If you say it's good, how does conversion between gamma corrected light <-> LAV work? Is there a simple formula available somewhere?
It may be good.
As always, my reference is decent quality sRGB image resizing. In this context, when enlarging, enlarging through LAB (in ImageMagick) has never given worse results than doing it through straight sRGB, and it often has given better looking results (better, even, than sigmoidization, on some occasions).
Anthony Thyssen (and I agree) thinks that it maybe because LAB is better at separating luma from chroma. On the other hand, isn't it what Y'CbCr does, pretty much?
-----
So, my suggestion is an "educated shot in the dark".
All the conversion code that does not rely on color profiles is in the colorspace.c file of the ImageMagick distribution. This tells you what formulas are used.
-----
(In baseball terminology, a "strike" is when the person at bat "swings in the air", an unproductive attempt at making progress.)

[huhn]

the image was shoot while the playback was still running this is maybe 1 of the frist frames.

like mention before stopping the playback fix the issue this is no serious error at all not "easy" to reproduce and there r workarounds it just happens to me alot resize it while the video is running or and stop it then is not to hard for me.

in windows mode it's fixable with move the point to the bottom and the mpc navi pops up (didn't ever notice this before...) it's still an issue in fse so yeah...

this bug is 1 year or even older so i report it.
i don't have xp 64 installed right now but i will test it at this weekend.

and xp64 is based on server 2003 x64 so not sure if is that easy to compare this os with xp sp3.

when u resize it 1 time to the fullscreen resolution then u have to restart the player before it can happens again

this is wrong be the way sorry

windows 7 screen with aero and proper osd:
http://s3.imgimg.de/uploads/retangle22528cc01png.png

windows 7 screen without aero:
http://s3.imgimg.de/uploads/retangle3a44f3b7apng.png
the present time is sky rocketing and it's tearing like hell

[madshi]

It may be good.
As always, my reference is decent quality sRGB image resizing. In this context, when enlarging, enlarging through LAB (in ImageMagick) has never given worse results than doing it through straight sRGB, and it often has given better looking results (better, even, than sigmoidization, on some occasions).
Anthony Thyssen (and I agree) thinks that it maybe because LAB is better at separating luma from chroma. On the other hand, isn't it what Y'CbCr does, pretty much?
-----
So, my suggestion is an "educated shot in the dark".
All the conversion code that does not rely on color profiles is in the colorspace.c file of the ImageMagick distribution. This tells you what formulas are used.
-----
(In baseball terminology, a "strike" is when the person at bat "swings in the air", an unproductive attempt at making progress.)
Yeah, a "strike" is sometimes good (bowling, I think?) and sometimes bad, that's why I wasn't sure what you meant.

Maybe LAB scaling would be worth a try. Y'CbCr is not really good at separating Luma from Chroma, because Y'CbCr comes from R'G'B', not from RGB. Y'CbCr is actually pretty bad.

[NicolasRobidoux]

Let's hope it's a bowling strike.

[SamuriHL]

Strike 3 you're out! :D

[NicolasRobidoux]

Strike 3 you're out!Another day, another game.

[SamuriHL]

LOL! I need to get off this Android stuff I've been working on lately (thank you Moto for the OTA!) and get back to work on my HTPC's. I'm woefully behind. I've got a driver update to do. I'm behind a version on madVR. I'm sure MC18 is out of date by now. ACK. :D

[mindbomb]

I noticed the mpc hc seekbar now shows the starting point of mkv chapters.
I love this feature, i was wondering if the full screen exclusive mode seekbar will have it too?

[Asmodian]

Nice! but it's asking to download yCMS so I presume that it will build a 96MB yRGB 16bit 3DLUT when I could easily get away with PS-based gamut mapping. I guess I'm so close to REC.709 that I'll just stick to it if allowing custom coordinates isn't to be considered without the use of a 96MB 3DLUT file :o

What is wrong with using the file? It might seem like overkill but if it works, what is the down side?

[NicolasRobidoux]

...
FWIW, SoftCubic80 is simple tensor Cubic with B=0.8 and C=0.2. All the "SoftCubic" variants in madVR have B+C=1.0.
Totally sensible since, for a given C, it makes B, the "blur" number, twice as large as it would be if it was a Keys cubic.
I like Keys a lot. But that's no reason to stay on the straight and narrow.

[NicolasRobidoux]

There is research that supports the "(first) haloing -> artificial acutance -> perceptual sharpness even if the data is actually not high res" thesis here:
http://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP092.pdf. See the top of p. 5 and the shape of the two filterss at the top left of p. 2.
(User hjulenissen on http://www.dpreview.com and also on the ImageMagick Forums pointed the existence of this paper to me.)

[leeperry]

Which one is it?

This one (http://www.hitachidigitalmedia.com/product.do?actionName=showProductAction&pt=17&pg=83&proid=768&language=en&country=GB). It's dead smooth in 48/59.94Hz and provides an extremely sharp picture together with a stunning subjective "pop effect"(and I'm not talking about halo-based EE). I saw many LCD screeens that either had a terribly blurry thick AR layer and/or a pretty dull picture. It would appear that 3D'ness doesn't only boil down to a high native CR because the only manufacturer that guarantees high grade panels is Sharp with its UV²A panels but their LC40LE730E left me vastly unimpressed, even though it was measured at >4K:1 (http://translate.google.com/translate?hl=en&sl=fr&tl=en&u=http%3A%2F%2Fwww.lesnumeriques.com%2Ftv-televiseur%2Fsharp-40le730e-p13935%2Ftest.html). Also, their obsolete 630 serie supports 24Hz but the current 730 really only does 60Hz, duh.

Samsung will rock if you get a golden sample (http://www.televisioninfo.com/content/Samsung-UN40EH5000-LED-LCD-HDTV-Review/Picture-Quality.htm), but if you don't(read the comments at the bottom of this page) you'll be SOL. Same story for Philips that sends "Sharp UV²A (http://translate.google.com/translate?hl=en&ie=UTF8&oe=UTF8&twu=1&u=http://www.lesnumeriques.com/tv-televiseur/philips-40pfl5507h-p12906/test.html)" panels for reviews but actually puts crappy panels for sale :(

Edge LED backlight is more efficient but most of them suffer from more or less severe clouding apparently, so if you end up with a dud you'll cry: http://img1.lesnumeriques.com/test/68/6858/PFL5527H_clouding.jpg

I was about to wait for OLED but their blue LED's lose 50% of brightness after 2 years, huh: http://www.displaymate.com/OLED_Galaxy_S123_ShootOut_1.htm

Lastly, Plasma seems to suffer from RBE just like DLP and there's the usual burn-in/brightness loss issues..

Mine uses CCFL and its only drawbacks are that its PSU regulation emits a fairly annoying buzzing noise when its backlight is dimmed and the viewing angles aren't nearly as good as a CRT...but all LCD screens seem to suffer from those two issues, and even some/most LED based ones seem to emit a buzzing noise when dimmed due to similarly sloppy SMPS designs...so it's still a screaming bargain IMHO and it saved my day when I was just about to give up and buy yet another DLP projector :p

25fps SD is not *generally* guessed as SMPTE-C. Actually, for sources with a height of 576 pixels (which is normally what 25fps SD is) the primaries are guessed as EBU/PAL. So the big question is: Why does madVR end up with SMTPE-C in your case? Maybe these sources don't have 576 pixels, anymore? That would be weird, though, a custom encoding with stripped black bars maybe? Or alternatively, maybe the video bitstream claims that the source has SMPTE-C primaries?
Well, there are many DVD rips without black borders and as much as you consider any 23.976 SD file to be SMPTE-C, you may also want to consider them as EBU if they're 25fps and HDTV if they're 24fps. Many ppl encode bluray's to SD and they have no clue whatsoever about the 601/709 decoding matrix story so you may also wanna enforce that SD/HD 24fps=709 matrix and SD 29.97=SMPTE-C.

I've no clue how to interpret .cal files. And while I'm sure that it would be possible to find out how they work and it would surely also be possible for me to implement that kind of stuff in madVR, I have a lot of other things on my to do list, and frankly, supporting .cal files is not what a lot of madVR users have asked so far, so it's rather low on my priority list. I only have so much development time available, and of course I have to spend it first and foremost on things which I find most important. And .cal support is not as important as several other things I still have to do, from my point of view.

Fair enough but Argyll is a strong asset to optimal HTPC installation and if your display doesn't provide all the colorimetry options, it is as good as i gets. Its user manual explains clearly that the contrast setting on a LCD screen is plain fake: http://www.argyllcms.com/doc/dispcal.html
"Almost all LCD displays lack a real contrast control. Those that do present such a control generally fake it by adjusting the video signal. For this reason it is usually best to set an LCD's contrast control at its neutral setting (ie. the setting at which it doesn't change the video signal). Unfortunately, it can be hard to know what this neutral setting is."

It also provides an option to quickly measure the CR, so I found out that my TV at 75% contrast gives a 2K:1 CR with a 2.4 gamma and 3200:1 at 100% with a 1.75 gamma....so I made a 2.5 LUT at 100% et voilà: best of both worlds :cool:

But PQ is already stunning as is, and I guess that at some point we'll either finally get 10bit 1080p digital connections or .cal support in mVR by then ^^

I also have no idea about what kind of PQ improvement could be expected from processing that 3x1DLUT stuff in 16bit within mVR instead of 8bit in the graphic card's CLUT :o

Maybe some time in the future, but not too soon. For now, please use yCMS or just live with the slightly inaccuracy.
I fail to understand why you went through the trouble of supporting 3DLUT files when a simple PS script can do it all without the need to wait for a 96MB file to be loaded. yRGB 3DLUT files can't embed 3x1DLUT calibration data either.

Also, did you use JohnAd's script verbatim?

once I implement custom pixel shader support, you could fix that small inaccuracy in your gamut yourself, couldn't you?
I don't really see how custom PS support would help me exactly? Because I'd need to be able to set up automatic rules, but maybe you also plan on supporting rules depending on resolution and frame rate?

The only thing that sounds appealing is that PS scripts are processed in 32fp RGB in MPC apparently, would that provide even better results than what mVR currently does?

All these fall under settings tweaks, and those are scheduled for closer to madVR v1.0 release. And for the record, madVR v1.0 will not necessary come after v0.99. Maybe after v0.99 there might be v0.100. Or maybe v1.0 will already come after v0.95. I simply don't know yet. v1.0 will come when all key features are implemented and everything is somewhat polished.
Alright, well I'm currently in an Andy Warhol mood and I kinda enjoy watching SMPTE-C and EBU movies in REC.709 :D

JVC decided to go wide gamut after many real world tests because people were enjoying the grossly oversatured colors, it's actually quite fun! If I get bored of it in a while, I'll just roll gamuts ^^

That settings page with those two buttons was just meant to be a helper page to get access to the full madExcept settings dialog in case you have the tray icon disabled. I don't plan to add any more buttons to that settings page.

Alright, I guess I'll assign the matrix/gamut/levels hotkeys to that Logitech USB controller I mentioned earlier then :)

I've always been extremely envious of how you can roll gamuts with a simple right-click in MPC, I guess I'll have to suck it up: http://thumbnails105.imagebam.com/21606/1cfbc7216056156.jpg (http://www.imagebam.com/image/1cfbc7216056156)

What is wrong with using the file? It might seem like overkill but if it works, what is the down side?
Several geeky reasons I guess:
1) I've got all my HTPC files on a ramdisk and that'll waste an extra 100MB of my 2 gigs
2) There'll be an uncalled for loading time wait each time I'll open a video file
3) I'm already a tester for quite a bunch of audio/video software and I've seen several older builds of yCMS not acting as expected(I'm kinda hard to please, I'll give you that :D) and the development of yCMS has been put on hold for a while.......so if anything doesn't work as I would expect it to, I'll be SOL.

A simple test will be to compare its results against JohnAd's PS script that has been proof-tested by a large number of people (http://www.avsforum.com/t/912720/color-correction-with-a-htpc-simpler-solution-and-now-it-really-works/0_100#post_11937064).

It used to be necessary to keep one 96MB 3DLUT file per gamut in older builds IIRC, but apparently the yRGB standard has put an end to this and you can get away with a single file now.....so alright, I'll test it all when I'll be bored I guess :p

[Xaurus]

Edge LED backlight is more efficient but most of them suffer from more or less severe clouding apparently, so if you end up with a dud you'll cry.
Normal LCD panels can suffer from clouding just as much as edge lit-models. If you want to have zero clouding then you need a full backlight panel with local dimming.

edit: After reading a bit on televisioninfo.com I can safely say that you should stay away from that site with regards to recommendations as the reviewers seem clueless.
They even have a review of my TV where they don't use the local dimming function; the exact reason why it's a flagship model and cost much more than the second in line.

[leeperry]

Well, local dimming doesn't come for free apparently and for instance a fast white object on a black background would end up with ghosting artifacts due to the fact that there isn't that many zones really. And if you don't enable it, then there doesn't seem to be any real world advantage over CCFL except for the lower power consumption.

lesnumeriques.com keep claiming that pretty much all LED backlit screens suffer from clouding but that it's extremely rare with CCFL thanks to the much better backlight homogeneity. They also said that the Sharp LED panels they tried had zero clouding, being pretty much the only manufacturer that fixed this problem for good.

This said, it's notorious that all manufacturers but Sharp contract several panel makers and that they often send golden samples for reviews but actually sell cheaper CMI/AUO panels IRL: http://news.cens.com/cens/html/en/news/news_inner_40642.html

Philips gave up on the UV²A panel that made its 5500 serie famous, they just don't use it anymore so all previous reviews can be seen as falsified now :o