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
3rd January 2011, 14:45
Im not sure how to understand this
Sorry, wrong quote... :o

aww, forgot about the subs.
you said the colour of the subs changes as well with all these changes being made, so I'd have to adjust them.

the colours I usually use for my .ass subs are 246 245 222 for primary, 255 0 0 for secondary and 0 0 0 for outline and shadow.
what would I have to do here with input 32 235 and gamma 0.405? im not very good at maths :S
Do you still need this?

Thunderbolt8
3rd January 2011, 15:15
if its not too much of an inconvenience, yes please.

cyberlolo
4th January 2011, 14:10
Hi yesgrey.

Thanks for the new build, but I have a newbie problem: with the previous versions, I used this command for color correction:

Gamut_Measurements 0.6350 0.3321 0.2890 0.6007 0.1528 0.0647 0.3127 0.3294

just as it was intended to be:

Gamut_Measurements redx redy greenx greeny bluex bluey whitex whitey

But now, with this new build, this is not possible, and the procedure seems to be as in this example:

Gamut_Measurements 1
21.26 0.676 0.321
71.52 0.308 0.685
7.22 0.144 0.045
100.00 0.3127 0.3290

But what is that first column (bold)? When the calibrator did his job on my TV, he gave me the xy coordinates and they were 2 numbers for each component, not 3!!

How can I solve this?

Thanks in advance.

janos666
4th January 2011, 16:24
How normal is it? (It looks strange for me, but not impossible with a 3DLUT and may be it makes sense, but...) I made these screenshots with the same settings and the same 3DLUT: 01 (http://img12.tar.hu/janos666/img/97491175.png), 02 (http://img12.tar.hu/janos666/img/97491174.png)

The near-white is correct while the near-R, near-G, near-B looks strange. It would be impossible with 2D CMS and RGB output, I guess.

yesgrey
4th January 2011, 16:33
But what is that first column (bold)?
The first column are the Luminance values of each primary. However, yCMS is not yet using that info, so for now you could use the same values (in bold) that you see in the example and that would be fine, but don't forget to use 'format' 1.;)

cyberlolo
4th January 2011, 17:49
The first column are the Luminance values of each primary. However, yCMS is not yet using that info, so for now you could use the same values (in bold) that you see in the example and that would be fine, but don't forget to use 'format' 1.;)

Ok, thanks. By the way, do you recommend me to generate new 3dluts with the last version, or keep the ones that I generated with v0.6? I'm using only this input parameters (these are for HD, but I use the same for SD):

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_Video 16

Gamut_Measurements 0.6350 0.3321 0.2890 0.6007 0.1528 0.0647 0.3127 0.3294

Input_Range 16 238
Output_Range 0 255

cyberbeing
4th January 2011, 17:55
yesgrey, I seem to get strong coloration of grayscale steps when using Grayscale_Measurements mode 1 & 2. Even when entering the exact same color temperature for all values using Grayscale_Measurements mode 1, there is still some coloration. Whatever color correction you are doing with IRE chromaticity doesn't appear to be working all that well.

Below is what I was using when I first noticed the problem (it's particularly bad with a RGB_Video 3dlut near white):
If you're curious how I came up with the xy values for IRE 0,2,4,6, and 8, I just used the xy values from IRE 10 which I figure is better then just using Grayscale_Measurements mode 0.
# IRE Grayscale Measurements
Grayscale_Measurements
0 1 0.14689 0.31527 0.32457
2 1 0.16114 0.31527 0.32457
4 1 0.19540 0.31527 0.32457
6 1 0.24432 0.31527 0.32457
8 1 0.44471 0.31527 0.32457
10 2 0.68909 0.70942 0.78720
12 2 1.01600 1.05940 1.15260
14 2 1.42000 1.44420 1.58220
16 2 1.82010 1.89070 2.01030
18 2 2.29720 2.38500 2.51430
20 2 2.82590 2.93710 3.10350
22 2 3.36740 3.47210 3.73200
24 2 3.97970 4.14340 4.47720
26 2 4.67530 4.88760 5.13810
28 2 5.35610 5.58070 6.00030
30 2 6.39890 6.67560 7.16940
32 2 7.42060 7.72820 8.45530
34 2 8.55820 8.99120 9.67810
36 2 9.71040 10.2020 10.9550
38 2 10.9860 11.5430 12.3990
40 2 12.3140 12.9340 13.8630
42 2 13.5040 14.1550 15.4300
44 2 14.9720 15.7370 16.8310
46 2 16.4300 17.3380 18.6440
48 2 17.9920 18.8880 20.2450
50 2 20.1580 21.1570 22.6120
52 2 21.9270 23.0990 24.7490
54 2 23.7100 24.8830 26.6020
56 2 25.6300 27.0160 28.9390
58 2 27.8920 29.3350 31.4350
60 2 30.0900 31.6720 33.9680
62 2 32.0000 33.6770 36.0050
64 2 34.5660 36.3080 38.8730
66 2 36.9120 38.9550 41.7120
68 2 39.5260 41.4930 44.9560
70 2 42.4650 44.7020 48.7940
72 2 45.3890 47.7390 51.8430
74 2 47.9880 50.5540 54.8440
76 2 50.8050 53.6500 58.5290
78 2 54.1080 56.9430 62.3890
80 2 57.0140 60.3300 65.3030
82 2 60.1620 63.4190 69.4190
84 2 63.4210 67.0090 72.5200
86 2 66.6250 70.4210 77.0140
88 2 69.9350 73.7780 79.9540
90 2 75.0960 79.0490 84.9870
92 2 78.6640 82.9110 88.9520
94 2 82.3160 86.7250 93.8370
96 2 87.0590 91.9160 97.8380
98 2 90.8390 95.3970 103.090
100 2 95.1410 100.000 108.730

# Target Camera Gamma
Gamma_Curve 1.0 2.6

# Display Gamut Measurements
Gamut_Measurements 2
45.3340 24.6690 2.30880
31.5860 65.5520 10.3620
18.2290 9.39720 94.0110
95.1410 100.000 108.730


http://img813.imageshack.us/img813/271/shader.th.png (http://img813.imageshack.us/img813/271/shader.png) MadVR Shader

http://img708.imageshack.us/img708/6417/3dlut0.th.png (http://img708.imageshack.us/img708/6417/3dlut0.png) Grayscale_Measurements mode 0

http://img190.imageshack.us/img190/5647/3dlut.th.png (http://img190.imageshack.us/img190/5647/3dlut.png) Grayscale_Measurements mode 1&2

yesgrey
4th January 2011, 23:42
How normal is it?
Please post your 3DLUT configuration file.

yesgrey
4th January 2011, 23:45
do you recommend me to generate new 3dluts with the last version, or keep the ones that I generated with v0.6?
There is no v0.6, but I guess you're referring to v.1.6 ;) , and considering your configuration file you wouldn't need to create new 3DLUTs. The changes won't affect you.

cyberlolo
4th January 2011, 23:53
There is no v0.6, but I guess you're referring to v.16 ;) , and considering your configuration file you wouldn't need to create new 3DLUTs. The changes won't affect you.

You're right, I meant v1.6... :)

Ok then, I won't recreate 3DLUTs. Thanks for your support!

janos666
4th January 2011, 23:56
Please post your 3DLUT configuration file.

Done. (http://forum.doom9.org/showpost.php?p=1466574&postcount=394)

yesgrey
5th January 2011, 00:34
yesgrey, I seem to get strong coloration of grayscale steps when using Grayscale_Measurements mode 1 & 2.
Can you post your test pattern video? I've tried with one I have here but it worked fine without any coloring issues...

yesgrey
5th January 2011, 00:40
Done.
I forgot one thing... please post the test pattern video too.

Thanks.

cyberbeing
5th January 2011, 05:36
Can you post your test pattern video? I've tried with one I have here but it worked fine without any coloring issues...

In my images above can you see how the Grayscale_Measurements mode 1&2 image has a strong red cast in the first 2 white steps and a blue cast on the 3rd white step?

I think janos666 and I are using the same mp4 test pattern set which can be found here: http://www.avsforum.com/avs-vb/showthread.php?t=948496

The 2-Grayscale Steps.mp4 can be found in ...\MP4-2c\Misc Patterns\A - Additional\ after extracted.

The 4-Color Clipping.mp4 which janos666 used can be found in ...\MP4-2c\Misc Patterns\A - Additional\ as well.

The 3-White Clipping.mp4 which janos666 used can be found in ...\MP4-2c\Basic Settings\.

yesgrey
5th January 2011, 14:40
In my images above can you see how the Grayscale_Measurements mode 1&2 image has a strong red cast in the first 2 white steps and a blue cast on the 3rd white step?
Yes, I saw it, but when I tried with a test pattern I have here it was OK, hence why I wanted to know which test you were using.

I think janos666 and I are using the same mp4 test pattern set which can be found here: http://www.avsforum.com/avs-vb/showthread.php?t=948496
OK, I have those too. I will test.

yesgrey
5th January 2011, 17:48
yesgrey, I seem to get strong coloration of grayscale steps when using Grayscale_Measurements mode 1 & 2. Even when entering the exact same color temperature for all values using Grayscale_Measurements mode 1, there is still some coloration. Whatever color correction you are doing with IRE chromaticity doesn't appear to be working all that well.
I have made several tests and there is nothing wrong with the color correction. The problem is that you are not creating the yCMS configuration file correctly, hence the problems you are getting. Let me try to explain...

First, the problem only happens when you are using RGB_Video as the output mode. The steps where the problem appears are only > 235 steps, which are steps that should not be shown when using RGB video levels. You should only use RGB video levels if that's what your display is expecting. In that case, the display will consider 16 as black and 235 as white, and the other values will not be shown. In your case, you might had sent a RGB video levels signal when the display was expecting a RGB full range signal (RGB_PC), so you ended up seeing colors that were not supposed to be seen.

I think what you were trying to do was to set up your video chain to watch part of the BTB and WTW data, but in that case you should not set the output to RGB_Video. You should use the Input_Range command for that instead. If you add this command:
Input_Range 1 254
You would be able to see the full BTB and WTW data correctly color corrected.

cyberbeing
5th January 2011, 20:12
Ah, I forgot that the YCbCr input preset uses a Video range.

PC->PC
Input_Format HD YCbCr 8
Input_Range 0 255
Output_Format HD RGB_PC 16

Well that fixed the strong red cast above 235, but not the color cast below 235.


First, the problem only happens when you are using RGB_Video as the output mode.
This is incorrect, the problem also happens with RGB_PC output. I just used RGB_Video output as the example because the color cast appeared worse (which I now know was because of the LUT misconfiguration).

TV->PC
Input_Format HD YCbCr 8
Input_Range 0 255
Output_Format HD RGB_PC 16

Grayscale_Measurements 0
http://img824.imageshack.us/img824/6830/hdpcgs0.th.png (http://img824.imageshack.us/img824/6830/hdpcgs0.png)

Grayscale_Measurements 2
From the top-right, first step white (235), second step bluish, third step greenish, forth step redish.
http://img375.imageshack.us/img375/6761/hdpcgs2.th.png (http://img375.imageshack.us/img375/6761/hdpcgs2.png)

http://img254.imageshack.us/img254/7043/30to100gray.png
With Grayscale_Measurements 2, I confirmed a bit of this irregularity with HFCR. Notice the irregular color temperature humps at 45%, 65%, 90%, and 95%. In order to maintain a smooth grayscale, the color temperature between steps should be averaged and linearized so there is a smooth transition between steps. Those abrupt jumps up and down in color temperature are what make the grayscale steps colorful, when they should appear neutral.

For comparison purposes, below is what color temperature looked like naturally with Grayscale_Measurements 0. Nice linear transitions, without any abrupt humps:
http://img192.imageshack.us/img192/5642/30to100gray0.png

madshi
5th January 2011, 20:30
FWIW, watching at these screenshots on a monitor other than the display they've been rendered for does not give an accurate result. E.g. if your display had a big lack of red at a specific part of the grayscale, yCMS would probably try to correct that. As a result there would be a red cast on the screenshot (when watched on a different display), but the grayscale would still look neutral on your target display.

That said, I can clearly see a red cast on one of those steps with my naked eyes. And that seems a bit too strong to make sense? But I don't really know, let's wait what yesgrey says about that... :)

yesgrey
5th January 2011, 23:52
Ah, I forgot that the YCbCr input preset uses a Video range.
YEs, but if you want to keep the BTB and WTW data you should use Input_Range 1 254. 0 255 is to be used only with full range material, which is not very common.

Well that fixed the strong red cast above 235, but not the color cast below 235.
As madshi wisely pointed the color cast would be wrong only when watched through the display for which the 3DLUT was created for. Simply grabbing a png image from the video player and posting it is meaningless. You should play it on the calibrated display and take a photo of the screen, or, even better, measuring a new grayscale to see how the corrected grayscale looks.

With Grayscale_Measurements 2, I confirmed a bit of this irregularity with HFCR. Notice the irregular color temperature humps at 45%, 65%, 90%, and 95%.
Now this is a relevant picture. If it's the result after the calibration it shows something needs to be improved.

For comparison purposes, below is what color temperature looked like naturally with Grayscale_Measurements 0. Nice linear transitions, without any abrupt humps:
I don't get it. The color temperature should be a straight line from 0 to 100 IRE. With the picture above you almost get it, even though there are still some bumps, but this picture is really bad, so I don't understand what you're trying to say...:confused:

Another thing is the Gamma_Curve you are using... Why do you want a BT.709 curve with a 2.6 gamma? Other than a BT.709 with ~2.2, or a pure power with ~2.35 I think it might be looking for trouble...;)

madshi
6th January 2011, 00:00
Another thing is the Gamma_Curve you are using... Why do you want a BT.709 curve with a 2.6 gamma? Other than a BT.709 with ~2.2, or a pure power with ~2.35 I think it might be looking for trouble...;)
A pure power curve is darker than a BT.709 curve. So a 2.35 pure power curve should be somewhat similar to a 2.6 BT.709 curve, or am I wrong?

yesgrey
6th January 2011, 00:59
So a 2.35 pure power curve should be somewhat similar to a 2.6 BT.709 curve, or am I wrong?
Here is an image comparing both (blue BT.709 with 2.6 gamma and red pure power curve with 2.35 gamma). They seem to be somewhat similar, but the difference at low IREs would be enough to damage color accuracy significantly.
11931

Furthermore, I don't believe any studios would master any movies with a BT.709 transfer function with a 2.6 gamma.;)

cyberbeing
6th January 2011, 09:42
I don't get it. The color temperature should be a straight line from 0 to 100 IRE. With the picture above you almost get it, even though there are still some bumps, but this picture is really bad, so I don't understand what you're trying to say...:confused:
The Grayscale_Measurements 0 is before color correction, the Grayscale_Measurements 2 is after color correction. It gives you a idea of what yCMS did when it corrected the color temperature. If I had only posted the Grayscale_Measurements 2 image, you would be unable to make conclusion about whether yCMS grayscale color correction improved things, or made them worse.

Grayscale_Measurements 0, while not perfect (6400 near black and 6550 near white) doesn't have any abrupt jumps up and down in color temperature. When the color temperature changes, it happens in a straight line.

When you go warm -> very cool -> very warm -> neutral on subsequent grayscale steps, they appear colorful.

When you go warm -> slightly warm -> neutral -> slightly cool -> cool, they don't appear colorful since the transition is smooth.

Here is the default view of the same images as before to help you better visualize what I'm saying:
Grayscale_Measurements 2
http://img440.imageshack.us/img440/2264/hdpcgs2b.png

Grayscale_Measurements 0
http://img811.imageshack.us/img811/7016/hdpcgs0b.png

From 65-100 IRE Grayscale_Measurements 2 is making the color temperature worse overall then Grayscale_Measurements 0.

From 30-60 IRE Grayscale_Measurements 2 is better overall then Grayscale_Measurements 0, but has a couple irregular bumps.

From 0-25 IRE Grayscale_Measurements 2 once again makes things worse then Grayscale_Measurements 0.

Conclusion: ycms color correction doesn't work well outside of midtones.


Another thing is the Gamma_Curve you are using... Why do you want a BT.709 curve with a 2.6 gamma? Other than a BT.709 with ~2.2, or a pure power with ~2.35 I think it might be looking for trouble...;)
I explained this before.

yCMS uses a BT.709 curve with a Camera Gamma of ~2.2. This results in a Display Gamma of ~1.9 after applied.

I calibrate my display to a Display Gamma of ~2.2. By setting Camera Gamma to 2.6 I get a Display Gamma close to 2.2, which is what I want.

I think you are misunderstanding something about transfer functions yesgrey. I was under the impression most ISF calibrators used a target Display Gamma between 2.2 and 2.6.

http://i43.tinypic.com/opxulz.png
Here is a good image which shows a 2.2 Power Curve, a BT.709 gamma curve, and a BT.709 2.5 gamma curve (BT.709 with a 1.125 power function).
The source is the thread here: http://www.avsforum.com/avs-vb/showthread.php?t=1008297&page=5
I use BT.709 2.6 gamma curve (BT.709 with a 1.17 power function). This results in a Display Gamma of ~2.22.
When I tried BT.709 with a 2.5 gamma curve (BT.709 with a 1.125 power function) awhile back, I believe my Display Gamma was ~2.17.

cyberbeing
6th January 2011, 10:38
From 65-100 IRE Grayscale_Measurements 2 is making the color temperature worse overall then Grayscale_Measurements 0.

From 30-60 IRE Grayscale_Measurements 2 is better overall then Grayscale_Measurements 0, but has a couple irregular bumps.

From 0-25 IRE Grayscale_Measurements 2 once again makes things worse then Grayscale_Measurements 0.

Conclusion: ycms color correction doesn't work well outside of midtones.

By using the following 3DLUT (which only color corrects from 30-64 IRE) I seem to have proven my above conclusion was correct:
# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# IRE Grayscale Measurements
Grayscale_Measurements
0 0 0.14689
2 0 0.16114
4 0 0.19540
6 0 0.24432
8 0 0.44471
10 0 0.70942
12 0 1.05940
14 0 1.44420
16 0 1.89070
18 0 2.38500
20 0 2.93710
22 0 3.47210
24 0 4.14340
26 0 4.88760
28 0 5.58070
30 2 6.39890 6.67560 7.16940
32 2 7.42060 7.72820 8.45530
34 2 8.55820 8.99120 9.67810
36 2 9.71040 10.2020 10.9550
38 2 10.9860 11.5430 12.3990
40 2 12.3140 12.9340 13.8630
42 2 13.5040 14.1550 15.4300
44 2 14.9720 15.7370 16.8310
46 2 16.4300 17.3380 18.6440
48 2 17.9920 18.8880 20.2450
50 2 20.1580 21.1570 22.6120
52 2 21.9270 23.0990 24.7490
54 2 23.7100 24.8830 26.6020
56 2 25.6300 27.0160 28.9390
58 2 27.8920 29.3350 31.4350
60 2 30.0900 31.6720 33.9680
62 2 32.0000 33.6770 36.0050
64 2 34.5660 36.3080 38.8730
66 0 38.9550
68 0 41.4930
70 0 44.7020
72 0 47.7390
74 0 50.5540
76 0 53.6500
78 0 56.9430
80 0 60.3300
82 0 63.4190
84 0 67.0090
86 0 70.4210
88 0 73.7780
90 0 79.0490
92 0 82.9110
94 0 86.7250
96 0 91.9160
98 0 95.3970
100 0 100.000

# Target Camera Gamma
Gamma_Curve 1.0 2.6

# Display Gamut Measurements
Gamut_Measurements 2
45.3340 24.6690 2.30880
31.5860 65.5520 10.3620
18.2290 9.39720 94.0110
95.1410 100.000 108.730

http://img717.imageshack.us/img717/5294/hdpcgs2mod.png

yesgrey
7th January 2011, 18:40
How normal is it?
Perfectly normal. Exactly as it should be.

The near-white is correct while the near-R, near-G, near-B looks strange.
All of them are correct. They show that the color correction is being performed, because when you perform the gamut correction only the colors are affected, the grayscale remains unchanged.

If no gamut correction is performed, all the primaries clip at 235. However, after the gamut correction, you will see the less saturated primaries, which have lower RGB values than the uncorrected ones, hence the not clipping at the 235 point as would happen with the uncorrected ones.;)

yesgrey
7th January 2011, 19:26
Let's split the discussion of gamma and the color correction issues to make it easier to follow. I will now comment about the color correction issues and will comment about gamma on another post.

The Grayscale_Measurements 0 is before color correction, the Grayscale_Measurements 2 is after color correction. It gives you a idea of what yCMS did when it corrected the color temperature.
That's better. It's the only way of keeping the discussion on a scientific level.

Grayscale_Measurements 0, while not perfect doesn't have any abrupt jumps up and down in color temperature.
I understand your point, and I agree that even though the GS 0 has a less constant color temperature scale the end result migh be preferable because those bumps might be too noticeable, despite the more accurate color temperature on the other IRE levels.

From 0-25 IRE Grayscale_Measurements 2 once again makes things worse then Grayscale_Measurements 0.
I will not give much importance to low IRE values, because as you admitted your meter is not too accurate at lower values, so we can't really know if the measurements are reliable enough or not. Furthermore, with GS 2 you are using guessing values for <10 IRE, and that might be increasing the errors instead of reducing them.

Conclusion: ycms color correction doesn't work well outside of midtones.
Your example did not prove this. Overall the color temperature is more accurate, the problem are the bumps and not the overall correction, so it should be correctable.

As I've told when released v1.8, I have not thoroughly tested this, and in fact I've detected that something strange is happening with yCMS when applying the color correction, so I will now investigate to see what's happening...

By using the following 3DLUT (which only color corrects from 30-64 IRE) I seem to have proven my above conclusion was correct
That would be a good interim solution until I solve the problems, but don't generalize, this conclusion is true only for your situation, and might not be the same for everyone... ;)

cyberbeing
8th January 2011, 00:07
I agree with what you said. As for my EyeOne Pro, it's only not very accurate on my CRT at Low IRE (below 20 IRE in the above posts) in ColorHCFR. With Argyll Highres Spectral, it gets much more consistent colorimetry measurements low luminance down to around 0.1cd/m2, and that is how I get measurements for my 3DLUTs recently.

I did a bit more investigation, and it appears that those bumps happen when yCMS makes an error targeting the gamma at a particular IRE, or more that there is an unexpected bump in the gamma at the same IRE where there is an unexpected bump in color temperature.



I also ran into a weird bug which seemed to break grayscale color correction in yCMS with the following 3DLUT:

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# IRE Grayscale Measurements
Grayscale_Measurements
0 2 0.072291 0.076557 0.061430
2 2 0.106180 0.121710 0.094321
4 2 0.211860 0.240240 0.252810
6 2 0.453610 0.503020 0.510340
8 2 0.757130 0.807570 0.880250
10 2 1.148000 1.208800 1.333700
12 2 1.550800 1.628500 1.800500
14 2 1.942100 2.085900 2.208400
16 2 2.472200 2.609700 2.836200
18 2 2.992800 3.202300 3.400900
20 2 3.657800 3.850600 4.163400
22 2 4.267800 4.499200 4.863700
24 2 4.920300 5.195200 5.604600
26 2 5.806600 6.136500 6.474900
28 2 6.678700 7.038200 7.623900
30 2 7.799400 8.220100 8.903600
32 2 8.928000 9.434300 10.00400
34 2 10.01400 10.56000 11.44500
36 2 11.12900 11.74100 12.71800
38 2 12.27200 12.94900 14.05600
40 2 13.56600 14.31900 15.53500
42 2 15.01600 15.79600 17.45400
44 2 16.54300 17.51400 19.10300
46 2 18.15600 19.14700 20.76600
48 2 19.85100 20.88400 23.03500
50 2 21.89900 23.03600 25.37900
52 2 23.63900 24.87200 27.41600
54 2 25.47000 26.80500 29.54000
56 2 27.24700 28.71700 31.25600
58 2 29.25300 30.83300 33.50700
60 2 31.83700 33.55500 36.51700
62 2 33.99700 35.81900 38.98100
64 2 36.72400 38.75600 41.68900
66 2 39.15300 41.25200 44.94400
68 2 41.49800 43.78100 47.13600
70 2 44.55100 46.77400 50.89300
72 2 46.86600 49.38500 53.87300
74 2 49.43800 52.14700 56.28600
76 2 52.26100 55.11100 59.56200
78 2 55.23300 58.16900 63.58200
80 2 58.63700 61.55300 67.12800
82 2 61.68300 64.75000 70.62800
84 2 65.27900 68.69700 75.16700
86 2 68.49100 72.09600 78.93900
88 2 71.88500 75.65800 82.86300
90 2 76.18700 80.17400 87.93300
92 2 79.81800 83.99100 92.09900
94 2 83.95600 88.07200 96.44000
96 2 88.01000 92.66600 100.8800
98 2 91.89500 96.74900 105.4300
100 2 95.05100 100.0000 109.0600

# Target Camera Gamma
Gamma_Curve 1.0 2.555555

# Display Gamut Measurements
Gamut_Measurements 2
44.52300 24.20800 2.091800
31.72700 65.82100 10.34800
18.22600 9.450000 95.30100
95.05100 100.0000 109.0600
My display is calibrated to a 2.222222 Display Gamma Power Curve with Argyll.

Gamma_Curve 1.0 2.5
Correct color temperature, Display Gamma 2.17

Gamma_Curve 1.0 2.6
Correct color temperature, Display Gamma 2.28

Gamma_Curve 1.0 2.555555
Horrible color temperature, Display Gamma 2.21

For whatever reason, when I used the above 3DLUT with Gamma_Curve 2.55555, yCMS undershot the color temperature considerably and was very inconsistent across the entire grayscale range, while Gamma_Curve 1.0 2.5 and Gamma_Curve 1.0 2.6 were just fine overall (with the exception of a couple small color temperature bumps).

yesgrey
8th January 2011, 00:39
I did a bit more investigation, and it appears that those bumps happen when yCMS makes an error targeting the gamma at a particular IRE, or more that there is an unexpected bump in the gamma at the same IRE where there is an unexpected bump in color temperature.
Yes, it's related to that. I'm currently investigating the problem.

My display is calibrated to a 2.222222 Display Gamma Power Curve with Argyll.
I will explain it more deeply when I reply to the gamma part, but if that's what you want why don't you stop using the BT.709 gamma curve (or camera as you call it), and simply use:
Gamma_Curve 0.0 2.222222
to get the response you want? If you read the manual you can see that curveType 0.0 is a pure power curve (or display gamma as you call it).;)

janos666
8th January 2011, 01:02
Your last post reminds me to a problem: Sometimes I have to use 0.0 number format as an input value because a simple 0 is denied.
It happened when I copy-pasted values from excel. I had to manually correct it or change the type from number to text and enter 0.0 manually first.

yesgrey
8th January 2011, 01:52
Sometimes I have to use 0.0 number format as an input value because a simple 0 is denied.
That's strange, but unless you show me a specific example it would be hard to fix because I don't know where to look at.

cyberbeing
8th January 2011, 02:08
why don't you stop using the BT.709 gamma curve (or camera as you call it), and simply use:
Gamma_Curve 0.0 2.222222
to get the response you want? If you read the manual you can see that curveType 0.0 is a pure power curve (or display gamma as you call it).;)

When I tried it in 0.18 awhile back, I seemed to get a totally different gamma then I specified. I just tried it in 0.19 and it seems to work properly now, which is good to know.
Edit: It seems grayscale color correction is much worse with Gamma_Curve 0.0 2.22222 then Gamma_Curve 1.0 2.6 is. I'm beginning to wonder if yCMS just doesn't like Gamma curves of more than a single decimal place.

The problem is that I actually do want BT.709 video displayed with a BT.709 gamma curve, so Gamma_Curve 1.0 is the only option. Gamma_Curve 1.0 modifies your current gamma curve to match the input gamma curve, correct? For that reason I need yCMS to scale the BT.709 curve as close to my calibrated gamma curve as possible, so only a minimal adjustment is made and the average gamma of my screen doesn't change. The answer appears to be Gamma_Curve 1.0 2.555555, but grayscale color correction is broken with that particular gamma for some reason.

If you are wondering why I'm calibrating to a 2.222222 power curve in Argyll, it's for simplicities sake (Previously I was calibrating to a 2.22 sRGB curve with BasICColor, since a sRGB curve is similar to the BT.709 curve). It's hard to target a specific gamma with BT.709 in Argyll, since it bases it on ambient light measurements. The last time I tried, I ended up with a BT.709 curve with a Display Gamma of ~2.7 or something which would be the equivalent of something like Gamma_Curve 1.0 3.0 in yCMS.

yesgrey
9th January 2011, 11:47
if its not too much of an inconvenience, yes please.
I've thought about it and it would take me a lot of time, while you should be able to find a good match with some trial and error in a few minutes.

Sorry.:(

Thunderbolt8
9th January 2011, 13:39
alright then, nvm.

cyberbeing
9th January 2011, 18:12
Furthermore, I don't believe any studios would master any movies with a BT.709 transfer function with a 2.6 gamma.;)

Now that your image attachment finally got approved day later, in relation to this comment, I'm unsure where you are getting these ideas from.

Your default BT.709 curve in yCMS (what yCMS calls 2.222222) effectively de-gamma's the image to produce a linear 1.0 gamma. Nothing would be mastered at a linear gamma, since it does not have the correct contrast enhancement suitable for viewing. The BT.709 gamma would be increased by power function to a average display gamma of 2.2-2.6 (BT.709 w/ 1.175-1.375 power function) at which it would be mastered.

That said, what yCMS considers a BT.709 2.6 gamma (or BT.709 /w 1.2 power function), would actually be very close to the absolute minimum gamma acceptable for mastering.

Edit: On a somewhat unrelated note, yCMS "Gamma_Curve 1.0" doesn't even produce the BT.709 camera gamma you specify. "Gamma_Curve 1.0 2.5" actually produces a 2.6 camera gamma, and "Gamma_Curve 1.0 2.6" produces a 2.7 camera gamma. Since you are currently looking into gamma bugs in yCMS you are probably already aware of this, but if not it's worth noting when fixing things.

Edit2: I gave calibrating to BT.709 in Argyll another try, since it's been many revisions since I tried last time. By setting Ambient Light in Argyll to 32 lux, I ended up with a BT.709 curve with an average gamma of 2.38 which is acceptable. I'm now convinced that yCMS gamma correction is broken, since after I set Gamma_Curve 1.0 2.7, yCMS appeared to be turning my BT.709 curve into a 2.38 power curve. Could you add an option to yCMS to use Grayscale_Measurements for color correction, but leave the gamma as-is?

janos666
12th January 2011, 00:15
[...] after the gamut correction, you will see the less saturated primaries, which have lower RGB values than the uncorrected ones, hence the not clipping at the 235 point as would happen with the uncorrected ones.

It's just weird. And it's strange after lcms2 in MPC-HC doesn't cause anything like this. (On the other hand, lcms likes to cause near-black banding. :()

That's strange, but unless you show me a specific example it would be hard to fix because I don't know where to look at.
Try this:
Input_Transfer_Function 1 0 0.425531915 0
As I can remember, this caused the problem for me but I didn't check it again (sorry).

BeNooL
26th January 2011, 19:19
A somewhat long time ago I tried to use yCMS with my poor HCFR colorimeter and was not able to achieve much. The quality of the meter was definitively to blame so I just let it be.

Things have changes since as I bought a decent meter. I was eager to give yCMS a new try and would like to relate here the results.

First of all, I calibrated my display with my primary source, an Oppo BDP-83, using the AVS HD709 patterns disc. The display has no CMS but has a White Balance menu allowing adjustment of primaries' gain/bias. The following results were obtained (calibration software CalMAN 4):
http://img511.imageshack.us/img511/793/oppobdp83whitebalance.th.png (http://img511.imageshack.us/i/oppobdp83whitebalance.png/)
A very nice white balance after calibration especially in the 20-80 IRE range. It rises at extremities but remains under 2.

http://img31.imageshack.us/img31/3422/oppobdp83gamut.th.png (http://img31.imageshack.us/i/oppobdp83gamut.png/)
Having no CMS I can't do much here but results are not too catastrophic


Now to move on the PC.
Initial measurements without any correction. Using MPC-HC with madVR on an ATI 4550 set in RGB PC Standard mode.
http://img375.imageshack.us/img375/1323/pcwhitebalancenormal.th.png (http://img375.imageshack.us/i/pcwhitebalancenormal.png/)
quite a different WB from before

http://img227.imageshack.us/img227/871/pcgamutnormal.th.png (http://img227.imageshack.us/i/pcgamutnormal.png/)
white point moved but we basically have the same extended gamut


After measurements were done with ArgyllCMS, I compiled this input file for yCMS.

Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Gamut_Measurements 2
49.787 22.566 0.39131
26.635 70.618 1.0149
16.223 6.3478 93.516
92.336 99.857 92.722
Grayscale_Measurements
0.40984 2 0.19656 0.2173 0.29234
0.81967 2 0.19704 0.21693 0.29294
1.2295 2 0.20501 0.21997 0.2967
1.6393 2 0.22411 0.22729 0.31592
2.0492 2 0.23832 0.2355 0.33466
2.459 2 0.25738 0.25113 0.35658
2.8689 2 0.28234 0.27719 0.39714
3.2787 2 0.31349 0.3033 0.42918
3.6885 2 0.31395 0.29871 0.4408
4.0984 2 0.3427 0.33095 0.47644
4.5082 2 0.38989 0.37029 0.52448
4.918 2 0.48421 0.45961 0.63333
5.3279 2 0.52503 0.50603 0.68509
5.7377 2 0.57961 0.55097 0.74415
6.1475 2 0.57323 0.55014 0.7402
6.5574 2 0.64953 0.62507 0.81154
6.9672 2 0.70777 0.68133 0.88415
7.377 2 0.7664 0.74397 0.94728
7.7869 2 0.85319 0.83235 1.0304
8.1967 2 0.87866 0.85696 1.0578
8.6066 2 0.88026 0.85462 1.0568
9.0164 2 0.89526 0.88149 1.0808
9.4262 2 0.94857 0.92353 1.1312
9.8361 2 0.97063 0.94927 1.1568
10.246 2 0.99381 0.97357 1.1757
10.656 2 1.0192 1.0002 1.2087
11.066 2 1.0698 1.0517 1.2497
11.475 2 1.0685 1.0537 1.261
11.885 2 1.1534 1.1344 1.3367
12.295 2 1.202 1.1868 1.3876
12.705 2 1.289 1.2752 1.4723
13.115 2 1.3713 1.3692 1.5595
13.525 2 1.5 1.4973 1.6805
13.934 2 1.6334 1.6416 1.8035
14.344 2 1.76 1.7816 1.9319
14.754 2 1.9058 1.9299 2.0594
15.164 2 2.0138 2.0483 2.1622
15.574 2 2.1676 2.2094 2.3034
15.984 2 2.2929 2.3405 2.4187
16.393 2 2.292 2.3443 2.419
16.803 2 2.4317 2.4944 2.5668
17.213 2 2.5907 2.6752 2.698
17.623 2 2.7138 2.8061 2.8197
18.033 2 2.8954 2.9976 2.9809
18.443 2 3.0273 3.146 3.0985
18.852 2 3.1612 3.2948 3.2328
19.262 2 3.1682 3.2973 3.2418
19.672 2 3.3454 3.4958 3.3945
20.082 2 3.5388 3.7048 3.6086
20.492 2 3.6934 3.8684 3.7684
20.902 2 3.8855 4.0938 3.974
21.311 2 4.0982 4.3077 4.1856
21.721 2 4.2168 4.4276 4.3017
22.131 2 4.2148 4.4248 4.3039
22.541 2 4.4809 4.7505 4.5994
22.951 2 4.8206 5.1118 4.9473
23.361 2 4.997 5.3138 5.1068
23.77 2 5.1829 5.5182 5.3173
24.18 2 5.1842 5.5125 5.3034
24.59 2 5.4204 5.7498 5.5862
25 2 5.6198 5.9803 5.7705
25.41 2 5.8239 6.2164 6.0138
25.82 2 5.9833 6.401 6.1631
26.23 2 6.0953 6.5386 6.2748
26.639 2 6.3213 6.7667 6.4656
27.049 2 6.4557 6.9363 6.589
27.459 2 6.6758 7.1523 6.8276
27.869 2 6.8222 7.333 6.9925
28.279 2 6.9753 7.4911 7.1772
28.689 2 7.1768 7.6874 7.3836
29.098 2 7.3701 7.8973 7.6002
29.508 2 7.5364 8.0962 7.7717
29.918 2 7.6371 8.2271 7.9247
30.328 2 7.9014 8.5347 8.1841
30.738 2 8.1069 8.7287 8.4185
31.148 2 8.3125 8.9659 8.6419
31.557 2 8.5085 9.1857 8.8023
31.967 2 8.8415 9.5592 9.1487
32.377 2 9.0827 9.8345 9.4105
32.787 2 9.269 10.026 9.6175
33.197 2 9.4961 10.24 9.8378
33.607 2 9.6921 10.479 10.051
34.016 2 9.938 10.748 10.312
34.426 2 10.182 11.002 10.544
34.836 2 10.347 11.207 10.712
35.246 2 10.657 11.527 11.057
35.656 2 10.86 11.729 11.256
36.066 2 11.148 12.083 11.542
36.475 2 11.413 12.334 11.868
36.885 2 11.67 12.641 12.045
37.295 2 11.877 12.897 12.18
37.705 2 12.119 13.16 12.352
38.115 2 12.339 13.359 12.706
38.525 2 12.624 13.694 12.996
38.934 2 12.972 14.073 13.385
39.344 2 13.247 14.361 13.627
39.754 2 13.479 14.624 13.844
40.164 2 13.703 14.883 14.097
40.574 2 14.019 15.215 14.448
40.984 2 14.62 15.879 15.016
41.393 2 14.911 16.188 15.308
41.803 2 15.134 16.452 15.55
42.213 2 15.508 16.862 15.982
42.623 2 15.748 17.181 16.216
43.033 2 16.016 17.386 16.487
43.443 2 16.329 17.759 16.733
43.852 2 16.632 18.076 17.052
44.262 2 16.908 18.37 17.368
44.672 2 17.26 18.802 17.744
45.082 2 17.661 19.198 18.106
45.492 2 17.876 19.477 18.337
45.902 2 18.199 19.754 18.694
46.311 2 18.528 20.186 19.17
46.721 2 18.803 20.537 19.264
47.131 2 19.137 20.849 19.633
47.541 2 19.472 21.238 19.951
47.951 2 19.674 21.479 20.119
48.361 2 20.119 21.979 20.582
48.77 2 20.432 22.192 21.021
49.18 2 20.793 22.6 21.397
49.59 2 21.144 22.965 21.808
50 2 21.885 23.816 22.288
50.41 2 22.236 24.211 22.597
50.82 2 22.654 24.689 23.05
51.23 2 23.057 25.074 23.54
51.639 2 23.413 25.504 23.88
52.049 2 23.886 25.986 24.354
52.459 2 24.353 26.512 24.842
52.869 2 24.583 26.773 25.031
53.279 2 25.008 27.23 25.561
53.689 2 25.437 27.744 25.867
54.098 2 25.895 28.193 26.3
54.508 2 26.139 28.434 26.616
54.918 2 26.613 28.948 27.143
55.328 2 26.987 29.36 27.58
55.738 2 27.423 29.908 27.919
56.148 2 27.84 30.313 28.368
56.557 2 28.283 30.756 28.844
56.967 2 28.764 31.364 29.268
57.377 2 28.998 31.57 29.398
57.787 2 29.529 32.097 29.96
58.197 2 29.942 32.487 30.416
58.607 2 30.429 33.14 30.854
59.016 2 30.961 33.7 31.46
59.426 2 31.792 34.691 32.189
59.836 2 32.223 35.122 32.657
60.246 2 32.73 35.617 33.247
60.656 2 33.11 35.985 33.661
61.066 2 33.527 36.437 33.945
61.475 2 34.066 37.04 34.551
61.885 2 34.645 37.61 34.985
62.295 2 34.895 38.052 35.356
62.705 2 35.432 38.627 35.903
63.115 2 35.823 39.041 36.231
63.525 2 36.258 39.498 36.796
63.934 2 36.804 40.1 37.255
64.344 2 37.402 40.799 37.981
64.754 2 37.725 41.199 37.947
65.164 2 38.22 41.757 38.422
65.574 2 38.719 42.343 38.799
65.984 2 39.184 42.815 39.352
66.393 2 38.033 41.4 38.268
66.803 2 40.109 43.853 40.25
67.213 2 40.722 44.545 40.982
67.623 2 41.177 44.977 41.424
68.033 2 41.756 45.608 42.121
68.443 2 42.695 46.717 42.968
68.852 2 43.064 47.185 43.174
69.262 2 43.731 47.778 43.915
69.672 2 44.305 48.415 44.378
70.082 2 44.796 49.091 45.117
70.492 2 45.309 49.589 45.663
70.902 2 45.82 50.168 46.094
71.311 2 46.379 50.84 46.665
71.721 2 46.8 51.473 47.011
72.131 2 47.577 52.069 47.972
72.541 2 48.048 52.472 48.153
72.951 2 48.411 52.791 48.697
73.361 2 49.067 53.576 49.231
73.77 2 49.614 54.257 49.756
74.18 2 50.155 54.886 50.397
74.59 2 50.773 55.497 51.211
75 2 51.306 56.125 51.469
75.41 2 52.078 56.82 52.478
75.82 2 52.609 57.43 52.956
76.23 2 53.358 58.306 53.835
76.639 2 53.478 58.552 53.81
77.049 2 53.941 58.903 54.098
77.459 2 55.251 60.285 55.516
77.869 2 56.034 61.174 56.313
78.279 2 56.647 61.684 57.051
78.689 2 56.944 62.033 57.217
79.098 2 57.766 62.898 57.948
79.508 2 58.332 63.537 58.47
79.918 2 59.148 64.318 59.316
80.328 2 59.902 65.156 60.057
80.738 2 60.219 65.562 60.075
81.148 2 60.984 66.447 60.877
81.557 2 61.438 66.797 61.23
81.967 2 62.124 67.544 61.965
82.377 2 62.716 68.076 62.704
82.787 2 63.477 69.072 63.356
83.197 2 64.041 69.59 63.928
83.607 2 64.828 70.462 64.612
84.016 2 65.206 70.902 64.954
84.426 2 65.905 71.776 65.634
84.836 2 66.443 72.185 66.337
85.246 2 67.096 72.712 67.037
85.656 2 67.868 73.556 67.583
86.066 2 68.395 74.22 68.242
86.475 2 69.55 75.379 69.288
86.885 2 70.308 76.098 70.227
87.295 2 71.072 77.068 70.863
87.705 2 71.606 77.531 71.45
88.115 2 72.216 78.178 72.151
88.525 2 73.074 79.19 73.349
88.934 2 73.808 79.994 73.545
89.344 2 74.162 80.329 73.773
89.754 2 74.849 81.055 74.398
90.164 2 75.688 81.953 75.486
90.574 2 76.47 82.903 75.999
90.984 2 77.163 83.479 77.073
91.393 2 77.949 84.333 77.822
91.803 2 78.276 84.674 78.043
92.213 2 79.323 85.772 79.232
92.623 2 79.815 86.289 79.665
93.033 2 80.812 87.452 80.735
93.443 2 81.489 88.31 81.464
93.852 2 82.149 88.881 82.168
94.262 2 83.037 89.858 83.042
94.672 2 83.422 90.212 83.392
95.082 2 84.298 91.215 84.435
95.492 2 85.762 92.857 85.832
95.902 2 86.849 94.316 86.774
96.311 2 87.367 94.708 87.364
96.721 2 88.171 95.28 88.555
97.131 2 88.234 95.453 88.149
97.541 2 89.047 96.407 88.832
97.951 2 89.849 97.238 89.8
98.361 2 90.709 98.243 90.559
98.77 2 91.526 99.116 91.768
99.18 2 92.195 99.846 92.398
99.59 2 92.409 99.985 92.726
100 2 92.336 99.857 92.722

It does complain about some inaccurate measurements:
Warning: Grayscale measurement on line 49 might be inaccurate.
Warning: Grayscale measurement on line 42 might be inaccurate.
Warning: Grayscale measurement on line 30 might be inaccurate.
Warning: Grayscale measurement on line 23 might be inaccurate.
The file '..\HD - PC.3dlut' was successfully created.
Running time: 6703ms; Computation time: 5718ms (85.3%)
but does complete.

The same measurements were done again this time with 3D LUT active in madVR:
http://img827.imageshack.us/img827/2350/pcwhitebalanceycms.th.png (http://img827.imageshack.us/i/pcwhitebalanceycms.png/)
Each primary has been flattened but no correction on the blue shift

http://img208.imageshack.us/img208/3784/pcgamutycms.th.png (http://img208.imageshack.us/i/pcgamutycms.png/)
on the gamut side, the improvement is quite clear but white point hasn't moved

And that's it. I'm really posting those results to check with you if that's the expected behavior of yCMS or if you can see a flaw in the measurement process applied.

Subjectively (and I saved that for the bottom line) the picture with the PC and CMS looks absolutely stunning! I think I'll buy an external CMS solution so that all sources can benefit from it.

janos666
26th January 2011, 20:13
What is your current sensor? Is it a colorimeter or a spectrophotometer? I am not familiar with this software and it's GUI. But for the fist look, it looks like your primaries are still out of the map (and the world of current display technologies).
May be it's only a presentation fault and their CIE diagram is not the usual full CIE chart. Or you are still using an incompatible instrument.

I think you should include the IRE_0.000 to get black point compensation.

By the way, if your display work with only 8 bit internal precision then you shouldn't use the RGB Gains. It will cause big rounding errors.
Check a gray gradient test image to see if the hardware adjustments cause banding or not. If the gradient is still smooth then use them. If it has visible banding than restore the defaults (or try to find a spot where you have the most available shades to start with) and leave them alone.

yesgrey
27th January 2011, 00:37
I was eager to give yCMS a new try and would like to relate here the results.
Thanks for such a detailed test. I will analyse your results to see if I can find the reason for your results. It seems the color balance is still not working OK...

BeNooL
27th January 2011, 14:48
What is your current sensor? Is it a colorimeter or a spectrophotometer? I am not familiar with this software and it's GUI. But for the fist look, it looks like your primaries are still out of the map (and the world of current display technologies).
May be it's only a presentation fault and their CIE diagram is not the usual full CIE chart. Or you are still using an incompatible instrument.

I think you should include the IRE_0.000 to get black point compensation.

By the way, if your display work with only 8 bit internal precision then you shouldn't use the RGB Gains. It will cause big rounding errors.
Check a gray gradient test image to see if the hardware adjustments cause banding or not. If the gradient is still smooth then use them. If it has visible banding than restore the defaults (or try to find a spot where you have the most available shades to start with) and leave them alone.

Yes the gamut points out of the chart have me worried a bit too. I'll have to try again another time to check if this is reproducible but I'm a bit fed up with doing measurements at the moment :)

The sensor is a variant of the Eye-One Display 2 called X2 and sold by Spectral.

Thanks for the advise on RGB gains. I'll check but most of the corrections were done with the bias controls.

janos666
27th January 2011, 21:40
The sensor is a variant of the Eye-One Display 2 called X2 and sold by Spectral.

It seems you didn't really learn about the last incident with improper sensors...
The gamut looks over-saturated because the Eye One is an old colorimeter which couldn't work on any wide gamut displays on it's own. You have two choices:
- Buy an own spectrophotometer (like the EyeOne Pro or the ColorMunki).
- Rent a spectrophotometer and use it to make a custom correction matrix for your given WCG-display+colorimeter combination. It will be usable with ArgyllCMS. And I think you can use it with CalMan too (not the ArgyllCMS specific file itself but this is basically 9 numbers in a 3x3 matrix. It won't require too much skills to edit some text files with notepad and insert these numbers in the proper format for different softwares...)
- If you would have a retail i1d2 (not an OEM one as you said), you could send it back to the factory (X-Rite) for factory-recalibration and ask for a new firmware which has some preset matrices too. -> Nearly as expensive as a new instrument (and a better instrument if you consider the spectros...)

adam777
28th January 2011, 09:58
Hello all,
I don't mean to disrupt the flow of this wonderful discussion, but I have a small question of my own.
I'm using a plain notebook screen as my main display device, so obviously I will not calibrate it in any way.
Considering the above, is there any advantage of creating vanilla 3DLUTs using the templates for use in madVR comparing to not using 3DLUTs at all?
Thanks in advance, Adam.

janos666
28th January 2011, 13:09
I'm using a plain notebook screen as my main display device, so obviously I will not calibrate it in any way.
Considering the above, is there any advantage of creating vanilla 3DLUTs using the templates for use in madVR comparing to not using 3DLUTs at all?


No.
May be if you can find an ICC profile for you display (manufacturer's website, forums or review sites where somebody uploaded one) you can read out the gamut coordinates which may help a bit with color saturation (TNs usually have narrow gamuts).

yesgrey
6th February 2011, 18:22
yCMS v1.10 released

http://yesgrey.com/ycms.html

- Added support for sYCC and xvYCC.
- Added sYCC, xvYCC_HD and xvYCC_SD videoStandards to Input/Output_Format.
- Added sYCC and xvYCC videoStandards to Input/Output_Transfer_Function.
- Fixed bug that caused some commands to not accept integers as FP values.
- Added Necsel videoStandard to Input/Output_Primaries.


This is a version with preliminary support for sYCC and xvYCC. I don't have any source files in any of these formats, so I cannot be sure that it's working fine. Please test and report the results.

I have added the Necsel primaries (laser) to help people test the new formats, because it would be able to hold almost all the colors. However, don't forget that when watched on a display with standard primaries the colors would be wrong, it is only for testing purposes.

I am still working on the related problems about the color balance correction.

cyberbeing
7th February 2011, 07:28
Could you add an option to yCMS to use Grayscale_Measurements for color correction, but leave the gamma as-is?
Do you plan to implement this request?

An option to use the gamma curve yCMS calculates from Grayscale_Measurements as the target gamma, instead of the Gamma_Curve parameter?

Was there anything else minor changed in yCMS 0.10 which would warrant recreation of 3DLUTs from 0.9? It doesn't sound like it, but just making sure.

yesgrey
7th February 2011, 14:34
Do you plan to implement this request?
I will think about it.

Was there anything else minor changed in yCMS 0.10 which would warrant recreation of 3DLUTs from 0.9?
No. Previous 3DLUTs are still valid.

starlight2
12th February 2011, 15:41
hello guys, I tried to use 3dlut but when active madvr tells me: "ready 3dlut file header failed. " Ycms and 'the latest version, I tried different strings but I always get the same error.
This' is an example:

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# Display Gamut Measurements
Gamut_Measurements 2
44.52300 24.20800 2.091800
31.72700 65.82100 10.34800
18.22600 9.450000 95.30100


Help me? Thanks!

yesgrey
12th February 2011, 16:49
# Display Gamut Measurements
Gamut_Measurements 2
44.52300 24.20800 2.091800
31.72700 65.82100 10.34800
18.22600 9.450000 95.30100

Your Gamut_Measurements command is missing the last line, the white point measurements.

starlight2
12th February 2011, 16:58
You can post an example please refer to? So 'copy and paste the file into the HD-video.3dlut and see if it works?
Sorry for my english!

cyberbeing
12th February 2011, 17:19
Gamut_Measurements 2
44.52300 24.20800 2.091800
31.72700 65.82100 10.34800
18.22600 9.450000 95.30100
Those measurements look familiar... they're ones I posted in this thread... starlight2, you need to use measurements from your own display. Using mine won't help at all.

Do not paste text into a 3DLUT file. yCMS needs to create the 3DLUT.

Navigate to C:\...\madVR\yCMS\

Run yCMS.exe "template - HD - PC.txt" "HD - PC"

Copy 96MB "HD - PC.3dlut" to C:\...\madVR\ directory.

yesgrey
12th February 2011, 17:23
You can post an example please refer to? So 'copy and paste the file into the HD-video.3dlut and see if it works?
Sorry for my english!
When you measured your display's primaries, it was supposed that you also had measured you display's white point... That would be the correct approach.

As a quick solution, just for you to make it work for now, use this (the bold line is what's missing in your file):
Gamut_Measurements 2
44.52300 24.20800 2.091800
31.72700 65.82100 10.34800
18.22600 9.450000 95.30100
95.04560 100.0000 108.90578

starlight2
12th February 2011, 17:37
I know I have to do measurements on my display but I wanted to see if it worked temporarily with some string, I just copied from you:)
However I did not understand how it works ..
The procedure that I do and I 'as follows:
1) Within the folder Madvr / Ycms yCMS.exe and then run it (it does not open anything and does not create any files)
2) Within the root / madvr and open with both blocknote (HD - PC.3dlut) that (HD - Video.3dlut), paste it into parameters like this:

Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Gamut_Measurements 2
70.28325 31.64575 1.074425
24.9915 84.4635 11.7725
23.6385 8.894625 124.175
118.385 124.48 136.145

Then I open a MKV with MPCHC ---- ---- madvr 3dlut active but the screen goes black and I get this error in red:
Ready 3dlut file header failed "