Log in

View Full Version : yCMS - Color Management System


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17

yesgrey
27th June 2011, 22:48
What I can say is that madVR does not have any out-of-gamma specific processing at all while I know that yCMS has some sort of out-of-gamma special handling.
Correct. That's why we are still working to correct the problems with the yRGB idea. This is an interim solution until we sort out all the problems with yRGB. However, for people whose displays have gamuts wider than BT.709, PAL and NTSC, the current method does not affect them negatively, because there would be no out of gamut colors to handle.;)

cyberbeing
27th June 2011, 22:49
Fixed. Otherwise is that how things are working in madVR 0.66 yesgrey?

yesgrey
27th June 2011, 22:51
Fixed. Otherwise is that how things are working in madVR 0.66 yesgrey?
If I only pointed an error in (7) what do you think?... ;)
Yes.

cyberbeing
27th June 2011, 22:51
This is an interim solution until we sort out all the problems with yRGB. However, for people whose displays have gamuts wider than BT.709, PAL and NTSC, the current method does not affect them negatively, because there would be no out of gamut colors to handle.;)
So this means that for displays with a gamut smaller than the source video gamut, no correction is done in madVR 0.66?

fairchild
30th June 2011, 14:52
Thanks yesgrey and madshi for your work on yCMS + MadVR, new version is working good again.

Can I get a clarification because I think I've confused myself. What is the correct method to setup MadVR + yCMS correctly when outputting from my HTPC to my Panasonic plasma through HDMI?

Do I first go into MadVR and set it up with: disable calibration controls for this display Then using my meter take readings being output by MadVR to my plasma and input those readings into MadVR + yCMS interface?

or

Do I just use the calibrated readings that I achieved by calibrating my plasma TV from my set-top blu-ray player?

I had been using the readings from the latter. (these settings have been providing good image quality for my set-top blu-ray player + my cable HDTV signal + HTPC output (all use HDMI so the settings works accross all devices)).

yesgrey
30th June 2011, 23:22
Do I first go into MadVR and set it up with: disable calibration controls for this display Then using my meter take readings being output by MadVR to my plasma and input those readings into MadVR + yCMS interface?

or

Do I just use the calibrated readings that I achieved by calibrating my plasma TV from my set-top blu-ray player?

For now, both should give the same end result. However, just to be sure, you can measure the final results using madVR and the created 3DLUT and see if the calibration is OK.

Thunderbolt8
1st July 2011, 03:51
when trying to create and use an external 3dlut file for current madvr and ycms versions, are these lines still valid?

Input_Format yRGB RGB_Video 8
Input_Range 32 235

Output_Format HD RGB_Video 16
Output_Transfer_Function 4.5 0.099 0.405 0.018

edit: ok no. but that also doesnt work:


Input_Format yRGB RGB_Video 8
Input_Range 20 235

Output_Format yRGB RGB_Video 16

-.- so how can I now create a valid 3dlut file for madvr 0.66 which uses Input_range 20 235? Im always being told "This 3DLUT file does not match the input format required by madVR."

fairchild
1st July 2011, 05:37
For now, both should give the same end result. However, just to be sure, you can measure the final results using madVR and the created 3DLUT and see if the calibration is OK.

Thanks for the reply, I went ahead and re-measured tonight. My red primary which was over-saturated is now much closer to reference, while green is a bit under-saturated now and blue continues almost spot on too. It also improved my gamma response from an average of 1.71ish to an average of 2.11

So far so good. :thanks:

yesgrey
1st July 2011, 18:51
so how can I now create a valid 3dlut file for madvr 0.66 which uses Input_range 20 235? Im always being told "This 3DLUT file does not match the input format required by madVR."
See madshi instructions. I put a link on the second (http://forum.doom9.org/showthread.php?p=1402013#post1402013) post of this thread...

Thunderbolt8
1st July 2011, 20:38
I read that (which doesnt help me much, because its too complicated for me), but even when I copy his lines 1:1 in the input file, then I get the same error.

so something is missing or wrong, but I dont know what it is.

yesgrey
1st July 2011, 21:51
but even when I copy his lines 1:1 in the input file, then I get the same error.

so something is missing or wrong, but I dont know what it is.
post the file you're using so I can see...

Thunderbolt8
2nd July 2011, 01:35
Input_Primaries 0.640000000000000 0.330000000000000 0.300000000000000 0.600000000000000 0.150000000000000 0.060000000000000 0.31272661468101209 0.32902313032606195
Output_Primaries 0.640000000000000 0.330000000000000 0.300000000000000 0.600000000000000 0.150000000000000 0.060000000000000 0.31272661468101209 0.32902313032606195

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Gamut_Measurements 1
1.0 0.640000000000000 0.330000000000000
1.0 0.300000000000000 0.600000000000000
1.0 0.150000000000000 0.060000000000000
1.0 0.312726614681012 0.329023130326062
just copy & pasted the example madshi wrote to get it working somehow.

want to include Input_Range 20 235 at some point, but cannot get it to work with v0.66 even without it -.-

yesgrey
2nd July 2011, 13:44
just copy & pasted the example madshi wrote to get it working somehow.

want to include Input_Range 20 235 at some point, but cannot get it to work with v0.66 even without it -.-
You must be doing something wrong... I've tried creating a 3DLUT with your commands above and madVR v0.66 accepted it. It also accepted one with the 20 235 range like you want.

How are you creating the 3DLUT files? Are you using yCMS v1.11?

Thunderbolt8
2nd July 2011, 15:05
yes.

just the normal way as before, ycms input.txt output.3dlut
and thats it

edit: guess I found the problem, it was in those lines beginning with '#'
they used to be no problem in the past, but apparently now madvr doesnt like them any more. when I deleted those, it got accepted fine.

so whats the most basic command line I can do atm with the current madvr version?
basically, all I need is that input_range line added as only modification. everything else should remain the same/basic.

Input_Format yRGB RGB_Video 8
Output_Format yRGB RGB_Video 16

doesnt seem to work and madshis example line already seems to modify too much (or is this wrong perception?)

yesgrey
2nd July 2011, 16:50
so whats the most basic command line I can do atm with the current madvr version?
Only madshi can answer that, so I suggest you to stick with his example.


Input_Format yRGB RGB_Video 8
Output_Format yRGB RGB_Video 16

doesnt seem to work and madshis example line already seems to modify too much (or is this wrong perception?)
Yes. We are working to solve the problems with the yRGB idea. Currently nobody should use yRGB.

The code from madshi doesn't change anything. Stick to it. You can add your Input_Range 20 235 line if you want, though.

Thunderbolt8
2nd July 2011, 16:54
ok thanks.

afaik those format_input values have to be integer, meaning 20.something wont change anything compared to just 20, right?

yesgrey
2nd July 2011, 18:02
those format_input values have to be integer, meaning 20.something wont change anything compared to just 20, right?
Considering the majority of video sources are limited to 8 bit it would not make much sense. Furthermore, the effect would be negligible, so I prefer to keep it as simple as possible.

Mark_A_W
3rd July 2011, 02:08
The latest madVR version (v0.66) should now finally fix the problems introduced by the last couple releases:

http://madshi.net/madVR.zip

I've once again changed the 3dlut requirements. If you let madVR create the 3dlut for you then you can skip the rest of this post.

If you want to manually create a 3dlut, it should be created like this:

(1) input/output must be RGB video levels
(2) input bitdepth must be 6, 7 or 8 bits
(3) output bitdepth must be 16 bit
(4) input transfer function must be a 2.20 pure power curve
(5) input/output primaries must match the measured gamut
(6) input white point must be D65

madVR v0.66 will refuse to use external 3dluts with different bitdepths. It will also refuse to use external 3dluts which contain the text "RGB_PC" or "YCbCr", or which do *not* contain the "Input_Primaries" command.

Here's an example of how madVR v0.66 itself creates 3dluts now:

Input_Primaries 0.640000000000000 0.330000000000000 0.300000000000000 0.600000000000000 0.150000000000000 0.060000000000000 0.31272661468101209 0.32902313032606195
Output_Primaries 0.640000000000000 0.330000000000000 0.300000000000000 0.600000000000000 0.150000000000000 0.060000000000000 0.31272661468101209 0.32902313032606195

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Gamut_Measurements 1
1.0 0.640000000000000 0.330000000000000
1.0 0.300000000000000 0.600000000000000
1.0 0.150000000000000 0.060000000000000
1.0 0.312726614681012 0.329023130326062
Make sure you always replace the last two floating point numbers in "Input_Primaries" with "0.31272661468101209 0.32902313032606195", which is the D65 white point. For the "Output_Primaries" use the measured white point instead.

Please note that this is just the way it *currently* works. I might go back to yRGB sooner or later.

Hi madshi/yesgrey

I'm trying to get the new version working.

I have deleted and let madVR re-download yCMS.

- With 3D LUT created with previous version, I get an error that the 3D LUT does not contain primary colours info (yes it did!).

- After deleting the old 3D LUT, madVR is unable to create a new one. I get a "Creating the 3DLUT for the display blah blah failed" error.

The measurements are the same dodgy ones I had before - for testing only (I'm testing the robustness of your system ;) )

Primaries:

red, Yxy, 5.112, 0.628, 0.337
green, Yxy, 9.018, 0.294, 0.595
blue, Yxy, 1.672, 0.156, 0.078
white, Yxy, 10.833, 0.321, 0.342


Greyscale:

20, Yxy, 0.301, 0.338, 0.349
30, Yxy, 0.179, 0.316, 0.333
40, Yxy, 2.705, 0.311, 0.335
50, Yxy, 5.037, 0.311, 0.340
60, Yxy, 7.476, 0.315, 0.340
70, Yxy, 10.364, 0.320, 0.341
80, Yxy, 10.603, 0.320, 0.341
90, Yxy, 10.749, 0.321, 0.342
100, Yxy, 10.850, 0.321, 0.342


Any ideas? Do you want me to activate debug mode.bat? (How do you deactivate it?)

jmone
5th July 2011, 08:57
I see some posts on X-Rite ColorMunki's new "Display" model and that the output may/may not be compatible with madVR. Do I buy this or the older "Photo" model?
Thanks
Nathan

salora
11th July 2011, 20:11
hi there
I've been following this and using madvr for a while, and I bought an eye one display to use the calibration option

so I took measurements with hcfr colorimeter and entered the data in madvr ycms tool

but everything is getting worth, my reds are more pink for example

it seems ycms and 3Dlut are working in the opposite way than they must do

anyone can help please?

regards

yesgrey
11th July 2011, 21:56
anyone can help please?
Post your measurements and your yCMS config file. If you could also send me your hcfr results file it would be even better.

salora
12th July 2011, 00:03
thank u yesgrey so here is the hcfr measurements, how can I send u the file?

greyscale measurements


% Grey 0 10 20 30 40 50 60 70 80 90 100
X 0,235968 0,346697 0,566339 0,904434 1,213372 1,58459 2,04543 2,568081 3,115475 3,75879 4,413152
Y 0,16129 0,282778 0,518842 0,889592 1,267085 1,706788 2,239217 2,865244 3,515726 4,262369 5,026543
Z 0,242194 0,370251 0,609809 0,974333 1,336218 1,782859 2,307657 2,922225 3,578988 4,326621 5,078697
R 0,396007 0,504242 0,733708 1,077692 1,318141 1,622528 2,035843 2,460827 2,90737 3,471629 4,042527
G 0,083929 0,209838 0,449758 0,832732 1,256504 1,740141 2,314111 3,007493 3,72452 4,532751 5,363346
B 0,236241 0,352984 0,570277 0,898782 1,221501 1,624586 2,096359 2,647369 3,239371 3,91315 4,588663


gamut


Measure Red Green Blue Yellow Cyan Magenta
X 2,183501 1,471347 1,007507 3,462801 2,463016 3,017612
Y 1,289556 2,713232 0,629746 4,210671 3,528374 1,833353
Z 0,385254 0,531081 3,996318 0,706389 4,96012 4,859451
R 4,9016 0,332482 0,304507 4,396823 0,084923 4,538054
G 0,318836 3,685971 0,370936 4,572214 4,438043 0,716456
B 0,265655 0,08976 4,151968 0,080396 4,660443 4,930661

TheElix
12th July 2011, 00:15
I think he's interested in seeing graphs and such (along with the data). You may archive your .chc file and upload it on a some file sharing service. And you forgot to post measurements in your yCMS file.

yesgrey
12th July 2011, 02:51
how can I send u the file?

You may archive your .chc file and upload it on a some file sharing service. And you forgot to post measurements in your yCMS file.
You can do that, or you can e-mail it to me. My e-mail address is at the end of yCMS's manual.

salora
12th July 2011, 07:06
OK
So , yesgrey I sent you the file by email and here is the ycms file generated by madvr


Input_Primaries 0.566 0.334 0.312 0.575 0.179 0.112 0.31272661468101209 0.32902313032606195
Output_Primaries 0.566 0.334 0.312 0.575 0.179 0.112 0.304 0.346

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Gamut_Measurements 1
1.290 0.566 0.334
2.713 0.312 0.575
0.630 0.179 0.112
5.027 0.304 0.346

Grayscale_Measurements
0 1 0.161 0.369 0.252
10 1 0.283 0.347 0.283
20 1 0.519 0.334 0.306
30 1 0.890 0.327 0.321
40 1 1.267 0.318 0.332
50 1 1.707 0.312 0.336
60 1 2.239 0.310 0.340
70 1 2.865 0.307 0.343
80 1 3.516 0.305 0.344
90 1 4.262 0.304 0.345
100 1 5.027 0.304 0.346


thank you guys

TheElix
12th July 2011, 09:30
From what I see your calibration is a far cry from being decent. What calibrator did you use? What tutorial? What display have you calibrated?
Also, it seems like your cailbrator gave you false readings on dark patterns (0 and 10). So it's better to avoid using these lines in yCMS to avoid incorrect gamut management.
0 1 0.161 0.369 0.252
10 1 0.283 0.347 0.283

salora
12th July 2011, 09:36
I'm using eye one display with hcfr and hcfr tutorial, it's a panasonic ptae2000

I'm hoping to have time to make others measurements, using curtpalme tutorial.
also it's the data before calibration

yesgrey
12th July 2011, 12:54
here is the ycms file generated by madvr
What display do you have? From what I can see your display has a very narrow color gamut, much smaller than the standard ones, so, a lot of clipping is happening. Therefore, with the current yCMS software you will not gain anything by using it to correct your display's color gamut. I'm planning to add clipping code to overcome situations similar to yours, but considering that the current trend is wider gamuts it's not one of my top priorities...

However, you might still benefit from yCMS by using it to correct your gamma curve. Try creating a 3DLUT with this file:
Input_Primaries 0.6400 0.3300 0.3000 0.6000 0.1500 0.0600 0.31272661468101209 0.32902313032606195
Output_Primaries 0.6400 0.3300 0.3000 0.6000 0.1500 0.0600 0.31272661468101209 0.32902313032606195

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Grayscale_Measurements
0 1 0.161 0.369 0.252
10 1 0.283 0.347 0.283
20 1 0.519 0.334 0.306
30 1 0.890 0.327 0.321
40 1 1.267 0.318 0.332
50 1 1.707 0.312 0.336
60 1 2.239 0.310 0.340
70 1 2.865 0.307 0.343
80 1 3.516 0.305 0.344
90 1 4.262 0.304 0.345
100 1 5.027 0.304 0.346
You might also try removing the 0, 10 and 20 IRE lines from grayscale measurements command. It might give you better results in case those values are not that accurate. Some meters aren't very accurate at very low luminance levels...

@madshi
This is a case where a user would benefit from using the Grayscale_Measurements command but not the Gamut_Measurements. The grayscale is flawed but the color gamut is too small, so it's better not to touch it. Of course this is valid only for current yCMS.;)

salora
12th July 2011, 16:14
it's a 4 years old with 1400h of playing, panasonic ptae2000

with your file gamma is better but still my black are going green and my red pink

better give up i think

thank u

yesgrey
13th July 2011, 10:53
with your file gamma is better but still my black are going green and my red pink
Strange... can you try removing also the Grayscale_Measurements command? This way you should get the same picture as before, so, if you're still getting the color changes than something else might be wrong... By the way, are you using madVR v0.66?

salora
13th July 2011, 12:47
yes madvr 0.66

jmone
15th July 2011, 01:10
I see some posts on X-Rite ColorMunki's new "Display" model and that the output may/may not be compatible with madVR. Do I buy this or the older "Photo" model?
Thanks
Nathan

Appologies if this is not the correct thread (if so what would be the correct one)?

jimwhite
16th July 2011, 10:23
Colormunki Display is a colorimeter, not a spectrophotometer like the Colormunki Photo or Design. As such, it is a newer, less costly and less accurate alternative which may or may not be supported in the future.

jmone
17th July 2011, 07:01
Thanks Jim - put an order in for a Colormunki Photo.

Fer
18th July 2011, 18:00
Hi yesgrey

Can you say me the way I have to change my old configuration file in order that can be used to generate an external 3dlut compatible with the new versions of madvr?

This is the file:


# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

Gamut_Measurements 1
18.97 0.693 0.304
72.89 0.299 0.692
6.77 0.140 0.053
100.00 0.314 0.329

# Grayscale IRE Measurements
Grayscale_Measurements
10 0 0.247
15 0 0.517
20 0 0.945
25 0 1.468
30 0 2.087
35 0 2.788
40 0 3.554
45 0 4.548
50 0 5.507
55 0 6.522
60 0 7.730
65 0 9.117
70 0 10.642
75 0 12.238
80 0 13.936
85 0 15.821
90 0 17.906
95 0 20.198
100 0 22.373

Gamma_Curve 1.0 2.60


Thank you very much.

yesgrey
18th July 2011, 19:09
Can you say me the way I have to change my old configuration file in order that can be used to generate an external 3dlut compatible with the new versions of madvr?

Use this:

Input_Primaries 0.693 0.304 0.299 0.692 0.140 0.053 0.31272661468101209 0.32902313032606195
Output_Primaries 0.693 0.304 0.299 0.692 0.140 0.053 0.314 0.329

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Gamut_Measurements 1
18.97 0.693 0.304
72.89 0.299 0.692
6.77 0.140 0.053
100.00 0.314 0.329

# Grayscale IRE Measurements
Grayscale_Measurements
10 0 0.247
15 0 0.517
20 0 0.945
25 0 1.468
30 0 2.087
35 0 2.788
40 0 3.554
45 0 4.548
50 0 5.507
55 0 6.522
60 0 7.730
65 0 9.117
70 0 10.642
75 0 12.238
80 0 13.936
85 0 15.821
90 0 17.906
95 0 20.198
100 0 22.373


The "Gamma_Curve 1.0 2.60" should be removed because madVR now supports it directly. Enable "Gamma processing" in madVR and use it instead.

Fer
18th July 2011, 23:26
Thank you so much. Your file seems work correctly. Are correct the following?:

-The equivalent to Gamma_Curve 1.0 2.60 in the madvr color & gamma menu is BT.709/ 601 curve.

- I think that I can yet use the Gamma_Curve command in the configuration file in the case that the gamma value I want does not exits in the madvr menu (for example the highest is just 2.60), of course with no enable gamma processing in madvr.

Fer
19th July 2011, 02:05
Unfortunately my preliminary observations were wrong. The following configuration (the calibrated several months ago that gives me a wonderfull image):

A) madVR 0.56 and

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

Gamut_Measurements 1
18.97 0.693 0.304
72.89 0.299 0.692
6.77 0.140 0.053
100.00 0.314 0.329

# Grayscale IRE Measurements
Grayscale_Measurements
10 0 0.247
15 0 0.517
20 0 0.945
25 0 1.468
30 0 2.087
35 0 2.788
40 0 3.554
45 0 4.548
50 0 5.507
55 0 6.522
60 0 7.730
65 0 9.117
70 0 10.642
75 0 12.238
80 0 13.936
85 0 15.821
90 0 17.906
95 0 20.198
100 0 22.373

Gamma_Curve 1.0 2.60

is not equivalent to any of the following:

1) madVR 0.67 and

Input_Primaries 0.693 0.304 0.299 0.692 0.140 0.053 0.31272661468101209 0.32902313032606195
Output_Primaries 0.693 0.304 0.299 0.692 0.140 0.053 0.314 0.329

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Gamut_Measurements 1
18.97 0.693 0.304
72.89 0.299 0.692
6.77 0.140 0.053
100.00 0.314 0.329

# Grayscale IRE Measurements
Grayscale_Measurements
10 0 0.247
15 0 0.517
20 0 0.945
25 0 1.468
30 0 2.087
35 0 2.788
40 0 3.554
45 0 4.548
50 0 5.507
55 0 6.522
60 0 7.730
65 0 9.117
70 0 10.642
75 0 12.238
80 0 13.936
85 0 15.821
90 0 17.906
95 0 20.198
100 0 22.373

with enable gamma processing (BT.709/601 curve, 2.60) in the madVR menu.


2) madVR 0.67 and

Input_Primaries 0.693 0.304 0.299 0.692 0.140 0.053 0.31272661468101209 0.32902313032606195
Output_Primaries 0.693 0.304 0.299 0.692 0.140 0.053 0.314 0.329

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Gamut_Measurements 1
18.97 0.693 0.304
72.89 0.299 0.692
6.77 0.140 0.053
100.00 0.314 0.329

# Grayscale IRE Measurements
Grayscale_Measurements
10 0 0.247
15 0 0.517
20 0 0.945
25 0 1.468
30 0 2.087
35 0 2.788
40 0 3.554
45 0 4.548
50 0 5.507
55 0 6.522
60 0 7.730
65 0 9.117
70 0 10.642
75 0 12.238
80 0 13.936
85 0 15.821
90 0 17.906
95 0 20.198
100 0 22.373

Gamma_Curve 1.0 2.60

with NO enable gamma processing in the madVR menu.


The observed gamma of the image in case 1) is clearly lower than that of A) (brighter image).

The observed gamma of the image in case 2) is clearly higher than that of A) (darker image).


So, sadly I have to continue with madVR 0.56 and the old color and gamma management.

Thank you so much.


(The measured results of configuration A) are very near to the last images shown in the post number #238).

madshi
19th July 2011, 07:36
madVR currently applies a correction factor to the gamma value, if you choose a BT.709 transfer function. The BT.709 transfer function is always brighter than the pure power function. The correction factor makes the overall brightness of the BT.709 and pure power curves similar, so if you switch the curve type in madVR (BT.709 <-> pure power), the overall brightness stays the same. The current correction factor is 1.25x, which means if you use a BT.709 curve of 2.6, madVR actually uses a BT.709 curve of 2.6 * 1.25. Try a BT.709 curve with a gamma value of 2.1, that should be near to what you had with madVR v0.56.

yesgrey already asked me to remove this correction factor. I'm not sure if I should or not. If I remove it, I'd have to increase the gamma value range to probably up to 3.0, or even higher. And it would then be much more difficult to quickly compare the different looks of the two curve types.

Fer
20th July 2011, 03:52
madVR currently applies a correction factor to the gamma value, if you choose a BT.709 transfer function. The BT.709 transfer function is always brighter than the pure power function. The correction factor makes the overall brightness of the BT.709 and pure power curves similar, so if you switch the curve type in madVR (BT.709 <-> pure power), the overall brightness stays the same. The current correction factor is 1.25x, which means if you use a BT.709 curve of 2.6, madVR actually uses a BT.709 curve of 2.6 * 1.25. Try a BT.709 curve with a gamma value of 2.1, that should be near to what you had with madVR v0.56.

yesgrey already asked me to remove this correction factor. I'm not sure if I should or not. If I remove it, I'd have to increase the gamma value range to probably up to 3.0, or even higher. And it would then be much more difficult to quickly compare the different looks of the two curve types.

I have several doubts about the color and gamma management that make now madVR. Perhaps something is wrong. I refer to the configurations of my previous post.

- With the configuration 1) the observed image gamma is clearly lower than that of A). So this fact is against your comment about the correction factor of 2.6 * 1.25 for a BT.709 curve, since such factor would increase the gamma (not decrease as observed).

- Configuration 2) and A) (in both cases the gamma management is made in the yCMS configuration file and not in madVR) should be equivalent, but surprisingly they are not since the observed gamma of the image in case 2) is clearly higher than that of A). Which is the reason? If both yCMS configuration files are equivalent the only explication is that madVR 0.67 treat the external 3dluts files in a different way (wrong way?) than that of madVR 0.56.

So seems to me that there is not a way to reproduce exactly my previous calibrated gamma with the present madVR versions.

Taking this problems into account, it would be possible that new versions of madVR have an option, of something similar, that allows to use the "old" external 3dlut files in the "old" way? Sorry for this kind of petition, but is a little bit frustating that I can not use the very pleasant previous calibration in the future madVR versions.


Thank you so much for your patience.

madshi
20th July 2011, 08:21
With the configuration 1) the observed image gamma is clearly lower than that of A). So this fact is against your comment about the correction factor of 2.6 * 1.25 for a BT.709 curve, since such factor would increase the gamma (not decrease as observed).
When you say "the observed gamma is lower" what do you mean exactly? Do you mean the image got brighter or darker? Have you tried my suggestion to use a 2.1 gamma with a BT.609 curve?

Configuration 2)...
... is not what you're supposed to do.

So seems to me that there is not a way to reproduce exactly my previous calibrated gamma with the present madVR versions.

Taking this problems into account, it would be possible that new versions of madVR have an option, of something similar, that allows to use the "old" external 3dlut files in the "old" way?
You're jumping to conclusions much too early. If there is a problem with the new way (and I'm still not convinced that there is) then let us fix that instead of returning to an old solution. If the new way proves to be broken and if we can't find a way to fix it, THEN we can talk about making the old solution available again.

alph@
20th July 2011, 11:02
I used a sensor x rite and the soft hcfr to calibrate my Sony hx 700,with this result
http://www.zimagez.com/miniature/sonygris.png

config.Ati 5750 panel full rgb 4:4:4-0.255,potplayer,diavc rgb 32,resize ffdshow out yv12 (only for movies if reso is not 1920/1080) lav splitter,madvr 0,67 with function 'calibrate this display use ycms.
http://www.zimagez.com/miniature/ycms.png (http://www.zimagez.com/zimage/ycms.php)

the gamut before corect by ycms
http://www.zimagez.com/miniature/sonygamutavant.png (http://www.zimagez.com/zimage/sonygamutavant.php)
and after corect by ycms
http://www.zimagez.com/miniature/sonygamutapres.png (http://www.zimagez.com/zimage/sonygamutapres.php)
corect is made in the blue green not in the red,I read that ycms can not expand the game only reduct,how to be good with the range of red.
thank for your job yesgrey and madshi:)

madshi
20th July 2011, 11:18
I find it surprising that a lot of people seem to have displays which are short on gamut. I thought most of today's display would have larger primaries than needed, not smaller. Very weird.

@alph@, does your Sony have color controls? Maybe different color modes? You could try to find a color mode which has primaries which are large enough. I'd suggest to set all the Sony color controls to neutral values as a start. Then switch through the different color modes.

alph@
20th July 2011, 12:00
madshi,I tried all modes of sony,(normal,warm 1,warm 2),You think that I could not reach the red gamme,
@alph@, does your Sony have color controls?.
What control, a cms

http://www.zimagez.com/miniature/delta9.png (http://www.zimagez.com/zimage/delta9.php)
the delta E after corect by ycms

yesgrey
20th July 2011, 12:05
- I think that I can yet use the Gamma_Curve command in the configuration file in the case that the gamma value I want does not exits in the madvr menu (for example the highest is just 2.60), of course with no enable gamma processing in madvr.
No, you can't. The Gamma_Curve command should not be used with madVR v0.66+. It should be used the gamma processing option in madVR instead.

- Configuration 2) and A) (in both cases the gamma management is made in the yCMS configuration file and not in madVR) should be equivalent, but surprisingly they are not
They're not equivalent, so it's no surprise. The Gamma_Curve command should not be used.

yesgrey
20th July 2011, 12:14
yesgrey already asked me to remove this correction factor. I'm not sure if I should or not. If I remove it, I'd have to increase the gamma value range to probably up to 3.0, or even higher. And it would then be much more difficult to quickly compare the different looks of the two curve types.
When I saw the comparison between the pure power and the BT.709 gamma curves with equivalent brightness, with the former looking better, I stopped asking you to remove it. However, I still think that you should give the true BT.709 transfer function as an option, because like it is now some people might wrongly assume that a pure power and a BT.709 with the same gamma values are almost the same, and we know that they aren't. ;)

Yes, I know that you don't want that many options inside madVR, and I agree with that on a user-friendliness level, but then some cases like this one from Fer might happen again.;)

yesgrey
20th July 2011, 12:28
corect is made in the blue green not in the red,I read that ycms can not expand the game only reduct,how to be good with the range of red.
It's not only yCMS, the color gamut can never be expanded. That's a hardware limitation of the display.

I find it surprising that a lot of people seem to have displays which are short on gamut. I thought most of today's display would have larger primaries than needed, not smaller. Very weird.
Not quite. Several LCD models still have small gamuts. It should be cheaper?...

You could try to find a color mode which has primaries which are large enough. I'd suggest to set all the Sony color controls to neutral values as a start. Then switch through the different color modes.
Yes, try that. Maybe you are using a color mode which shrinks the original wider gamut to try to fit the standard ones. Your gamut is not very far from the standard, so it might be that.

madshi,I tried all modes of sony,(normal,warm 1,warm 2)
Are those the only modes available? From a quick googling I got these modes:
Picture Mode Vivid / Standard / Custom / Cinema / Game-Standard / Game-Original / Graphics / Sports / Photo-Vivid / Photo-Standard / Photo-Original / Photo-Custom

Have you tried the vivid and the custom ones?

jmone
20th July 2011, 12:28
While waiting for my colormunki to arrive, some newbie questions if you don't mind:

Setup: HTPC / Win7 / nvidia GTS450 --> HDMI --> yami V2700 receiver --> Pio LX607a plasma

Should I make any changes to the default settings in the nvidia config prior to running the colormunki? eg should I:
1) change the format from "Limited" to Full"
2) use the AVSForum "Brightness and Contrast" test clips to adjust Black and White level first or will the yCMS also do this?
3) ??? Other stuff ???

Thanks
Nathan

nevcairiel
20th July 2011, 12:39
Before measuring, you should always do the most basic adjustments with what the TV offers on controls, eg. Black/White level should be as good as you can get them.

Sadly, the NVIDIA option to change Limited to Full does not do what you think it would. It only affects EVR rendering output, not the actual output of the GPU. NVIDIA HDMI defaults to limited RGB, it only does Full Range if you create a custom resolution (or by some trick you have to apply to the driver inf file, i forgot what it was though). I always create me a 24p, 50p and 60p resolution anyway, so i don't suffer from that issue anymore.

Fer
20th July 2011, 12:47
EDIT: According to yesgrey conf. 2) is not option. Disregard conf. 2) in the following.

When you say "the observed gamma is lower" what do you mean exactly? Do you mean the image got brighter or darker? Have you tried my suggestion to use a 2.1 gamma with a BT.609 curve?

I mean the image got brighter and washed out, with less contrast.

With conf. 2) I tried Gamma_Curve 1.0 2.08, where 2.08 is 2.6/1.25 (as I understand you suggest), and the result is different to the old conf. A). Again the observed gamma is lower than A). Even Gamma_Curve 1.0 2.20 gives a little bit lower observed gamma than A).

With conf. 1) the effect of the selection 2.1 gamma with a BT.609 curve in the madVR menu is what would be expected. The observed gamma is lower than with 2.6 gamma with a BT.609 curve in the madVR menu and so much lower than conf. A).

... is not what you're supposed to do.

So the yCMS configuration files of A) and 2) are not equivalent? yCMS generate with them equivalent 3dlut files or not? Is not allowed now the command Gamma_Curve 1.0 in madVR? or they are not equivalent in the final observed gamma curve due to the 1.25 factor and something more that now do madVR?

You're jumping to conclusions much too early. If there is a problem with the new way (and I'm still not convinced that there is) then let us fix that instead of returning to an old solution. If the new way proves to be broken and if we can't find a way to fix it, THEN we can talk about making the old solution available again.

I will be happy if you reach the way that conf. 1) or 2) gives "exactly" the observed or measured gamma curve of the old conf. A).


Thank you so much :thanks:.