Discussion:
Is CIE XYZ really absolute color space?
(too old to reply)
Tomáš Pažourek
2014-04-08 08:22:14 UTC
Permalink
Absolute color space means that its colors are unambiguous, that is, the interpretations of colors in the space are colorimetrically defined without reference to external factors.
CIEXYZ and sRGB are examples of absolute color spaces, as opposed to a generic RGB color space.
(...)
The L*a*b* is sometimes referred to as absolute, though it also needs a white point specification to make it so.
I deduce from this that when I have a color vector in sRGB space, I can find the same color described by some vector in XYZ color space.

However the [Bruce Lindbloom's CIE Color Calculator][2] can convert one sRGB color into several XYZ colors depending on the reference white point chosen. Why does the reference white point matter? Shouldn't the result be the same? Both input and output color spaces are absolute.

In the [description of the RGB-XYZ conversion algorithm][3] there is stated that the resulting XYZ values will be relative to the same reference white as the RGB system. In sRGB color system that would mean that the output of the algorithm is XYZ relative to D65. How do I get the output in absolute XYZ color space without the needed D65?

Disclaimer:
*I assume that I probably have a misunderstanding of some concept, but I keep reading the facts over and over and I cannot find it.*

[1]: http://en.wikipedia.org/wiki/Absolute_color_space
[2]: http://www.brucelindbloom.com/index.html?ColorCalculator.html
[3]: http://www.brucelindbloom.com/index.html?Eqn_RGB_to_XYZ.html
Ingo Thies
2014-04-09 20:10:21 UTC
Permalink
Post by Tomáš Pažourek
However the [Bruce Lindbloom's CIE Color Calculator][2] can convert
one sRGB color into several XYZ colors depending on the reference
white point chosen. Why does the reference white point matter?
Shouldn't the result be the same? Both input and output color spaces
are absolute.
The ambiguity of an RGB color space is with the definition of what is
"white". Naively, one would tend to define white as equal powers for
each primary red, green and blue. But depending mainly on the peak
wavelength and peak width, this can result in different whites.
Moreover, the equal-energy "white" may not be the desired whitepoint.
Therefore, a whitepoint definition independent from the XYZ coordinates
of the primaries is needed to define the neutral point where the
primaries are considered equal-valued.

This is also true for sRGB, but here the convention defines D65 as the
unique whitepoint of sRGB (although it is easy to use another
whitepoint, but then it is no longer sRGB, strictly speaking).
Post by Tomáš Pažourek
mean that the output of the algorithm is XYZ relative to D65. How do
I get the output in absolute XYZ color space without the needed D65?
D65 is simply part of the definition of sRGB, so there is no degree of
freedom for the reference white. The same is true for other RGB spaces
like e.g. Adobe RGB, which uses D50 as reference, so it is absolute as
well. But RGB in general is not since it refers to a family of color
spaces rather than a well-defined one. That is my understanding of it.

Ingo
gr
2014-04-11 03:04:54 UTC
Permalink
Post by Tomáš Pažourek
Absolute color space means that its colors are unambiguous, that is, the interpretations of colors in the space are colorimetrically defined without reference to external factors.
CIEXYZ and sRGB are examples of absolute color spaces, as opposed to a generic RGB color space.
(...)
The L*a*b* is sometimes referred to as absolute, though it also needs a white point specification to make it so.
I deduce from this that when I have a color vector in sRGB space, I can find the same color described by some vector in XYZ color space.
However the [Bruce Lindbloom's CIE Color Calculator][2] can convert one sRGB color into several XYZ colors depending on the reference white point chosen. Why does the reference white point matter? Shouldn't the result be the same? Both input and output color spaces are absolute.
In the [description of the RGB-XYZ conversion algorithm][3] there is stated that the resulting XYZ values will be relative to the same reference white as the RGB system. In sRGB color system that would mean that the output of the algorithm is XYZ relative to D65. How do I get the output in absolute XYZ color space without the needed D65?
*I assume that I probably have a misunderstanding of some concept, but I keep reading the facts over and over and I cannot find it.*
[1]: http://en.wikipedia.org/wiki/Absolute_color_space
[2]: http://www.brucelindbloom.com/index.html?ColorCalculator.html
[3]: http://www.brucelindbloom.com/index.html?Eqn_RGB_to_XYZ.html
For real absolute color , spectral reflectance is the way to go! It is
even traceable to NIST!
Thomas Richter
2014-04-11 20:59:52 UTC
Permalink
Post by Tomáš Pažourek
Absolute color space means that its colors are unambiguous, that is, the interpretations of colors in the space are colorimetrically defined without reference to external factors.
I deduce from this that when I have a color vector in sRGB space, I can find the same color described by some vector in XYZ color space.
Correct. For given sRGB coordinates, you get one unique point in XYZ
defined by the primaries of RGB and the sRGB gamma correction.
Post by Tomáš Pažourek
However the [Bruce Lindbloom's CIE Color Calculator][2] can convert one sRGB color into several XYZ colors depending on the reference white point chosen. Why does the reference white point matter? Shouldn't the result be the same? Both input and output color spaces are absolute.
In the [description of the RGB-XYZ conversion algorithm][3] there is stated that the resulting XYZ values will be relative to the same reference white as the RGB system. In sRGB color system that would mean that the output of the algorithm is XYZ relative to D65. How do I get the output in absolute XYZ color space without the needed D65?
Well, it all depends on which problem you want to solve. If you want to
compute *absolute* color values, all you need are indeed the RGB
primaries in XYZ. The coordinates of 1,1,1 in sRGB then give you the XYZ
coordinates of the D65 white in XYZ. Problem solved? Maybe not.

However, this is rarely the problem you want to solve. You typically
have a scene recorded with a specific white point, and want to convert
this scene *perceptually* to a scene in sRGB. Fortunately, or
unfortunately, the human visual system has a white point adaption. A
white recorded with D72 white looks "as white" as a D65 white with a D65
illumination.

That is, if you want *perceptually* convert a scene with one white point
to another, you need an *additional* transformation that shifts the
white point of the scene to the white point of the display device, and
in the above example D72 to D65. Typically, a Bratford transformation is
used for that, which first computes the LMS cone responses from the
input scene, then scales the cone responses accordingly, and then maps
the cone values back into the target scene. It is a rough but often
sufficient approximation.

Or to put it another way: There is a reason why ICC profiles have more
than one "rendering intent". One is "absolute", which does exactly what
you say. But that's often not what is desired. If you want more, you
need one additional information (at least) and this is the white point.

Clearly, with white point adaption in place the coordinate conversion
from RGB to XYZ will (or may) change, depending on your white point in
XYZ in the target scene.

Greetings,

Thomas
Tomáš Pažourek
2014-04-19 17:05:27 UTC
Permalink
Post by Thomas Richter
Post by Tomáš Pažourek
Absolute color space means that its colors are unambiguous, that is, the interpretations of colors in the space are colorimetrically defined without reference to external factors.
I deduce from this that when I have a color vector in sRGB space, I can find the same color described by some vector in XYZ color space.
Correct. For given sRGB coordinates, you get one unique point in XYZ
defined by the primaries of RGB and the sRGB gamma correction.
Post by Tomáš Pažourek
However the [Bruce Lindbloom's CIE Color Calculator][2] can convert one sRGB color into several XYZ colors depending on the reference white point chosen. Why does the reference white point matter? Shouldn't the result be the same? Both input and output color spaces are absolute.
In the [description of the RGB-XYZ conversion algorithm][3] there is stated that the resulting XYZ values will be relative to the same reference white as the RGB system. In sRGB color system that would mean that the output of the algorithm is XYZ relative to D65. How do I get the output in absolute XYZ color space without the needed D65?
Well, it all depends on which problem you want to solve. If you want to
compute *absolute* color values, all you need are indeed the RGB
primaries in XYZ. The coordinates of 1,1,1 in sRGB then give you the XYZ
coordinates of the D65 white in XYZ. Problem solved? Maybe not.
However, this is rarely the problem you want to solve. You typically
have a scene recorded with a specific white point, and want to convert
this scene *perceptually* to a scene in sRGB. Fortunately, or
unfortunately, the human visual system has a white point adaption. A
white recorded with D72 white looks "as white" as a D65 white with a D65
illumination.
That is, if you want *perceptually* convert a scene with one white point
to another, you need an *additional* transformation that shifts the
white point of the scene to the white point of the display device, and
in the above example D72 to D65. Typically, a Bratford transformation is
used for that, which first computes the LMS cone responses from the
input scene, then scales the cone responses accordingly, and then maps
the cone values back into the target scene. It is a rough but often
sufficient approximation.
Or to put it another way: There is a reason why ICC profiles have more
than one "rendering intent". One is "absolute", which does exactly what
you say. But that's often not what is desired. If you want more, you
need one additional information (at least) and this is the white point.
Clearly, with white point adaption in place the coordinate conversion
from RGB to XYZ will (or may) change, depending on your white point in
XYZ in the target scene.
Greetings,
Thomas
Thank you Thomas for a very nice explanation. I now understand the concept much better. I will try to paraphrase your answer, anyone please correct me if I am wrong.

If I have a color in sRGB, there is only one and unique representation of the color in XYZ. But if my use-case is different (lets say I print the source image in sRGB and I use LAB with D50 for the target print), it is very useful to remember that I got the XYZ values from color space, which was using D65 (this is what Bruce Lindbloom probably means as XYZ relative to D65). That way I can do chromatic adaptation of the XYZ colors to D50 before I convert from XYZ to LAB. That should ensure better results in the output LAB, no colors will be cropped.

For example D65 white and few white colors very close to D65 cannot be represented in a color space, which is using D50 as a white point, and will be all represented as D50 white even though they are slightly different. The chromatic adaptation ensures that D65 white in source is adapted to D50 and other colors are scaled accordingly. This means that I don't lose that much color information, as without the adaptation.

The color calculator mentioned in my question probably does both conversion to XYZ and then chromatic adaptation to the desired white point.
Thomas Richter
2014-04-20 11:02:43 UTC
Permalink
Post by Tomáš Pažourek
Thank you Thomas for a very nice explanation. I now understand the concept much better. I will try to paraphrase your answer, anyone please correct me if I am wrong.
If I have a color in sRGB, there is only one and unique representation of the color in XYZ. But if my use-case is different (lets say I print the source image in sRGB and I use LAB with D50 for the target print), it is very useful to remember that I got the XYZ values from color space, which was using D65 (this is what Bruce Lindbloom probably means as XYZ relative to D65). That way I can do chromatic adaptation of the XYZ colors to D50 before I convert from XYZ to LAB. That should ensure better results in the output LAB, no colors will be cropped.
That's correct, yes.
Post by Tomáš Pažourek
For example D65 white and few white colors very close to D65 cannot be represented in a color space, which is using D50 as a white point, and will be all represented as D50 white even though they are slightly different. The chromatic adaptation ensures that D65 white in source is adapted to D50 and other colors are scaled accordingly. This means that I don't lose that much color information, as without the adaptation.
That's not quite correct. If you have a colorspace with D65 white, and
you use or require a chromatic adaption, and your target colorspace uses
a D50 white, then colors close to D65 will end up in colors close to the
D50 white point in the target colorspace. *That* part is not the
problem, the white point adaption maps D65 to D50 exactly (that's kind
of its point). However, what will happen is that some colors in the
extreme points of the D65 RGB gamut might not have a representation in
the colorspace in the D50 colorspace (and vice versa).

Due to chromatic adaption, the primaries of a D65 RGB colorspace will
not map to the primaries of the D50 RGB colorspace, *even if* both RGB
colorspaces are based on the same primaries. The reason is that
chromatic adaption will shift such primaries off-place, and sometimes
out of the gamut of the target colorspace, i.e. chromatic adaption may
make some colors unoptainable. As D65 white has a higher color
temperature than D50, and thus a cooler color, the chromatic adaption
from D65 to D50 will shift all colors somewhat "red-wards", and
especially will move the original D65 red out of gamut if both target
and source colorspace use the same primaries. The D65 red primary is
hence not representable in D50 even with the same primaries.

A color management can now do several things: It can clip off, or it can
make all colors a little bit "duller" to move them back into the target
gamut. Again something that can be expressed by the ICC rendering intent.
Post by Tomáš Pažourek
The color calculator mentioned in my question probably does both conversion to XYZ and then chromatic adaptation to the desired white point.
Maybe. Depends on how it is configured.

Greetings,
Thomas
Dale
2014-09-06 22:37:11 UTC
Permalink
On Tue, 8 Apr 2014 01:22:14 -0700 (PDT), TomᚠPažourek
Shouldn't the result be the =
same? Both input and output color spaces are absolute.
color matching, yes

appearance matching, no

see CIECAM
Dale

Loading...