madVR - high quality video renderer (GPU assisted)

[cyberbeing]

Anyway, if you view the combined madVR + yCMS processing steps as one chain with both v0.61 and v0.62, the whole chain is virtually unchanged. It's just that some processing steps moved from yCMS/3dlut to madVR.

I'm still not convinced this new way of doing things is mathematically sound in terms of color science and the accuracy of the resulting color corrections.

Doing gamut correction multiple times (instead of just once) on linear data from different gamma curves (instead of just one) is just asking for trouble. When yCMS becomes capable of doing more complex color corrections within the 3dlut, the error this causes will likely become more apparent.

Now my hunch could be wrong, but just taking your word without some hard data to back it up doesn't have me convinced. Since you want madVR to have the highest quality possible, I assume you've already done tests to make sure the new shader + 3dlut render chain isn't harming quality compared to the old 3dlut-only render chain? I would like it very much if you could share any data from such tests, which show new render chain vs the old has near-identical corrected RGB values across a wide spectrum of colors (sampling output values directly from the GPU in an automated fashion). Doing so with an extremely large funky gamut correction would likely yield the most interesting results if there was error from this new method. Of course, fixing the 3dlut bugs which myself in others have reported comes first. That such bugs can even exist now, is another cause of my concern.

Then madVR would have to convert Y'CbCr -> R'G'B' -> RGB -> R'G'B' -> Y'CbCr and feed that into the 3dlut. Why would that be preferred over doing only Y'CbCr -> R'G'B' -> RGB -> R'G'B' and feeding that into the 3dlut? Feeding Y'CbCr into the 3dlut would require both madVR and yCMS to do one step more, each.
I'm not understanding how you are coming up with these extra steps.

madVR would feed the 3dlut Y'CbCr directly (no RGB or linear conversion), the 3dlut would converted to RGB, madVR would do gamut and/or gamma corrections as needed on the RGB data.

Y'CbCr (source) -> Y'CbCr (3dlut input) -> RGB (3dlut output) -> RGB (gamma/gamut correction and whatever else madVR needs to do, keeping things in RGB)

Having the 3dlut processing at the beginning at the chain working with direct Y'CbCr input from the video should be beneficial, especially when shaders afterwards could be bypassed when certain adjustments aren't needed.

Edit: Actually nevermind. I see the problem, since either conversion would need to be done to feed the 3dlut, or you would need to go back to only accepting 8-but Y'CbCr (no RGB, no high-bitdepth). madVR would need to feed the 3dlut 16 bit RGB. So it would need to be like below:

madVR:
(1) input = 8bit Y'CbCr, 709 primaries, 709 gamma
(2) convert -> 32bit float R'G'B', 709 primaries, 709 gamma
3dlut:
(6) input = 8bit float R'G'B', 709 primaries, 709 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, 709 gamma

[TheElix]

How are you setting madVR when you test this, and what calibration pattern are you using? If you're setting madVR to PC levels, then when you set pixel format (I guess you have an ATI card) to RGB Full you should not see anything below level 16 (on the usual calibration patterns) and that means your display is accepting the full RGB signal.
I used mp4 format test videos available here: http://www.avsforum.com/avs-vb/showthread.php?t=948496

For this test I used black clipping, white clipping and APL clipping tests. In these tests I get near-perfect results when I use following settings: YCbCr 4:4:4 or Limited RGB 4:4:4 in pixel format, 0-255 in Video Settings in CCC, 0-255 in levels in madVR. By near-perfect I mean 17-28 stripes are flashing while 16 stripe remains black at all times (reference black). If I set pixel format to Full RGB then none of the bars are flashing (everything is black). If I set madVR levels at 16-235 it's the same as my reference variant. I don't know the theory, but I really see no difference.

But in case of Full RGB outside of the video player blacks and whites are crushed and I can't fix it by calibrating the screen.

[yesgrey]

Related question for yesgrey. Doesn't creating a 2.2 Gamma yRGB 3dlut cause anomalies in your calculations, when color correction is being done with linearized data form a gamma which is neither the encoded gamma nor the desired output gamma?
No, because we are using the exact same gamma, so it would be almost the same as if yCMS would remove the gamma itself.

Removing steps and having the 3dlut do the conversion from Y'CbCr to RGB, as well as (709, 601, PAL, etc) video primaries to yRGB makes more sense to me when using a 3dlut:
So you did not get right the idea behind yRGB... ;)

yRGB was created with the only purpose of allowing the usage of 709, PAL and NTSC with the same 3DLUT. yRGB is an intermediate color space just big enough to hold these three primaries sets so that a sing 3DLUT file could be used. To do like you are saying to, yRGB is not needed, because it would always be better to convert directly from the source gamut to the display gamut, instead of using yRGB as the middle man. However, considering that the precision loss is very tiny, we decided to go with the present solution. Both madshi and I are sure that once the current bug is solved you will enjoy the new working method. ;)

If it is indeed works as my 8 bit -> 16 bit (6 bit corrections) example does, then the quality should be decent.
I would say much more than just decent... ;)

Now the question is, can I visually tell the difference between the 8 bit and 6 bit 3dlut, and if so, is it worth losing quality for a problem that happens only 1-5% of the time.
And the answer is: only you can tell. :)

[madshi]

I'm still not convinced this new way of doing things is mathematically sound in terms of color science and the accuracy of the resulting color corrections.

Doing gamut correction multiple times (instead of just once) on linear data from different gamma curves (instead of just one) is just asking for trouble.
Agreed. But that's not what we're doing. There are 2 gamut conversions, but they're both applied in linear light in the same "gamma format" (I'm lacking a better word), if you know what I mean. As I've explained before, the RGB -> R'G'B' -> RGB steps between madVR <-> 3dlut equal each other out and have no mathematical meaning.

I assume you've already done tests to make sure the new shader + 3dlut render chain isn't harming quality compared to the old 3dlut-only render chain?
If you do: "y := x * 5" and then "z := y / 5" then you know that "x = z", you don't have to do a test run for that. But if you want, you can do a small test run yourself:

Let's take the data produced by madVR's shader math. It's RGB in linear light. Let's say the data after gamut conversion in linear light is [0.1, 0.5, 0.3]. Now we want to process this further with a 3dlut. The 3dlut internally calculates with linear light RGB, too. Ideally we'd like to feed the [0.1, 0.5, 0.3] directly into the 3dlut in linear light, that would save a few cross-conversions steps. Unfortunately yesgrey has run a few accurateness benchmarks and found out that due to the 3dlut being limited to 8bit, linear light doesn't work well as a communication platform between madVR and the 3dlut. So we convert [0.1, 0.5, 0.3] to gamma corrected light by applying a pure power curve of 2.2. So we do:

RGB = [0.1, 0.5, 0.3]
R'G'B' = [0.1 ^ 2.2, 0.5 ^ 2.2, 0.3 ^ 2.2]

Now we feed R'G'B' into the 3dlut. The 3dlut internally converts the R'G'B' input back to RGB by applying a pure power of 2.2 again. So the 3dlut does:

R'G'B' = [0.1 ^ 2.2, 0.5 ^ 2.2, 0.3 ^ 2.2]
RGB = [0.1 ^ 2.2 ^ (1/2.2), 0.5 ^ 2.2 ^ (1/2.2), 0.3 ^ 2.2 ^ (1/2.2)] = [0.1, 0.5, 0.3]

See? The 3dlut now has the same linear light data madVR had with no change in gamma. So really, there's only one "gamma format" the gamut is processed in. The gamut is converted twice, but in the same "gamma format".

[yesgrey]

The gamut is converted twice, but in the same "gamma format".
I would like to add that, considering that yRGB contains the entire BT.709. PAL and NTSC gamuts, there is no clipping involved in the first gamut conversion (inside madVR). It's still yCMS who handles the out-of-gamut colors that cannot be displayed by the display.

[Budtz]

Are there Any of the new settings that Can be tweaked witout a meter? I dont know how my tv is calibrated ether.

[madshi]

Are there Any of the new settings that Can be tweaked witout a meter? I dont know how my tv is calibrated ether.
You can modify the gamma in the "Color & Gamma" settings page, or by using the Ctrl+Alt+Shift C/F/G keys.

Correct, you are not doing gamut correction in two different gammas. The problem is the "gamma format" used for gamut corrections isn't the encoded gamma nor the output gamma. It's an arbitrary gamma which has been converted from the source gamma and then converted back after gamut corrections.
It is not an arbitrary gamma, it's the "desired display gamma". It's the same method Janos666 used which produces pretty good measurement results. Doing gamut correction any other way measures worse.

The other problem is doing gamut corrections twice, when it optimally should only be done a single time.
If you do "y = x * 10" and "z = y * 2" then that's the same as doing "z = x * 20". What is the problem? There's no real loss in quality because the data is never rounded down. The biggest loss comes from the weakest link in the processing chain, and that is the 8bit input limitation of the 3dlut. This limitation exists no matter which math/logic you use and will define the max accuracy we can achieve. But even this limitation is not really as weak as it seems. As I said before, the professional photo and movie industry commonly uses ca. 4bit 3dluts !!

If the 3dlut is yRGB to yRGB, aren't you only correcting the gamut to yRGB, and madVR for the display (709, 601, PAL) primaries?
No, the 3dlut does convert to the final display primaries. The 3dlut output is *not* yRGB. I know, Output_Format reads yRGB, but that is irrelevant because you're providing primary measurements. The primary measurements take preference over "yRGB" for output.

Completely unrelated question about high bit-depth:
madshi do you currently have any plans to support 10-bit input and 10-bit output? yesgrey do you have plan to support 10-bit -> 16-bit 3dlut? In the near future we may have the likes of ffmpeg-based decoders capable of outputting 10-bit h264 and there are already high-end LCDs w/ displayport which accept 10-bit input. I assume supporting 10-bit with shaders-only wouldn't be, but how large would a 10-bit 3dlut end up being? Are we just going to be stuck using a 8-bit 3dlut to correct 10-bit data (like using a 6-bit lut for 8bit data)?
10bit output may come at some time in the future, but honestly, I don't consider it very important. madVR already supports up to 16bit *input* today. The output is dithered down from the internal calculation bitdepth (32bit float) to the 8bit output bitdepth. So madVR can already show 16bit input without any problems. The only benefit of adding 10bit output would be to lower the dithering noise. If you can't see the dithering noise in madVR's current 8bit output then 10bit will bring no benefit to you whatsoever.

An 8bit 3dlut is 96MB. A 9bit 3dlut is 768MB. A 10bit 3dlut 6GB. That really doesn't make much sense. I understand the wish to match the 3dlut bitdepth to the video bitdepth. But that's really not necessary. Trilinear interpolation works pretty well. As explained above, if a 4bit 3dlut is good enough for the professional photo and movie industry then we should be great with an 8bit 3dlut for content of *any* bitdepth.

[cyberbeing]

ack, re-read my post madshi. I deleted when I was in the process of making many edits in hopes nobody would reply, but you replied to fast...
agreed. But that's not what we're doing. There are 2 gamut conversions, but they're both applied in linear light in the same "gamma format" (i'm lacking a better word), if you know what i mean. As i've explained before, the rgb -> r'g'b' -> rgb steps between madvr <-> 3dlut equal each other out and have no mathematical meaning.
...
see? The 3dlut now has the same linear light data madvr had with no change in gamma. So really, there's only one "gamma format" the gamut is processed in. The gamut is converted twice, but in the same "gamma format".
no, because we are using the exact same gamma, so it would be almost the same as if ycms would remove the gamma itself.
This isn't the case. madVR is doing gamut conversion with data linearized with a rec709 curve, and yCMS is doing gamut conversion with data converted from rec709 to 2.2 gamma and then linearized. That linear data isn't identical.

An additional problem is the "gamma format" used for gamut corrections by the 3dlut isn't the encoded gamma nor the output gamma. It's an arbitrary gamma which has been converted from the source gamma and then converted back after gamut corrections. Doing gamut corrections twice, when it optimally should only be done a single time introduces error as well, as we've seen with this current madVR bug.

So you did not get right the idea behind yrgb... ;)
...
To do like you are saying to, yrgb is not needed
...
No, I see the purpose of yRGB, but I'm just willing to forgo the main benefits. All the more reason I've been requesting the old 3dlut method as an option. ;)

I would like to add that, considering that yRGB contains the entire BT.709. PAL and NTSC gamuts, there is no clipping involved in the first gamut conversion (inside madVR). It's still yCMS who handles the out-of-gamut colors that cannot be displayed by the display.
What happens if your display gamut is larger than REC.709 but smaller than NTSC (SMPTE-C)? Wouldn't this lead to problems since your gamut would fall within the yRGB gamut but still need corrections? Does madVR deal with this somehow?

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

If the 3dlut is yRGB to yRGB, aren't you only correcting the display primaries to yRGB?

Completely unrelated question about high bit-depth:
madshi do you currently have any plans to support 10-bit input and 10-bit output? yesgrey do you have plan to support 10-bit -> 16-bit 3dlut? In the near future we may have the likes of ffmpeg-based decoders capable of outputting 10-bit h264 and there are already high-end LCDs w/ displayport which accept 10-bit input. I assume supporting 10-bit with shaders-only wouldn't be hard, but how large would a 10-bit 3dlut end up being? Are we just going to be stuck using a 8-bit 3dlut to correct 10-bit data (like using a 6-bit lut for 8bit data)?

[madshi]

This isn't the case. madVR is doing gamut conversion with data linearized with a rec709 curve, and yCMS is doing gamut conversion with data converted from rec709 to 2.2 gamma and then linearized. That linear data isn't identical.
No, I'm sorry but that's simply not true. madVR is doing gamut conversion with data linearized with the transfer function defined in the "Color & Gamut" settings section, if you have gamma processing enabled. Or it uses the transfer function defined in the "Calibration" settings otherwise. And yCMS uses the very same linear data that madVR used for gamut conversion.

I hope you do agree that the following is true:

x ^ 2.2 ^ (1 / 2.2) = x

Do you agree? If so, you should be able to see that the linear data being processed by madVR and yCMS is identical.

[cyberbeing]

It is not an arbitrary gamma, it's the "desired display gamma".
The arbitrary gamma is the 3dlut gamma.

No, the 3dlut does convert to the final display primaries. The 3dlut output is *not* yrgb. I know, output_format reads yrgb, but that is irrelevant because you're providing primary measurements. The primary measurements take preference over "yrgb" for output.
My mistake, I got confused for a second. I should have known that after using a 3dlut for so long.


If you do "y = x * 10" and "z = y * 2" then that's the same as doing "z = x * 20". What is the problem? There's no real loss in quality because the data is never rounded down. The biggest loss comes from the weakest link in the processing chain, and that is the 8bit input limitation of the 3dlut. This limitation exists no matter which math/logic you use and will define the max accuracy we can achieve. But even this limitation is not really as weak as it seems.
Yes, I realize there should be minimal loss doing two separate gamut corrections. The biggest issue is a bug like the current outstanding one, where madVR gamut adaption is behaving differently from the 3dlut gamut adaption, and the challenge of getting shader+3dlut gamut adaption to match up perfectly or improve upon 3dlut-only.

No, I'm sorry but that's simply not true. madVR is doing gamut conversion with data linearized with the transfer function defined in the "Color & Gamut" settings section, if you have gamma processing enabled. Or it uses the transfer function defined in the "Calibration" settings otherwise. And yCMS uses the very same linear data that madVR used for gamut conversion.

I hope you do agree that the following is true:

x ^ 2.2 ^ (1 / 2.2) = x

Do you agree? If so, you should be able to see that the linear data being processed by madVR and yCMS is identical.
Yes, I agree. I think I'm losing track of what I was trying to say, and started arguing something unimportant and unrelated. The problem isn't the linear gamma itself, I'm unsure why I brought that up. Back to the core issue.

I was under the impression that the gamut corrections yCMS does on the linear data is different based on what the 3dlut input and output gamma is. If this is true, it's an issue that the 3dlut is using a gamma of 2.2 rather than the source or desired gamma. If this is false with madVR 0.62+, then there is no issue. If this happens to only apply to 3dlut used in madVR 0.61 and prior, there is also no issue. madVR's shader gamut correction is fine, it's the one done with the 3dlut which I'm concerned about.

[fairchild]

I used mp4 format test videos available here: http://www.avsforum.com/avs-vb/showthread.php?t=948496

For this test I used black clipping, white clipping and APL clipping tests. In these tests I get near-perfect results when I use following settings: YCbCr 4:4:4 or Limited RGB 4:4:4 in pixel format, 0-255 in Video Settings in CCC, 0-255 in levels in madVR. By near-perfect I mean 17-28 stripes are flashing while 16 stripe remains black at all times (reference black). If I set pixel format to Full RGB then none of the bars are flashing (everything is black). If I set madVR levels at 16-235 it's the same as my reference variant. I don't know the theory, but I really see no difference.

But in case of Full RGB outside of the video player blacks and whites are crushed and I can't fix it by calibrating the screen.

This is exactly how I test that my display's are calibrated correctly, I also use the Color Clipping pattern. I've also come to the same conclusion as you regarding what works and what doesn't. In my case I've just stuck with using RGB Limited with PC levels in MadVR so that I don't have to constantly be switching from RGB Full to RGB Limited depending on what I'm going to do (watching video or everything else). Madshi has already said that this is not the best method since then there is a double conversion being done and it will not produce max quality, but it looks identical to my eyes so it's what I'll be using. I wouldn't use ycbcr because that would introduce yet another conversion.

Regarding what you said "But in case of Full RGB outside of the video player blacks and whites are crushed and I can't fix it by calibrating the screen.", you can fix it kind of by keeping MadVR at PC levels and then increasing the brightness on the display until 17-25 start to flash, but there is still some black clipping that occurs and is visible while gaming. The increasing of the brightness is also not a workaround for my display since my display doesn't save individual settings per input. (meaning that my calibrated Cinema preset retains it's setting across my 3 HDMI inputs)

[madshi]

I was under the impression that the gamut corrections yCMS does on the linear data is different based on what the 3dlut input and output gamma is.
Ah, I understand your concern then. But no, fortunately gamma and gamut processing are totally independent. Gamut conversion is always the same.

[cyberbeing]

Ah, I understand your concern then. But no, fortunately gamma and gamut processing are totally independent. Gamut conversion is always the same.

It did have an effect in 0.61 and prior though, since it was the 3dlut linearizing the video data (instead of madVR shaders in 0.62+), correct? I believe that is what got me confused.

[madshi]

It did have an effect in 0.61 and prior though, since it was the 3dlut linearizing the video data (instead of madVR shaders in 0.62+), correct? I believe that is what got me confused.
Well, R'G'B' -> RGB conversion is done before gamut conversion, and using different transfer functions of course result in different data, so there's an indirect effect of the transfer function on the gamut conversion. The gamut conversion math is always the same, though.

What I just wrote applies to both the old and new chain.

When comparing the old and new madVR/yCMS chain, there's no difference to gamut processing. The new chain has two more gamma processing steps, but these steps equal each other out. So basically the data that flows into the gamut processing "circuit" is virtually the same with the old and new chain.

[Andy o]

I used mp4 format test videos available here: http://www.avsforum.com/avs-vb/showthread.php?t=948496

For this test I used black clipping, white clipping and APL clipping tests. In these tests I get near-perfect results when I use following settings: YCbCr 4:4:4 or Limited RGB 4:4:4 in pixel format, 0-255 in Video Settings in CCC, 0-255 in levels in madVR. By near-perfect I mean 17-28 stripes are flashing while 16 stripe remains black at all times (reference black). If I set pixel format to Full RGB then none of the bars are flashing (everything is black). If I set madVR levels at 16-235 it's the same as my reference variant. I don't know the theory, but I really see no difference.

But in case of Full RGB outside of the video player blacks and whites are crushed and I can't fix it by calibrating the screen.

Which Panasonic model do you have? If Panasonic plasmas can't get full RGB signals by now that's pretty disappointing, especially since they became the better plasma manufacturer since Pioneer's Kuros died.

You might wanna try to use the DVI input, another user mentioned that that has the option for full RGB input, and you might have to change some DVI settings.

[Mikey2]

Can anyone please do me a favor and tell me where to start with working with yCMS/Gamut calibration? I have been reading this thread; however, it seems there is some baseline knowledge I am missing. (For instance, how do you display those graphs to verify your results. (Example (http://forum.doom9.org/attachment.php?attachmentid=11197&d=1277287857) )

I am normally pretty proficient with learning new technologies; so just a point in the right direction should be enough.

Thank you very much!

[cyberbeing]

When comparing the old and new madVR/yCMS chain, there's no difference to gamut processing.
With the exception of bug causing anomalies in the new madVR/yCMS chain, which needs fixing. ;)

(For instance, how do you display those graphs to verify your results. (Example (http://forum.doom9.org/attachment.php?attachmentid=11197&d=1277287857) )
ColorHCFR (http://www.homecinema-fr.com/colorimetre/index_en.php) is a common choice for use with a meter. Video test patterns can be found here (http://www.avsforum.com/avs-vb/showthread.php?t=948496).
Use ColorHCFR (View Images) to measure your monitor primaries, whitepoint, and optionally IRE grayscale, using that data in yCMS for creation of a 3dlut. Afterwards, use ColorHCFR (DVD Manual) with a test pattern video set designed for ColorHCFR (http://img810.imageshack.us/img810/6889/colorhcfrmp4patterns.png), click the necessary button and ColorHCFR, and play said videos in madVR when asked to verify results.

[madshi]

With the exception of bug causing anomalies in the new madVR/yCMS chain, which needs fixing. ;)
Haha, true. We're near to having it fixed, though.

[TheElix]

Which Panasonic model do you have? If Panasonic plasmas can't get full RGB signals by now that's pretty disappointing, especially since they became the better plasma manufacturer since Pioneer's Kuros died.

You might wanna try to use the DVI input, another user mentioned that that has the option for full RGB input, and you might have to change some DVI settings.
I have TX-PR42GT20 (42" 3D model in Europe). It's a 2010 model. DVI (aka PC) input doesn't support Full HD, 1366x768@60Hz max. Also, no 3D and HDMI audio.

[Budtz]

Is it possible to get Motion Interpolation with madvr?

[fairchild]

Which Panasonic model do you have? If Panasonic plasmas can't get full RGB signals by now that's pretty disappointing, especially since they became the better plasma manufacturer since Pioneer's Kuros died.

You might wanna try to use the DVI input, another user mentioned that that has the option for full RGB input, and you might have to change some DVI settings.

Another user mentioned this workaround, but my 2010 Panasonic S2 plasma doesn't even have a PC input, let alone a DVI input. (my other 2 HDTV's have VGA inputs, not DVI)

[Mikey2]

ColorHCFR (http://www.homecinema-fr.com/colorimetre/index_en.php) is a common choice for use with a meter. Video test patterns can be found here (http://www.avsforum.com/avs-vb/showthread.php?t=948496).
Use ColorHCFR (View Images) to measure your monitor primaries, whitepoint, and optionally IRE grayscale, using that data in yCMS for creation of a 3dlut. Afterwards, use ColorHCFR (DVD Manual) with a test pattern video set designed for ColorHCFR (http://img810.imageshack.us/img810/6889/colorhcfrmp4patterns.png), click the necessary button and ColorHCFR, and play said videos in madVR when asked to verify results.

Wow thank you so much for the response! However, is there a way of getting around building your own color-meter as they suggest? I actually have a degree in ECE (Electrical and Computer Engineering) but it has been years since I have worked with hardware circuits and I no longer have access to the labs. ...I wouldn't suppose there is a way to "cheat" and at not use any hardware is there? (I know it would not be exact, but in theory wouldn't an approximation with test patterns be better than not doing anything at all?) If that is not possible, what sort of meters are most of you guys working with?

Thanks again for your help! I feel bad when there are so many different levels of knowledge on this same thread...although I think I have a grasp of everything up to this, I have yet to take the plunge this deep into this. (But I would like to!)

[Andy o]

Well that sucks for Panasonic plasmas then. Have you guys tried with another GPU, like an Nvidia card, or something like a PS3 that can also be set up to output Full RGB, and see if it works then?

[TheElix]

Still the color and contrast are better than any LCD display I've seen ;)

[Mikey2]

Another user mentioned this workaround, but my 2010 Panasonic S2 plasma doesn't even have a PC input, let alone a DVI input. (my other 2 HDTV's have VGA inputs, not DVI)

So you do not even have an HDMI input? How do you do...anything? Wow I'm sory to hear that. :(

TheElix - This may or may not apply to you, as I am not sure how much of the Pioneer Kuro technology has already been ported over to the Panny's yet. But I have a Pioneer Kuro and it is NOT recommended at all to use the RGB/DSub input. That input is limited to VGA-type settings with hardly any means of configuration. In addition, I am looking at my manual right now and it only goes up to 1280x1024 (SXGA) (Where naturally HDMI goes to 1920x1080.) In addition, while the manual tried to suggest that this input should be used with a computer, it is basically a given that you should just use an HDMI input (even if you have to use an HDMI<>DVI converter (which will only cost you a few dollars.)) I mention all this on the off-chance that you are not using HDMI set on Video-mode (not computer mode) ...that would definitely cause most of your colorspace etc issues and limitations...

[cyberbeing]

However, is there a way of getting around building your own color-meter as they suggest?
lol, I never noticed that build-your-own meter link before. Most people buy a meter, not build one.

...I wouldn't suppose there is a way to "cheat" and at not use any hardware is there? (I know it would not be exact, but in theory wouldn't an approximation with test patterns be better than not doing anything at all?) If that is not possible, what sort of meters are most of you guys working with?

Unfortunately no. Our vision is non-linear and is influenced by many environmental factors, making it useless for the measurements a meter takes.

For a standard gamut display (~72% NTSC, with gamut similar to sRGB/REC709) buy a colorimeter: EyeOne Display 2, Spyder3, or DTP94

For a wide-gamut display (with gamut similar in size to AdobeRGB1998) you need to spend more for a spectrophotometer: Colormunki or EyeOne Pro

You'll get poor results using a colorimeter on a wide-gamut display, unless the software has a wide-gamut correction matrix for your meter.

[fairchild]

So you do not even have an HDMI input? How do you do...anything? Wow I'm sory to hear that. :(

I think you misread what I said. My TV has 3 HDMI inputs, and my HD 5830 video card outputs to my TV through it's HDMI port.

[Andy o]

What about trying with another GPU? ATI has been known to have this sort of trouble. I find it hard to believe that at this point displays can't take full RGB signals through HDMI.

[fairchild]

I don't currently own an Nvidia card so that's not an option.

[TheElix]

For a wide-gamut display (with gamut similar in size to AdobeRGB1998) you need to spend more for a spectrophotometer: Colormunki or EyeOne Pro
What about wide gamut PDPs, huh? With spectrophotometers having a hard time taking low brightness readings and spectrometers being way off (I know because I have i1 Display2)? :confused:

[Andy o]

EyeOne pro is very expensive, but colormunki might just be within reason... anyone using it? I'm also using a i1 Display and it doesn't work well at all with my Kuro, makes me raise blues +23 (out of 60 I think).

[Neeto]

Thanks e-t172 - much appreciated

There are two.

First, to apply the ICC profile to your video output, Windows needs to alter the CLUTs in your video card. This is accomplished using the internal SetDeviceGammaRamp (http://msdn.microsoft.com/en-us/library/dd372194%28v=vs.85%29.aspx) function. Problem is, you can only set a 3x1D LUT (three separate LUTs for each primary) this way, which is not the same as a 3DLUT. The downside is, there are some things you can't do with a 3x1D LUT (most notably, gamut correction), whereas a 3DLUT allows you to do basically anything with the output.

Second, it is unknown whether the video card applies dithering after the CLUT stage. If it doesn't, then there is potential for banding (Posterization (http://en.wikipedia.org/wiki/Posterization)), which is bad. madVR on the other hand always use dithering after the 3DLUT, and thus doesn't have this problem.

There are, however, two advantages from using the card's CLUT.

First, calibration is applied to all Windows applications, not just madVR.

Second, there is one thing Windows ICM does that yCMS doesn't do (yet), it's white point calibration (D65). Note that this is a limitation of yCMS, not of 3DLUTs in general.

So, to summarize:

Windows ICM using the hardware CLUTs:
- Gamma correction
- White point correction
- No gamut correction
- Probably no dithering

madVR with yCMS:
- Gamma correction
- No white point correction
- Gamut correction
- Dithering



You shouldn't use any profile before calibrating. However I think that the "sRGB" profile in Windows ICM doesn't actually do anything, so you are probably good to go. Execute "xcalib (http://xcalib.sourceforge.net/) -c" before calibrating just to be sure.



The Eye-One comes with software (Eye-One Match) for that. It's quite user-friendly, and will guide you through all steps of the process. You can also use ArgyllCMS (http://www.argyllcms.com/) which is more customizable but much harder to use.



In theory, that's the best way to do it. This way you'll have all three: gamma correction and white point correction for all Windows applications, plus gamut correction for madVR only. The only problem is, when using madVR there will be two correction stages one after the other (madVR's 3DLUT + the video card's CLUTs), which could be detrimental to image quality due to numerical imprecision, especially if the video card's CLUT stage doesn't dither.

[cyberbeing]

janos666 has a ColorMunki
(~$350 last year, now it's more like ~$450 for unknown reasons, look for sales)

I personally have an EyeOne Pro
(very expensive ~$1000, I only bought mine since I found it new for $537 during a Amazon close-out sale in '08)

What about wide gamut PDPs, huh? With spectrophotometers having a hard time taking low brightness readings and spectrometers being way off (I know because I have i1 Display2)? :confused:
I'm unsure what you are asking.

Spectrophotometers are rated down to 0.20 cd/m2.
Very high accuracy on both wide-gamut and standard-gamut displays. Good compatibility with all types of displays.

Spectrophotometers have trouble measuring near-black tones accurately. Using Adaptive mode in Argyll CMS helps negate, but never fully resolves the issue.


Colorimeters are usually rated down to 0.05 cd/m2.
High accuracy on standard-gamut displays, but very low accuracy on wide-gamut displays. Good compatibly with CRT/LCD, bad compatibility with PDP.

Colorimeters on the other hand will measure everything (except luminance) inaccurately on a wide-gamut display. If you own both a spectrophotometer and a colorimeter, you can create a correction matrix for the colorimeter to make its wide-gamut measurements accurate. Using the colorimeter w/ correction matrix for measuring near-black tones and a spectrophotometer for everything else is good option for working around the weakness of the spectrophotometer. The Spyder3 Pro/Elite is supposedly half-decent (instead of horrid like most colorimeters) measuring wide-gamut LCDs without a correction matrix, if cost of spectrophotometers is a major issue, but for all I know it still has poor compatibility with PDP (something you should read up on if you have a PDP). Unfortunately, many people mistakenly buy colorimeters for wide-gamut displays and are never aware of the detrimental effect they are having, since they have nothing to reference their results against.

Paying for someone to come out and do an ISF calibration for your TV is also an option if you don't want or can't afford to buy a spectrophotometer.
Just have the person doing it give you measurements for your 3dlut after they finish calibration.

[Neeto]

@mashi
I think you already know about this, but just in case...

I've got a NTSC DVD that madVR insists is on playing at 25fps
I've got 1080p24, 1080p50, 1080p60 configured in the madVR auto changer
madVR will not change to 1080p60, uses 1080p50 which is the native resolution & speed of the desktop.

madVR status displays says "movie 25.000 fps (says source filter)"

Both ffdshow and reclock show it as 29.970 fps.
If I play the VOBs directly it's fine & madVR changes 1080p60.
"movie 29.970 fps (says source filter)"

I live in "PAL" land so 50hz is my "standard" screen resolution on my PDP & thus what my desktop is displayed at. Perhaps this has something to do with it?

I'm using patches suggested from this thread to ge the DVD playback working.

I'll head over to the yCMS thread if I have any more calibration questions - thanks

[oddball]

Interesting you should say that. I have the benefit of comparing a wide gamut monitor (HP LP2475w) next to a non wide gamut monitor. The problem is not so much the calbration I find but the fact that applications do not obey the color profiles set on dual display setups. Adobe Photoshop and Lightroom are notorious for this. If you open either on the secondary display the profile gets ignored and it just uses sRGB from what I recall. I went through all this before because I could not gte colors to match on either display. But from what I remember I set both to sRGB in Photoshop and compared and there was little between them. The HP does have more saturated colors if profiles are ignored entirely.

I calibrated with an i1 Display on both btw. Also calibrated my Pioneer G20 using AVCHD and the relevant tool (Not X-rite's software as that would be foolish to use on a HDTV).

[oddball]

@mashi
I think you already know about this, but just in case...

I've got a NTSC DVD that madVR insists is on playing at 25fps
I've got 1080p24, 1080p50, 1080p60 configured in the madVR auto changer
madVR will not change to 1080p60, uses 1080p50 which is the native resolution & speed of the desktop.

madVR status displays says "movie 25.000 fps (says source filter)"

Both ffdshow and reclock show it as 29.970 fps.
If I play the VOBs directly it's fine & madVR changes 1080p60.
"movie 29.970 fps (says source filter)"

I live in "PAL" land so 50hz is my "standard" screen resolution on my PDP & thus what my desktop is displayed at. Perhaps this has something to do with it?

I'm using patches suggested from this thread to ge the DVD playback working.

I'll head over to the yCMS thread if I have any more calibration questions - thanks

Sounds like the bug I reported earlier. Maybe he forgot about it.

[madshi]

I've got a NTSC DVD that madVR insists is on playing at 25fps
I've got 1080p24, 1080p50, 1080p60 configured in the madVR auto changer
madVR will not change to 1080p60, uses 1080p50 which is the native resolution & speed of the desktop.

madVR status displays says "movie 25.000 fps (says source filter)"
That's not a bug in madVR. The filter which delivers the data and information to madVR is claiming the video is 25.000 fps. It's not something madVR invented for itself. madVR is being *told* that the video file is 25.000 fps. If you want to find out who is responsible for this error, you can in MPC-HC right click the properties of every loaded filter, then lock at the "Pin Info" tab. Write down the value "AvgTimePerFrame" for all filters and post it here.

[Neeto]

That's not a bug in madVR. The filter which delivers the data and information to madVR is claiming the video is 25.000 fps. It's not something madVR invented for itself. madVR is being *told* that the video file is 25.000 fps. If you want to find out who is responsible for this error, you can in MPC-HC right click the properties of every loaded filter, then lock at the "Pin Info" tab. Write down the value "AvgTimePerFrame" for all filters and post it here.

Five filters:

ReClock Audio Renderer

madVR Render
AvgTimePerFrame: 400000

ffdshow Audio Decoder

fddshow Video Decoder
AvgTimePerFrame: 0

DVD Navigator
AvgTimePerFrame: 0

"0" looks a bit sus as a value

[madshi]

Five filters:

ReClock Audio Renderer

madVR Render
AvgTimePerFrame: 400000

ffdshow Audio Decoder

fddshow Video Decoder
AvgTimePerFrame: 0

DVD Navigator
AvgTimePerFrame: 0

"0" looks a bit sus as a value
Try using a different video decoder, one that outputs a proper AvgTimePerFrame value. Although, the DVD Nagivator should already do that...

[Neeto]

Try using a different video decoder, one that outputs a proper AvgTimePerFrame value. Although, the DVD Nagivator should already do that...

Changed to the inbuilt decoder and all is good.

No pin info on the inbuilt decoder, but ffdshow (for post processing) shows AvgTimePerFrame 33.....
I'm surprised that ffdshow does not supply this info if the previous filter does not supply it - perhaps a bug for the ffdshow developers - any idea where I report that?

[renq]

Decoder queue 7-8/8
Upload queue 6-8/8
Render queue 1-3/8
Present queue 0-2/4

suggests weak GPU?

[xvidivx]

Thanks Madshi
I have some questions.
1. The numbers of dropped frames and delayed frames will increase after Windows turn into screensaver or by Win+L. The only way to stop it is to reopen MPC-HC.
2. Is there also OSD to show time message(like "00:01:09 / 01:45:09" on windows mode) on exclusive mode when I click seek bar?

Thanks.

[Portioli]

When I was using older versions of madvr I liked when the 3dlut was enabled.
How I configure this now?
I don't have any calibration experience neither hardware nor software ,
I think this new yCMS feature is Overkill for 99% of madvr users.
It's impossible, somebody can input correct measurements using patterns from Internet
And using his eyes for colorimeter.

[HTPC-User]

Hi!

Concerning the strange mouse/seekbar behaviour in MPC-HC:
http://forum.doom9.org/showthread.php?p=1498500#post1498500

Looks like MPC-HC bugs, not madVR bugs to me. FWIW, the "D3D Fullscreen" option in the MPC-HC "Output" section is not supported by me. Which means that you can use it, but at your own risk.


I thought that the D3D fullscreen option is used by madVR, so it was always checked! :eek:

Although I don`t understand why it should be a bug in MPC-HC as everything is working with EVR, it is ok for me as I found a setting that works for me. :) So don't bother.

As I am trying to integrate madVR in my HTPC, I notice some strange things (besides the DVD navigation problem :) ):
1.) The OSD is not fully shown in green, i.e. some parts of the text are green, some parts are grey (that also applies to the old OSD in red). I am using a projector (which supports that format), RGB 4:4:4 output (selected in ATI CCC, which is some months old) with an ATI 5770.

Is this due to the 'famous' bug in the ATI driver or due to some incorrect settings in ffdshow/MPC-HC or in madVR (still 0.61) itself?

2.) I am using ffdshow (for deinterlacing) so I would like to know what I have to select in the 'output' tab of ffdshow: PC levels or standard TV (limited) levels? madVR output is set to PC levels (CCC is also set to PC levels). I understand that the madVR levels and the level setting in the graphic card driver must match, but must the ffdshow output also match or is madVR always expecting input with TV/limited levels?
(My projector supports PC levels, my LCD TV not, so I have to find a way to activate automatically the right level settings including different LUTs, but that is another story.)

:thanks:

[cyberbeing]

decoder queue 7-8/8
upload queue 6-8/8
render queue 1-3/8
present queue 0-2/4

suggests weak gpu?

Is your GPU a ATI 6950, as in your signature? If so, the problem is not a weak gpu.

In Catalyst Control Center make sure Anti-aliasing and Anisotropic filtering are set to Use Application Settings and Morphological filtering is disabled.

[Portioli]

a few questions:
1)where we change this settings(Anti-aliasing and Anisotropic filtering)?
2)sRGB is the same like FullRGB
3) i have two displays. One LCD connected with HDMI where i successfully have changed pixel format to Full RGB, the other is a dell u2410 connected with display port.
but i cannot change the pixel format.
this monitor has not even pixel format options!
4)for the pc monitor is better to use sRGB or Standard RGB when madVR outputs pc levels?

[nevcairiel]

2) sRGB is a color space, typically the "default" RGB color space for PC applications. sRGB is basically the same as BT.709, but those are not related to the Range of RGB values, you can have both full range or limited range using those.
3) PC Monitors are typically always Full-Range RGB.
4) On the U2410, "Standard" is a wide-gamut, unless you know how to deal with that properly, using sRGB is probably better.

[cyberbeing]

@Portioli
1) In your GPU's control panel (i.e. NVIDIA Control Panel / ATI Catalyst Control Center)
2) sRGB and FullRGB are two different things. sRGB is a color space. FullRGB is 0-255 luminance range.
3) GPU control panels usually have two modes. TV-mode for televisions (selectable pixel format), and PC-mode for computer monitors (always FullRGB). Your u2410 is a computer monitor, if you don't have any pixel format options, it is using PC-mode as it should be.
4) Those things are unrelated to each other. For other reasons you should use the sRGB mode (gamut emulation) on your monitor so your colors aren't over-saturated.

Edit: nevcairiel beat me to it as I was typing, same info stated slightly differently, but there is your answer to (1).

[webs0r]

Hey guys, complete noob with colour here.

Can I ask a few questions out of curiousity?
- Are you meant to calibrate your display so that it displays a superset of colour, measure it and feed into yCMS, then madVR will adjust the output colour depending on the source content?
i.e. What is the actual process to use madVR/yCMS effectively?

Thanks

[renq]

Is your GPU a ATI 6950, as in your signature? If so, the problem is not a weak gpu.

In Catalyst Control Center make sure Anti-aliasing and Anisotropic filtering are set to Use Application Settings and Morphological filtering is disabled.
No, it's an older laptop with T5600, 256MB GF7600Go...