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 20th October 2012, 07:38   #14901  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
BTW, an option to mirror the picture horizontally with a hotkey would be fantastic if any possible. I used to do it in ffdshow, but 8bit yadayada and noise comes back with a vengeance

It would also be useful to the RPTV/DIY projector ppl

Last edited by leeperry; 20th October 2012 at 07:57.
leeperry is offline   Reply With Quote
Old 20th October 2012, 07:38   #14902  |  Link
Xaurus
Registered User
 
Join Date: Jun 2011
Posts: 288
Quote:
Originally Posted by leeperry View Post
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.
I guess you are referring to halos. Yes, that could be an issue but fortunately I have managed to keep them cloze to non-visible, even with white text on a black background (typically at the start or end of a movie). The TV I use have 105 zones.

I agree on the "if you don't enable it" part. I would never buy such a set if I wasn't going to use that feature.

Quote:
Originally Posted by leeperry View Post
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.
After working over 10 years as a sales person for electronics I can tell you that all brands suffer from clouding, including Sharp. However, some sets can be "fixed" by calibrating it correctly.

Quote:
Originally Posted by leeperry View Post
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/ne...ner_40642.html
Yes, that's why you should never buy a set simply from a review on the net or any printed article. Use your own eyes.

In any case, this is off-topic for this thread so I'll leave it at that.
__________________
SETUP: Win 10/MPC-HC/LAV/MadVR
HARDWARE: Fractal Design Node 804 | Xeon E3-1260L v5 | Supermicro X11SSZ-TLN4F | Samsung 2x8GB DDR4 ECC | Samsung 850 EVO 1TB | MSI GTX 1650 Super | EVGA G2 750
Xaurus is offline   Reply With Quote
Old 20th October 2012, 09:25   #14903  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by huhn View Post
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
Ok, thanks, I managed to reproduce the issue, but it's not happening every time. I'll see if I can fix it.

Quote:
Originally Posted by mindbomb View Post
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?
Maybe some day, but not too soon.

Quote:
Originally Posted by NicolasRobidoux View Post
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/w...les/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.)
I've had a look at that paper, but it's all chinese to me. Anyway, there are people which like a bit of haloing. Personally, I hate it.

Quote:
Originally Posted by leeperry View Post
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 [...]
Which dimensions (width, height) do such files usually have?

Quote:
Originally Posted by leeperry View Post
[...] 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 won't do SD 24fps -> 709. That wouldn't be a good idea, because NTSC movie DVDs are often IVTCed and reencoded to 24fps. You can also convert 25fps PAL movies to 24fps. I actually do that myself sometimes. So doing 24fps -> 709 would produce wrong results in many cases. Changing movie FPS is so simple, you can do that with eac3to without even reencoding, that's why I prefer to base auto guessing on resolution instead of framerate, because that's a quite reliable way to detect the true source gamut. E.g. if you have a file with 576 height, it's extremely likely it's PAL/EBU. But I guess only few people would be changing 24fps movies to 25fps, so maybe auto guessing 25fps SD files to be PAL/EBU, too, might be safe, as an additional detection step.

SD 24fps could be everything, SMPTE-C, EBU/PAL or BT.709. The proper way to encode SD 24fps would be to use SMPTE-C, so that's what I'm using as default - unless the height is 576 pixels, then I'm auto guessing EBU/PAL.

Quote:
Originally Posted by leeperry View Post
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.
Because 3dlut files have the potential to do so much more than what that simple PS script does. E.g. that script can't do gamma corrections. And that's only one of many things that 3dlut could potentially do. Ultimately 3dlut files could do virtually "everything". The only limitation is the software which creates 3dlut files.

But let's not go there again, we had a heated discussion about this in the past already, if you remember. I don't feel like going there again. So this will be my last post on why I'm supporting 3dluts.

Quote:
Originally Posted by leeperry View Post
Also, did you use JohnAd's script verbatim?
Not sure what you mean, I'm not using his script at all.

Quote:
Originally Posted by leeperry View Post
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?
If you tell madVR that your display is already (externally) calibrated to e.g. BT.709, madVR will convert every input gamut to BT.709. So you could make a custom pixel shader which simply converts BT.709 gamut to your custom display primaries.

Automatic rules to make madVR choose the correct *source* gamut is a totally separate issue, which has nothing to do whatsoever with which gamut your display has. Source gamut is one thing. Display gamut is a totally separate thing. Of course both must be correct to reproduce correct results.

Quote:
Originally Posted by leeperry View Post
BTW, an option to mirror the picture horizontally with a hotkey would be fantastic if any possible.
It's on my to do list, but not coming too soon.

Last edited by madshi; 20th October 2012 at 09:29.
madshi is offline   Reply With Quote
Old 20th October 2012, 12:24   #14904  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by madshi View Post
Which dimensions (width, height) do such files usually have?
Well, any 25fps SD file has 99.99% chances of being PAL, hence EBU...so I still believe that 25fps SD files should be automatically recognized as EBU, and if you have a funky file you can always override it by pushing a hotkey if need be.

In the same way, any 29.97 SD file will be SMPTE-C but I presume you already did that(I didn't check).

Quote:
Originally Posted by madshi View Post
I won't do SD 24fps -> 709. That wouldn't be a good idea, because NTSC movie DVDs are often IVTCed and reencoded to 24fps. You can also convert 25fps PAL movies to 24fps. I actually do that myself sometimes. So doing 24fps -> 709 would produce wrong results in many cases. Changing movie FPS is so simple, you can do that with eac3to without even reencoding, that's why I prefer to base auto guessing on resolution instead of framerate, because that's a quite reliable way to detect the true source gamut.
Well, going 29.97 telecine NTSC to IVTC'ed 23.976 and then accelerated to 24fps will require an audio reencoding in order to be pitchshifted at least AFAIK.

Anyway, OK I wasn't aware that some ppl would accelerate NTSC DVD movies to 24fps.

Quote:
Originally Posted by madshi View Post
Because 3dlut files have the potential to do so much more than what that simple PS script does.
You're entirely right, but at this point they really only do the same as your PS script(which didn't exist when we previously discussed this matter) and yRGB is not a finalized standard so no one else can really work on it....but fair enough! I will stop questioning your technical choices and I sincerely thank your for your patience and your kindness sharing your stunning work with us

Quote:
Originally Posted by madshi View Post
that script can't do gamma corrections.
I tried to change the gamma value of your script from 1.80 to 2.60 when set as "pure power curve" with my display set as REC.709, but I didn't see much change in the PQ...that might explain, but I will try test patterns.

Quote:
Originally Posted by madshi View Post
Not sure what you mean, I'm not using his script at all.
But you're not using the math from his Excel sheet either? I guess you thoroughly proof-tested the gamut mapping results anyway? with those pesky out-of-gamut colors and all

Quote:
Originally Posted by madshi View Post
If you tell madVR that your display is already (externally) calibrated to e.g. BT.709, madVR will convert every input gamut to BT.709. So you could make a custom pixel shader which simply converts BT.709 gamut to your custom display primaries.
Oh, that's pushing it

Quote:
Originally Posted by madshi View Post
Automatic rules to make madVR choose the correct *source* gamut is a totally separate issue
Well, automatic rules for PS scripts based on resolution and frame rate could come in handy IMHO...for instance to do hardcore deinterlacing on (partially) broken encodes or to upscale SD with some additional processing. But then we would also need an option like in MPC so you can either set the script to be applied before or after scaling.

Quote:
Originally Posted by madshi View Post
It's on my to do list, but not coming too soon.
OK, sweet! TBH, I'm quite floored by how noisy PQ gets when I enable mirroring in ffdshow

I guess toying around in those 8bit ffdshow/avisynth apps is out of the question for me now, so indeed PS scripts inside mVR applied in 32fp would be full of win! I might even be able to find a script that would do that mirroring thingie for me without raising a stormload of noise gremlins

Last edited by leeperry; 20th October 2012 at 12:46.
leeperry is offline   Reply With Quote
Old 20th October 2012, 12:34   #14905  |  Link
DragonQ
Registered User
 
Join Date: Mar 2007
Posts: 934
Quote:
Originally Posted by leeperry View Post
Well, any 25fps SD file has 99.99% chances of being PAL, hence EBU...so I still believe that 25fps SD files should be automatically recognized as EBU, and if you have a funky file you can always override it by pushing a hotkey if need be.
Agreed, if you do a rip from a DVD there's no guarantee it'll have a height of 576 pixels (especially if it's been cropped). A frame rate of 25 or 50 fps seems a much more sensible indicator of a file having an EBU/PAL colour space.
__________________
TV Setup: LG OLED55B7V; Onkyo TX-NR515; ODroid N2+; CoreElec 9.2.7
DragonQ is offline   Reply With Quote
Old 20th October 2012, 12:46   #14906  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by leeperry View Post
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
Most people have only been evaluating gamut with 100% measurements for the longest time now. You really need to look at, at the very least, saturation in 25% increments.

I suspect these scripts probably don't do a great job of it. You really need LUT capabilities for proper calibration. Unfortunately the tools don't currently exist to do this with yCMS files. You can convert ArgyllCMS files to yCMS 3DLUTs, but ArgyllCMS does not do a very good job of creating LUTs in my opinion.

Quote:
Originally Posted by madshi View Post
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.
Downsampling in linear light using Catmull-Rom and anti-ringing seemed to have good results in my limited testing, but I don't really use downsampling much.

With upsampling, linear light scaling seems much more difficult to get good results. (but sometimes it is useful)

Quote:
Originally Posted by madshi View Post
Have tried that, but I can't see any difference. FWIW, I'm using linear interpolation when reading the LUT. That probably helps.
I realise that this was actually related to scaling algorithms, but it actually got me thinking about the yCMS LUT creation, with all this other calibration talk recently.

Am I correct to assume that if you give it say inputs for 20-100% in 10% increments, you will use linear interpolation for the LUT? In my experience building LUTs, this is optimal.

However, how you handle going to black is also very important and most LUT devices/creation tools do not do a good job of it. Because I am no longer using a CRT, I have not run into these specific issues with madVR, but that doesn't mean that they don't exist.

The problem is that a lot of LUT creation tools try to end up with the LUT reading 0,0,0 at black by changing the curve significantly from the lowest data point you give it.

For example, here is a LUT which has three data points set at 10% (38) 100% (235) and 109%? (255) with a hard clip at black (16) to 0,0,0 RGB.



A hard clip to black sounds really bad, but in practice is generally what actually looks best on a display that requires a LUT with raised shadow detail like this. (if you don't hard clip to black, you raise the black level on the display)

Most LUT tools, when given data for 10% and 100%, will try to converge RGB to 0,0,0 rather than clip it, which results in significant greyscale errors and posterization near black. What should be done, is that linear interpolation should be used to follow the line down from the two smallest measurements down (e.g. 100-10 in this example, linearly down to 1% then clipped at 0%, or 20-10% linearly down to 1% then clipped at 0% if that's what the smallest measurements were)

I don't know if this is something you handle yourself in madVR, or if you're simply passing the input data onto yCMS to let it handle LUT creation though, so it may be a discussion better suited in that topic. (though development seems to have been put on hold indefinitely?)

Quote:
Originally Posted by madshi View Post
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?
Right now, all we can do in madVR is input current measurements from the display, have it generate a LUT based on that, and then hope that the results look good... often they do not, in my experience.

What I end up doing is manually tweaking the LUT input values so that the values measured from my display when showing test patterns actually measure 2.4 gamma at all points, when that's what I have set in madVR. (my display is calibrated to 2.2 gamma for computer use, and I want madVR using 2.4 for video) This is a very laborious process though, as you are setting input Yxy values for the LUTs. I could do it in 1/10th the time if I could set RGB output values for the LUT at specific points.


Quote:
Originally Posted by madshi View Post
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.
It would actually be really useful for me if you could implement some kind of level clipping option in madVR. Right now we have the option to toggle output levels between PC (0-255) and Video (16-235) and for that, I have it set to PC.

We can also set whether an input source is using Video levels (16-235) or PC levels. (0-255) I have some videos which have not been encoded correctly, and have compressed PC levels into a Video-levels file resulting in a raised black level. The only way I have been able to fix that so far, is to change my decoder to ffdshow for those specific videos, and use its levels feature to fix the black/white points. It seems like it would be a really easy fix for madVR to offer a "compressed levels" option to fix it. (30-218 if I have done the math correctly - or even a custom option that let you hit a shortcut for +/- on the range, adjusting black & white simultaneously)

Quote:
Originally Posted by madshi View Post
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.
I know it doesn't seem like much at all, but I find even that amount of ringing distracting when it's on the subtitles layered over a moving image. Because the subtitles are fixed, and the background is moving, the ringing is far more apparent than it is in stills.

Quote:
Originally Posted by madshi View Post
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...
I strongly agree with this. I have experimented with sharpening a number of images scaled in madVR, using different techniques in Photoshop, and it seemed futile. Any benefits from using softer, low-ringing, low-aliasing scaling were immediately lost when sharpening the image. (but maybe there are better ways to do it)

Quote:
Originally Posted by madshi View Post
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.
The issue I have is that while the anti-ringing filter manages to eliminate the obvious effects of ringing, there are still "ripple" effects on the image that are caused by the ringing.

I think I have posted this example before, it's much easier to illustrate with 3-tap vs 8-tap, but still affects 4-tap:


Lanczos 3, Lanczos 8
Lanczos 3AR, Lanczos 8AR.

As you can see, the right of the red (B) is still distorted by the ringing in Lanczos 8, even though the anti-ringing filter has removed most of the visible haloing.

Quote:
Originally Posted by leeperry View Post
Same story for Philips that sends "Sharp UV²A" panels for reviews but actually puts crappy panels for sale
For what it's worth, back when I was reviewing HDTVs for one of the bigger sites out there, and helped set the standards for what hardware measurements should be taken, and what tests needed to be performed on the displays (didn't win the battle for uv charts rather than xy, unfortunately) we would never accept displays from the manufacturer. They were either purchased, or on loan from shops that would sponsor the site. (these were not selected at all, just shipped to us as anyone would get when purchasing a set, and then used as a display model)

Quote:
Originally Posted by leeperry View Post
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_Gala...ShootOut_1.htm
20,000 hours of use, at 8 hours a day is almost seven years to 50% brightness. Even at 12 hours use a day, that's just under five years - much longer than most people buying the first batch of OLED displays are likely to keep them.

Quote:
Originally Posted by leeperry View Post
Mine uses CCFL and its only drawbacks are that its PSU regulation emits a fairly annoying buzzing noise when its backlight is dimmed
Personally I experience green "RBE"-like effects when watching modern CCFL LCDs that use PWM to dim the backlight.

Quote:
Originally Posted by leeperry View Post
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
Spec is 2.4 gamma for displays with sufficient contrast (off the top of my head, I think it's 10,000:1 at reference levels) else you should be using the BT.1886 curve.

Quote:
Originally Posted by leeperry View Post
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.
I think you over-estimate what this PS script can do, and under-estimate the value of LUT calibration.

Quote:
Originally Posted by NicolasRobidoux View Post
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/w...les/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.)
In my experience, these kinds of tests are performed at "typical viewing distances" which are generally much further from the display (and using smaller displays) than HT enthusiasts will use. They are often done by testing groups of people from the general public, rather than trained observers, and don't have any eyesight requirements. (it's shocking how many people actually need vision correction, but believe their eyesight to be good)

Personally I like to sit up close, or have a big screen as anything less than about 45-50 degrees viewing angle is not immersive at all to me. At those sizes, it's purely about pixel-level image quality, and ringing like that is very obvious.

Quote:
Originally Posted by leeperry View Post
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.
The disadvantages of local dimming are overstated by people who were never in the market for buying one of those sets in the first place. Local-dimming LED backlit displays are the closest thing we have to reference-class displays available for consumers today in my opinion. (Plasma has far too many image quality compromises to be considered "reference" in my opinion, even if the Kuros had good contrast and colour accuracy)

It is rare that haloing appears on my Sony HX900, and when it does, it is still a far better image than a non-local-dimming set puts out. (CRTs suffered far worse effects and no-one seemed to complain then)

Quote:
Originally Posted by leeperry View Post
I tried to change the gamma value of your script from 1.80 to 2.60 when set as "pure power curve" with my display set as REC.709, but I didn't see much change in the PQ...that might explain, but I will try test patterns.
Use Yxy values in the greyscale/gamma measurements box, and use 0.312713, 0.329016 as your xy values.

Set Y values at various IRE points to adjust gamma in the 3DLUT. It takes a bit of going back-and-forth when displaying test patterns and updating the LUT, but you should be able to achieve a flat 2.40 gamma (or the correct BT.1886 values for your display) with a bit of patience. (note: raise Y values to lower Y on the display, and vice-versa)


And I only just noticed this but "measured IRE" should be chanced to something like "%stim".

IRE is a term for analogue voltages, and does not apply to digital video. (it is often used incorrectly, however, as people think the term is interchangeable)
6233638 is offline   Reply With Quote
Old 20th October 2012, 13:20   #14907  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by leeperry View Post
Quote:
Originally Posted by madshi
Which dimensions (width, height) do such files usually have?
Well, any 25fps SD file has 99.99% chances of being PAL, hence EBU...so I still believe that 25fps SD files should be automatically recognized as EBU, and if you have a funky file you can always override it by pushing a hotkey if need be.
For some reason I already anticipated that you were going to ignore my question.

Quote:
Originally Posted by 6233638 View Post
Am I correct to assume that if you give it say inputs for 20-100% in 10% increments, you will use linear interpolation for the LUT?
For *creating* the LUT, you mean? You'd have to ask yesgrey about that, I have not developed yCMS. From what I remember, he's actually using a better algorithm than linear interpolation. Similar to how Bilinear isn't the best algorithm for image upsampling.

Quote:
Originally Posted by 6233638 View Post
Most LUT tools, when given data for 10% and 100%, will try to converge RGB to 0,0,0 rather than clip it, which results in significant greyscale errors and posterization near black. What should be done, is that linear interpolation should be used to follow the line down from the two smallest measurements down (e.g. 100-10 in this example, linearly down to 1% then clipped at 0%, or 20-10% linearly down to 1% then clipped at 0% if that's what the smallest measurements were)
I remember that yesgrey did a lot of extra work to try to avoid these problems. But I don't really know the details.

Quote:
Originally Posted by 6233638 View Post
though development seems to have been put on hold indefinitely?
No, there's going to be a yCMS update with a bugfix "soon". I could say more, but this is really yesgrey's area, not mine.

Quote:
Originally Posted by 6233638 View Post
It would actually be really useful for me if you could implement some kind of level clipping option in madVR. Right now we have the option to toggle output levels between PC (0-255) and Video (16-235) and for that, I have it set to PC.

We can also set whether an input source is using Video levels (16-235) or PC levels. (0-255) I have some videos which have not been encoded correctly, and have compressed PC levels into a Video-levels file resulting in a raised black level. The only way I have been able to fix that so far, is to change my decoder to ffdshow for those specific videos, and use its levels feature to fix the black/white points. It seems like it would be a really easy fix for madVR to offer a "compressed levels" option to fix it. (30-218 if I have done the math correctly - or even a custom option that let you hit a shortcut for +/- on the range, adjusting black & white simultaneously)
Maybe sooner or later.

Quote:
Originally Posted by 6233638 View Post
The issue I have is that while the anti-ringing filter manages to eliminate the obvious effects of ringing, there are still "ripple" effects on the image that are caused by the ringing.

I think I have posted this example before, it's much easier to illustrate with 3-tap vs 8-tap, but still affects 4-tap

As you can see, the right of the red (B) is still distorted by the ringing in Lanczos 8, even though the anti-ringing filter has removed most of the visible haloing.
Yes, but this is 3-tap vs 8-tap, and the difference is *much* smaller with 4-tap. Still, I agree that 4-tap has more ringing artifacts than 3-tap, even with AR on. However, Lanczos 4-tap also has more sharpness and less aliasing. So I still say that it's a matter of taste which to use. I don't think anybody should use Lanczos 8-tap, though, except maybe for extremely soft content where ringing isn't ever a problem at all.
madshi is offline   Reply With Quote
Old 20th October 2012, 14:55   #14908  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by madshi View Post
For some reason I already anticipated that you were going to ignore my question.
Hah, sorry for that! Well, you're the math genius and I'm the whiner

I would guess that sloppy PAL DVD encodes are anything between 860 and 500 pixels wide and proper ones are indeed 1024 pixels wide, height will depend on the AR really. But 25fps is PAL in essence, so I still believe that 99.99% of all 25fps SD files are PAL...be it advertisements, demos, home made stuff or whatever else involving undressed ppl.

If some chipmunk voices lovers like to encode NTSC DVD's to 25fps, their files are technically out of specs anyway.

Quote:
Originally Posted by 6233638 View Post
I have some videos which have not been encoded correctly, and have compressed PC levels into a Video-levels file resulting in a raised black level. The only way I have been able to fix that so far, is to change my decoder to ffdshow for those specific videos, and use its levels feature to fix the black/white points. It seems like it would be a really easy fix for madVR
I would definitely also need some adjustable input levels in mVR in order to keep ffdshow out of the loop....two hotkeys would be great, otherwise we could always work it out with a simple PS script

Quote:
Originally Posted by 6233638 View Post
Most people have only been evaluating gamut with 100% measurements for the longest time now. You really need to look at, at the very least, saturation in 25% increments.
Indeed, I've been repeatedly told that HCFR only shows a 2D view of a 3D gamut so WYS is definitely not WYG.

I've always been using this kind of test pattern if that makes any difference:

Quote:
Originally Posted by 6233638 View Post
I suspect these scripts probably don't do a great job of it. You really need LUT capabilities for proper calibration. Unfortunately the tools don't currently exist to do this with yCMS files.
The gamut mapping math was worked out by yesgrey in matlab and proof-tested by several other colorimetry experts AFAIK. This said, I don't run a mastering house and we're all essentially looking for non-oversaturated truer-to-the-source colors. Besides, if you don't recalibrate your displays on a weekly basis using a freshly recalibrated Minolta professional spectrophotometer, you might very well soon be wasting your time IMHO.

Quote:
Originally Posted by 6233638 View Post
ArgyllCMS does not do a very good job of creating LUTs in my opinion.
Well, why not taking actions and dropping an email to Graeme Gill? He's always happy to discuss about improvements to his software and he's very fast at releasing them too.

Quote:
Originally Posted by 6233638 View Post
Personally I experience green "RBE"-like effects when watching modern CCFL LCDs that use PWM to dim the backlight.
Ah, you nail it! I thought I was imagining things but I definitely see very faint rainbows on the Windows desktop with a black background....this said, I don't see them in movies and I've survived 48Hz 4X DLP for years so I'm not afraid

Last edited by leeperry; 20th October 2012 at 16:27.
leeperry is offline   Reply With Quote
Old 20th October 2012, 15:54   #14909  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by madshi View Post
For *creating* the LUT, you mean? You'd have to ask yesgrey about that, I have not developed yCMS. From what I remember, he's actually using a better algorithm than linear interpolation. Similar to how Bilinear isn't the best algorithm for image upsampling.
Yes, I have found that using anything other than linear interpolation leads to errors/posterization when working with LUTs. I wasn't sure whether you were just passing the values onto yCMS rather than creating your own LUTs for madVR, so this discussion really belongs in the yCMS topic, sorry for that.

Quote:
Originally Posted by madshi View Post
Yes, but this is 3-tap vs 8-tap, and the difference is *much* smaller with 4-tap. Still, I agree that 4-tap has more ringing artifacts than 3-tap, even with AR on. However, Lanczos 4-tap also has more sharpness and less aliasing. So I still say that it's a matter of taste which to use. I don't think anybody should use Lanczos 8-tap, though, except maybe for extremely soft content where ringing isn't ever a problem at all.
That's true, and I agree that Lanczos 4 is better for aliasing and sharpness without a huge increase in ringing. (with AR on) But it's becoming a moot point now with the introduction of Jinc anyway, and I think I prefer Spline 3 over Lanczos these days. (I always go back and forth between the two, as they're very similar)

Quote:
Originally Posted by leeperry View Post
Indeed, I've been repeatedly told that HCFR only shows a 2D view of a 3D gamut so WYS is definitely not WYG.
HCFR has the ability to take luminance and saturation measurements and graph them as well. In fact up until fairly recently, HCFR was the only software that implemented this until ChromaPure came along, and now CalMAN v5. (I had been bugging the CalMAN team about this for years)

Quote:
Originally Posted by leeperry View Post
The gamut mapping math was worked out by yesgrey in matlab and proof-tested by several other colorimetry experts AFAIK. This said, I don't run a mastering house and we're all essentially looking for non-oversaturated truer-to-the-source colors. Besides, if you don't recalibrate your displays on a weekly basis using a freshly recalibrated Minolta professional spectrophotometer, you might very well soon be wasting your time IMHO.
My point is that you are only looking at 100% saturation there. You can easily correct 100% saturation, but what tends to happen is that everything below 100% saturation, ends up rather under-saturated. With most displays that have a gamut exceeding spec, it's often best to only reduce it slightly, for the sake of overall color reproduction vs only looking at 6 specific points that rarely actually show up in real-world content.

This is why I am hoping that at some point, yCMS will be updated so that you can create a LUT with corrections for 25/50/75% saturation in addition to just 100% saturation.


As for your comment regarding meters and calibration, I think you overstate the issue. Generally, display gamut/saturation tends not to drift much. You should only have to calibrate it once and you're usually good for the life of the display. At most I'd be checking it every few months or perhaps once a year with a high-end meter depending on the environment in which the display is being used. (shouldn't matter for home theater) An EyeOne Pro or even the ColorMunki Spectro are more than sufficient for calibrating gamut on consumer-grade displays. (and unless you have a grade-1 monitor you probably don't even need anything more than an EyeOne Pro at all)

Daily/weekly calibration is usually unnecessary with higher-end displays, and it's really only brightness and greyscale that drifts, so a colorimeter is suitable for that task.

For what it's worth, I use an EyeOne Pro in conjunction with a colorimeter (upgrading that to the latest "SpectraCal C6" now) and my Sony HX900 has barely drifted at all in the two years that I've had it, from probably at least 12 hours of use a day. It's impressive how stable high-end LED backlit displays can be. I've only made ±1-2pt adjustments to greyscale and contrast over the life of the display, and now only bother to update its calibration every couple of months. (which generally just involves changing contrast a notch or two, to bring the different backlight scanning modes to a uniform brightness)

If you have a projector though, that's another matter entirely. I would be wanting to calibrate that on at least a monthly basis, if not biweekly, as they tend to drift a lot as the bulb ages.

Quote:
Originally Posted by leeperry View Post
Well, why not taking actions and dropping an email to Graeme Gill? He's always happy to discuss about improvements to his software and he's very fast at releasing them too.
I don't know that it's necessarily a problem with the software, but rather, that I am used to commercial tools, and disagree with the method used. With ArgyllCMS, the focus seems to be on taking as many measurements and making as many adjustments as you can to each individual point on a display.

In my experience, having too much data is a bad thing when working with LUTs, and you are actually best off to use as few points of adjustment as you can (but with repeated readings to ensure total accuracy of those points) while still being within a reasonable tolerance. That is to say, it's pointless to make a LUT that has adjustments in 1% brightness increases (or even at each individual RGB point) because meter accuracy/repeatability and drift over the length of time it takes to make these measurements, means that this LUT is going to be a complete mess and suffer from noticeable posterization/discoloration throughout the greyscale.

You are much better off with adjustments at 10% (or maybe 5% if your display is particularly bad) and using interpolation between those points for smooth results, even if it means the display is technically somewhat less accurate according to your meter.

For example, here is what I ended up with, after letting ArgyllCMS create a LUT for my display, rather than simply entering 10pt values into madVR and letting it create a LUT:

http://forum.doom9.org/showpost.php?...&postcount=230


P.S. 10-bit out from madVR would still be really nice when using LUTs to avoid posterization on the display...
Quote:
Originally Posted by leeperry View Post
Ah, you nail it! I thought I was imagining things but I definitely see very faint rainbows on the Windows desktop with a black background....this said I don't see them in movies and I've survived 48Hz 4X DLP for years so I'm not afraid
At lower brightnesses (48 nits reference for projectors) I personally have not been too troubled by RBE with single-chip DLP projectors. Plasma particularly and the CCFL LCDs I owned that used PWM to dim the backlight gave me headaches to watch though.

It seems to vary by person though. I know someone that is perfectly happy with their plasma, but can't watch DLP.
6233638 is offline   Reply With Quote
Old 20th October 2012, 16:11   #14910  |  Link
MSL_DK
Registered User
 
Join Date: Nov 2011
Location: Denmark
Posts: 137
Quote:
Originally Posted by madshi View Post
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?
By showing test patterns and calibrate my display by using the options in my display's setup menu.
MSL_DK is offline   Reply With Quote
Old 20th October 2012, 16:38   #14911  |  Link
secvensor
Registered User
 
Join Date: Sep 2011
Posts: 72
Quote:
Originally Posted by madshi View Post
chroma upsampling comparison:



A picture says more than 1000 words. I don't think I have to comment this, do I?



These pictures are 400% enlarged. If you want to see the original 100% images, I've uploaded them here:

ATI - VMR9 - red fonts.png
ffdshow 2867 - red fonts.png
MPC HC YV12 Shader - red fonts.png
Haali Renderer - red fonts.png
madVR 0.5 - red fonts.png

extreme downscaling comparison:



I'm aware that you usually don't downscale that much. But I still thought that the differences were interesting, so I'm posting them here.

The ffdshow gray background is *not* caused by incorrect settings (like output levels), I've double checked that. The gray background must originate from calculation errors in the scaling algorithm (lanczos, default settings). The ATI VMR9 and Haali Renderer downscaling results might not look that bad on a quick check, but you need to see it in motion! It sparkles like crazy, totally unwatchable. ffdshow's and madVR's downscaling don't sparkle, they're both stable and smooth.

visible benefits of more than 8bit processing:

I've some screenshots to demonstrate that higher than 8bit processing does help in specific situations, but the screenshots are too big to include them in this post, so I'll just post links instead. Please open the 3 links in different tabs of your browser and then switch between them. Please make sure that your browser does not rescale the images, so that there are no additional artifacts added by the browser scaling.

The following screenshots were made with images produced by the "madTestPatternSource" YCbCr test pattern generator. More details about that in this thread:

http://forum.doom9.org/showthread.php?t=146203

Now the comparison images:

ATI - VMR9 - colors.png
ffdshow 2867 - colors.png
Haali Renderer - colors.png
madVR 0.1 - colors.png

This test pattern consists of colored rectangles which form a smooth full screen color gradiant. Properly displayed you should be able to see the rectangle borders, but you shouldn't see any visible patterns in the color gradiants.

Now if you look at the ATI VMR9 and Haali Renderer result, you do see some kind of pattern. It doesn't look that bad on the screenshot, but in motion it's really ugly, because the pattern changes with every frame. The ffdshow result is even worse. The madVR result is exactly how the test pattern is supposed to look. It also stays stable in motion. The patterns in the color gradiants are caused either by too low processing bitdepth or by rounding or truncating the final processing result down to 8bit. The madVR output is only that smooth because it uses proper dithering.

If you like these kind of comparisons, I'd suggest to try "madTestPatternSource" yourself. It's contained in the madVR archive. Use it to compare image quality yourself with the renderer you're usually using.

ATI - VMR9 - smallramp.png
ffdshow 2867 - smallramp.png
Haali Renderer - smallramp.png
madVR 0.4 - smallramp.png

On a first check these 3 images might not look all that different. But if you look closer you should see two things: (1) The gradiants in the ATI VMR, Haali Renderer and madVR screenshots are smooth from left to right, while there are some unexpected bright bars standing out in the ffdshow gradiant. (2) In the ATI VMR, Haali Renderer and ffdshow screenshots the whole gradiant is covered by very small and faint vertical bars. In contrast the madVR screenshot doesn't show any such bars.

This test pattern works very well to test whether the processing queue beginning with upscaling and ending with final output somewhere somewhen ends up in rounded or truncated 8bit. If it does, you will see those faint vertical bars. The only way to produce a really smooth output with this test pattern is to do scaling and all the processing steps afterwards with more than 8bit. Also the final result must not be rounded or truncated down to 8bit. Instead only proper dithering preserves the smoothness.
Time to Upgrade the IMGs!
Jinc+anti-ringing filter
__________________
Win7x64
Core i7 920 3.5GHz
Noctua NH-D14/ArcticCooling MX-3
6(3x2)GB Transcend 1426MHz
RoyalHD (64MB)[Solo6c][JPLAY]/HD7850DC22GD5V2[EIZOT965]
Seasonic X-750
VelociRaptor WD4500HLHX/16TB_STORE
secvensor is offline   Reply With Quote
Old 20th October 2012, 18:06   #14912  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by leeperry View Post
I would guess that sloppy PAL DVD encodes are anything between 860 and 500 pixels wide and proper ones are indeed 1024 pixels wide, height will depend on the AR really.
You know, it would have been nice if you had put a bit of effort into answering my question. Like actually investing 5 minutes to look at your PAL movies and give me a list of typical resolutions...

Quote:
Originally Posted by MSL_DK View Post
By showing test patterns and calibrate my display by using the options in my display's setup menu.
In that case I'd recommend to tell madVR that your display is not calibrated yet. You can do this by telling madVR to disable the calibration controls. Then after you've calibrated your display by using your display's setup menu, you can tell madVR that your display is already calibrated and how you calibrated it. That will allow you to change gamma curves/values through the madVR controls, without damaging your calibration. As the first step of the calibration you should make sure that GPU and madVR RGB output levels are set correctly, by checking black and white levels with a test pattern.

Last edited by madshi; 20th October 2012 at 20:48.
madshi is offline   Reply With Quote
Old 20th October 2012, 18:11   #14913  |  Link
njfoses
Registered User
 
Join Date: Feb 2012
Posts: 44
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.


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.

With all the new versions out in the last few weeks i have not really been keeping up. Im in the same boat as you as i cant stand ringing. I have a dlp and prefer the film look. What would you recommend at this point for chroma, image up and image down on the latest madvr?
njfoses is offline   Reply With Quote
Old 20th October 2012, 19:58   #14914  |  Link
pankov
Registered User
 
Join Date: Mar 2002
Location: Sofia, Bulgaria
Posts: 661
madshi,
thank you very much for the new and improved version of madVR with Jinc and the user asignable keyboard shortcuts.
I have a small complaint though - I'm no more able to control madVR's OSD via Girder (the old v3.3.9 to be precise). I guess you've changes something in the way you hook the keyboard events and it prevents other keyboard "emulators" including Microsoft's own "On-Screen Keyboard" to fake the input.
I've tried changing the "use only if media player has keyboard focus" checkbox but sadly this doesn't fix the issue.
So is there any chance you can change back to old keyboard hooking method?
__________________
Z370M Pro4 | i3-8100 | 16GB RAM | 256GB SSD + 40TB NAS
NVIDIA GTX 1060 6GB (385.28) | LG OLED65B7V
Win 10 64bit 1803 + Zoom Player v14
pankov is offline   Reply With Quote
Old 20th October 2012, 20:49   #14915  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by pankov View Post
I have a small complaint though - I'm no more able to control madVR's OSD via Girder (the old v3.3.9 to be precise). I guess you've changes something in the way you hook the keyboard events and it prevents other keyboard "emulators" including Microsoft's own "On-Screen Keyboard" to fake the input.
I've tried changing the "use only if media player has keyboard focus" checkbox but sadly this doesn't fix the issue.
So is there any chance you can change back to old keyboard hooking method?
I haven't really changed the hooking method. Can you please try to identify the exact version with which the problem started?
madshi is offline   Reply With Quote
Old 20th October 2012, 21:04   #14916  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by huhn View Post
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.



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
I've checked. This appears to be a bug in MPC-HC. The media player is responsible for telling the renderer where to render the video. MPC-HC tells madVR the correct size and position when starting in windowed playback. Then when pausing and stopping playback, then maximizing the player, then restarting playback, MPC-HC never tells madVR to change the playback size/position. So madVR continues to render at the (relative) pos/size which MPC-HC used in windowed playback. Nothing I can do about it. Would have to be fixed by the MPC-HC developers.
madshi is offline   Reply With Quote
Old 20th October 2012, 21:06   #14917  |  Link
pankov
Registered User
 
Join Date: Mar 2002
Location: Sofia, Bulgaria
Posts: 661
OK
I guess I've made a mistake
The MS one does work - it's only the Girder App that I'm using that is failing to work.

I've just tried all 0.84.x versions and the problem is present since 0.84.0. v0.83.7 works fine - so it's the first version that introduced the configuration window for the shortcuts.

Are you familiar with Girder, the old version that was very popular a few years ago?
If you are not and have the will and time to try it I can send you a copy and a configuration file that you can use to test it.
__________________
Z370M Pro4 | i3-8100 | 16GB RAM | 256GB SSD + 40TB NAS
NVIDIA GTX 1060 6GB (385.28) | LG OLED65B7V
Win 10 64bit 1803 + Zoom Player v14
pankov is offline   Reply With Quote
Old 20th October 2012, 22:35   #14918  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by madshi View Post
You know, it would have been nice if you had put a bit of effort into answering my question. Like actually investing 5 minutes to look at your PAL movies and give me a list of typical resolutions.
Well, I'm afraid we're really misunderstanding each other here as I've got a lot of 25fps SD files, some are DVD encodes, some aren't, some are 16:9, others 4:3, some are 640 pixels wide, others plain 1024....encodes aren't standardized you know.

I can assure you that my posts in this thread today took me more than 5 mins to write up and the only answer there really is is the good ole' "x<1025 + y<577", which IIRC is the usual SD automatic detection spec. 25fps and 50fps mean PAL, hence EBU. The same way anything SD and 23.976, 29.97 or 59.94fps is SMPTE-C. I did check the resolution of my files

I also believe that a proper untouched PAL DVD remux should be done in 720x576 MKV with a DAR of either 4/3 or 16/9, because encoding upscaled pixels is a terrible idea to begin with.

I've watched a few SD PAL files today and I was forced to manually roll their gamuts because they were all recognized as SMPTE-C(none of them was 1024x576). You seem to currently treat all SD files as SMPTE-C apart from 1024x576=EBU...that'd be great if this could be worked out if any possible.

Quote:
Originally Posted by 6233638 View Post
Daily/weekly calibration is usually unnecessary with higher-end displays, and it's really only brightness and greyscale that drifts, so a colorimeter is suitable for that task.
All I know is that mastering houses usually have their CRT/CCFL LCD screens recalibrated on a weekly basis and that most consumer grade colorimeters might not be accurate enough(especially in dark areas) to warrant an extremist approach to colorimetry. But good to know that LED backlights are very stable colorimetry-wise

Quote:
Originally Posted by 6233638 View Post
For example, here is what I ended up with, after letting ArgyllCMS create a LUT for my display, rather than simply entering 10pt values into madVR and letting it create a LUT:

http://forum.doom9.org/showpost.php?...&postcount=230
This could be an import problem in that .ti3 parser, isn't it? I've got a hard time believing that this nasty posterization problem would come from Argyll's LUT. I call on a misbehaving middle-man here. Argyll spends a lot of time smoothing its curves AFAIK.

As you know, Argyll has an accuracy level switch that goes from "low" to "very high"(which is undocumented for a good reason) and "medium" seems to be the right balance between too little measurements and too many of them that could temper with the results(especially with a spectrophotometer).

The "medium" 3x1DLUT graphic card's CLUT I personally build with Argyll make HCFR plenty happy:

So a detailed bug report might be in good order if your posterized picture is really what a vanilla Argyll LUT gave you.

Last edited by leeperry; 21st October 2012 at 04:55.
leeperry is offline   Reply With Quote
Old 21st October 2012, 00:06   #14919  |  Link
pankov
Registered User
 
Join Date: Mar 2002
Location: Sofia, Bulgaria
Posts: 661
Quote:
Originally Posted by leeperry View Post
I've watched a few SD PAL files today and I was forced to manually roll their gamuts because they were all showing up as SMPTE-C(none of them was 1024x576), so that'd be great if this could be worked out if any possible.
leeperry,
I don't want to offend you by any means but why is it so hard for you to answer the simple question madshi is asking? Instead of saying what the resolutions of these files were not just say what they were. Even provide a sample or two. I'm sure this will help him better understand your issue and probably provide a better solution. I'm not saying that I disagree with your logic about 25/50fps being PAL but from my experience madshi asks his questions for a reason so, please, be kind enough to provide him an exact answer.

Again, I'm posting this only to help you both clear everything up and avoid the conflict that seems to be building up.
__________________
Z370M Pro4 | i3-8100 | 16GB RAM | 256GB SSD + 40TB NAS
NVIDIA GTX 1060 6GB (385.28) | LG OLED65B7V
Win 10 64bit 1803 + Zoom Player v14
pankov is offline   Reply With Quote
Old 21st October 2012, 02:35   #14920  |  Link
Gser
Registered User
 
Join Date: Apr 2008
Posts: 418
Bobbed deinterlacing doesn't seem to work. Running on madvr v0.84.3, win7 b4bit, AMD 5870 driver 12.8. I'm not exactly sure how long its been broken.

Last edited by Gser; 21st October 2012 at 03:04.
Gser 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 11:20.


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