yCMS - Color Management System

[janos666]

@cyberbeing
I can notice it with blue colors only but this is the only primary color where the native point does not reach the Rec709 reference point, and it is out of the reference rectangle. I posted my gamut measures in #53
Here is an other blue sample: NLC logo (<- Right click, save as).
I can see some strange things with red colors as well but I can reproduce them with one movie only (Cargo), so it can be some encoding/decoding bug. There are some strange things with red scenes but they looks strange without 3DLUT processing as well. So I think that gamut conversion makes it more strange only. (Closed area, intense red light, red faces...)

@Mark_A_W
Yes. As yesgrey wrote it, we should do gamut correction only with current versions. But I suggested for him to measure the grascale as well if he already placed the instrument on his display because it can be useful in the (near?) future.
The other thing what I suggested that he can use PC softwares for gamma correction through VGA LUT. Some calibration softwares will let you define custom x^y gamma curves or sRGB curve, and a few (expensive) one will let you choose Rec709 or even allow you to define a custom math definition for any complex curves. The result won't be too close to perfect if you do not have 10+ bit output from your VGA but it will be close enough when you want a curve which is close to the native characteristics.

But this is a very complicated story. I was not able to figure it out yet that I should use sRGB or x^2.2 curve for a general purpose home PC. There are some arguments on both sides but I think that there is no one correct answer here. It is more like a recommendation. I used sRGB curve in the last few months but I calibrated my display with x^2.2 same days ago.
And the only software which can do Re709 calibration (as I know) is CalMan. That is more expensive than my EyeOne itself. And I do not want to manually load the VGA LUTs every time I watch movies.

So, my display will be calibrated to sRGB or x^2.2 (with VGA LUT) and I will convert the Rec709 sources with yCMS to match with this characteristic.


@iSeries
Sorry. I feel this is off-topic here, and I am not so familiar with Spyders. May be they can help: Color HCFR Calibration Discussion @ AVS Forum. But it will be some incompatibility with your DLL or device driver version.

[yesgrey]

yCMS v1.2 released

http://yesgrey.com/ycms.html

   - Fixed corruption of blue and red at very low levels.

This is a new version only for fixing the corruption of blue and red at very low levels, noted by several users.

It's still recommended to not use the Grayscale_Measurements command until I fix what's wrong with it.

[yesgrey]

Originally Posted by cyberbeing

so maybe it only effects blue?

Originally Posted by janos666

I can see some strange things with with red colors as well

You were both correct. The bug affected both blue and red at very low levels.

Let me know how it works with v1.2.

Thanks for reporting the problem.

[cyberbeing]

yCMS 1.2 fixes the sample I posted.

Is there a reason why you removed the Out_Of_Gamut_Clipping option which was in cr3dlut? Previously I always used the Simple method (if >1.0 -> 1.0; if <0.0 -> 0.0), which I assume is similar to Relative Colorimetric. Same goes for the Chromatic_Adaptation parameter.

Another thing which would be nice is if yCMS automatically outputted LUTs with the .3dlut extension, unless a different extension is specified.

[janos666]

Originally Posted by yesgrey

The bug affected both blue and red at very low levels.
Let me know how it works with v1.2.

Yes, it is much better now. But still not perfect. Play my sample file and look at the lower right corner. There is some black blocks there with 3LUT processing.
But I think it won't be noticeable in actual movie scenes.

@cyberbeing - I was not able to see any real differences in actual movie scenes between those clipping modes. But I used the simple method.

[yesgrey]

Originally Posted by cyberbeing

Is there a reason why you removed the Out_Of_Gamut_Clipping option

Currently that option is not needed in yCMS.

Originally Posted by janos666

Play my sample file

I can't download it. I only get a 1kB file.

[janos666]

@yesgrey - Try this link.

[yesgrey]

Originally Posted by janos666

Try this link.

I got it, but I also need your configuration file for creating the 3DLUT.

[janos666]

Originally Posted by yesgrey

I got it, but I also need your configuration file for creating the 3DLUT.

Last code area.

Originally Posted by yesgrey

It's still recommended to not use the Grayscale_Measurements command until I fix what's wrong with it.

Will it affect the output_primaries command? I prefer to use that one as I use the VGA LUT to get gamma 2.2

[cyberbeing]

Originally Posted by yesgrey

Currently that option is not needed in yCMS.

Can you explain why you believe it is no longer needed? Doing color correction with a Perceptual rendering intent isn't automatically best for everything you know.

[yesgrey]

Originally Posted by cyberbeing

Doing color correction with a Perceptual rendering intent isn't automatically best for everything you know.

Using simple clipping isn't automatically best for everything you know, also. So, it has to be some kind of a mixed method, which yCMS is doing, hence the not inclusion of such an option.

[cyberbeing]

Originally Posted by yesgrey

Using simple clipping isn't automatically best for everything you know, also.

'Simple clipping' taken literally would actually be Absolute Colorimetric, which you absolutely should not be doing. If by 'simple clipping' you actually mean Relative Colorimetric, then you are correct, which is why you would optimally need two different LUTs. One Perceptual and one Relative Colorimetric, depending on the content. At least that is how it is in the photography ICC color profile world.

Originally Posted by yesgrey

So, it has to be some kind of a mixed method, which yCMS is doing, hence the not inclusion of such an option.

If you are compressing the gamut to preserve out-of-gamut gradients (which may not even matter), you are using a Perceptual method. This results in tone/hue color shifts of all colors which originally fell within the destination color space. This is usually the preferred method if your source has a lot of detail which falls out-of-gamut. If there is just one stray color which is way out-of-gamut, Perceptual can really mess up all your colors.

If you are not compressing the gamut and instead mapping out-of-gamut colors to the closest color in your destination color space, you are using Relative colorimetric. The goal of this method is to keep the original colors which were in-gamut in your destination color space unchanged. This is usually the preferred method if your source detail is mostly in-gamut. The goal is to preserve original colors whenever possible, which is not possible using a Perceptual method.

I don't really see how a mixed method is possible without two different LUTs or intervention of the video renderer. If you would explain what your mixed method was doing, that might help.

If a color is out-of-gamut, does yCMS do?

If if a particular color exists in both source and destination color space, what does yCMS do?

[yesgrey]

Originally Posted by cyberbeing

If a color is out-of-gamut, does yCMS do?

yCMS is not compressing the color gamut. All colors that lay in the destination gamut are untouched, it only changes the colors that lay outside the color gamut. yCMS can use a mixed method because it calculates all possible color combinations, and changes only the problematic ones.

[racerxnet]

I was wondering if a lut file could be created from the information from the panel manufacture. I copied the info and if someone could help I would appreciate it. CHI MEI LCD PANEL

Color Chromaticity


Red R x 0.632 -
R y 0.324 –

Green G x 0.273 -
G y 0.591 –

Blue B x 0.144 -
B y 0.068 –

White W x 0.280 -
W y 0.285

Color Gamut Min 68 Max 72

Thanks,

MAK

[yesgrey]

Originally Posted by racerxnet

I was wondering if a lut file could be created from the information from the panel manufacture.

Add this line to your configurationFile:

Gamut_Measurements 0.632 0.324 0.273 0.591 0.144 0.068 0.280 0.285

Though, don't forget that the ideal situation would be measuring the primaries, because those indicated in the panel might not be accurate enough. However, it might give you a more accurate image than not using any correction at all.

Let us know how it worked.

[cyberbeing]

Originally Posted by yesgrey

yCMS is not compressing the color gamut. All colors that lay in the destination gamut are untouched, it only changes the colors that lay outside the color gamut. yCMS can use a mixed method because it calculates all possible color combinations, and changes only the problematic ones.

So what type of 'changes' are being made to out-of-gamut colors?

You can:
A) Clip them (remove completely)
B) Move all out-of-gamut colors to the closet reproducible tone with no way to distinguish the out-of-gamut tones from your in-gamut tones. (multiple colors on the edge of the destination gamut represented as a single color)
C) Move all out-of-gamut colors to the destination gamut in a way so they are distinguishable from each other and produce smooth gradients (compress the gamut).
D) ????

[flanger216]

I'm still trying to stay afloat in all this colorimetry theory, but I'm hitting a conceptual dead-end:

I was under the impression that chromaticity primaries were an 'immutable' property of your display --- that is, you can tweak color and hue and gain settings as much as you like, but only a true CMS could actually alter the xy coordinates of your display's primaries. However, when I plot my TV's primaries to the CIE chart in HCFR, and then mess with the display settings, it quite clearly affects the shape and accuracy of the triangle on the CIE chart. In other words, my tweaks are affecting the chromaticity primaries, as reported in HCFR. Hue, color, gain, bias and temperature all affect the readings --- some quite severely.

My best attempt at wrapping my brain around this is the following: there are two sets of primaries --- let's call them the 'native' primaries and the 'gamut' primaries --- and the former refers to the full color gamut of which your display is capable, and the latter refers to the color gamut that ultimately results from your display settings (color temp, bias, gain, hue, etc.). HCFR intrinsically can only measure the 'gamut' primaries, because it must take its readings at the end of the display-chain, after the TV has performed its own post-processing.

Is this remotely accurate? Or am I still hopelessly confused? Most importantly, when and how should one measure the primaries for use in yCMS? As an extreme example, if I turn the 'color' control all the way down, the TV renders a black-and-white image, and HCFR would 'measure' the primaries as forming a curved line instead of a triangle at all. But this isn't really true, right? Turning the color saturation all the way down doesn't actually shift the color primaries into a linear curve... I imagine it merely distorts the measurements, not the 'true' chromaticity values of the display. So... for the purposes of using yCMS, should I measure the primaries at factory defaults, or after display calibration? Or am I doing this wrong? Is there some other method to calculate 'native' primaries?

Again, apologies... I'm usually semi-successful at figuring this stuff out, but colorimetry and CMSes are boiling my brains

[cyberlolo]

Originally Posted by flanger216

I'm still trying to stay afloat in all this colorimetry theory, but I'm hitting a conceptual dead-end:

I was under the impression that chromaticity primaries were an 'immutable' property of your display --- that is, you can tweak color and hue and gain settings as much as you like, but only a true CMS could actually alter the xy coordinates of your display's primaries. However, when I plot my TV's primaries to the CIE chart in HCFR, and then mess with the display settings, it quite clearly affects the shape and accuracy of the triangle on the CIE chart. In other words, my tweaks are affecting the chromaticity primaries, as reported in HCFR. Hue, color, gain, bias and temperature all affect the readings --- some quite severely.

My best attempt at wrapping my brain around this is the following: there are two sets of primaries --- let's call them the 'native' primaries and the 'gamut' primaries --- and the former refers to the full color gamut of which your display is capable, and the latter refers to the color gamut that ultimately results from your display settings (color temp, bias, gain, hue, etc.). HCFR intrinsically can only measure the 'gamut' primaries, because it must take its readings at the end of the display-chain, after the TV has performed its own post-processing.

Is this remotely accurate? Or am I still hopelessly confused? Most importantly, when and how should one measure the primaries for use in yCMS? As an extreme example, if I turn the 'color' control all the way down, the TV renders a black-and-white image, and HCFR would 'measure' the primaries as forming a curved line instead of a triangle at all. But this isn't really true, right? Turning the color saturation all the way down doesn't actually shift the color primaries into a linear curve... I imagine it merely distorts the measurements, not the 'true' chromaticity values of the display. So... for the purposes of using yCMS, should I measure the primaries at factory defaults, or after display calibration? Or am I doing this wrong? Is there some other method to calculate 'native' primaries?

Again, apologies... I'm usually semi-successful at figuring this stuff out, but colorimetry and CMSes are boiling my brains

I'm in the same boat.

[yesgrey]

Originally Posted by cyberbeing

So what type of 'changes' are being made to out-of-gamut colors?

Not A), not B), not exactly C). So I would say it's D)...

Originally Posted by flanger216

So... for the purposes of using yCMS, should I measure the primaries at factory defaults, or after display calibration?

I don't have yet the definitive answer for that. Furthermore, it might be the case that it will depend on the display type.
The main goal is the user setting the brightness and the contrast and let yCMS calibrate all the rest, but yCMS it's still a bit far from that...

After I correct the current problems with the Grayscale_Measurements command, I will post some simple instructions, but now, I need to keep my focus on yCMS.

[cyberbeing]

Originally Posted by yesgrey

Not A), not B), not exactly C). So I would say it's D)...

So in other words you don't want to share what you are doing...