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 18th October 2012, 18:33   #14861  |  Link
TheLion
Registered User
 
Join Date: Dec 2010
Posts: 62
Quote:
Originally Posted by dansrfe View Post
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.
TheLion is offline   Reply With Quote
Old 18th October 2012, 19:00   #14862  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
Quote:
Originally Posted by blackjack12 View Post
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.
Asmodian is offline   Reply With Quote
Old 18th October 2012, 20:45   #14863  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by TheLion View Post
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 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.


Quote:
Originally Posted by Asmodian View Post
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.
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.
6233638 is offline   Reply With Quote
Old 18th October 2012, 21:06   #14864  |  Link
Pat357
Registered User
 
Join Date: Jun 2006
Posts: 452
Quote:
Originally Posted by iSunrise View Post
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.
Pat357 is offline   Reply With Quote
Old 18th October 2012, 21:13   #14865  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
Quote:
Originally Posted by 6233638 View Post
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
Asmodian is offline   Reply With Quote
Old 18th October 2012, 21:26   #14866  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Montreal Canada
Posts: 269
I find 6233638's observations interesting.
NicolasRobidoux is offline   Reply With Quote
Old 18th October 2012, 22:30   #14867  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
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.
Asmodian is offline   Reply With Quote
Old 19th October 2012, 01:19   #14868  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
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
Quote:
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 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:

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


Last edited by leeperry; 19th October 2012 at 05:37.
leeperry is offline   Reply With Quote
Old 19th October 2012, 02:28   #14869  |  Link
pie1394
Registered User
 
Join Date: May 2009
Posts: 212
Quote:
Originally Posted by Asmodian View Post
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.
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.
pie1394 is offline   Reply With Quote
Old 19th October 2012, 02:32   #14870  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
Quote:
Originally Posted by leeperry View Post
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.

Quote:
Originally Posted by leeperry View Post
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
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.

Quote:
Originally Posted by pie1394 View Post
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.

Last edited by Asmodian; 19th October 2012 at 02:42.
Asmodian is offline   Reply With Quote
Old 19th October 2012, 03:21   #14871  |  Link
agustin9
Registered User
 
Join Date: Aug 2008
Posts: 86
Quote:
Originally Posted by 6233638 View Post
Did you ever run 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
agustin9 is offline   Reply With Quote
Old 19th October 2012, 04:10   #14872  |  Link
TheLion
Registered User
 
Join Date: Dec 2010
Posts: 62
Quote:
Originally Posted by agustin9 View Post
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 It seems to be a better choice for madVR.
TheLion is offline   Reply With Quote
Old 19th October 2012, 04:57   #14873  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by Asmodian View Post
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:
Quote:
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

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.

Quote:
Originally Posted by Asmodian View Post
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

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.

Quote:
Originally Posted by Asmodian View Post
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:



-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

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

Last edited by leeperry; 19th October 2012 at 07:22.
leeperry is offline   Reply With Quote
Old 19th October 2012, 05:28   #14874  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
Check out the yCMS section, I just write my RGBW primaries into madVR and it takes care of the rest.

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

Last edited by Asmodian; 19th October 2012 at 05:31.
Asmodian is offline   Reply With Quote
Old 19th October 2012, 05:47   #14875  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
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
leeperry is offline   Reply With Quote
Old 19th October 2012, 13:34   #14876  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by NicolasRobidoux View Post
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.

Quote:
Originally Posted by NicolasRobidoux View Post
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.

Quote:
Originally Posted by NicolasRobidoux View Post
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?

Quote:
Originally Posted by huhn View Post
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.

Quote:
Originally Posted by NicolasRobidoux View Post
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.

Quote:
Originally Posted by NicolasRobidoux View Post
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.

Quote:
Originally Posted by MSL_DK View Post
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?

Quote:
Originally Posted by 6233638 View Post
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.

Quote:
Originally Posted by 6233638 View Post
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.

Quote:
Originally Posted by iSunrise View Post
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...

Quote:
Originally Posted by 6233638 View Post
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 DVD)



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.

Quote:
Originally Posted by strumf666 View Post
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.

Quote:
Originally Posted by Pulstar View Post
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.

Quote:
Originally Posted by cyberbeing View Post
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.

Quote:
Originally Posted by NicolasRobidoux View Post
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

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.
Quote:
Originally Posted by NicolasRobidoux View Post
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

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

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.

Quote:
Originally Posted by NicolasRobidoux View Post
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 is offline   Reply With Quote
Old 19th October 2012, 13:38   #14877  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Peekstra View Post
It's probably the adaptive vsync option, it's enabled.
Yes, that sounds like a very likely explanation.

Quote:
Originally Posted by yok833 View Post
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.

Quote:
Originally Posted by jmone View Post
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.)

Quote:
Originally Posted by Xaurus View Post
And it tackles anything you throw at it
For now...

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

Quote:
Originally Posted by NicolasRobidoux View Post
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...

Quote:
Originally Posted by 6233638 View Post
Quote:
Originally Posted by dansrfe View Post
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.

Quote:
Originally Posted by blackjack12 View Post
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.

Quote:
Originally Posted by 6233638 View Post
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.

Quote:
Originally Posted by leeperry View Post
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?

Quote:
Originally Posted by leeperry View Post
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?

Quote:
Originally Posted by leeperry View Post
2) My display is calibrated via an 11kb 3x1DLUT .cal file 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.

Quote:
Originally Posted by leeperry View Post
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:

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?

Quote:
Originally Posted by leeperry View Post
... 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.

Quote:
Originally Posted by leeperry View Post
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.
madshi is offline   Reply With Quote
Old 19th October 2012, 14:40   #14878  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Montreal Canada
Posts: 269
Mathias:
I am often wrong.
But I am occasionally right.
NicolasRobidoux is offline   Reply With Quote
Old 19th October 2012, 14:41   #14879  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Montreal Canada
Posts: 269
Jinc3 with AR often looks really good.
NicolasRobidoux is offline   Reply With Quote
Old 19th October 2012, 14:42   #14880  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by NicolasRobidoux View Post
Mathias:
I am often wrong.
But I am occasionally right.
Can I get that in percentages?

Quote:
Originally Posted by NicolasRobidoux View Post
Jinc3 with AR often looks really good.
Yes, I really like it.
madshi 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 00:31.


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