madVR - high quality video renderer (GPU assisted)

[janos666]

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?

I think it covers 99% of the possible needs if you list these formats when you want your display to do the deinterlacing: 1080p23, 1080i50, 1080i59 and these when you wish to do i with other software filters: 1080p23, 1080p50, 1080p59 or 1080p50, 1080p59, 1080p60, 1080p72 (depending on your display).

I use the interlaced settings with my PDP and I set up my friend's LCD with the progressive (72Hz) settings right now. It works well with BD cinema movies, US and EU TV Shows. What else would you play?
Am I missing any usual materials? Because I think you shouldn't over-complicate the automatized mechanisms thinking about the "once in a year" situations.

[nevcairiel]

Also, how do you teach every decoder out there to communicate properly with a renderer made by a random guy in a random forum? That would be awesome, and people here would do it, but I'll be yet another hack in a world full of hacks.

Most decoders do only a very cheap RGB conversion for compat with renderers that don't accept YUV format anyway, and do not let you configure any of the properties required for proper conversion, so i don't accept that point.

If that format would be supported by ffdshow, the MPC-HC decoders and mine, there would already be pretty good coverage. :p

PS:
This is not a hack, its actually a proper solution.

[Darth Viorel]

Just out of interest: isn't sRGB the same as BT.709?

[Andy o]

I think it covers 99% of the possible needs if you list these formats when you want your display to do the deinterlacing: 1080p23, 1080i50, 1080i59

OK, just to be clear, this is completely apart from the problems above of wrong refresh rate change. This is assuming madVR works as intended, after madshi fixes the bugs.

I already use those options you listed (instead of 1080i50 I got 1080p50), but the problem is that there is no option to change to 1080p59 for 59p video. If I add 1080p59 to the list, then it works, but then my 59i videos also change refresh to that rate. It's not a simple matter of where to do the deinterlacing, it's that Pioneer displays do IVTC only up to 1080i, not 1080p.

So, if there's 24p content encoded in 59i, the 59i will change the rate to 59p and I'd lose IVTC from my display. If my refresh rate stays at 59i for that content, then IVTC is fine.

What I'm asking really should not affect people who don't use 59i, because they would not have 1080i59 in the madVR options. If you have it there, it's cause you wanna use it.

[leeperry]

Blu-Ray and PAL all have different primary color coordinates. The differences are *NOT* dealt with by just using the correct YCbCr -> RGB matrix. E.g. if you take the color "red: 200; blue: 20; green: 20", this color is supposed to result in a different wavelength being produced by your display for NTSC content than for PAL or Blu-Ray.

Practically that means, if you display an NTSC SD DVD you have to calibrate your display to BT.601 primaries. If you display a Blu-Ray, you have to calibrate your display to BT.709 primaries. If you display a PAL DVD, you have to calibrate your display to PAL primaries. If you don't do that, you'll get incorrect colors. All of this applies even if you convert YCbCr -> RGB with the correct matrices!
well, it's a bit more complicated I'm afraid...as Bluray's mastered in Europe do use the EBU gamut, and >90% of the BD's mastered in the US still use SMPTE-C(coz they're mastered on CRT's).

YCbPr encoding/decoding color matrixes:
Rec. ITU-R BT.601-5 => SD
Rec. ITU-R BT.709-4 => HD

Gamuts :
- Rec 709: HD primaries (in theory at least)
- SMPTE RP 145: SMPTE-C primaries (US/Japan SD/ HD) => used for NTSC and 90% of the Blu-Rays(confirmed by the CEO of the ISF)
- EBU Tech. 3213: EBU primaries (Europe SD/HD) => used for PAL/SECAM and european Blu-rays

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

To avoid confusion, it's widely acknowledged to use those terms:
- SMPTE-C / EBU / HDTV for gamuts.
- REC-601 / REC-709 for color matrixes.

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

So far 0.62 has been dead smooth for me, but the main problem I got w/ >0.49 was getting really random dropped frames from time to time in 89.91/96Hz(0.49 is an unstoppable train when that option -that was removed in >0.49- is checked)...so I could only confirm whether the problem is actually fixed after watching a lot of movies. I still wish that option was back, but well..

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. Anyway, my current main focus is on smoothness....I'll wait for the colorimetry options to become a bit clearer :p

fixed: removed nonsense 9bit/10bit display bitdepth options
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.

[STaRGaZeR]

Most decoders do only a very cheap RGB conversion for compat with renderers that don't accept YUV format anyway, and do not let you configure any of the properties required for proper conversion, so i don't accept that point.

If that format would be supported by ffdshow, the MPC-HC decoders and mine, there would already be pretty good coverage. :p

PS:
This is not a hack, its actually a proper solution.

I was refering to the fact that decoders telling the renderers all info about the source so they can do proper, non-guessed YCbCr->RGB conversions would be fantastic, but there's no way of doing that right now without custom hacky stuff, and it'd only be supported by open source decoders and a closed source renderer. No future there I'm afraid.

Yes, it's a proper solution, but since it's unsupported by the DS ecosystem I consider it a hack. Keep in mind that joe average uses WMP and the like, and W7 already comes with decoders for all the important formats, no need for MPC-HC/ffdshow/LAV in there unfortunately. Getting this widely used would be extremely difficult.

[nevcairiel]

Yes, it's a proper solution, but since it's unsupported by the DS ecosystem I consider it a hack. Keep in mind that joe average uses WMP and the like, and W7 already comes with decoders for all the important formats, no need for MPC-HC/ffdshow/LAV in there unfortunately. Getting this widely used would be extremely difficult.

But WMP also cannot use madVR, so i still fail to see the point. Its not meant to replace any existing options.
People using WMP really don't even notice that the colors are off, tbh.

There is only one decoder which can do this high-quality and configurable RGB conversion, and thats ffdshow. So you're already very limited. Other decoders either output a YUV format, or if you force RGB out of them, they do who knows what for the conversion.

The whole idea is to simply enable a perfect high-quality playback chain for madVR (and other custom renderes), so if you use madVR, you don't have to rely on a decoder to produce proper RGB, you just use one of the supported decoders, and they provide all relevant information for madVR to do what it was designed for.
It'll come sooner or later anyway, at the latest for 3D playback, because the current info headers are not suited for that.

The main point is, there is nothing to lose, only to gain. If you prefer ffdshow doing the RGB conversion, sure, why not. But if you use ffdshow anyway, could as well let it supply the information to madVR to do it itself.
In addition, an option in madVR for "don't touch RGB" for those people that want it shouldn't be that bad to add.

[e-t172]

well, it's a bit more complicated I'm afraid...as Bluray's mastered in Europe do use the EBU gamut, and >90% of the BD's mastered in the US still use SMPTE-C(coz they're mastered on CRT's).

Gamuts :
- Rec 709: HD primaries (in theory at least)
- SMPTE RP 145: SMPTE-C primaries (US/Japan SD/ HD) => used for NTSC and 90% of the Blu-Rays(confirmed by the CEO of the ISF)
- EBU Tech. 3213: EBU primaries (Europe SD/HD) => used for PAL/SECAM and european Blu-rays

Wait… you're basically telling us that there is no way to know for sure which gamut to use based on information in the source? Meaning we can never be sure that we're using the right gamut and getting the right color? That's quite shocking…

[nevcairiel]

Wait… you're basically telling us that there is no way to know for sure which gamut to use based on information in the source? Meaning we can never be sure that we're using the right gamut and getting the right color? That's quite shocking…

If the encode is good, it should be in the stream headers.
I'm not sure i actually have a european Blu-ray to check this, sure i have european releases, but most are US movies .. i dont think they remaster the video, do they? :d

The Blu-ray spec at least says that you're supposed to use BT.709 primaries.
I think it would be quite moronic if they encode movies to look good on their professional super expensive displays, wouldn't they be smart enough to make it look good on a consumer HDTV? Thats what they are mastering it for, afterall.

BTW, i rather have some infos from a Tech then a CEO.

[n3w813]

Wow, deep discussions....

You guys mind taking a quick break to answer my question about levels? :)

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.

:thanks:

[Plutotype]

Wow, deep discussions....

You guys mind taking a quick break to answer my question about levels? :)

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.

:thanks:

Hi,
I have the KDL-40EX500 series from Sony and I find the TV Levels set in madVR better FOR THIS PARTICULAR PANEL. 0-255 gives me too much B/W contrasty picture - black is too black and white is too white. Just watch some movies with both modes and then you will surely see / decide.
Pluto

[pacemaker1000]

can someone help a noob

i have a few ripped blurays in bdmv folders that a currently play with TMT which uses hardware acceleration

can i play just the m2ts with MadVR and MPC-HC?
i have a dual core 2.7 but the cpu goes to max and it wont play

thanks

[SamuriHL]

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?

[n3w813]

Hi,
I have the KDL-40EX500 series from Sony and I find the TV Levels set in madVR better FOR THIS PARTICULAR PANEL. 0-255 gives me too much B/W contrasty picture - black is too black and white is too white. Just watch some movies with both modes and then you will surely see / decide.
Pluto

I don't think the selection is a personal 'choice'....there is a correct setting if you don't want compressed or expanded levels. After the correct setting is selected you will then need to calibrate your television to the settings. :)

[janos666]

can i play just the m2ts with MadVR and MPC-HC?

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

----

@n3w813

And what is the correct choice if your display device has limited and full range settings too but the physical precision of the display is unknown or known as significantly lower than 8-bit without internal dithering (like every PDP and many LCDs).
I guess it's the full range but simply because it contains more data. Otherwise, it could be the limited if your display handles the full range input but it compresses it back to limited range during the internal processing (which is hard to tell if it happens with high precision because you probably need to count the gray shades manually on a gradient :p). I think 10-bit output would make this dilemma much less significant.

An example: 8-bit gradient test videos look smooth without dithering and limited range output, full range output looks horrible without dithering but it's smooth with dithering. However, you can't always trust in dithering.
A special case when your display applies "undefeatable" noise reduction algorithms which can partially filter out the dithering noise too (some and not only a few HDTVs). And another example (which could be combined with the previous one) when the display already works with heavy dithering (every PDPs, but some of them is really noisy and use an awfully simple noise patter. -> even the expensive models, like some Panasonic PDPs -> that's why I prefer the Samsung PDPs with much finer dithering noise which really works for my eyes, not like the Panasonic joke but some people would probably argue with me about this, and this is not that topic...).


----


@madshi

Did you think about the possibility to somehow output YCC 4:2:2 for HDTVs? JanWillem says he has some ideas to make it possible, so I think it's theoretically possible...
(Did you even read my arguments why would it be "essential" for many HDTV owners (probably many HTPC users) even if they doesn't really know/care(yet) about it?)

[leeperry]

you're basically telling us that there is no way to know for sure which gamut to use based on information in the source? Meaning we can never be sure that we're using the right gamut and getting the right color?
There clearly isn't any way to automatically "guess" the gamut that was used during mastering...the same way there is no way to "guess" whether 25fps is genuine PAL or sped up cinema NTSC.

You can detect the decoding matrix(601/709) if it was added to video stream headers, but no can do about the gamut being used during mastering.

Ideally(and I made this feature request to madshi a while back), we'd need some automatic rules like:
-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)

You'll find some food for thoughts in this thread: http://www.avsforum.com/avs-vb/showthread.php?t=1038602
Tom Stites has stated that almost all material is mastered on SMPTE-C monitors and that Rec 709 monitors are rarely used.

It's a fact that the hero of CARS will be never as deep red in the movie as he is on the movie poster...the video industry went cheap and decided to use the royalties-free SMPTE-C gamut, and orangey red is part of the kludge :devil:

The CEO of the french ISF used to keep a BD list on his website as to whether you should use EBU or SMPTE-C..but it basically boiled down to: mastered in the US: SMPTE-C / mastered in Europe: EBU. The ISF takes care of the (free) calibration worldwide on those high-end Samsung DLP projectors(that were blessed by Joe Kane). You even get direct access buttons on their remote to map gamuts on the fly, goodness gracious!

Some mastering houses are said to use a 3DLUT at the very very last stage to map SMPTE-C to HDTV....but IRL, most bluray's don't go through this stage apparently.

All I can say is that IME european BD's look washed out in SMPTE-C(the smallest gamut ever) and US/JAP BD's look oversaturated in EBU/HDTV...I'd even dare saying that using the right gamut seems to increase the subjective CR, because the colors are simply as accurate as the mastering engineer saw them...they don't "overlap" each other anymore, so to speak ;)

Another testimonial of gamut mapping goodness: http://www.avsforum.com/avs-vb/showpost.php?p=11937064&postcount=90
no more sunburnt faces

The first time I watched a US HD movie in SMPTE-C on my DLP projector will always remain deeply imprinted in my brain...wow, proper colors! yay, about ******* time \o/

It's like Reclock, once you've seen the light...you're doomed :D

This said, I'm very pleased to see that mVR is finally diving into the colorimetry nitty gritty http://forum.slysoft.com/images/smilies/agreed.gif

[Plutotype]

I don't think the selection is a personal 'choice'....there is a correct setting if you don't want compressed or expanded levels. After the correct setting is selected you will then need to calibrate your television to the settings. :)

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

[gendouhydeist]

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?

[janos666]

I think we need "Display Calibration with madVR + yCMS FAQ" in one of the fist posts. :readfaq:

[Snowknight26]

For the sake of every non-German, you might wish to change Strg to Ctrl. ;D

[janos666]

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

[iSunrise]

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

[madshi]

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>

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.

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!).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

[madshi]

For the sake of every non-German, you might wish to change Strg to Ctrl. ;D
Ooooops. Done.

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?

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:

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

[iSunrise]

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. That´s exactly how I know it, because the picture is noticably darker, when 2.35 is still active.

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, that´s exactly what I wanted to know.

[Hprd]

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

[leeperry]

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.

you can switch source gamuts via keyboard shortcut, which is what you always asked for.
oh, cool! :eek:

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

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 (http://www.homecinema-fr.com/forum/download/file.php?id=54246), 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 :devil:

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/archive/index.php/t-499097.html
"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.

[pankov]

....
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?p=1484587&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)
:(

[janos666]

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

[agustin9]

DVDs are working without any hacks now or is it just me?

[andybkma]

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

[madshi]

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 (http://www.homecinema-fr.com/forum/download/file.php?id=54246), 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?

oh, cool! :eek:

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

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

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

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.

DVDs are working without any hacks now or is it just me?
Can anybody confirm? Don't know why it should work now, though.

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?

[pacemaker1000]

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?


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

[Mark_A_W]

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

[leeperry]

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

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.

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.

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)

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: http://thumbnails39.imagebam.com/13558/ef805a135579689.jpg (http://www.imagebam.com/image/ef805a135579689)

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! (http://cgi.ebay.com/Sony-BVM-A20F1U-20-Broadcast-CRT-Monitor-w-HD-SDI-Opt-/370458256325)) 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 http://forum-images.hardware.fr/images/perso/_jbm.gif

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.

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

[jmone]

If I want to do my own Calibration (Pio LX608) instead of using an ISF tech what reasonably priced HW/SW do you need?

[madshi]

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.

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.

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.

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.

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.

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.

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.

[nevcairiel]

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? :D

[STaRGaZeR]

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.

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

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.

[leeperry]

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.

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.

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

I said, "except for the automatic rules". Which means, automatic rules are NOT implemented.
Oops, I read your sentence too fast...my bad :o

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

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

:thanks: 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 :D

[e-t172]

These are the primaries/secondaries saturations on my ex-Mitsubishi HC3100: http://thumbnails39.imagebam.com/13558/ef805a135579689.jpg (http://www.imagebam.com/image/ef805a135579689)

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

The best solution would probably be to use ARGYLL to generate a very precise 3dlut instead of an ICC profile (or convert the ICC profile to a 3dlut). This way you could have a 3dlut which not only covers primaries, secondaries and grayscale, but every other color as well, with independant gamma ramps for every RGB channel (something yCMS isn't able to do - yet). Then you load this 3dlut into madVR, and you get near-perfect colorimetry. The only problem is it will be downsampled to 8-bit, but considering madVR's dithering it shouldn't make a noticeable difference.

Unfortunately, I am not aware of any software which convers high-precision measurements from an ARGYLL results file or an ICC profile to a 3dlut... there is a need to fill here!

In fact you can already approach this by loading the ICC profile into Windows. There are two problems though: (1) it is very probable the card's VideoLUT won't do any dithering, and (2) my experiments seem to show that although individual RGB channels are corrected, the primaries (gamut) are not. Anyone know why loading an ICC profile into Windows fix gamma but not the gamut? Maybe that's because I'm using Eye-One Match instead of ARGYLL, and the ICC profile generated by Eye-One is at fault? I'll try with ARGYLL as soon as I get the time.

[leeperry]

The best solution would probably be to use ARGYLL to generate a very precise 3dlut

Surely, but that's not the job of the ISF..which was my original point. They don't do 8bit color correction, and they don't make LUT's. They use the display onboard settings only as they're readily available, work on all inputs and work in 10/12bit.

I asked tritical if I could compensate for those saturations in a 3DLUT and he said no...so that settles it :p

Anyone know why loading an ICC profile into Windows fix gamma but not the gamut? Maybe that's because I'm using Eye-One Match instead of ARGYLL, and the ICC profile generated by Eye-One is at fault? I'll try with ARGYLL as soon as I get the time
That's because the graphic card's CLUT is 1D only, you need a 3DLUT to map gamuts. It was confirmed to me by Graeme Gill BTW ;)

[andybkma]

Hmmmm... You say you're "switching display devices". What does that mean exactly? How are you doing that?

My laptop has an 8600M-GT video card and has the following ports on it: HDMI, S-Video and VGA. I have my external monitor hooked up to the VGA port and my projector to the HDMI port. I press Function + F6 and the video gets alternatively output through each port if a device is plugged into it (internal laptop video screen --> the external monitor (video output only through VGA port) --> the projector (video output only through HDMI port) --> back to internal laptop screen). Basically I'm just selecting the video display (device) on which to view the operating system desktop and thus selecting which video display device on which to view the videos I am playing.

[cvrkuth]

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.

How can I do that? I have Panasonic TX-p42g20e

[janos666]

@leeperry

I can partially accept your reasoning but I would never ask or even accept money for a calibration if the overal result of my changes is worse than the default state. And the objective way to figure it out that you check some (>40) random colors and of course judge the result sumjectively.
If the overal result is worse then I would ask for apologise, restore the factory settings, leave the fild, refuse any other contracts for the particular display model and recommend it to my collegues to do the same.
I know, this is why I am not a real pro. :)


If you mentioned Samsung... Did you saw their latest PDPs? I wouldn't give my 51D550 in exchange for the much more expensive 50GT30. And I simply unable to understand why many people prefer the Panasonic PDPs (I talk about 2D of course, 3D is a joke anyway...).
Well, may be they never try to set up the settings properly because I admit that the THX mode on Pana is almost "spot-on" (given the possibilities) and Sam requires a complicated ad long calibration. (I fully reconfigured my ADC/WP setting in the SM and played a lot with the user OSD too but it worth it...)
I don't even use 3DLUTs anymore because they make very slight difference and the slightly off state looks subjectively better or me. (And ah yes, I would never play games or watch movies on LCD anymore, p/H-IPS or not...)


And I the thechnoly is alredy here: 3DLUT. (Professionals widely use it already.) It could be carried out as a fully automated process.
But no... An IFS guy will ask for even more sliders in the OSD. (I image tercier color sliders and +1 point in every year for grayscale to make it look like an improvement...) :D

[madshi]

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? :D
leeperry wants rules for primaries, too, so that makes at least 2 people. I guess I'll implement it sooner or later, but not too soon.

How will you know what levels the Fraps decoder uses, since these kind of filters will never output such information?
Isn't Fraps video always 0-255? In that case I could just detect that the video is Fraps encoded, then madVR would automatically know the content is 0-255.

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 :rolleyes:
It is not the job of the decoder to modify video/PC levels. Many decoders do not even offer a switch for that!! Still many of them they support RGB output, if the renderer refuses to accept YCbCr connections. Guess what the decoders output then? Video levels!

Let me say it again: The task of a decoder is to decode. It is not the task of the decoder to do anything display specific. Doing display specific things is the task of the video renderer. So setting your decoder to convert video level source material to PC levels is conceptually "wrong", from my point of view.

1. You're asking me to fool the decoder about my output levels
No, I'm asking you to tell the decoder to leave the levels alone. The decoder is supposed to decode and nothing else.

... so madVR, which assumes video levels for everything, produces proper output.
As I said, I plan to improve madVR in this regard. You can see from the madVR version number (< 1.0) that it's still a work in progress, not feature complete yet. If you want a fully feature complete version you'll have to wait for v1.0.

2. I can configure my decoder properly, then I fool madVR about my display levels
Except that you haven't configured your decoder "properly". Actually you've configured it wrong, because it's not the job of the decoder to do display specific things. The decoder doesn't even know if you really display the decoded video somewhere or whether you're feeding it into a DirectShow MPEG2 encoder filter or something like that. The decoder is the wrong place to do display specific things.

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.
I agree with you that this is not good. As I said, madVR is not feature complete yet. The aim is to make everything work automatically and correctly, as long as you configure the decoder to leave levels untouched. And I'm confident I'll make that work in a future madVR version.

As a nice workaround for now, you can simply press Ctrl+Alt+Shift+Y, that will make madVR switch between video <-> PC levels on the fly. This way you don't have to open up settings dialogs and search for the level setting.

4. Let's say you make an interface, header or whatever, so decoders can tell madVR the properties of the source.
Why do you come back to this idea? I told you this is not what I'm aiming to do.

I'll tell you again that there's no proper solution for this
You think you know that better than me?

HD is always using the BT.709 YCbPr decoding matrix, no exception.
Ok, thx.

[madshi]

My laptop has an 8600M-GT video card and has the following ports on it: HDMI, S-Video and VGA. I have my external monitor hooked up to the VGA port and my projector to the HDMI port. I press Function + F6 and the video gets alternatively output through each port if a device is plugged into it (internal laptop video screen --> the external monitor (video output only through VGA port) --> the projector (video output only through HDMI port) --> back to internal laptop screen). Basically I'm just selecting the video display (device) on which to view the operating system desktop and thus selecting which video display device on which to view the videos I am playing.
Hmmmmm... It seems that the OS in this scenario doesn't tell applications about these changes. If you use an application (e.g. MonInfo) which lists the EDID block of the display, do you get different EDID blocks when you switch displays?

How can I do that? I have Panasonic TX-p42g20e
Do you have a meter to measure your display? That's a requirement if you want madVR/yCMS to calibrate your display.

[jmone]

Do you have a meter to measure your display? That's a requirement if you want madVR/yCMS to calibrate your display.

Any suggestions/recomendations on an affordable meter?

[leeperry]

leeperry wants rules for primaries, too, so that makes at least 2 people. I guess I'll implement it sooner or later, but not too soon.
Oh, I thought this was the current scope...OK, I can waithttp://forum-images.hardware.fr/images/perso/garuvooz.gif
I would never ask or even accept money for a calibration if the overal result of my changes was worse than the default state
I don't even use 3DLUTs anymore because they make a very slight difference and the slightly off state looks subjectively better or me.
You seem to have gotten used to the colors of your uncalibrated display...some ppl don't like D65 and use D75, some others use Reclock@25fps even though their display fully supports a 24Hz multiple. At the end of the day, what truly matters is your own satisfaction.

Surely, D65 and 24Hz take some time to get used to...and I've got a hard time believing that a calibrated display would look "worse" than uncalibrated. Crushed whites, dark blacks, FUBAR gamma curves...blueish/greenish teints....you can't fix those w/o a colorimeter. Either you learn the tricks of the trade and buy an Eye One, or you call a pro and pay for it.

It'd be like asking a pro to tune a POS old car, and then complain that the results of his work don't quite meet your expectations.

you mentioned Samsung... Did you see their latest PDPs?
Nope, I've got no interest in Samsung whatsoever...I'm only interested in the high level of expertise Joe Kane provided them w/ on those high end DLP projectors. We need to learn from it, and get it all embedded within mVR.

[janos666]

No, I used a "perfectly" calibrated H-IPS for a year with every possible corrections.
I stopped using 3DLUT since I calibrated my new PDP with it's hardware controls and 3DLUTs make very slight difference. And considering the observer metamerism and sensor imperfections it's virtually nothing but the non-3DLUT corrected results looks subjectively better. (A very mild oversaturation is every directions.) My setting are still D65, gamma ~2.2
But the higher contrast ratio and smaller native gamut (did you care about the observer metamerism when you think you use offser WP? May be it's visually closer to what you called D65 on another display...) produces a noticably different image. (That' why I take this question less seriously now...)