madVR - high quality video renderer (GPU assisted)

[fairchild]

Or, with Panasonic PLASMA, you can connect on DVI <---> HDMI and then the TV propose a settings "DVI complete" for full RGB and you can have:
Pixel Format: RGB Full
MadVR: PC Levels

I tried this, connected my HD 5830 through it's DVI-HDMI adapter, but still the same issue. I have black crush and BTB/WTW + color clipping.

I also don't know what you mean by "the TV propose a settings DVI Complete for full RGB". I don't know if you mean that some plasma's have this setting, but my Panasonic S2 doesn't have anything like that in the User Menu.

I can only achieve retain BTB/WTW and Colors like my set top Blu-ray player by using RGB Full in ATI drivers and TV levels in MadVR. It's the same thing with using DXVA or standard software decoding with EVR, I have to select 16-235 to get correct levels and full BTB/WTW + no color clipping.

Maybe it is my TV's that don't handle RGB signals correct. /shrug

[yesgrey]

What`s wrong with madVR and 3dlut (except it is buggy in detecting correct 3dlut files)?
The gamut correction is not working correctly. If you want to know more details take a look into yCMS thread.

(Also, just to be pedantic: AFAIK, the 3DLUT file format can in fact be used to reach D65, it's yCMS that can't)
yet... ;)

[Portioli]

Could somebody tell us what happens with conversions and output levels settings?
When I set madvr in pc levels and catalyst pixel format fullrgb
I have very dark picture on my display like fairchild.
Do recommended settings fit any display?
What is the main reason we have to do that?

[Shark321]

No I don't mean the usual jerking you get with scrolling text sections in some anime. I mean it actually affects playback. If I hit arrow left to go back a bit it does not do it other than the usual scrolling text jerkiness. It's an entirely different effect. MadVR (Or MPC-hC or perhaps a combination of filters I'm not sure) does a weird repeating frame thing like it's bouncing between each frame several times. I've only seen this happening since build 0.61 and the latest MPC-HC and ffdshow (I tend to update them all at the same time for each build).

I get the exact same effect since updating to 0.65, but only in windowed mode. In exclusive mode no jerking at all. This is on Win7x64, second monitor (Sony TV), Nvidia GTX 560 Ti and Zoom Player 7. Turning disable desktop composition on "solves" the problem.

p.s.

Turning use D3D11 for presentation results in a black screen and nothing else.

[cyberbeing]

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.
The problem wouldn't (5) or (7), it would potentially be (9). What does 'display corrected gamma' default to with gamma correction disabled? In the above example it should be 709 gamma, so there is no change from (1). Converting to anything else other than (1) in step (9) would result in a change of gamma.

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.
Seeing the more detailed workflow you posted, it appears (2) became the functional replacement of 3dlut input_transfer_function in prior versions. In which case it would be (2), the curve you initially choose the linearize the video with, which would need to be tweak-able. The janos666 'special-tweak' would be setting (2) to your display gamma. I personally never did this, so I like it as you currently have it.

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+.
Interesting. Which software is this? Do you have a link?

And I still don't see any practical situation where v0.62+ limits your 3dlut usage. Can you give me a practical example?
I don't doubt there is a practical example, but I would have to think of a use-case, since it's nothing I'm using currently. I just have a feeling that if you don't re-add support for the previous four 3dlut 'dumb' functionality soon to complement the new yRGB+Shaders, we will be stuck this way, even if a need arises in the future.

The non-practical example would be if you wanted to manipulate the video in a non-standard way. You could look at how the film industry uses 3dluts during post-processing to give you an idea of the possibilities. In version 0.61 you could feed madVR such a 3dlut and it would get processed correctly. In 0.62+ you are forced to make 3dluts which are practical for common playback needs.

I suspect you rightfully see this as a non-issue, but the ways a 3dlut can be used in 0.62+ are more limited.

madVR doesn't deal with it at all at the moment. madVR strictly expects all input content to be "video levels".
Just to confirm, this applies to RGB input as well? You should probably make a note of this in the Readme.txt or something.


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.
Well I finally got around to testing today. I can't get 0.61 to match 0.65 when using a 8 bit 3dlut. It appears other people are having issues as well, but I unfortunately see no improvement from madVRprecision1, madVRprecision2, or madVRprecision3.

Gamut_Measurements 2
44.879 24.456 2.3025
31.815 65.848 10.537
18.241 9.5207 95.101
95.1206 99.9977 108.75

After doing some measurements, it appears to be a bug in how madVR is adapting the RED primary to yRGB. I see where the mistake is, and it appears it should be easy for you to fix.

http://img41.imageshack.us/img41/5220/061t.pnghttp://img832.imageshack.us/img832/3204/065precision.png
madVR 0.61 on the left and 0.65 precision 3 on the right.

Uncorrected RED primary 0.626474x 0.3413855y
REC709 RED primary 0.640x 0.330y

With 0.61 the RED primary is 0.626326x 0.341512y
With 0.65 the RED primary is 0.604817x 0.329905y


The bug appears to affect GREEN and BLUE as well, but to a lesser extent. You should be aiming to maximize and bind to the edges of the gamut triangle whenever possible, as yCMS does.

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.
I don't know if this is good news or bad news. 8bit and 7bit had the bug, but 6bit didn't.

Is this even worth it quality-wise? You'll need to explain how madVR deals with a 6 bit lut. I hope madVR is giving the 3dlut 8bit color data, at which point it does color corrections on the 8 bit color data with 6 bit precision (same adjustment to colors which fall within 4x4x4 blocks of color), while converting to 16 bit. If instead madVR is converting the video to 6 bit color before feeding it to the 3dlut, it would be very lossy and kind of pointless. I have the feeling yCMS does the latter, but you'll need to check with yesgrey...

Even though it fixes the rare 3dlut performance issue, I'm unsure this is the best answer to the problem. I hope it at least gives you an idea of what the bottleneck may be, and are able to come up with a higher quality solution.

ps. I like the changes you made to settings dialog. Everything is much less confusing now. My only request would be duplicating the bit-depth selection for the 3dlut into the Calibration or yCMS tab so all the settings are in one place, and you can just click apply to create it when done.

[6233638]

After doing some measurements, it appears to be a bug in how madVR is adapting the RED primary to yRGB. I see where the mistake is, and it appears it should be easy for you to fix.

http://img41.imageshack.us/img41/5220/061t.pnghttp://img832.imageshack.us/img832/3204/065precision.png
madVR 0.61 on the left and 0.65 precision 3 on the right.

Uncorrected RED primary 0.626474x 0.3413855y
REC709 RED primary 0.640x 0.330y

With 0.61 the RED primary is 0.626326x 0.341512y
With 0.65 the RED primary is 0.604817x 0.329905y


The bug appears to affect GREEN and BLUE as well, but to a lesser extent. You should be aiming to maximize and bind to the edges of the gamut triangle whenever possible, as yCMS does.That is how color correction is supposed to work. What you propose, is not correct at all. Luminance and Hue take priority over Saturation.

This is the exact same thing you will see happen with ICC color correction, which is an industry standard.

This is why the display industry needs to move towards wide gamut displays that are capable of high levels of gradation, and why displays sold for photo editing and film grading are already doing that.

Eg:
http://www.barco.com/en/product/2146
http://www.eizo.com/global/products/coloredge/cg232w/index.html
http://www.eizo.com/global/products/coloredge/cg221/index.html
http://h10010.www1.hp.com/wwpc/uk/en/sm/WF05a/382087-382087-64283-3884471-3884471-3648397.html

[Andy o]

I tried this, connected my HD 5830 through it's DVI-HDMI adapter, but still the same issue. I have black crush and BTB/WTW + color clipping.

I also don't know what you mean by "the TV propose a settings DVI Complete for full RGB". I don't know if you mean that some plasma's have this setting, but my Panasonic S2 doesn't have anything like that in the User Menu.

I can only achieve retain BTB/WTW and Colors like my set top Blu-ray player by using RGB Full in ATI drivers and TV levels in MadVR. It's the same thing with using DXVA or standard software decoding with EVR, I have to select 16-235 to get correct levels and full BTB/WTW + no color clipping.

Maybe it is my TV's that don't handle RGB signals correct. /shrugI think he meant that you connect the cable to the DVI port on your TV, if it has one, not on your card. Since DVI was used primarily for computer, some TVs use this port differently, and allow full RGB signals through it.

[cyberbeing]

6233638, you must be confused since that is not how color correction is supposed to work.

The black triangle is the REC709 target gamut. In a perfect world the white triangle (measured gamut) would line up perfectly over the black triangle. That is what monitors with hardware 3dluts do, but since they are wide-gamut, they should never run into issues like I'm showing here. Color corrections are supposed to minimize deltaE, not make it worse by reducing your gamut when it is already smaller than the target gamut. A 3dlut has the potential to correct all 16.7M potential colors individually within the gamut triangle (yCMS uses a combination of Perceptual and Relative Colorimetric rendering). Colors outside the white triangle are forever lost, which mean a less accurate correction from the 3dlut. Maximizing gamut volume within the target gamut should take priority over primary colors which you'll never see in real footage anyways. My reds become almost pink with what madVR 0.65 is doing with yRGB 3dluts.

http://img825.imageshack.us/img825/5678/photoshopq.png
Here is Photoshop's ICC color management. (very similar to madVR 0.61 /w 3dlut)
RED Primary 0.622968x 0.341998y

http://img191.imageshack.us/img191/3703/crtcy.png
Here is my CRT's uncorrected gamut.

[Portioli]

Is it possible to have a standard 3dlut file for every single tv ?
Just like icc profiles for pc monitors?
E.g. Pqnasonicvt30.3dlut , lgpk550.3dlut etc

I think 90% of users would be very pleased with a standard calibrated setting.

[tschi]

features request : shortcut configurable or shortcut with less than 4 keys. I use logitech diNovo mini, quite hard to have all the shortcut with 4 keys :
http://images.karp-shop.de/1-tas0042052_k.jpg
I also use iMon soundgraph with remote but it can only manage 3 keys at same time :(
The new shortcuts are very useful in order to correct decoding matrix and adapt gamma to ligthing condition :cool:
Thank you for your consideration :)`

Edit : Never mind, I found a workaround with evenghost :)

[6233638]

6233638, you must be confused since that is not how color correction is supposed to work.

The black triangle is the REC709 target gamut. In a perfect world the white triangle (measured gamut) would line up perfectly over the black triangle. That is what monitors with hardware 3dluts do, but since they are wide-gamut, they should never run into issues like I'm showing here. Color corrections are supposed to minimize deltaE, not make it worse by reducing your gamut when it is already smaller than the target gamut. A 3dlut has the potential to correct all 16.7M potential colors individually within the gamut triangle (yCMS uses a combination of Perceptual and Relative Colorimetric rendering). Colors outside the white triangle are forever lost, which mean a less accurate correction from the 3dlut. Maximizing gamut volume within the target gamut should take priority over primary colors which you'll never see in real footage anyways. My reds become almost pink with what madVR 0.65 is doing with yRGB 3dluts.To do what you suggest, skews all color reproduction, and/or clips out of gamut colors.

Measure the full gamut - that is luminance, hue and saturation, and you will find that overall color reproduction is far better.

Order of importance is Luminance, Hue, Saturation. The primary saturation points (all you are showing) is probably the least important thing for color reproduction when it comes to displaying an accurate image. (or as accurate as a display is capable of)


Imagine that you have a line going from each primary through the white point, and out the other side.

Every point of red saturation from 0% at the D65 white point through to 100% at the edge of the gamut triangle, should be on this line, with equal (linear) spacing between each point.

If your red primary is skewed off to orange, as you seem to want, it means that either all color reproduction is hue-shifted or you have a hue-twist going on which does all sorts of unpleasant things to the image.

It also means that your cyan secondary should be skewed over to blue by the same amount that red is skewed towards orange, even if that half of the CIE triangle is entirely in-gamut for the display.

You should also be using uv charts for your data, as xy is outdated and misrepresents where your display's gamut deficiencies lie.

http://img825.imageshack.us/img825/5678/photoshopq.png
Here is Photoshop's ICC color management. (very similar to madVR 0.61 /w 3dlut)
RED Primary 0.622968x 0.341998yYou have Photoshop set up incorrectly, and/or clipping out of gamut colors here, if that is the result you are getting.

The behaviour you have posted is common with ICC management, except it is typically noticed with blue more than red, as people often ask why their blues have "turned purple" after calibration on displays that have a limited gamut.

[e-t172]

You have Photoshop set up incorrectly, and/or clipping out of gamut colors here, if that is the result you are getting.

The behaviour you have posted is common with ICC management, except it is typically noticed with blue more than red, as people often ask why their blues have "turned purple" after calibration on displays that have a limited gamut.

It depends on the ICC rendering intent. If the display gamut is smaller that the target gamut, then ICC will behave differently depending on the rendering intent selected (absolute, relative, perceptual, or saturation). This is supposed to be configurable in the software which is using the ICC profile.

Details:
http://en.wikipedia.org/wiki/Color_management#Rendering_intent
http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm

At first glance I would say that cyberbeing's Photoshop results were obtained using the saturation intent, which is considered to be the worst.

[pankov]

6233638,
First I must admit that I've just recently begun reading about calibration and color spaces and so on but I think (or at least I hope) that I start to understand the "strange language" that you advanced users use.
;)
Now am I correct to think that "uv charts" means a chart that shows the measurement results in uv coordinate system as in Yuv?
Can you post some links to such "uv charts"? Is colorHCFR capable of showing them or you use another software?

I apologize to interfere in your discussion with cyberbeing but I hope you'll help me here.

[6233638]

It depends on the ICC rendering intent. If the display gamut is smaller that the target gamut, then ICC will behave differently depending on the rendering intent selected (absolute, relative, perceptual, or saturation). This is supposed to be configurable in the software which is using the ICC profile.

Details:
http://en.wikipedia.org/wiki/Color_management#Rendering_intent
http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm

At first glance I would say that cyberbeing's Photoshop results were obtained using the saturation intent, which is considered to be the worst.Yes, this is why I said he has it set up incorrectly.

6233638,
First I must admit that I've just recently begun reading about calibration and color spaces and so on but I think (or at least I hope) that I start to understand the "strange language" that you, advanced users use.
;)
Now am I correct to think that "uv charts" means a chart that shows the measurement results uv coordinate system as in Yuv?
Can you post some links to such "uv charts"? Is colorHCFR capable of showing them or you use another software?

I apologize to interfere in your discussion with cyberbeing but I hope you'll help me here.I think you have the option to switch if you right click the CIE chart.

Should look something like this (google image result)
http://img198.imageshack.us/img198/5315/cal4.png

Unfortunately HCFR has a tendency to stretch out its charts rather than keeping the axes to the same scale, which can hurt the perceptually uniform intent of these charts, but I think you can maybe change that when exporting a copy.

http://en.wikipedia.org/wiki/CIELUV

[ced007]

I tried this, connected my HD 5830 through it's DVI-HDMI adapter, but still the same issue. I have black crush and BTB/WTW + color clipping.

I also don't know what you mean by "the TV propose a settings DVI Complete for full RGB". I don't know if you mean that some plasma's have this setting, but my Panasonic S2 doesn't have anything like that in the User Menu.

I can only achieve retain BTB/WTW and Colors like my set top Blu-ray player by using RGB Full in ATI drivers and TV levels in MadVR. It's the same thing with using DXVA or standard software decoding with EVR, I have to select 16-235 to get correct levels and full BTB/WTW + no color clipping.

Maybe it is my TV's that don't handle RGB signals correct. /shrug

I have a 50VT20, and I have the "Full RGB" option that appears only if connected in DVI -> HTMI, under the menu "Configuration" / "Other settings" ("Configuration" / "Autres réglages" in French so I am not sure about their correspondence in English).
Now I don't know if all Pana plasma have this option.

Does this work while still maintaining the ability to take 24p input and refresh at 96Hz?

I didn't know that I could have a refresh at 96Hz with my plasma, I thought that 60Hz was the max... Need to check this.

[yesgrey]

The problem wouldn't (5) or (7), it would potentially be (9). What does 'display corrected gamma' default to with gamma correction disabled?
As long as you don't give the grayscale measurements your gamma will be untouched.

I unfortunately see no improvement from madVRprecision1, madVRprecision2, or madVRprecision3.
It's a bug, and madshi is working on it.

Is this even worth it quality-wise? You'll need to explain how madVR deals with a 6 bit lut.
The same it deals with 7 bit and 8 bit. It uses trilinear interpolation to get a better approximation.

Furthermore, some while ago I did some precision tests to find which bit depths combinations would be the preferred ones for madVR's usage. Just to give you an idea, here are the error analysis results for 6 bit input / 16 bit output and for 8 /16. The upper values (%) are relative errors, and the bottom ones are absolute values, on a scale 0-255:

in gamma 6bit - out gamma 16bit
Mean - R: 0.006420498 G: 0.008891874 B: 0.006795065 [%] (N: 250047)
StDe - R: 0.002319500 G: 0.003262942 B: 0.002451371 [%]
Max - R: 0.297517029 [%] - [ 0.5, 21.5, 17.5] [ 22.5, 85.5, 72.1]
G: 0.283557112 [%] - [ 47.5, 0.5, 33.5] [178.8, 22.4, 128.8]
B: 0.296553471 [%] - [ 14.5, 23.5, 0.5] [ 63.3, 93.9, 22.4]
PSNR - R: 90.968 G: 89.196 B: 90.679 [dB]
Mean - R: 0.002985598 G: 0.002957731 B: 0.003017776
StDe - R: 0.000411212 G: 0.000522080 B: 0.000427074
Max - R: 0.067848596 - [ 0.5, 20.5, 24.5] [ 22.9, 81.8, 96.6]
G: 0.064399604 - [ 39.5, 0.5, 59.5] [151.9, 22.9, 226.3]
B: 0.067331197 - [ 3.5, 24.5, 0.5] [ 33.1, 97.3, 22.8]



in gamma 8bit - out gamma 16bit
Mean - R: 0.000883031 G: 0.001232038 B: 0.000920341 [%] (N: 16581375)
StDe - R: 0.000180594 G: 0.000281853 B: 0.000189370 [%]
Max - R: 0.310449382 [%] - [ 0.5, 0.5, 3.5] [ 0.6, 0.5, 3.1]
G: 0.348503051 [%] - [ 0.5, 0.5, 3.5] [ 0.6, 0.5, 3.1]
B: 0.265714347 [%] - [ 1.5, 0.5, 0.5] [ 1.4, 0.5, 0.5]
PSNR - R: 108.919 G: 108.380 B: 108.853 [dB]
Mean - R: 0.000715752 G: 0.000738833 B: 0.000718038 (N: 16581375)
StDe - R: 0.000035518 G: 0.000039522 B: 0.000036036
Max - R: 0.006385626 - [ 1.5, 86.5, 58.5] [ 21.2, 84.9, 61.5]
G: 0.006084292 - [194.5, 1.5, 104.5] [180.4, 21.2, 100.3]
B: 0.006322896 - [ 30.5, 97.5, 0.5] [ 42.8, 95.8, 21.2]

So, probably you would be fine with the 6 bit one, but madshi and I preferred to consider the default as the 8/16 ones. We considered 96MB to be a perfectly manageable size and we wanted the extra precision, even if it might not be visible to the majority of users... ;)

I have the feeling yCMS does the latter
yCMS doesn't convert the video to 6 bit. It would be more like considering the video to be 6 bit. There is no other way of doing it.

My only request would be duplicating the bit-depth selection for the 3dlut into the Calibration or yCMS tab so all the settings are in one place, and you can just click apply to create it when done.
+1

Is it possible to have a standard 3dlut file for every single tv ?
With madVR 0.62+ it's now possible. madVR detects your different displays, and has different setting for each, so you can have different 3DLUT files for each display.

[TheElix]

I hate to be repeating myself, but isn't there anyone with the same problem as me? ("Creating the 3dlut for the display Х failed")

[suanm]

Hi,madshi
why do I only get black video image(actually no video image,but sound) with madvr 0.65,when I choose "calibrate this display by using yCMS" function. However I get normal video image with madvr 0.61 by using yCMS,This is why?
virtually I don't understand at all how I should setup the parameters of yCMS ,so I setup the parameters of yCMS random,the result is that I get no video image(black screen),what should I do for perfect video image?

[cyberbeing]

yCMS doesn't convert the video to 6 bit. It would be more like considering the video to be 6 bit. There is no other way of doing it.
You'll need to explain the the differentiation you are making between converting and considering to be 6 bit.

The other way I was thinking it could be done:
(1) Store the gamut/gamma calculations for a 6bit to 16bit lut.
(2) Store a basic 8bit to 16bit lut without any corrections.
(3) Convert your 6bit calculations to 8bit without dither
(4) Apply converted gamut/gamma calculations to your basic 8bit to 16bit lut.
(5) Save your final 96MB 3dlut.

In this way you retain the full 8 bit data, but only apply gamut/gamma correction on the data 1x1x1 data in 4x4x4 chunks (6 bit accuracy). Do you understand? If not hopefully the extremely simplified explanation of the concept below for eight 8-bit points clears things up.

First column is the data point. Second is the size of the data point. Third is the correction. Forth is the 8-bit result after correction which would be converted to 16-bit. (yes, the below isn't really accurate for a 3dlut, yes, I left out conversion to 16 bit, to hard to type out...) Can you see the differentiation between the three methods I'm trying to make?

8 bit -> 16 bit
1 (1x1x1) +2 = 3
2 (1x1x1) +3 = 5
3 (1x1x1) +5 = 8
4 (1x1x1) +8 = 12
5 (1x1x1) +11 = 16
6 (1x1x1) +12 = 18
7 (1x1x1) +15 = 22
8 (1x1x1) +16 = 24

6 bit -> 16 bit
1 (4x4x4) +4.5 = 5.5
....................= 5.5
....................= 5.5
....................= 5.5
5 (4x4x4) +13.5 = 19.5
......................= 19.5
......................= 19.5
......................= 19.5

8 bit -> 16 bit (6 bit gamut/gamma)
1 (1x1x1) +4.5 = 5.5
2 (1x1x1) +4.5 = 6.5
3 (1x1x1) +4.5 = 7.5
4 (1x1x1) +4.5 = 8.5
5 (1x1x1) +13.5 = 18.5
6 (1x1x1) +13.5 = 19.5
7 (1x1x1) +13.5 = 20.5
8 (1x1x1) +13.5 = 21.5


For a long time I've suspected my bottleneck is the pixel processing power for 256x256x256 color corrections, rather than processing a 256x256x256 LUT itself. In other words, the number of unique pixels which require color corrections is too great when two or more near-100% saturated colors are on screen. If you could make a 256x256x256 LUT with only 64x64x64 color corrections, that would be preferable to a 64x64x64 LUT with 64x64x64 color corrections. If luck would have it, that will resolve my bottleneck while retaining the higher quality.

[tschi]

@TheElix : did you try "restore default settings.bat" and set again your ycms data ? You can also try to generate manually your 3dlut files with ycms but anyway, currently madVR doesn't work well with 3dlut

[cyberbeing]

TheElix, have you set write permissions to the madVR directory? If you placed madVR in Program Files on Win7, you'll need to edit the permissions to allow non-Administrative write access. That could certainly cause creation of a 3dlut to fail, but it's just a guess.

madshi, on that note you should probably change the following line:
(1) Unzip "madVR.zip" and copy the folder to a suitable place (e.g. Program Files).
to
(1) Unzip "madVR.zip" and copy the folder to a suitable place with USERS write access (e.g. My Documents).

[TheElix]

@TheElix : did you try "restore default settings.bat" and set again your ycms data ? You can also try to generate manually your 3dlut files with ycms but anyway, currently madVR doesn't work well with 3dlut
Nah, I still wasn't able to create the 3dlut file with madVR. I guess I'll just wait for madshi to fix 3dlut issues.
Also, I created two 3dlut files (hd - pc.3dlut & sd - pc.3dlut) using yCMS and specified it in madVR, but it gave me the following error for either of them:
"This 3dlut file does not match the input format required by madVR."
Here's a config file I used to create hd - pc.3dlut:
# Example input file for yCMS v1.0 and up
#
# Settings for creating a 3DLUT file for watching the following Video formats:
# Blu-ray, HD DVD, ATSC HD Broadcast, DVB HD Broadcast
# without any Display correction
# Includes YCbCr->RGB conversion using PC Levels (Black: 0 and White: 255)

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# Grayscale calibration
Grayscale_Measurements
20 1 5.210 0.309 0.329
30 1 11.808 0.314 0.331
40 1 21.633 0.314 0.333
50 1 35.625 0.314 0.332
60 1 53.377 0.314 0.331
70 1 73.243 0.312 0.328
80 1 99.744 0.312 0.326
90 1 129.090 0.312 0.327
100 1 162.966 0.312 0.326

# Gamut calibration
Gamut_Measurements 1
36.994 0.644 0.335
114.868 0.299 0.602
13.224 0.145 0.063
162.966 0.312 0.326

[yesgrey]

You'll need to explain the the differentiation you are making between converting and considering to be 6 bit.
An 8 bit source video has values that go from 0 to 255. A 6 bit source video has values that go from 0 to 63. THe external application that uses the 3DLUT (in this case madVR), would be responsible to correlate the 8 bit source video with the 6 bit input 3DLUT. madVR does it using trilinear interpolation.

In this way you retain the full 8 bit data, but only apply gamut/gamma correction on the data 1x1x1 data in 4x4x4 chunks (6 bit accuracy). Do you understand?
Yes, I understand, but it would not be worth it. What you are proposing is to create a 6 bit input 3DLUT storing it into an 8 bit one. The way you are proposing would be by using trilinear interpolation, so, if madVR is already doing it, why wasting the extra memory needed to store and manipulate an 8/16 3DLUT? You would get the exact same results using madVR, whether you use a 6/16 3DLUT, or your proposed 8/16 3DLUT.


6 bit -> 16 bit
1 (4x4x4) +4.5 = 5.5
....................= 5.5
....................= 5.5
....................= 5.5
4 (4x4x4) +13.5 = 15.5
......................= 15.5
......................= 15.5
......................= 15.5


I think your example is not correct... Wouldn't you want to say:
1 (4x4x4) +4.5 = 5.5
....................= 5.5
....................= 5.5
....................= 5.5
5 (4x4x4) +13.5 = 18.5
......................= 18.5
......................= 18.5
......................= 18.5

[tschi]

@TheElix, you need yRGB RGB_Video input & output like
# Set input format
Input_Format yRGB RGB_Video 8

# Set output format
Output_Format yRGB RGB_Video 16

[madshi]

so.... how do i use Ycms now??? completely lost
Do you have a meter to measure your display? If not, yCMS will not help you.

Yes that´s it, if I add "Output_Format HD RGB_Video 16" it works, also files are identical except the part where the config file is stored (cause all settings of Output_Format are overridden by the other options).
Yeah, madVR is too stupid to understand that you didn't use "Output_Format" but replaced all its parts by separate commands. madVR requires Output_Format to be present, so it can double check you're using the correct bitdepth.

What`s wrong with madVR and 3dlut
Calibration via 3dluts doesn't work correctly with the latest madVR version. yesgrey and I are working on a fix.

Hello Madshi. Can i please request that there is an option in Display Modes in Madvr that stops Madvr switching to ones desired resolution/refresh-rate unless the Media Player is in full screen mode
Has been requested before, is on my to do list. No ETA.

So if we're not supposed to use rgb limited, then what is the purpose of madvr having a tv levels setting?
In your latter example, wouldn't madvr output 16-235 only to have it expanded by the video card on rgb full? Wouldn't you want to match up rgb limited and tv levels to stay at 16-235 all the way through? (And likewise rgb full + pc levels)? Just trying to understand.
The ATI switch names are not very good. Let me redefine them for you:

The ATI switch "RGB Full" really means: "leave all applications' RGB output untouched"
The ATI switch "RGB Limited" really means: "molest RGB output of all applications behind their back"

For best quality with madVR switch ATI to "RGB Full". Then you can switch between video/PC levels in madVR. You can switch video/PC levels with madVR without quality degradation.

If you have an ATI card that sends unmolested 0-255 then it depends on the capability of your display. For example, on my system with my 5830 through it's HDMI port feeding the signal to my Panasonic plasma HDTV, you can have it setup two correct ways:

Pixel Format: RGB Limited
MadVR: PC Levels

or

Pixel Format: RGB Full
MadVR: TV Levels

The latter should provide the best quality and gives full BTB + WTW same as my Blu-ray player provides.

The problem for me and using RGB Full is that my desktop and games look a bit off and there is black crush going on.
If desktop and games have black crush then you can't have full BTB with "RGB Full" and madVR TV levels, either. Seems to me that your display simply clips away some of the BTB data. That's sad, of course, but there's probably not much we can do about it... :(

Impression from newer madVRs. Tried 0.62 and Precision 3.
Watched 3 720 videos and 1 FullHD video. With FullHD video everything seems fine. If video has size < actual display size I can't get rid of impression that dynamic range is HUGE. I mean it looks like it's out of the range sometimes. I even had to change Luma scaler from Spline to SoftCubic50 and decrease contrast on my TV from 82 to 79. Didn't make mach comparisons with < 0.62 because it seems like I'm not the only one with similar impressions.
Hmmmm... I'm not sure from your description: Do you like the v0.62 image quality or rather not?

feature request: is it possible to add an option to madVR which disables the video card's 3x1D CLUT when madVR is active, and re-enables it when playback is finished?
Yes, this is on my to do list.

I'm sorry if this problem's been discussed before, but I get "Creating the 3dlut for the display Panasonic-TV failed" error when I try to use yCMS.
That's weird! Can you post the gamut and gamma measurements you're trying to use? Maybe yCMS doesn't like them? Not sure what else could be going wrong.

BTW, what's the preferable pixel format for my display, YCbCr or RGB?
Best output mode should be RGB 0-255, if your display properly supports it.

i am an ATi user & i am using CoreAVC software acceleration as long as DXVA is not supported with MadVR. i would like you to check some of my settings if possible.

should i change the output formats and output levels?
No, should be ok as it is.

@ ati catalyst control
pixel format is set to 4:4:4 FullRGB
Good.

madshi, I found an issue today playing any video file that has a higher frame rate than my display refresh, when in fullscreen exclusive mode. (trying some 60hz video files today with my display at 50hz)

The problem is that some frames seem to appear on screen in the wrong order, then I might get a few seconds of perfect playback, then another few seconds of glitchy backwards / forwards motion, as I say it looks like some frames come in the wrong order.

I narrowed the problem down to the enabling of the "run presentation in a seperate thread" option. With it off, the problem never happens, with it on, it seems to always happen. I'm using a GTX 295 in Wind 7 64bit. I have it turned off now and am 100% happy, just thought you should know. If you think I should report it over on the nvidia forums as a bug on their end I'll do so. I'm using madVR 0.65.
Can anybody else reproduce this?

FWIW, those tweak options like "run presentation in a separate thread" were added in order to fix presentation glitches. You should only enable these tweaks only if you really need them. Otherwise it's better to leave them off.

Could somebody tell us what happens with conversions and output levels settings?
When I set madvr in pc levels and catalyst pixel format fullrgb
I have very dark picture on my display like fairchild.
Then set madVR to "TV levels".

The problem wouldn't (5) or (7), it would potentially be (9). What does 'display corrected gamma' default to with gamma correction disabled? In the above example it should be 709 gamma, so there is no change from (1). Converting to anything else other than (1) in step (9) would result in a change of gamma.
The chain I described was for the situation where you provide yCMS with both gamut and gamma measurements. In that situation the 3dlut of course applies corrections for "bugs" in your display's measured gamma response.

Seeing the more detailed workflow you posted, it appears (2) became the functional replacement of 3dlut input_transfer_function in prior versions. In which case it would be (2), the curve you initially choose the linearize the video with, which would need to be tweak-able. The janos666 'special-tweak' would be setting (2) to your display gamma. I personally never did this, so I like it as you currently have it.
Changing the gamma curve in the madVR "Color & Gamut" settings tab has the same effect as changing either Gamma_Curve or Input_Transfer_Function with madVR v0.61. So this is already fully flexible. Which means: No loss in flexibility at all. All the things that are fixed in the connection between madVR <-> 3dlut are adjustable in runtime inside of madVR now. madVR has practically replaced some of the yCMS functionality. I still believe that there's no loss of flexibility worth mentioning for all real time video playback usage scenarios.

Interesting. Which software is this? Do you have a link?
PM me, if you want to know. Don't want to advertize a competitor of yesgrey here... :)

Just to confirm, this applies to RGB input as well? You should probably make a note of this in the Readme.txt or something.
Yes, it applies to everything. madVR has not reached version 1.0 yet. So madVR users have to live with certain limitations. And I won't list them all in the readme. Things change too fast for that to make sense.

Well I finally got around to testing today. I can't get 0.61 to match 0.65 when using a 8 bit 3dlut. It appears other people are having issues as well
Yes, there's a bug somewhere. yesgrey and I are working on it.

I don't know if this is good news or bad news. 8bit and 7bit had the bug, but 6bit didn't.
So with 6bit you have no stuttering? That's good news, at least.

Is this even worth it quality-wise? You'll need to explain how madVR deals with a 6 bit lut.
The professional photo industry commonly uses 3dluts with 17x17x17 input points, I've been told. madVR/yCMS 8bit 3dluts use 256x256x256 input points. With 7bit it's 128x128x128 input points, with 6bit 64x64x64. So even a 6bit madVR/yCMS 3dlut still has a higher resolution than what the professional photo industry commonly uses. I think that should put things nicely into perspective.

Technically, as yesgrey said, madVR uses trilinear interpolation. Consider an 8bit 3dlut as being a big cube consisting of 256x256x256 little subcubes. So there are 256 * 256 * 256 junction points, at most of which 8 cube corners meet. At each of these junction points there's a data value stored. The 3D coordinate of a junction point is the input RGB value. The data value stored at that junction point is the RGB output value. Now if you feed a simple 8bit video into this big cube, every pixel will hit exactly one of the junction points, resulting in a direct output value. Now imagine you feed 9bit video into this 8bit cube. Some video values will still hit junction points. But others will e.g. hit the middle of a subcube. No big problem, though. You can interpolate the correct output value, by calculating a weighted average of the 8 nearest junction points, taking the distance to the junction points into account. This is called "trilinear interpolation". GPUs do that almost for free.

Even though it fixes the rare 3dlut performance issue, I'm unsure this is the best answer to the problem. I hope it at least gives you an idea of what the bottleneck may be, and are able to come up with a higher quality solution.
The bottleneck is likely to be the texture cache of your GPU.

ps. I like the changes you made to settings dialog. Everything is much less confusing now. My only request would be duplicating the bit-depth selection for the 3dlut into the Calibration or yCMS tab so all the settings are in one place, and you can just click apply to create it when done.
Glad you like the changes. I've thought about putting the 3dlut bitdepth setting into the yCMS tab, too. But then I decided against that because it would take space away for the gamma measurement list. Furthermore it truely is a "trade quality for performance" option and should only be used if you need to trade quality for performance. I think there are arguments for both locations for this option. But I think I prefer it where it is right now.

Is it possible to have a standard 3dlut file for every single tv ?
Just like icc profiles for pc monitors?
E.g. Pqnasonicvt30.3dlut , lgpk550.3dlut etc

I think 90% of users would be very pleased with a standard calibrated setting.
You mean a database where users upload 3dluts they have created for their displays? The problem with this is that the measurements of your display will vary VERY MUCH depending on how your display is configured. E.g. change brightness, contrast, saturation, color, whatever settings even slightly and measurements (and thus the 3dlut file) will change noticeably. So I rather doubt that such an uploaded 3dlut file would really work well for other users of the same display - unless you 100% match all display settings. But even then, I've heard of manufacturers changing from one LCD panel manufacturer to another panel manufacturer in the middle of a product lifetime. So I doubt this would really work...

features request : shortcut configurable
Already on my to do list.

why do I only get black video image(actually no video image,but sound) with madvr 0.65,when I choose "calibrate this display by using yCMS" function. However I get normal video image with madvr 0.61 by using yCMS,This is why?
virtually I don't understand at all how I should setup the parameters of yCMS ,so I setup the parameters of yCMS random,the result is that I get no video image(black screen),what should I do for perfect video image?
Random parameters won't work. The black video is probably a result of those random values. If you want to use yCMS, you need to have a meter to measure your display. If you have a meter and don't know how to get the values needed for yCMS then please ask in the yCMS thread.

TheElix, have you set write permissions to the madVR directory? If you placed madVR in Program Files on Win7, you'll need to edit the permissions to allow non-Administrative write access.
Actually, madVR is cleverer than that. If there's no write access to the current folder, yCMS is downloaded and installed to "user\local application settings\madVR\...".

Also, I created two 3dlut files (hd - pc.3dlut & sd - pc.3dlut) using yCMS and specified it in madVR, but it gave me the following error for either of them:
"This 3dlut file does not match the input format required by madVR."
Here's a config file I used to create hd - pc.3dlut:
madVR v0.62+ needs specific parameters. Please do a search for "yRGB", if you want to know the exact details.

[TheElix]

That's weird! Can you post the gamut and gamma measurements you're trying to use? Maybe yCMS doesn't like them? Not sure what else could be going wrongHere: http://rghost.ru/10309331/image.png
In plain text:
red, Yxy, 36.994, 0.644, 0.335
green, Yxy, 114.868, 0.299, 0.602
blue, Yxy, 13.224, 0.145, 0.063
white, Yxy, 162.966, 0.312, 0.326

20, Yxy, 5.210, 0.309, 0.329
30, Yxy, 11.808, 0.314, 0.331
40, Yxy, 21.633, 0.314, 0.333
50, Yxy, 35.625, 0.314, 0.332
60, Yxy, 53.377, 0.314, 0.331
70, Yxy, 73.243, 0.312, 0.328
80, Yxy, 99.744, 0.312, 0.326
90, Yxy, 129.090, 0.312, 0.327
100, Yxy, 162.966, 0.312, 0.326
madVR v0.62+ needs specific parameters. Please do a search for "yRGB", if you want to know the exact details.tschi has already pointed at my mistake, and it worked. :) I'm able to use the 3rd option for now (to calibrate using an external 3DLUT file).

And if my Panasonic PDP doesn't support Full RGB, which pixel format should I use and what levels should I use in video driver, in renderer settings?

[madshi]

In plain text: [...]
Weird. 3dlut creation works for me with those numbers. Don't really know what's going wrong for you...

And if my Panasonic PDP doesn't support Full RGB, which pixel format should I use and what levels should I use in video driver, in renderer settings?
That's a misunderstanding. Pretty much all TVs support RGB input. It's just that many of them expect black to be at value 16 and not at value 0. If you switch your GPU to "Full RGB" and your display can't be switched to expect black at value 0, then your desktop and applications and games will look too dark. But you can still use madVR that way, you just have to switch madVR to "TV levels". The GPU will then output 0-255, but madVR will make sure that it renders black to value 16, so that your display is happy. So even if your display doesn't support 0-255 input, it still does support your GPU being set to "RGB Full" as long as you switch madVR to TV levels. But, as I said, with that setup games and applications will have black crush.

[TheElix]

But, as I said, with that setup games and applications will have black crush.Blacks are crushed only when I choose 4:4:4 Full RGB. In all other cases (4:4:4 Limited RGB, 4:4:4 YCbCR and 4:2:2 YCbCr) the picture seems normally calibrated. You suggest that in order to watch videos I have to switch to FullRGB? That's problematic. I don't want to switch back and forth every time I want to watch something. Currently I use 4:4:4 YCbCR with 0-255 levels set everywhere and the picture seems fine. Let me change the question: which is more preferable of the other three?

[madshi]

which is more preferable of the other three?
Don't know, I don't test anything other than what is optimal for image quality.

[pankov]

TheElix
have you tried setting RGB Full and change your brightness and contrast in the same time?
Do you see the missing dark shade detail or you simply get brighter blacks but still no detail?
You can/should use some test patterns which show grey scale ramp from 0 to 255 with at least levels 16 and 232 marked out.

[pankov]

madVR v0.64 released
...
* seekbar is now shown only if mouse cursor is on playback monitor
...

madshi,
I'm sad to report that the second part of problem 2 that I reported here
http://forum.doom9.org/showpost.php?p=1496219&postcount=7453
is still present - moving the mouse anywhere on the secondary monitor still forces the seebar to show up.

[fairchild]

If desktop and games have black crush then you can't have full BTB with "RGB Full" and madVR TV levels, either. Seems to me that your display simply clips away some of the BTB data. That's sad, of course, but there's probably not much we can do about it... :(

I've verified that I do. When using RGB Full in CCC + TV levels in MadVR I get full flashing bars from 2-25 (once I adjust my Brightness up, obviously a properly calibrated display will only show 17-25 once it's configured properly) and shows full WTW flashing bars from 230-252. This is verified with the AVS HD 709 calibration disc.

When I use RGB Full in CCC + PC levels in MadVR, that's when I get no BTB/WTW. Basically, no matter how high I set my brightness (calibrated is 60, have to go to 77 to get rid of the black crush and get proper 17-25 black bars flashing), I never get anything below 17 to flash. WTW gets clipped and only gives 230-234 flashing bars on the White clipping pattern.

So my display doesn't give BTB/WTW info with RGB Full and MadVR PC levels, which might explain why things look off and I get black crush during gaming (even after properly setting the brightness and bringing it up to get no clipping from 17-25 on the Black clipping pattern).

The weird thing is, when I use EVR (with Output Range 0-255) and select the Input Range in ffdshow as Full Range (Y :0-255, CbCr :16-240) then I get full BTB and WTW with properly calibrated settings on my TV (I don't have to change the brightness or anything). But this still doesn't help my situation with the desktop being crushed and having to adjust the brightness up when I want to game and possibly have some lost detail.

For now I've just dealt with using RGB Limited + TV levels so I don't have to fuss with changing back and forth settings. This is of course not going to give me optimal image quality, but IMO the visual quality difference is most likely neglible to my eyes and ultimately I love MadVR for it's unparalleled smoothness + ycms. :devil:

[TheElix]

or you simply get brighter blacks but still no detail?This. I'm able to get some detail, but not as perfectly as with Limited RGB (I'm able to distinguish 1-2 from 0 at Limited RGB but only 7-8 with Full RGB).

[Neeto]

madshi you are seriously good!
I'm getting very good uplifts in the WAF (Wife Approval Factor) - there is no higher praise ;-)

Given the recent intenstive discussions on color correction etc, I think I might be able to get some guidance on something that I've long wanted to ask.

To watch movies, MPC-HT is invoked from Window Media Center via My Movies & with 3DLUT support & display calibration it's all good picture quality :-)

But the splitter/decoder/render chain is DMO etc when watching live TV in Windows.

This is the "family" HTPC onto a 50" Panasonic PDP and needs to service "never logged onto a PC but have perfect eye sight" users.
i.e. no custom Live view TV apps! So I'm stuck using Media Center for Live TV viewing & thus the DMO chain.

Windows 7 added automatic custom ICC Profile loading
Control Pannel->All Control Pannel Items->Display->Screen Resolution->Advanced Settings->Color Management->Color Management

And this is processed in the video card - right?
What if any limitations does this have compared to what is done madVR with yCMS/3DLUTs?

So given that I want best picture in BOTH MPC-HT and standard windows 7 DMO chains, would it be best to:

1. Calibrate display as best as possible
using the standard ICC profile is "sRGB IEC61966-2.1" via the standard DMO windows chain
Is sRGB IEC61966-2.1 the correct profile?

2. Then create a "Panasonic 50 model xxx" custom ICC profile and assign this as the default ICC Profile for the display device in windows color management using standard DMO windows chain
Recommendations on how to create & what tools the customer ICC Profile for auto loading by Windows7 Color Managament? I have an Eye One.

3. Then calibrate again and get another set of primary measures for madVR/yCMS using MPC-HT, ffdshow, madVR chain

Windows 7 DMO chain will use 1 & 2.
MPC-HT will use 1, 2 & 3.

If I'm lucky I won't need 2 or 3 because I'll be able to perfectly calibrate my display? (I live in hope)
And I might not need 3 because 1 & 2 will give me a correct picture
But in reality I'll need all 1, 2 & 3?

The standard windows DMO chain seems to want to output TV levels, even with FullRGB set in CCC.
This if is fine a picture/jpg display & desktop seem to be fine.
And I can set TV Levels in madVR and get everything correct.

[pacemaker1000]

anybody find a fix for the horrible green bar and colours being off you get with certain mp4 videos when switching refresh rate while loading

loading another file before hand, in other words changing refreesh first, solves the problem

[suanm]

Hi madshi & yesgray
To me playback doesn't drop frames or isn't stuttering & stammering any longer for no use calibration function with madvr 0.65 version.This is very great.But no use yCMS calibration function will make video image quality reduced.I want to use yCMS function,But I don't know how to setup values of yCMS parameter,I don't have any of instruments or meters to test RGB on my displayer.what will I do?

[madshi]

madshi,
I'm sad to report that the second part of problem 2 that I reported here
http://forum.doom9.org/showpost.php?p=1496219&postcount=7453
is still present - moving the mouse anywhere on the secondary monitor still forces the seebar to show up.
Playback on primary, mouse on secondary?

I've verified that I do. When using RGB Full in CCC + TV levels in MadVR I get full flashing bars from 2-25 (once I adjust my Brightness up, obviously a properly calibrated display will only show 17-25 once it's configured properly) and shows full WTW flashing bars from 230-252. This is verified with the AVS HD 709 calibration disc.

When I use RGB Full in CCC + PC levels in MadVR, that's when I get no BTB/WTW. Basically, no matter how high I set my brightness (calibrated is 60, have to go to 77 to get rid of the black crush and get proper 17-25 black bars flashing), I never get anything below 17 to flash. WTW gets clipped and only gives 230-234 flashing bars on the White clipping pattern.
When you set madVR to PC levels, madVR renders black to 0 and white to 255. RGB does not support negative values, so BTB and WTW are automatically cut off. Setting madVR to PC levels means that it's impossible to transport BTB/WTW to the display. That is bad if you want to check calibration stuff, but it's not a big problem (if any at all) for real movie watching since BTB/WTW are not supposed to be seen, anyway.

This has nothing to do with games, though. If you can make all 16-235 bars visible with madVR and GPU set to PC levels, then you should see all game information, too. However, it's possible that modifying the display brightness/contrast options so much could screw up the gamma response somehow.

For now I've just dealt with using RGB Limited + TV levels
RGB Limited + TV levels means double expansion for video. With this setup video black should be brighter (more grey) than games black.

Given the recent intenstive discussions on color correction etc, I think I might be able to get some guidance on something that I've long wanted to ask.
For strictly calibration related questions it'd be better to ask in the yCMS thread. I can't answer most of those questions.

anybody find a fix for the horrible green bar and colours being off you get with certain mp4 videos when switching refresh rate while loading
Have you tried a different decoder?

But no use yCMS calibration function will make video image quality reduced.I want to use yCMS function,But I don't know how to setup values of yCMS parameter,I don't have any of instruments or meters to test RGB on my displayer.what will I do?
The main purpose of yCMS is to fix imperfections in your display. In order to do that yCMS first needs to know if your display has any imperfections and what they are exactly. There's no way for you to tell yCMS that without having a meter. So if you don't have a meter, you simply can't use yCMS. End of story.

[WontonNoodle]

so for madvr pre 0.61, how did ycms work??? (I dont have a meter)

[madshi]

so for madvr pre 0.61, how did ycms work??? (I dont have a meter)
With older madVR versions you could activate a 3dlut, but without a meter yCMS just performed some rather simple conversions. These simple conversions are now performed by madVR instead in real time via pixel shaders in the same quality. So with newer madVR versions using yCMS doesn't bring any benefit, anymore, if you don't have a meter. From now on yCMS is only for people who have a meter (or who know the exact primary coordinates of their display).

So to sum up:

If you don't have a meter, don't use yCMS. There's no need to. madVR does all that you need in the same quality.

If you do have a meter, use yCMS to calibrate/optimize your display.

[kostik]

I have a question about pixel format.
How do I know that when I choose Full RGB , my card is really outputting full RGB?
When I choose full RGB it looks I get strong white and black. But when I choose Limited it seems to be more brighter and less "PUNCHY" like RGB FULL.

[e-t172]

Windows 7 added automatic custom ICC Profile loading
Control Pannel->All Control Pannel Items->Display->Screen Resolution->Advanced Settings->Color Management->Color Management

And this is processed in the video card - right?
What if any limitations does this have compared to what is done madVR with yCMS/3DLUTs?

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

So given that I want best picture in BOTH MPC-HT and standard windows 7 DMO chains, would it be best to:

1. Calibrate display as best as possible
using the standard ICC profile is "sRGB IEC61966-2.1" via the standard DMO windows chain
Is sRGB IEC61966-2.1 the correct profile?

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.

2. Then create a "Panasonic 50 model xxx" custom ICC profile and assign this as the default ICC Profile for the display device in windows color management using standard DMO windows chain
Recommendations on how to create & what tools the customer ICC Profile for auto loading by Windows7 Color Managament? I have an Eye One.

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.

3. Then calibrate again and get another set of primary measures for madVR/yCMS using MPC-HT, ffdshow, madVR chain

Windows 7 DMO chain will use 1 & 2.
MPC-HT will use 1, 2 & 3.

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.

[madshi]

I have a question about pixel format.
How do I know that when I choose Full RGB , my card is really outputting full RGB?
When I choose full RGB it looks I get strong white and black. But when I choose Limited it seems to be more brighter and less "PUNCHY" like RGB FULL.
Best way is probably to test with some kind of calibration test video which has BTB sections.

[pankov]

Playback on primary, mouse on secondary?

No, playback on the secondary and mouse anywhere on the secondary, not only at the bottom where it's supposed to popup the seekbar.

Sorry for not being clear enough
:o

[Andy o]

This. I'm able to get some detail, but not as perfectly as with Limited RGB (I'm able to distinguish 1-2 from 0 at Limited RGB but only 7-8 with Full RGB).

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.

[suanm]

With older madVR versions you could activate a 3dlut, but without a meter yCMS just performed some rather simple conversions. These simple conversions are now performed by madVR instead in real time via pixel shaders in the same quality. So with newer madVR versions using yCMS doesn't bring any benefit, anymore, if you don't have a meter. From now on yCMS is only for people who have a meter (or who know the exact primary coordinates of their display).

So to sum up:

If you don't have a meter, don't use yCMS. There's no need to. madVR does all that you need in the same quality.

If you do have a meter, use yCMS to calibrate/optimize your display.

:thanks:madshi,I see finally .understand generally basic working principle for newer madvr.:thanks:again

[Shah Jahan]

After updating to 0.65 I'm having a problem, please help!

In the calibration option, if I select yCMS is asks me to provide gamut. What is that?!
If I select 3DLUT file, then from the previous version of madVR, I had HD-PC and DD-PC 3DLUT files, I point madVR to that file and it says: This 3dlut file does not match the input format required by madVR.

What should I do? Please help!

[cyberbeing]

Changing the gamma curve in the madVR "Color & Gamut" settings tab has the same effect as changing either Gamma_Curve or Input_Transfer_Function with madVR v0.61. So this is already fully flexible.
...
I still believe that there's no loss of flexibility worth mentioning for all real time video playback usage scenarios.
This is only half-true, when you assume Grayscale_Measumrents is always used, and/or you want to apply gamma correction.

What you seem to be missing is that Input_Transfer_Function is only used when linearizing the video for color correction and then reapplying the same gamma. In other words, no change in gamma, but color correction would have a different effect on the changed linear data. In other words, assuming the video was encoded with the gamma of the mastering monitor, instead of a assumed REC709 curve. janos666 reported better results by linearizing the video for color-correction with the same gamma as his monitor. If you should actually be doing this is an entirely different question, but it wouldn't hurt for the curve madVR linearizes with to be toggleable when no gamma adjustments are being made. Just make extra care to ensure it, by default, uses the same output gamma, so no gamma adjustment takes place in the final steps when the initial linearizing gamma is changed.

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? I'm still trying to wrap my head around madVR linearizing data, changing the gamma, feeding the 3dlut, re-linerizing the gamma, and putting it back to the original gamma.

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, 709 gamma

VS.

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 709 gamma
3dlut:
(6) input = 8bit float R'G'B', yRGB primaries, pure power 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

AND

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

Should have slight differences, since gamut adaption is done taking gamma into account.

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:

madVR:
(1) input = 8bit Y'CbCr, 709 primaries, 709 gamma
3dlut:
(6) input = 8bit Y'CbCr, 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

This should also be faster since there are less shader operations. Is there really a purpose of off-loading steps (2), (3), (4), and (5) to shaders when using a 3dlut? I guess it goes back to only wanting to use a single 3dlut for this yRGB stuff? Is having a yRGB 3dlut for each input format (709, 601, PAL) really a problem? Is this defeating the purpose of using yRGB? They take hardly any disk space, and they load quick enough.

PM me, if you want to know. Don't want to advertize a competitor of yesgrey here... :)
I think I found it, if you are talking about that application in closed beta. Seem to have a different focus then my current needs, and appears it will eventually be a payed application.

What would be really cool is if someone created a patch which modified the colprof codebase from Argyll CMS to output a 3dlut using it's XYZ LUT calculations, rather than a ICC profile, using a standard Argyll CMS workflow.

Getting a proven fully-featured 3dlut CMS functionally (unlimited color patches taken into account) is still something we really need. yesgrey has said he'll eventually get around to adding such functionally, but it would be really nice to see something as the above with 3dlut creation hooking into a traditional CMS from the likes of Argyll, Basiccolor, Coloreyes, etc. Argyll being free, open-source, widely used, and trusted quality in the professional industry, seems the best bet.

It's a bug, and madshi is working on it.Yes, there's a bug somewhere. yesgrey and I are working on it.
Since it only had an major effect on my RED primary (which lies on the gamut triangle edge), and not BLUE and GREEN (which lie outside the gamut triangle and need to be shifted), hopefully the bug isn't hard to track down.

It seems one of two things are happening. (1) You are just missing some code for detecting and dealing with gamuts smaller than that target gamut. (2) You are shifting the x and y values separately, ignoring the effect one has on the other. The code may be skipping x value as not needing adjustment, but then the y value is shifted without considering the detrimental effect on x value.

No doubt you and yesgrey will be able to figure it out, even if it's more complex than that.

So with 6bit you have no stuttering? That's good news, at least.
It seems to fix frame drops != stuttering.

I'm making that distinction because 0.62+ may (unconfirmed) have introduced some vsync stuttering (slight flickering in windowed mode) or other performance issues (had heavy dropped frames downscaling 1080p with Spline64). I say may since I've hardly done any testing with the new builds so far. I'm waiting for the 3dlut fixes before I do any serious testing and evaluations. For the time being take these reports with a grain of salt, since they were only impressions from watching less than 10 seconds of video. If there is a real (confirmed) regression in these respects from 0.61 and not just my imagination, I'll be sure to report it after I do serious testing...


An 8 bit source video has values that go from 0 to 255. A 6 bit source video has values that go from 0 to 63. The external application that uses the 3DLUT (in this case madVR), would be responsible to correlate the 8 bit source video with the 6 bit input 3DLUT. madVR does it using trilinear interpolation.
The professional photo industry commonly uses 3dluts with 17x17x17 input points, I've been told.
...
I think that should put things nicely into perspective.
...
Technically, as yesgrey said, madVR uses trilinear interpolation.
...
You can interpolate the correct output value, by calculating a weighted average of the 8 nearest junction points, taking the distance to the junction points into account. This is called "trilinear interpolation". GPUs do that almost for free.Yes, I understand, but it would not be worth it. What you are proposing is to create a 6 bit input 3DLUT storing it into an 8 bit one. The way you are proposing would be by using trilinear interpolation, so, if madVR is already doing it, why wasting the extra memory needed to store and manipulate an 8/16 3DLUT? You would get the exact same results using madVR, whether you use a 6/16 3DLUT, or your proposed 8/16 3DLUT.

It seems my lack of understanding of the technicalities of how "trilinear interpolation" works is this case was where I was getting stuck. If it is indeed works as my 8 bit -> 16 bit (6 bit corrections) example does, then the quality should be 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. Unless the quality loss is extremely visible, it shouldn't be a big deal either way. I'll eventually upgrade my GPU after-all, at which point I'll no longer need to worry about it.

I think your example is not correct...
Oops... I originally had it as 1 & 2 in the first column without listing the other 4x4 entries (why the math was how it was). At the end I decided to show them individually without re-doing the basic math. FIXED.

[madshi]

Removing steps and having the 3dlut do the conversion from Y'CbCr to RGB, as well as REC709 primaries to yRGB makes more sense to me when using a 3dlut
It should end up with the same data. We've moved the processing to madVR to be able to switch between different gamuts and gamma curves on the fly. Just imagine you want to support NTSC, HD and PAL content at the same time, as well as having the option to achieve a gamma curve of 2.2, 2.3 and 2.4. For that you'd need nine (!!) 3dlut files. And every time you switch, madVR would have to reload a 96MB file.

What would be really cool is if someone created a patch which modified the colprof codebase from Argyll CMS to output a 3dlut using it's XYZ LUT calculations, rather than a ICC profile, using a standard Argyll CMS workflow.
Developers are welcome to create such a software. Things like this is what we made the 3dlut specification public and free for.

[cyberbeing]

It should end up with the same data.
It should end up with slightly improved gamut correction, since it is taking the correct gamma into account. Your conversion to a 2.2 power-curve is resulting in the 3dlut doing corrections on the linear data with the assumption it is 2.2 gamma, instead of 709 gamma (in this case). It doesn't matter if to put it back how it was after the fact, it should still have an effect for any color corrections done.

We've moved the processing to madVR to be able to switch between different gamuts and gamma curves on the fly. Just imagine you want to support NTSC, HD and PAL content at the same time, as well as having the option to achieve a gamma curve of 2.2, 2.3 and 2.4. For that you'd need nine (!!) 3dlut files. And every time you switch, madVR would have to reload a 96MB file.
Aside that loading a 96MB file normally takes only 1 second on a modern hard drive, there would be no need for NINE 3dluts. Only one to three, depending on the video content you watch. Gamma correction could still be done via shaders.

[madshi]

It should end up with slightly improved gamut correction, since it is taking the correct gamma into account. Your conversion to a 2.2 power-curve is resulting in the 3dlut doing corrections on the linear data with the assumption it is 2.2 gamma, instead of 709 gamma (in this case). It doesn't matter if to put it back how it was after the fact, it should still have an effect for any color corrections done.
Ok, gotta admit I wasn't 100% truthful in my original description of the madVR v0.61 -> 3dlut chain. Actually madVR uses the desired transfer function (Color & Gamut) to convert from R'G'B' to RGB, similar to Janos666's solution, and similar to what newer yCMS versions do. Or if you disable gamma processing, madVR uses the display transfer function (Calibration). I didn't explain this earlier in order to make things not even more complicated and hard to understand than they already are. But now I see it was wrong to try to avoid this complication. Sorry about that. Anyway, if you view the combined madVR + yCMS processing steps as one chain with both v0.60 and v0.61, the whole chain is virtually unchanged. It's just that some processing steps moved from yCMS/3dlut to madVR.

Aside that loading a 96MB file normally takes only 1 second on a modern hard drive, there would be no need for NINE 3dluts. Only one to three, depending on the video content you watch. Gamma correction could still be done via shaders.
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.