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. |
6th June 2011, 23:56 | #8021 | Link | |
Registered User
Join Date: Jan 2010
Posts: 479
|
Quote:
|
|
7th June 2011, 00:03 | #8022 | Link |
Registered User
Join Date: Dec 2008
Posts: 496
|
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? I´m 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. I´m 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 I´m 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 00:11. |
7th June 2011, 00:24 | #8023 | Link | |||||||||||||||||||||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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:
Quote:
Quote:
Quote:
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:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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:
Quote:
Quote:
v0.63 should have made things quite a bit clearer. If things are still unclear for you I'm open for questions/feedback. Quote:
Quote:
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 00:45. |
|||||||||||||||||||||||||||
7th June 2011, 00:35 | #8024 | Link | ||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
|
||||
7th June 2011, 00:37 | #8025 | Link | ||
Registered User
Join Date: Dec 2008
Posts: 496
|
Quote:
Quote:
Last edited by iSunrise; 7th June 2011 at 00:44. |
||
7th June 2011, 02:07 | #8026 | Link |
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 02:12. |
7th June 2011, 02:16 | #8027 | Link | |||||
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
OTOH, there is no REC.601 gamut...NTSC SD is always using SMPTE-C. Quote:
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:
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:
PS: some more discussion around Joe Kane's Samsung projectors: http://archive2.avsforum.com/avs-vb/.../t-499097.html Quote:
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 03:16. |
|||||
7th June 2011, 03:04 | #8028 | Link | |
Registered User
Join Date: Mar 2002
Location: Sofia, Bulgaria
Posts: 661
|
Quote:
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 |
|
7th June 2011, 04:33 | #8029 | Link |
Registered User
Join Date: Jan 2010
Posts: 479
|
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...). |
7th June 2011, 04:44 | #8031 | Link |
Registered User
Join Date: Sep 2006
Posts: 212
|
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 04:53. |
7th June 2011, 09:07 | #8032 | Link | ||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
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:
Quote:
Quote:
Can anybody confirm? Don't know why it should work now, though. Quote:
Last edited by madshi; 7th June 2011 at 09:17. |
||||||
7th June 2011, 09:58 | #8033 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 90
|
Quote:
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:
again how do you play them with mpc and madvr please? thanks, sory if this is a dumb question |
||
7th June 2011, 10:45 | #8034 | Link |
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.... |
7th June 2011, 10:50 | #8035 | Link | ||||
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
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:
Quote:
-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:
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. 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 11:00. |
||||
7th June 2011, 11:07 | #8037 | Link | ||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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. |
||||||
7th June 2011, 11:25 | #8038 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
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 |
7th June 2011, 11:26 | #8039 | Link | ||
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
Quote:
Quote:
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. |
||
7th June 2011, 11:26 | #8040 | Link | |||||
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
Quote:
Quote:
Quote:
Quote:
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 |
|||||
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
|
|