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 7th June 2011, 00:56   #8021  |  Link
janos666
Registered User
 
Join Date: Jan 2010
Posts: 473
Quote:
Originally Posted by Plutotype View Post
Calibration of the TV is a must. But when feeding the LCD with video, one thing is for sure the main culprit - avoiding crushed blacks and whites. In my ATI settings I have RGB full ( 4:4:4 ) and madVR is set it to TV levels. If you manage to calibrate your SONY to accept PC levels and keep the picture detailed and without B/W being crushed, than you can of course use the PC levels. I have not managed that, other would say - the settings would have to be very extreme to believe it is correct.
Just a tip, but there is an "ADC/WB" category in the service menu of my Samsung PN51D550 where I could fine-tune something called "HDMI calibration" (the names could wary between models, as well as the available controls, so it's only a tip what could help...) to avoid the mild black-clipping (I think it was intentional to "filter out" the usually noisy dark shades and make the images appear "more clear and contrasty" and look like the blacks are deeper black -> some contents never hit the Y=16 level because they are noisy on dark areas, so some user would complain that their MLL doesn't seem to be as low as they expect it from a PDP...)
janos666 is offline   Reply With Quote
Old 7th June 2011, 01:03   #8022  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 497
Thanks a lot for 0.62 and 0.63 madshi. Those are some great changes you did there (imho).

To be honest, with 0.62 I was kinda confused at first, when looking through all the new additions and to be 100% sure, how to setup everything correctly for my display. With 0.63, however, everything got a lot easier, but I still have at least one further question (look at the bottom of my post).

Bug report with 0.63:
While I tried to do some more in-depth testing with madVR 0.63 and my 8-bit IPS display (it accepts 10-bit through DisplayPort, but FRCs down to 8-bit internally) I found a bug in color & gamma. It seems that the gamma processing settings are always enabled, no matter if you disable or enable the gamma processing itself. To reproduce, just change the default 2.20 desired display gamma to 2.35 and then disable the gamma processing. The 2.35 setting is still active after you disabled the gamma processing, however. Same thing with desired transfer function. Should be very easy to fix.

One more thing (cosmetical, not a bug per se) with 0.63:
In the color & gamma tab, the descriptions of the gamma processing are reversed. It should say "desired transfer function / display gamma" since that is the way the pulldown-menus are ordered.

Now my question(s):
My display is calibrated to sRGB, 80cd, D65, 2.20 for everyday work, games and movies (levels from 0 to 255 are perfectly distinguishable), therefore I assume I should be using sRGB, pure power curve and 2.20 in the calibration tab and disable the gamma processing, since my display is already perfectly calibrated. Is that correct?

Im asking since I have tested the gamma processing under the color & gamma tab and changing the desired transfer function from pure power curve to BT.709/601 curve does look more natural to my eyes, while pure power curve looks a lot more saturated.

Im a bit unsure now, what madVR actually does internally when I have it setup like that. Am I supposed to change the transfer function under the gamma processing according to the content Im playing or is there only one "right" setting? (With the actual calibration of my display in mind.)

Last edited by iSunrise; 7th June 2011 at 01:11.
iSunrise is offline   Reply With Quote
Old 7th June 2011, 01:24   #8023  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by Andy o View Post
Now it doesn't work at all with 1080i59 in there, but it works with 1080i29, if 1080p23 is not there. If 1080p23 or 1080p50 is there, then it switches to those instead, in that priority.

Here are the logs for when it does work (1080i29 by itself) and when it doesn't (1080p23 and 1080p50 in there as well).
Ok, the log says your content is 59p and the interlaced display mode is 29i. Currently madVR accepts an interlaced mode only if the refresh rate is at least as high as the movie framerate. But I understand that in your case the GPU simply names the mode differently than I do. It says 29i and that's really the same as 59i, just a different name. Guess I need to support that, too. <sigh>

Quote:
Originally Posted by Andy o View Post
Also, if madVR can't tell when the video is interlaced, then would it be possible for madVR to give priority always to 1080i59/60 when both 1080i59/60 (or 1080i29/30) and 1080p59/60 are on the list?
madVR should prefer 1080i59 mode for 59i content. But for 59p content 1080p59 is preferred. If you don't want that, simply remove the 1080p59 mode from the list.

Quote:
Originally Posted by Andy o View Post
madshi, to add to my post above... 1080i59 doesn't work at all now, and 1080i29 only works with 60p content (the interframe sample). With 59i content (m2ts from the Dolby bluray) it switches to 1080p50, when 1080p23, 1080p50, 1080i29 are in the list. When I add to those 1080i59, it doesn't switch at all from other rates.
Yeah, that's weird, will have to check that. FWIW, don't use 1080i59, your GPU doesn't seem to like/support that. Use 1080i29, but madVR currently doesn't like it (yet!).

Quote:
Originally Posted by STaRGaZeR View Post
I don't really know about this stuff, but are you saying that, since no renderer does gamut correction besides madVR, all of them will only display 1 type of content (NTSC, PAL, etc.) properly, assuming the display is locked to one of them?
I don't know if other renderers do gamut correction but I don't think so. So what you're saying is most probably correct.

Quote:
Originally Posted by STaRGaZeR View Post
That rises the question: how does madVR know which correction it has to apply? You tell it your monitor properties, but how does it decide between the source options?
Currently it's a bit stupid. madVR assumes BT.709 if the source width is > 1024 or if the source height > 576. It uses PAL if the height is exactly 576 and NTSC otherwise. You can rotate between these color standards by pressing Ctrl+Alt+Shift+C.

Quote:
Originally Posted by STaRGaZeR View Post
The renderer is not in position either. It has no way of knowing the original source levels, as far as I can see madVR just assumes TV levels for everything. Fraps and PC-range encoded H.264 sources will always be wrong as long as this behaviour doesn't change. ffdshow adapts to this because it has all the info, the renderer cannot, unless you offer an option not to process RGB input.
Actually I plan to make madVR aware of all this stuff in a future version, by peeking into the h264 bitstream myself. However, the levels issue is a big problem, because the h264 "full range" flag is incorretly activated in many many European broadcasts.

Quote:
Originally Posted by STaRGaZeR View Post
So what do we do, let the renderer assume source properties it doesn't have, or let the decoder assume monitor properties it doesn't have? The trend when YCbCr conversion is done in the renderer is to assume source properties, and the trend when the YCbCr conversion is done in the decoder (RGB output) is to assume monitor properties and not touching it in the renderer. You can go against the trend, but that won't give you much success I'm afraid.
I don't agree that RGB is not touched by the renderer. The renderer at least has to scale it. That is already touching the data. Also, if you want to calibrate your display by using the renderer, additional touch is necessary. Furthermore, if you change the renderer's brightness & contrast controls (which madVR doesn't have yet) I would expect this to affect RGB, too. Finally, if the renderer does things like motion interpolation or black/dark frame insertion, again the RGB data needs to be touched.

I simply do not agree with your "a renderer should not touch RGB input" concept. I think it's fundamentally flawed. Ok, so there are problems right now, let's solve them. But properly, not by sticking to flawed concepts.

Quote:
Originally Posted by STaRGaZeR View Post
And how does madVR know which corrections are necessary and which aren't, when it doesn't know the original properties of the video? The corrections madVR does now with all known (by me) RGB sources are incorrect because of this. That's the point, no filter I know of tells the renderer any of this info. The same issue happens when resizing SD content to HD, the renderer doesn't know that the source is SD and converts it with HD settings, you know the result.
These are all things I have on my to do list to solve. It's not difficult for me to find out which resolution the original video had before being resized by some other filter. I've just not found the time to implement that yet.

Quote:
Originally Posted by STaRGaZeR View Post
The common trend among renderers is to convert assuming their input resolution is the source resolution, just like the common trend is to not touch RGB input because it's assumed to be properly processed.
I don't care about common trends. I care about proper solutions. If I cared about common trends there would be no madVR right now and everybody would use EVR.

Quote:
Originally Posted by STaRGaZeR View Post
Do you know of any filters that, when outputting RGB32, work without issues in madVR?
Sure. If I switch CoreAVC to RGB output, image quality is just fine - except for the lousy chroma upsampling performed by CoreAVC, of course. Or if I decode a video with ffdshow and switch ffdshow to RGB, image quality is fine, too, if I configure ffdshow correctly.

Quote:
Originally Posted by cyberbeing View Post
So madVR is treating all videos as a 2.2 power-curve (which is a reasonable guess, but isn't necessarily correct)? The problem would be if you wanted your videos to be linearized with the assumption they were something other than a 2.2 power-curve, like a REC709 curve or some other arbitrary gamma which is unique to the source.

Then what does happen? madVR linearizes REC601 with a REC601 curve, REC709 with a REC709 curve, PAL with a PAL curve and then coverts to a gamma of 2.2? If that is really what you are doing, that gamma of 2.2 intermediary gamma should be configurable when used with a 3dlut.
Let me try to explain in a different way. Maybe that helps. The processing chain with v0.62+ is like this:

madVR:
(1) input = 8bit Y'CbCr, 709 primaries, 709 gamma
(2) convert -> 32bit float R'G'B', 709 primaries, 709 gamma
(3) convert -> 32bit float RGB, 709 primaries, linear light
(4) convert -> 32bit float RGB, yRGB primaries, linear light
(5) convert -> 32bit float R'G'B', yRGB primaries, pure power 2.2 gamma
3dlut:
(6) input = 8bit float R'G'B', yRGB primaries, pure power 2.2 gamma (with trilinear interpolation)
(7) convert -> 64bit float RGB, yRGB primaries, linear light
(8) convert -> 64bit float RGB, display primaries, linear light
(9) convert -> 16bit int R'G'B', display primaries, display corrected gamma
madVR:
(10) input = 16bit int R'G'B', display primaries, display corrected gamma
(11) dither down to 8bit R'G'B', display primaries, display corrected gamma

Where in this chain do you see any reason for problems? The steps (5) and (7) are exactly the opposite of each other, so they equal each other out. It does not make any sense to make steps (5) and (7) adjustable because they have to be opposite of each other. And as long as they are, it doesn't matter if we use a pure power gamma curve of 2.2, or something completely different. These two steps must just cancel each other out, that's all. We only do this because the transport from madVR -> 3dlut is mathematically more correct if we use gamma light instead of linear light. If that were not the case we'd keep the data linear light all the time. But that would mathematically be worse.

Quote:
Originally Posted by cyberbeing View Post
I don't believe so, yesgrey seemed to think it was a valid use-case of the option. janos666 was using the input_transfer_function to describe his display rather than the transfer function of the video.
IIRC at that time janos666 did that because it produced better results with test patterns. In the meanwhile yesgrey has made this the default yCMS behaviour. So the special tweak used by janos666 is no longer necessary. At least that's IIRC.

Quote:
Originally Posted by cyberbeing View Post
If that is the reason you left it in, so be it. There would be little incentive to anybody else to implement an application for creating 3dlut files for madVR with the input format requirements being so limited.
There's already one other CMS software supporting 3dlut creation for madVR. The author of that software has already confirmed that he'll add support for yRGB and madVR v0.62+.

Quote:
Originally Posted by cyberbeing View Post
Sure the gamut adaption could be different, but you've cut out madVR's ability to use 90% of the 3dlut functionality in 0.62+. I still don't like that you are limiting the usefulness and flexibility of the 3dlut compared to shaders.
And I still don't see any practical situation where v0.62+ limits your 3dlut usage. Can you give me a practical example? And you saying: "I can't use Input_Transfer_Function, anymore" only qualifies if you explain what practical benefit you'd get from using Input_Transfer_Function.

Quote:
Originally Posted by cyberbeing View Post
Thanks for this. I'm still a bit confused how madVR is dealing with 16-235 input vs 0-255 input. Can you explain? How does madVR processing of 16-235 YUV input differ from 0-255 YUV input? How does madVR processing of 16-235 RGB input differ from 0-255 RGB input?
madVR doesn't deal with it at all at the moment. madVR strictly expects all input content to be "video levels". Yes, that's not good and I need to fix that. But there are a million other things I need to do, too, and since PC levels content is very rare, it's not top of my priority. I will support PC levels content sooner or later, though.

Quote:
Originally Posted by cyberbeing View Post
As of right now, I still can't help this lingering feeling that 0.62+ is a downgrade from 0.61 functionality wise (3dlut stuff).
And I still don't understand why you think that way. Nothing has changed, really. The only difference is that some parts of 3dlut functionality are now available in madVR, and as a consequence the interface between madVR and the 3dlut is stricter defined. But that doesn't have any *practical* disadvantages, from what I can see.

Quote:
Originally Posted by cyberbeing View Post
Is that really true that conversion from 0-255 to 16-235 to 0-255 in 32 bit FP math is lossless? It seems like it would be lossy to some extent.
It is not lossless, but the loss is so small that it's far from visible. We humans already have problems seeing a difference between 8 and 10 bit. We can see that, but we have to look closely. The more bits you add the smaller the visible difference gets. 32bit float is TONS of superfluous bits.

Quote:
Originally Posted by cyberbeing View Post
If I'm not able to get madVR 0.62+ to produce a video which looks identical to 0.61 then something is wrong.
Yes, that's an approach I like.

Quote:
Originally Posted by cyberbeing View Post
I don't use the Gamma_Curve command, which is why I am stressing about it. I've gotten to the point that I don't want anything to touch my gamma (except linearizing for gamut correction).
Then v0.63 should make you happy.

Quote:
Originally Posted by cyberbeing View Post
For my needs, does 0.62+ offer any advantage over 0.61 [...]?
YES. The "trade quality for performance" section allows you to use a 7bit or 6bit 3dlut, which might fix that nasty 3dlut stuttering you get with out-of-gamut scenes in Avatar etc.

Quote:
Originally Posted by STaRGaZeR View Post
how do you teach every decoder out there to communicate properly with a renderer made by a random guy in a random forum?
You don't. Instead you let that random guy in a random forum collect all needed information without the help of the decoder.

Quote:
Originally Posted by STaRGaZeR View Post
True. But since I'm not a color freak I don't need that level of perfection. Just want to use madVR's awesome vsync with my RGB32 sources, is that simple.
Try v0.63. By default gamma processing is disabled. Then switch ffdshow to video levels and you should be fine.

Quote:
Originally Posted by Darth Viorel View Post
Just out of interest: isn't sRGB the same as BT.709?
The primaries/gamut are the same, yes. But it's more intuitive to allow users to pick sRGB in the settings dialog because not everybody knows that the primaries are shared with BT.709.

Quote:
Originally Posted by leeperry View Post
To avoid confusion, it's widely acknowledged to use those terms:
- SMPTE-C / EBU / HDTV for gamuts.
- REC-601 / REC-709 for color matrixes.
Don't know. BT.601 and BT.709 also define gamuts, AFAIK. And SMPTE-C and EBU probably also define color matrixes.

Quote:
Originally Posted by leeperry View Post
I have to admit that I really don't follow what's going on w/ all this in >0.61, but that's no biggy...also, compressed LUT's don't seem to be supported (yet)?
No, they're not supported yet. BUT you can switch source gamuts via keyboard shortcut, which is what you always asked for.

Quote:
Originally Posted by leeperry View Post
You also seem to imply that the new LUT's only accept TV levels? But it's a bit confusing atm...I do feed PC levels to mVR.
Well, madVR doesn't cut BTB/WTW. So if you feed madVR with PC levels, madVR will treat dark gray and bright white as BTB/WTW. The information will survive and be sent to the display. But color and gamma processing will not be 100% accurate this way.

Quote:
Originally Posted by leeperry View Post
I'll wait for the colorimetry options to become a bit clearer
v0.63 should have made things quite a bit clearer. If things are still unclear for you I'm open for questions/feedback.

Quote:
Originally Posted by leeperry View Post
I use VGA to a CRT...the CLUT works in 10bit(double-checked w/ ARGYLL), so can it be considered as a 10bit display? It's 8bit w/ a 10bit CLUT on top...VGA is indeed 30bit AFAIK.
I'm not sure, to be honest. Best would be to test this with a test pattern. But won't work for now, anyway, since madVR doesn't really support > 8bit output yet. The 9bit/10bit options are gone in v0.63.

Quote:
Originally Posted by n3w813 View Post
What should I set the option of levels for MadVR if I'm using Lav Splitter, Lav Cuvid, ffdshow raw processor [sharpen] (output=YV12), to MadVR? Should I select TV or PC levels? How do I check to see if the levels are compressed/expanded?

My video card is a Nvidia and the Nvidia Control Panel setting is set to output RGB. TV is a Sony LCD connected via HDMI.
First of all you may want to re-create your preferred video output mode as a custom mode, because with current NVidia drivers that's the only way to force the driver to output proper 0-255 levels. Once you've done that, get yourself one of those cheap calibration DVDs, or download the free AVSForum calibration disc. With these discs you should be able to double check whether you have to set madVR to 0-255 or 16-235 output. Since your display is a TV, it will *probably* want TV levels, but better double check with a calibration DVD.

Quote:
Originally Posted by gendouhydeist View Post
hi guys, i got a problem here... i dunno how to calibrate madVR to my LCD monitor it said that i should provide a gamut and grayscale measurements for my monitor, so how I'm going to do that?
It asks you for gamut/grayscale measurements if you enable the option "calibrate this display by using yCMS". For that to work you need to have your own meter. Then you have to measure your display and ever the measurements into the "yCMS" tab in the settings dialog. If you don't have a meter, you'll have to choose the option "don't calibrate this display".

Last edited by madshi; 7th June 2011 at 01:45.
madshi is offline   Reply With Quote
Old 7th June 2011, 01:35   #8024  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by Snowknight26 View Post
For the sake of every non-German, you might wish to change Strg to Ctrl. ;D
Ooooops. Done.

Quote:
Originally Posted by iSunrise View Post
I found a bug in color & gamma. It seems that the gamma processing settings are always enabled, no matter if you disable or enable the gamma processing itself. To reproduce, just change the default 2.20 desired display gamma to 2.35 and then disable the gamma processing. The 2.35 setting is still active after you disabled the gamma processing
How do you know it's still active? Do you see that from the darker image? Or by some other way?

Quote:
Originally Posted by iSunrise View Post
My display is calibrated to sRGB, 80cd, D65, 2.20 for everyday work, games and movies (levels from 0 to 255 are perfectly distinguishable), therefore I assume I should be using sRGB, pure power curve and 2.20 in the calibration tab and disable the gamma processing, since my display is already perfectly calibrated. Is that correct?
If your display is already perfectly calibrated then you don't need to use a 3dlut. So you can keep all that stuff disabled. Your setup sounds correct to me. You don't have to disable gamma processing on the Color & Gamma settings page, though. If you like it that way, that's fine, but:

Quote:
Originally Posted by iSunrise View Post
Im asking since I have tested the gamma processing under the color & gamma tab and changing the desired transfer function from pure power curve to BT.709/601 curve does look more natural to my eyes, while pure power curve looks a lot more saturated.

Im a bit unsure now, what madVR actually does internally when I have it setup like that. Am I supposed to change the transfer function under the gamma processing according to the content Im playing or is there only one "right" setting? (With the actual calibration of my display in mind.)
The ideal gamma curve and value depend on many things, including e.g. ambient light level. There's no single "right" or "wrong" setting. Just choose what looks best to your eyes. For batcaves the usual recommendation is 2.35, for ambient light 2.2 or 2.0. I believe ISF calibrators usually calibrate to a pure power curve. But madVR also allows you to realize a BT.709 curve. Choose the curve type you like better. It's probably simply a matter of taste. The BT.709 curve should give you better shadow detail. The pure power curve should give you more punch.
madshi is offline   Reply With Quote
Old 7th June 2011, 01:37   #8025  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 497
Quote:
Originally Posted by madshi
How do you know it's still active? Do you see that from the darker image? Or by some other way?
Yes, should have mentioned that to be more clear. Thats exactly how I know it, because the picture is noticably darker, when 2.35 is still active.

Quote:
Originally Posted by madshi
The ideal gamma curve and value depend on many things, including e.g. ambient light level. There's no single "right" or "wrong" setting. Just choose what looks best to your eyes. For batcaves the usual recommendation is 2.35, for ambient light 2.2 or 2.0. I believe ISF calibrators usually calibrate to a pure power curve. But madVR also allows you to realize a BT.709 curve. Choose the curve type you like better. It's probably simply a matter of taste. The BT.709 curve should give you better shadow detail. The pure power curve should give you more punch.
Thanks, thats exactly what I wanted to know.

Last edited by iSunrise; 7th June 2011 at 01:44.
iSunrise is offline   Reply With Quote
Old 7th June 2011, 03:07   #8026  |  Link
Hprd
Registered User
 
Join Date: Mar 2011
Posts: 60
v.63 working good here, for the most part. The colorspace conversion thing is nice first off, SD videos look better. Like others have said here as well, the scaling is improved as well, on both SD and 720p (or anything below 1080p i'd imagine) videos, a bit sharper indeed. Only issue is that on 48/60 (or now 59.94 hz, which i changed a while ago actually) after playing a video for a short while (most of the time), the present que runs out (and the render que gets very low as well), resulting in fairly constant glitches. On 23.976/29.970hz this doesn't happen (although maybe i just haven't played something long enough), and playback is the same as on previous versions of madvr. I messed with some of the settings and found the previous ones to be the best (overshoot max frame latency, nothing else on there. As turning this off, and any of the other tweaks on [or off, they don't really make any difference...] gets rid of the problem i described, but introduces random glitches reguardless of HZ).

Aside from that, this is about perfect, although i don't need any of the calibration things, as this monitor looks good enough without any to me

Last edited by Hprd; 7th June 2011 at 03:12.
Hprd is offline   Reply With Quote
Old 7th June 2011, 03:16   #8027  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,475
Quote:
Originally Posted by madshi View Post
Don't know. BT.601 and BT.709 also define gamuts, AFAIK. And SMPTE-C and EBU probably also define color matrixes.
oh, definitely not...I haven't made up all the technical infos I cut/pasted in my previous post, they've been double-checked by many colorimetry experts...including the CEO of the french ISF(who knows Joe Kane personally). There is indeed a REC.709 gamut, but to avoid confusion it's better to call it HDTV.

OTOH, there is no REC.601 gamut...NTSC SD is always using SMPTE-C.

Quote:
Originally Posted by madshi View Post
you can switch source gamuts via keyboard shortcut, which is what you always asked for.
oh, cool!

together w/ an OSD stating the current gamut mapping being processed and some automatic rules as explained above, this would rock really really hard.

Quote:
Originally Posted by madshi View Post
v0.63 should have made things quite a bit clearer. If things are still unclear for you I'm open for questions/feedback.
As you can see in this animated gif, sRGB/REC.709/HDTV are several names for the very same gamut...and "PAL" should really read "EBU". There's no "PAL" gamut per se.

A 2.22222 gamma value might be good too, being essentially 1/0.45 at heart.

Then we have the BT.601/709 issue...as currently both HD and upscaled SD use the BT.709 YCbPr decoding color matrix. The only solution to this problem would be automatic detection of uspcaled SD from ffdshow...a while back you seemed to imply that this would be entirely doable, and this would really rock

Quote:
Originally Posted by madshi View Post
Well, madVR doesn't cut BTB/WTW. So if you feed madVR with PC levels, madVR will treat dark gray and bright white as BTB/WTW. The information will survive and be sent to the display. But color and gamma processing will not be 100% accurate this way.
Yep, I used to have LUT's that wouldn't touch the levels...and yet provide gamut mapping from my display native gamut to HDTV/EBU/SMPTE-C. This was a bit annoying to always unpack manually the right LUT before watching a movie, but the colors were flawless when using test patterns.

PS: some more discussion around Joe Kane's Samsung projectors: http://archive2.avsforum.com/avs-vb/.../t-499097.html
Quote:
"SMPTE-C is not a High Definition Color Space."

In theory you are correct, but in practice... You see all of the displays used to color correct HD at this point have SMPTE-C phosphor.

The Samsung has SMPTE-C, REC.709 and EBU all pre-defined. You choose the color primaries you want from the menu.
We basically need the very same features in mVR...Joe Kane knows, the ISF knows. Providing the same kind of features in mVR would be too awesome to be put into words...even more so w/ automatic rules(which his projectors can't do)

PPS: the Epson EH–TW5000 has been certified by the ISF, and it also allows you to change the gamut size(HDTV/EBU/SMPTE-C) on the spot...but the option is hidden within several sub-menus.

Last edited by leeperry; 7th June 2011 at 04:16.
leeperry is offline   Reply With Quote
Old 7th June 2011, 04:04   #8028  |  Link
pankov
Registered User
 
Join Date: Mar 2002
Location: Sofia, Bulgaria
Posts: 658
Quote:
Originally Posted by madshi View Post
....
First of all you may want to re-create your preferred video output mode as a custom mode, because with current NVidia drivers that's the only way to force the driver to output proper 0-255 levels. ...
Well, mark0077 posted another solution here
http://forum.doom9.org/showpost.php?...postcount=5978
and I must say that I like it more and it definitely works as expected.
I'm kind of reluctant to mess around with NVidia's custom resolutions UI - it's often hit or miss with this non-userfriendly UI and I really miss PowerStrip's precision (can't get anything better than 23.9776xx)
__________________
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 7th June 2011, 05:33   #8029  |  Link
janos666
Registered User
 
Join Date: Jan 2010
Posts: 473
ISF, ISF... Even some enthusiast amateurs can see some problems with the practically applied ISF definition of color. (I don't say there are no smart people there, but at the end, on the end-user side, in practice...)

And some ISF certified devices are only jokes. For example, the ISFcc mode in Panasonic plasmas is nowhere on the corner when compared with the calibration capabilities of an EIZO CG or NEC PA but I never heard if any ISF/THX calibrator asked for a 3DLUT in the HDTVs (not even in high-end ones...). You can do so much more with madVR+yCMS than any other "hardware" solutions, ISF, THX certified displays, or anything but may be some professional monitors.

And I tell you more: None of the ISF/THX certified softwares (CalMan and others) measure any random mixed colors during the "verify" step! They fine-tune the available controls and simply measure the same adjusted colors back to proof that they didn't miss anything. But they doesn't proof how accurate the whole gamut of the display. May be the primary and secondary colors are "spot-on", and some points are on their correct place on the chosen gamma curve but they doesn't really care what actually happened with all the other (millions of) colors.
Are primaries look right on the CIE chart? Yes? Ok, it's a perfect display now. Oh God... Horrible things can happen with some shitty image processors if you touch the primary colors but they didn't measure anything else but the directly adjusted colors!

And this "I want to tweak it manually, even if it doesn't follow the standard (if there is a "standard" which really standardizes every important things...)" thinking makes the things worse than they are (standards which doesn't cover every important things...).
janos666 is offline   Reply With Quote
Old 7th June 2011, 05:42   #8030  |  Link
agustin9
Registered User
 
Join Date: Aug 2008
Posts: 85
DVDs are working without any hacks now or is it just me?
agustin9 is offline   Reply With Quote
Old 7th June 2011, 05:44   #8031  |  Link
andybkma
Registered User
 
Join Date: Sep 2006
Posts: 183
Hi, XP SP3, Nvidia 8600M-GT, madVR .63, Zoom Player 7 Max

When I switch display devices from my (1) external Acer LCD monitor to my (2) internal laptop screen to my (3) Benq DLP projector, madVR still shows my display device as the external Acer monitor. In other words, it doesn't "see" my internal laptop screen nor my Benq projector. I selected Add New Device but then the accompanying options are greyed out. Does this matter? So for testing sake, I did add the New Device when I had my internal laptop display selected and named it "Internal Display". But then when I switched back to my Acer external monitor, madVR still has "Internal Display" highlighted instead of switching back to the Acer external monitor. So something isn't working right.

Is there a trick to getting madVR to see all three of my display devices? Thank you...

Note: Also same problem with older madVR releases

Last edited by andybkma; 7th June 2011 at 05:53.
andybkma is offline   Reply With Quote
Old 7th June 2011, 10:07   #8032  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by leeperry View Post
There is indeed a REC.709 gamut, but to avoid confusion it's better to call it HDTV.

OTOH, there is no REC.601 gamut...NTSC SD is always using SMPTE-C.

As you can see in this animated gif, sRGB/REC.709/HDTV are several names for the very same gamut...and "PAL" should really read "EBU". There's no "PAL" gamut per se.
@yesgrey?

Quote:
Originally Posted by leeperry View Post
oh, cool!

together w/ an OSD stating the current gamut mapping being processed and some automatic rules as explained above, this would rock really really hard.

We basically need the very same features in mVR...
Except for the automatic rules this is already available in v0.63!

Press Ctrl+Alt+Shift+C once and you'll see the current gamut + decoding matrix. Press another time without delay and madVR will toggle between BT.709 -> BT.601 -> PAL. The switching will define both the gamut and the decoding matrix.

Now please don't tell me that some movies use a BT.709 decoding matrix together with NTSC primaries?? That would be awful! In that case I'd have to make 2 keyboard shortcuts: One for toggling primaries (BT.709, BT.601, PAL) and one for toggling decoding matrixes (BT.709, BT.601 = PAL).

Quote:
Originally Posted by leeperry View Post
A 2.22222 gamma value might be good too, being essentially 1/0.45 at heart.
Yeah, might make sense.

Quote:
Originally Posted by leeperry View Post
Then we have the BT.601/709 issue...as currently both HD and upscaled SD use the BT.709 YCbPr decoding color matrix. The only solution to this problem would be automatic detection of uspcaled SD from ffdshow...a while back you seemed to imply that this would be entirely doable, and this would really rock
I've told you several times that I plan to implement that. Just didn't have the time for it yet. BTW, if you switch source formats by using Ctrl+Alt+Shift+C, that will switch both primaries and the YCbCr -> RGB matrix. So with v0.62/63 you should be able to get perfect image quality, you just need to switch to the correct format via Ctrl+Alt+Shift+C.

Quote:
Originally Posted by janos666 View Post
ISF, ISF... Even some enthusiast amateurs can see some problems with the practically applied ISF definition of color. (I don't say there are no smart people there, but at the end, on the end-user side, in practice...)

And some ISF certified devices are only jokes. For example, the ISFcc mode in Panasonic plasmas is nowhere on the corner when compared with the calibration capabilities of an EIZO CG or NEC PA but I never heard if any ISF/THX calibrator asked for a 3DLUT in the HDTVs (not even in high-end ones...). You can do so much more with madVR+yCMS than any other "hardware" solutions, ISF, THX certified displays, or anything but may be some professional monitors.

And I tell you more: None of the ISF/THX certified softwares (CalMan and others) measure any random mixed colors during the "verify" step! They fine-tune the available controls and simply measure the same adjusted colors back to proof that they didn't miss anything. But they doesn't proof how accurate the whole gamut of the display. May be the primary and secondary colors are "spot-on", and some points are on their correct place on the chosen gamma curve but they doesn't really care what actually happened with all the other (millions of) colors.
Are primaries look right on the CIE chart? Yes? Ok, it's a perfect display now. Oh God... Horrible things can happen with some shitty image processors if you touch the primary colors but they didn't measure anything else but the directly adjusted colors!

And this "I want to tweak it manually, even if it doesn't follow the standard (if there is a "standard" which really standardizes every important things...)" thinking makes the things worse than they are (standards which doesn't cover every important things...).
Oh well. That doesn't sound good at all.

Quote:
Originally Posted by agustin9 View Post
DVDs are working without any hacks now or is it just me?
Can anybody confirm? Don't know why it should work now, though.

Quote:
Originally Posted by andybkma View Post
When I switch display devices from my (1) external Acer LCD monitor to my (2) internal laptop screen to my (3) Benq DLP projector, madVR still shows my display device as the external Acer monitor. In other words, it doesn't "see" my internal laptop screen nor my Benq projector. I selected Add New Device but then the accompanying options are greyed out. Does this matter? So for testing sake, I did add the New Device when I had my internal laptop display selected and named it "Internal Display". But then when I switched back to my Acer external monitor, madVR still has "Internal Display" highlighted instead of switching back to the Acer external monitor. So something isn't working right.

Is there a trick to getting madVR to see all three of my display devices? Thank you...

Note: Also same problem with older madVR releases
Hmmmm... You say you're "switching display devices". What does that mean exactly? How are you doing that?

Last edited by madshi; 7th June 2011 at 10:17.
madshi is offline   Reply With Quote
Old 7th June 2011, 10:58   #8033  |  Link
pacemaker1000
Registered User
 
Join Date: Mar 2011
Posts: 90
Quote:
Originally Posted by SamuriHL View Post
Why not just play the BDMV folder itself? Open the index.bdmv file with MPC-HC. But you will need to give us more information. What video decoder are you using? What splitter?
there is no reason other than i dont know how
i just have the latest mpc and madvr installed, thats it. sounds like i need more. please could you enlighten me?
i suppose there is no way to use the HW acceleration and it must be done in software?


Quote:
Originally Posted by janos666 View Post
Yes, it's the simplest way if the whole movie is contained by a single m2ts file. But some DBs split the movie into many m2ts files to offer you different versions (Theatrical Cut, Director's cut, Unrated, Extended, etc) on the same disk. In this case you need to open the correct playlist file (from the playlist folder).

I don't know if there is a more objective way for that but I usually open the one with the longest runtime.
i only rip the main movie so all my rips have just one m2ts file. ( are subtitles here too? i havnt looked)
again how do you play them with mpc and madvr please?

thanks, sory if this is a dumb question
pacemaker1000 is offline   Reply With Quote
Old 7th June 2011, 11:45   #8034  |  Link
Mark_A_W
3 eyed CRT supporter
 
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
A small feature request madshi.

If it makes sense, can you separate out the 3 colours in the Gamma Processing section? A control per colour?

Currently, using Powerstrip (or Video Equalizer) I run three different gamma curves for R, G and B. I run a CRT projector still, and it's quirky.



And yesgrey, someone is going to have to write a dummies guide to yCMS....I'm lost....
Mark_A_W is offline   Reply With Quote
Old 7th June 2011, 11:50   #8035  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,475
Quote:
Originally Posted by madshi View Post
Press Ctrl+Alt+Shift+C once and you'll see the current gamut + decoding matrix. [..]
Now please don't tell me that some movies use a BT.709 decoding matrix together with NTSC primaries?? That would be awful! In that case I'd have to make 2 keyboard shortcuts
breaking news, they do

I'm not too interested in manual YCbPr decoding matrixes, these really need to be made automatic...for once, we don't have to bother w/ those. The end-user should only bother w/ the gamut, the decoding matrix is a done deal.

SD(native or upscaled)=BT.601
HD(x>1024)=BT.709

But the end user needs to be able to switch from SMPTE-C/EBU/HDTV on the fly indeed...the end-user sole job is to find out where his source was mastered and what video format it was encoded as:
-US/JAP BD or NTSC SD: SMPTE-C
-EUR BD or PAL DVD: EBU
-consumer HD: HDTV

of course, there are exceptions...and you also have the case of ppl ripping HD to SD and having no clue that they had to convert BT.709 to BT.601...so surely, a manual override could come in handy but in 99.999% of all cases the BT.601/BT.709 choice can be made automatic(hence the mandatory requirement to detect upscaled SD from ffdshow)...otherwise, at the end of the day we'll still have to use the ColorMatrix() kludge in the ffdshow "SD" automatic profiles.

Quote:
Originally Posted by madshi View Post
madVR will toggle between BT.709 -> BT.601 -> PAL. The switching will define both the gamut and the decoding matrix [..]
In that case I'd have to make 2 keyboard shortcuts: One for toggling primaries (BT.709, BT.601, PAL) and one for toggling decoding matrixes (BT.709, BT.601 = PAL).
This all sounds very confusing to me because there is no "PAL" YCbPr encoding/decoding matrix..only BT.601 for SD and BT.709 for HD. That's it.

Quote:
Originally Posted by madshi View Post
Except for the automatic rules this is already available in v0.63!
O RLY? like this:
-23.976: SMPTE-C(that you could always change to EBU using a hotkey if it was mastered in Europe)
-25: EBU(it could also be HDTV, so you could always swap it if need be)
-29.97: SMPTE-C(it's most likely SD VIDEO NTSC, but it could also be HDTV if it's HD)

Quote:
Originally Posted by janos666 View Post
None of the ISF/THX certified softwares (CalMan and others) measure any random mixed colors during the "verify" step
[..]
Do primaries look right on the CIE chart? Yes? Ok, it's a perfect display now. Oh God... Horrible things can happen with some shitty image processors
That's mostly because you should not expect this from a professional calibrator....his job is to get the gamma curves/gamut/primaries/secondaries spot-on, using a high-end -freshly calibrated- Minolta spectrophotometer. If the manufacturer screwed up somewhere else, that's his own business. This technician is not here to create a CLUT or call the manufacturer and whine for a firmware fix, he's here to calibrate whatever can be calibrated.

These are the primaries/secondaries saturations on my ex-Mitsubishi HC3100:

Who's to blame? Me? My spanking new Eye One colorimeter(their gelatin filters age poorly, so I always make sure to use a fairly new one)? Mitsubishi is to blame! coz they didn't allow those saturations to be adjusted every 10 IRE. Surely, I could fix them w/ a CLUT using ARGYLL...but that'll be processed in 8bit, the pj inner settings work in 12bit

My point is that the ISF does weekly calibration for a lot of mastering houses(CRT, baby!) and high end theaters as well. Their job is to get the gamma curves/gamut/primaries/secondaries spot-on...if the display has issues, tough luck

And that's the very reason why Joe Kane was asked to work as a consultant on those Sammys, that's because Sammy wanted to own the market w/ a display that would finally abide by the very cinema industry hard rules. You can find those Sammys(weekly calibrated by the ISF) in Hollywood and pretty much any pro video area. They do own the market because they're 100% kosher and don't skimp in any area.

Quote:
Originally Posted by janos666 View Post
You can do so much more with madVR+yCMS than any other "hardware" solutions, ISF, THX certified displays, or anything but may be some professional monitors.
Surely, and that's why we're all here. All that is required is some improvements to reach the level of excellence of those Sammys. Calling a cat a cat, and making things as automatic as they can be made...something those Sammy's will never be able to do. Their only improvement over mVR is that their CMS works in 12bit...we're still stuck w/ a very lossy 8bit pipeline, but dithering comes to the rescue so it ain't as bad as it sounds

Last edited by leeperry; 7th June 2011 at 12:00.
leeperry is offline   Reply With Quote
Old 7th June 2011, 11:51   #8036  |  Link
jmone
Registered User
 
Join Date: Dec 2007
Posts: 613
If I want to do my own Calibration (Pio LX608) instead of using an ISF tech what reasonably priced HW/SW do you need?
jmone is offline   Reply With Quote
Old 7th June 2011, 12:07   #8037  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by Mark_A_W View Post
If it makes sense, can you separate out the 3 colours in the Gamma Processing section? A control per colour?
What would that be good for? If you have measured your display properly then yCMS should automatically compensate for any gamma differences between R, G and B.

Quote:
Originally Posted by Mark_A_W View Post
And yesgrey, someone is going to have to write a dummies guide to yCMS....I'm lost....
With madVR v0.62/63 you don't need to know how to use yCMS. All you need to do it measure your display and enter your measurements in the "yCMS" tab in the madVR settings dialog.

Quote:
Originally Posted by leeperry View Post
I'm not too interested in manual YCbPr decoding matrixes, these really need to be made automatic...for once, we don't have to bother w/ those. The end-user should only bother w/ the gamut, the decoding matrix is a done deal.

SD(native or upscaled)=BT.601
HD(x>1024)=BT.709
Ok, I thought those would be wrong, too, on the Blu-Rays with "wrong" primaries.

Quote:
Originally Posted by leeperry View Post
But the end user needs to be able to switch from SMPTE-C/EBU/HDTV on the fly indeed...the end-user sole job is to find out where his source was mastered and what video format it was encoded as:
-US/JAP BD or NTSC SD: SMPTE-C
-EUR BD or EUR DVD: EBU
-consumer HD: HDTV
Ok. So I'll replace the current Ctrl+Alt+Shift+C with Ctrl+Alt+Shift+P (for primaries) and with Ctrl+Alt+Shift+M (for matrix) to allow separate toggling of decoding matrix and primaries.

Quote:
Originally Posted by leeperry View Post
This all sounds very confusing to me because there is no "PAL" YCbPr encoding/decoding matrix..only BT.601 for SD and BT.709 for HD. That's it.
"There is no PAL matrix" sounds to me as if PAL would never be converted from YCbCr to RGB. Of course you need to decode PAL, too. So there is a PAL matrix. It just happens to be the same as BT.601. That's why I wrote "BT.601 = PAL", because both use the same en/decoding matrix.

Quote:
Originally Posted by leeperry View Post
O RLY? like this:
-23.976: SMPTE-C(that you could always change to EBU using a hotkey if it was mastered in Europe)
-25: EBU(it could also be HDTV, so you could always swap it if need be)
-29.97: SMPTE-C(it's most likely SD VIDEO NTSC, but it could also be HDTV if it's HD)
I said, "except for the automatic rules". Which means, automatic rules are NOT implemented.

Quote:
Originally Posted by leeperry View Post
Their only improvement over mVR is that their CMS works in 12bit...we're still stuck w/ a very lossy 8bit pipeline
Nope. Our CMS works in 32bit/64bit floating point. Our *output* is dithered 8bit, though, that's true. But that's only the very last step of the pipeline. The rest is higher bitdepth.
madshi is offline   Reply With Quote
Old 7th June 2011, 12:25   #8038  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,859
Some custom rules for primaries would be neat.
Say all 720p content i watch is from HD broadcasts (re-encoded from 1080i MPEG-2 after deinterlacing/IVTC), and all 1080p content i watch is from BDs - any chance we would get some automatic switching of the primaries for those?
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 7th June 2011, 12:26   #8039  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,307
Quote:
Originally Posted by nevcairiel View Post
There is only one decoder which can do this high-quality and configurable RGB conversion, and thats ffdshow.
I know I'm limited, and that sucks, believe me. Just like it sucks to be tied to madVR if you want a good renderer.

Quote:
Originally Posted by madshi View Post
Actually I plan to make madVR aware of all this stuff in a future version, by peeking into the h264 bitstream myself. However, the levels issue is a big problem, because the h264 "full range" flag is incorretly activated in many many European broadcasts.

I don't agree that RGB is not touched by the renderer. The renderer at least has to scale it. That is already touching the data. Also, if you want to calibrate your display by using the renderer, additional touch is necessary. Furthermore, if you change the renderer's brightness & contrast controls (which madVR doesn't have yet) I would expect this to affect RGB, too. Finally, if the renderer does things like motion interpolation or black/dark frame insertion, again the RGB data needs to be touched.

I simply do not agree with your "a renderer should not touch RGB input" concept. I think it's fundamentally flawed. Ok, so there are problems right now, let's solve them. But properly, not by sticking to flawed concepts.

These are all things I have on my to do list to solve. It's not difficult for me to find out which resolution the original video had before being resized by some other filter. I've just not found the time to implement that yet.

I don't care about common trends. I care about proper solutions. If I cared about common trends there would be no madVR right now and everybody would use EVR.

Sure. If I switch CoreAVC to RGB output, image quality is just fine - except for the lousy chroma upsampling performed by CoreAVC, of course. Or if I decode a video with ffdshow and switch ffdshow to RGB, image quality is fine, too, if I configure ffdshow correctly.

You don't. Instead you let that random guy in a random forum collect all needed information without the help of the decoder.

Try v0.63. By default gamma processing is disabled. Then switch ffdshow to video levels and you should be fine.
How will you know what levels the Fraps decoder uses, since these kind of filters will never output such information?

When we're talking about untouched RGB is about changing actual values for whatever reason, not scaling. I think this is obvious...

Sure, if you count setting CoreAVC's and ffdshow's options to TV range when I have a PC monitor, I guess you could count them as working with madVR

I find it really hard to believe what you propose. I see 4 possible situations:

1. You're asking me to fool the decoder about my output levels, so madVR, which assumes video levels for everything, produces proper output. This is not a scientific anything, just a bad workaround for a madVR limitation.
2. I can configure my decoder properly, then I fool madVR about my display levels, so it doesn't do a double expansion. This is another workaround for the same madVR limitation.
3. The decoder can't be configured in any way, like Fraps, so I can't workaround anything. Native RGB content. I'm screwed, because only the madVR route is available here, and I'd have to manually change it every time I want to see a Fraps video.
4. Let's say you make an interface, header or whatever, so decoders can tell madVR the properties of the source. This won't be used by most decoders, so we're back at square one for these decoders. And it doesn't matter how much data you collect from the graph, some filters just don't expose the relevant info. Bitstream parsing? Good luck with all the different bitstreams out there, and as you say the badly flagged ones.

I'll tell you again that there's no proper solution for this, and probably never will, all 4 are bad for something. However a processing bypass option for RGB, like all the other renderers do, will fix 1. because I won't have to fool any decoder, 2. because I won't have to fool madVR since it won't touch the properly converted by a properly configured (or locked for a reason) decoder RGB output, 3. and 4. for the same reason as 2.

This is not about following some stupid trend, this is about making things work. Please reconsider this option.

In the meantime, I guess I will be in option 2., as with v0.63 everything will be displayed correctly as long as I fool madVR about my monitor levels.
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.
STaRGaZeR is offline   Reply With Quote
Old 7th June 2011, 12:26   #8040  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,475
Quote:
Originally Posted by madshi View Post
Ok, I thought those would be wrong, too, on the Blu-Rays with "wrong" primaries.
HD is always using the BT.709 YCbPr decoding matrix, no exception.

Quote:
Originally Posted by madshi View Post
I'll replace the current Ctrl+Alt+Shift+C with Ctrl+Alt+Shift+P (for primaries) and with Ctrl+Alt+Shift+M (for matrix) to allow separate toggling of decoding matrix and primaries.
OK, sounds good! until you provide automatic detection from ffdshow, I'll keep using ColorMatrix for upscaled SD then. So I would manually leave the decoding matrix on BT.709.

Quote:
Originally Posted by madshi View Post
"There is no PAL matrix" sounds to me as if PAL would never be converted from YCbCr to RGB. Of course you need to decode PAL, too. So there is a PAL matrix. It just happens to be the same as BT.601. That's why I wrote "BT.601 = PAL", because both use the same en/decoding matrix.
Yep, SD=BT.601...there's really no need to talk about NTSC/PAL or SECAM, that'll only make things more confusing in the end IMHO.

Quote:
Originally Posted by madshi View Post
I said, "except for the automatic rules". Which means, automatic rules are NOT implemented.
Oops, I read your sentence too fast...my bad

Quote:
Originally Posted by madshi View Post
Nope. Our CMS works in 32bit/64bit floating point. Our *output* is dithered 8bit, though, that's true. But that's only the very last step of the pipeline. The rest is higher bitdepth.
You're entirely right, and I guess dithered 8bit couldn't easily be DBT'ed from 10/12bit. OTOH, My Avisynth scripts do kill the bitdepth...but the first script I use is SmoothLevels() and it does drastic dithering...so it might also not be as bad as it sounds

One thing I'm sure of is that -subjectively speaking- the PQ is far less bandy when I use SmoothLevels() before LSF and GrainF3. Protools also use dithering from 48 to 24int before processing....I always read that processing dithered data would be a terrible idea, but I guess the ppl who wrote ProTools know their business...and that also matches my real world experience.

Anyway, as always I'm utterly stunned by the PQ of my rig...the icing on the cake would be automatic gamut mapping, as I've grown really bored of manually decompressing the right LUT for the right gamut before watching each and every movie. Besides my CRT is pretty much SMPTE-C spot-on, so this is major nitpicking(my fav. activity ^^)

for making it all become reality, I'm sure some ppl on AVS will fall off their chair when they'll see what's cooking
leeperry is offline   Reply With Quote
Reply

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

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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

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

Forum Jump


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


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