madVR - high quality video renderer (GPU assisted)

[fairchild]

Originally Posted by ced007

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]

Originally Posted by xv

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.

Originally Posted by e-t172

(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]

Originally Posted by oddball

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]

Originally Posted by madshi

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.

Originally Posted by madshi

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.

Originally Posted by madshi

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?

Originally Posted by madshi

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.

Originally Posted by madshi

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.

Originally Posted by madshi

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.


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.

Originally Posted by madshi

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]

Originally Posted by cyberbeing

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.


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/...32w/index.html
http://www.eizo.com/global/products/...221/index.html
http://h10010.www1.hp.com/wwpc/uk/en...1-3648397.html

[Andy o]

Originally Posted by fairchild

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


Here is Photoshop's ICC color management. (very similar to madVR 0.61 /w 3dlut)
RED Primary 0.622968x 0.341998y


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 :

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
Thank you for your consideration `

Edit : Never mind, I found a workaround with evenghost

[6233638]

Originally Posted by 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.

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.

Originally Posted by cyberbeing

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

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.

[e-t172]

Originally Posted by 6233638

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_m...ndering_intent
http://www.cambridgeincolour.com/tut...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]

Originally Posted by e-t172

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_m...ndering_intent
http://www.cambridgeincolour.com/tut...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.

Originally Posted by 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 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)


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]

Originally Posted by fairchild

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.

Originally Posted by Andy o

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]

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

I unfortunately see no improvement from madVRprecision1, madVRprecision2, or madVRprecision3.

It's a bug, and madshi is working on it.

Originally Posted by cyberbeing

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

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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

Originally Posted by Portioli

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]

Originally Posted by yesgrey

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