> Okay, sorry, I didn't think it was possible to compare different color
> spaces like sRGB or Adobe RGB without selecting a white point.

The "basis" of most colour spaces is XYZ. XYZ defines a colour exactly 
(in terms of human perception) with just three numbers. The numbers are 
linear in terms of physical power, so if you have two light sources in 
very close proximity, you can simply add the two XYZ values to get the 
resulting colour. What this means though is that doubling XYZ does not 
give a perceived brightness twice as bright. Note there is no dependency 
on any "white point", the three numbers alone are enough.

sRGB in turn defines exactly what "colour" full red, green and blue are 
in terms of XYZ (you can look up the values). I say "colour", because 
obviously you can scale all the values to get a brighter or dimmer 
result, which is still technically sRGB. There is no white point assumed 
or needed in the definitions of sRGB either. The same goes for Adobe 
RGB, that defines a different set of RGB physical colours.

However, given that RGB are defined in sRGB exactly in terms of physical 
colour, this then defines exactly what physical colour "white" in sRGB 
is, ie if you add up equal ratios of the defined R,G and B, you get what 
is "white" in the sRGB colour space. This happens to be very close to 
D65, I assume by design.

> Still, I would like to plot the horseshoe in 3D, anyway, using a
> specific white point. (Or maybe multiple images, each with a different
> white point.)

Sorry this just doesn't make sense. The "horseshoe" shape is totally 
independent of any white point, "using" a white point to plot it is 
meaningless, the shape is the same and fixed by the XYZ values for each 
wavelength of light only.

Post a reply to this message

Am 29.11.2016 um 13:52 schrieb scott:
>> Okay, sorry, I didn't think it was possible to compare different color
>> spaces like sRGB or Adobe RGB without selecting a white point.
> 
> The "basis" of most colour spaces is XYZ. XYZ defines a colour exactly
> (in terms of human perception) with just three numbers. The numbers are
> linear in terms of physical power, so if you have two light sources in
> very close proximity, you can simply add the two XYZ values to get the
> resulting colour. What this means though is that doubling XYZ does not
> give a perceived brightness twice as bright. Note there is no dependency
> on any "white point", the three numbers alone are enough.
> 
> sRGB in turn defines exactly what "colour" full red, green and blue are
> in terms of XYZ (you can look up the values). I say "colour", because
> obviously you can scale all the values to get a brighter or dimmer
> result, which is still technically sRGB. There is no white point assumed
> or needed in the definitions of sRGB either. The same goes for Adobe
> RGB, that defines a different set of RGB physical colours.
> 
> However, given that RGB are defined in sRGB exactly in terms of physical
> colour, this then defines exactly what physical colour "white" in sRGB
> is, ie if you add up equal ratios of the defined R,G and B, you get what
> is "white" in the sRGB colour space. This happens to be very close to
> D65, I assume by design.

This is not quite true.

sRGB does /not/ explicitly specify what full red, green and blue are.

What sRGB does define is the _xy coordinates_ - i.e. the absolute hue
and saturation - of red, green and blue (aka the "primaries"). This can
be visualized as defining the direction (but not the "length") of the
red, green and blue axes in XYZ space.

sRGB also /does/ explicitly define the _xy coordinates_ of the so-called
"illuminant whitepoint" - i.e. which defines what colours are nominally
"neutral", i.e. entirely desaturated - and also defines that such
neutral colours are to be represented by the red, green and blue
channels all set to the same value (which is typical for RGB colour
models). This can be visualized as defining the direction (but again not
the "length") of the RGB "cube"'s diagonal in XYZ space.

sRGB also /does/ explicitly define the _Y coordinate_ - i.e. the
luminance - of the brightest representable colour: 80 cd/m^2; however,
not everyone adheres to this.

sRGB also defines a host of other things that make matters even more
complicated, namely the "image surround", as well three properties for
both the "encoding" and "typical viewing" conditions: "ambient
illuminance level", "ambient white point" (which is D50, not D65), and
"viewing flare". (And no, don't ask me to explain what these parameters
mean - I barely understand those myself.)


>> Still, I would like to plot the horseshoe in 3D, anyway, using a
>> specific white point. (Or maybe multiple images, each with a different
>> white point.)
> 
> Sorry this just doesn't make sense. The "horseshoe" shape is totally
> independent of any white point, "using" a white point to plot it is
> meaningless, the shape is the same and fixed by the XYZ values for each
> wavelength of light only.

It /does/ make some sense to plot the 3D extension of the horseshoe for
pigment colours under a given illuminant.

It should be noted however that such a plot is non-trivial: It does
/not/ suffice to specify the xy coordinates of the illuminant; the
entire colour spectrum needs to be considered instead. For example with
illuminants from the F series (fluorescent lighting) we can probably
expect the 3D shape to show a distinctive "fingerprint" of the
illuminant's spectral emission lines (though I'm not sure how exactly
this fingerprint would look like).

Post a reply to this message

On 11/29/2016 11:42 AM, clipka wrote:
> It should be noted however that such a plot is non-trivial: It does
> /not/ suffice to specify the xy coordinates of the illuminant; the
> entire colour spectrum needs to be considered instead. For example with
> illuminants from the F series (fluorescent lighting) we can probably
> expect the 3D shape to show a distinctive "fingerprint" of the
> illuminant's spectral emission lines (though I'm not sure how exactly
> this fingerprint would look like).
>

Okay, you've convinced me to give up!

I like to code but suck at math.

;)

Mike

Post a reply to this message

On 11/29/2016 11:42 AM, clipka wrote:
> sRGB also defines a host of other things that make matters even more
> complicated, namely the "image surround", as well three properties for
> both the "encoding" and "typical viewing" conditions: "ambient
> illuminance level", "ambient white point" (which is D50, not D65), and
> "viewing flare". (And no, don't ask me to explain what these parameters
> mean - I barely understand those myself.)

EasyRGB defaults to "Daylight". Isn't that D65?

http://www.easyrgb.com/index.php?X=CALC

ColorMine uses these values:

#declare XYZWhiteReference = color <95.047,100.000,108.883>;
#declare XYZEpsilon = 0.008856;
#declare XYZKappa = 903.3;

Which illuminant does that correspond to? I have no clue, and assumed it 
was D65 as well.

Mike

Post a reply to this message

On 11/29/2016 7:52 AM, scott wrote:
> The "basis" of most colour spaces is XYZ. XYZ defines a colour exactly
> (in terms of human perception) with just three numbers. The numbers are
> linear in terms of physical power, so if you have two light sources in
> very close proximity, you can simply add the two XYZ values to get the
> resulting colour. What this means though is that doubling XYZ does not
> give a perceived brightness twice as bright. Note there is no dependency
> on any "white point", the three numbers alone are enough.

The LAB > XYZ > RGB conversion algorithms I am using simply don't 
*function* without setting a white point, though.

http://colormine.org/

Mike

Post a reply to this message

Am 29.11.2016 um 18:12 schrieb Mike Horvath:
> On 11/29/2016 11:42 AM, clipka wrote:
>> sRGB also defines a host of other things that make matters even more
>> complicated, namely the "image surround", as well three properties for
>> both the "encoding" and "typical viewing" conditions: "ambient
>> illuminance level", "ambient white point" (which is D50, not D65), and
>> "viewing flare". (And no, don't ask me to explain what these parameters
>> mean - I barely understand those myself.)
> 
> EasyRGB defaults to "Daylight". Isn't that D65?

"Daylight" could be D65 - but it could just as well be any other member
of the "Illuminant D series" (D50, D55, D65, D75), each of which
simulates daylight at another time of day, or even illuminant B or C,
both of which were designed as daylight simulations (although that's
unlikely, since these illuminants have been deprecated).

> http://www.easyrgb.com/index.php?X=CALC

Any colour converter that supports a colour space named "RGB" (or "CMY"
or "CMYK", for that matter) without further qualification isn't worth a
rotten bit.

"RGB", "CMY" and "CMYK" aren't colour models - they are colour model
_families_. The minimum additional information required to convert
colours from one of these models into any other model are the colour
coordinates of the primaries, the whitepoint and - since most real-life
RGB colour models don't use linear encoding - the transfer function (aka
"gamma"). Or the official name of the specific member of the family,
which defines these properties via the model's official standard.

For example, "RGB" could be "sRGB" - or it oculd be "CIE RGB", which is
a totally different beast.

> ColorMine uses these values:
> 
> #declare XYZWhiteReference = color <95.047,100.000,108.883>;
> [...]
> 
> Which illuminant does that correspond to? I have no clue, and assumed it
> was D65 as well.

XYZ (95.047,100,108.883) corresponds to xy (95.047,100)/303.93 =
(0.3127,0.3290), which is indeed D65 (presuming XYZ is CIE 1931 XYZ).

(Don't ask me what XYZEpsilon and XYZKappa are.)

Post a reply to this message

Am 29.11.2016 um 18:26 schrieb Mike Horvath:
> On 11/29/2016 7:52 AM, scott wrote:
>> The "basis" of most colour spaces is XYZ. XYZ defines a colour exactly
>> (in terms of human perception) with just three numbers. The numbers are
>> linear in terms of physical power, so if you have two light sources in
>> very close proximity, you can simply add the two XYZ values to get the
>> resulting colour. What this means though is that doubling XYZ does not
>> give a perceived brightness twice as bright. Note there is no dependency
>> on any "white point", the three numbers alone are enough.
> 
> The LAB > XYZ > RGB conversion algorithms I am using simply don't
> *function* without setting a white point, though.
> 
> http://colormine.org/

Of course not. You can't convert to RGB unless you know /what/ RGB model
you're converting to, and whitespace is one of the defining factors.

You will also need to specify the colour primaries, if the conversion
algorithm is any good.

Post a reply to this message

> sRGB does /not/ explicitly specify what full red, green and blue are.
>
> What sRGB does define is the _xy coordinates_ - i.e. the absolute hue
> and saturation - of red, green and blue (aka the "primaries"). This can
> be visualized as defining the direction (but not the "length") of the
> red, green and blue axes in XYZ space.
>
> sRGB also /does/ explicitly define the _xy coordinates_ of the so-called
> "illuminant whitepoint" - i.e. which defines what colours are nominally
> "neutral", i.e. entirely desaturated - and also defines that such
> neutral colours are to be represented by the red, green and blue
> channels all set to the same value (which is typical for RGB colour
> models). This can be visualized as defining the direction (but again not
> the "length") of the RGB "cube"'s diagonal in XYZ space.
>
> sRGB also /does/ explicitly define the _Y coordinate_ - i.e. the
> luminance - of the brightest representable colour: 80 cd/m^2; however,
> not everyone adheres to this.

The exact definition may not be as I simplified to, but the point is the 
same. The "output" of the spec is that XYZ for each of R,G,B are numbers 
that are always the same, there is no dependence on some externally 
provided white point information.

The only additional piece of information you may want to know is if it 
has been scaled above the 80 cd/m^2 standard. eg with an "sRGB" computer 
monitor these are typically nearer 300 cd/m^2, but knowing that you can 
calculate the true colours, there is no need for any additional white point.

Post a reply to this message

Am 30.11.2016 um 09:15 schrieb scott:
>> sRGB does /not/ explicitly specify what full red, green and blue are.
>>
>> What sRGB does define is the _xy coordinates_ - i.e. the absolute hue
>> and saturation - of red, green and blue (aka the "primaries"). This can
>> be visualized as defining the direction (but not the "length") of the
>> red, green and blue axes in XYZ space.
>>
>> sRGB also /does/ explicitly define the _xy coordinates_ of the so-called
>> "illuminant whitepoint" - i.e. which defines what colours are nominally
>> "neutral", i.e. entirely desaturated - and also defines that such
>> neutral colours are to be represented by the red, green and blue
>> channels all set to the same value (which is typical for RGB colour
>> models). This can be visualized as defining the direction (but again not
>> the "length") of the RGB "cube"'s diagonal in XYZ space.
>>
>> sRGB also /does/ explicitly define the _Y coordinate_ - i.e. the
>> luminance - of the brightest representable colour: 80 cd/m^2; however,
>> not everyone adheres to this.
> 
> The exact definition may not be as I simplified to, but the point is the
> same. The "output" of the spec is that XYZ for each of R,G,B are numbers
> that are always the same, there is no dependence on some externally
> provided white point information.

You're right in that respect. The above information was mainly for the
records.

Post a reply to this message

Am 29.11.2016 um 18:08 schrieb Mike Horvath:
> On 11/29/2016 11:42 AM, clipka wrote:
>> It should be noted however that such a plot is non-trivial: It does
>> /not/ suffice to specify the xy coordinates of the illuminant; the
>> entire colour spectrum needs to be considered instead. For example with
>> illuminants from the F series (fluorescent lighting) we can probably
>> expect the 3D shape to show a distinctive "fingerprint" of the
>> illuminant's spectral emission lines (though I'm not sure how exactly
>> this fingerprint would look like).
>>
> 
> Okay, you've convinced me to give up!
> 
> I like to code but suck at math.
> 
> ;)

You've made me curious though, so see povray.binaries.animations for a
series of animated CIE xyY gamuts of various illuminants.

Using meshes instead of isosurfaces, because the latter would have been
virtually impossible to manage.

Even then it took me several attempts before I knew how the problem
could be tackled.


I was rather surprised at first to see that the shape isn't convex,
until I realized that it would only be convex in CIE XYZ space. But then
it becomes rather boring, and its relation to the xy horseshoe less obvious.

Post a reply to this message