> Taken care of by whom? Well, thats a rhetoric question 'cause obviously 
> you do *NOT* use chromatic adaption but again and in more detail: 
> chromatic adaption is *ALWAYS NEEDED* when your target color space uses a 
> whitepoint that differs from D50 and the source xyz is referring to 
> reflective colors (as Munsell) and not to emitted colors (as spectral 
> data).

Doesn't that depend on whether he wants to reproduce the exact XYZ colour on 
his monitor, or the colour that the surface would have looked if lit with 
the same white point as his monitor rather than the original white?

Post a reply to this message

scott wrote:
>> Taken care of by whom? Well, thats a rhetoric question 'cause 
>> obviously you do *NOT* use chromatic adaption but again and in more 
>> detail: chromatic adaption is *ALWAYS NEEDED* when your target color 
>> space uses a whitepoint that differs from D50 and the source xyz is 
>> referring to reflective colors (as Munsell) and not to emitted colors 
>> (as spectral data).
> 
> Doesn't that depend on whether he wants to reproduce the exact XYZ 
> colour on his monitor, or the colour that the surface would have looked 
> if lit with the same white point as his monitor rather than the original 
> white?
> 

I'm talking about the correct conversion xyY to s(c)RGB and nothing 
else. How exact the reproduction on any kind of monitor will be depends 
on quality and calibration of that device and has nothing to do with the 
  color space conversion itself. The second half of your sentence does 
not make much sense.

-Ive

Post a reply to this message

> I'm talking about the correct conversion xyY to s(c)RGB and nothing else.

In that case the idea of a "source whitepoint" is meaningless - xyY 
specifies colours exactly in absolute colour space, there is no need for a 
reference white, nor does one exist.  An xyY colour like (0.3,0.3,10) 
specifies one unique colour exactly, no need for any additional information 
about a white point.

Post a reply to this message

scott wrote:
>> I'm talking about the correct conversion xyY to s(c)RGB and nothing else.
> 
> In that case the idea of a "source whitepoint" is meaningless - xyY 
> specifies colours exactly in absolute colour space,

The CIE calls it a device independent color space.


> there is no need for 
> a reference white, nor does one exist.

The CIE has defined D50 as reference white for the device independent 
xyz color space and e.g. every spectrophotometer including my own one is 
calibrated to D50 for exactly this reason.


An xyY colour like (0.3,0.3,10)
> specifies one unique colour exactly, no need for any additional 
> information about a white point.

There is a strong need to take the reference white and the whitepoint of 
any device dependent target color system (and e.g. RGB or CMY or YCC are 
always device dependent) into account.
You can only ignore refrence white for e.g. converting from CIE xyz to 
CIE L*a*b 'cause L*a*b is also a device independent color space.

-Ive

Post a reply to this message

> The CIE has defined D50 as reference white for the device independent xyz 
> color space and e.g. every spectrophotometer including my own one is 
> calibrated to D50 for exactly this reason.

Sure, but your meter does not use the reference white to calculate xyY 
values, these are calculated directly from the measured spectral response 
using only the colour matching functions - a "reference white" does not 
appear in these calculations at all!

(Your meter *will* use the reference white of D50 to calculate things like 
dominant wavelength, L*a*b* colour, saturation, etc).

> There is a strong need to take the reference white and the whitepoint of 
> any device dependent target color system (and e.g. RGB or CMY or YCC are 
> always device dependent) into account.

Of course, but showing an exactly specified colour (like XYZ, xyY, Yuv etc) 
on an sRGB monitor is a simple process.  You can see the calculation here:

http://en.wikipedia.org/wiki/SRGB#Specification_of_the_transformation

It is completely incorrect to do any chromatic adaption before plugging the 
XYZ values into the calculation.

FWIW, if you do attempt a chromatic adaption, eg from D50 to D65, what you 
are in affect doing is saying "ok these colours come from a reflective 
object lit with D50, now tell me how they will appear if I had instead lit 
it with D65".  I don't understand why you would want to do that if you 
simply want to show a particular xyY colour on a monitor.

> You can only ignore refrence white for e.g. converting from CIE xyz to CIE 
> L*a*b 'cause L*a*b is also a device independent color space.

Err no, CIE L*a*b* colour space *needs* a reference white.  xyY (or XYZ, Yuv 
etc) does not.

Taken from: http://en.wikipedia.org/wiki/Lab_color_space

"Lab values do not define absolute colors unless the white point is also 
specified."

Post a reply to this message

scott wrote:
>> The CIE has defined D50 as reference white for the device independent 
>> xyz color space and e.g. every spectrophotometer including my own one 
>> is calibrated to D50 for exactly this reason.
> 
> Sure, but your meter does not use the reference white to calculate xyY 
> values, these are calculated directly from the measured spectral 
> response using only the colour matching functions - a "reference white" 
> does not appear in these calculations at all!
>
Err, my spectrophotometer has to illuminate the surface to be measured 
to get the reflected spectral data (otherwise everything would obviously 
be just pitch black) and therefor it is calibrated to D50. I can also 
measure spectral emissions (e.g. to calibrate a monitor) but thats a 
different story.


> Of course, but showing an exactly specified colour (like XYZ, xyY, Yuv 
> etc) on an sRGB monitor is a simple process.  You can see the 
> calculation here:
> 
> http://en.wikipedia.org/wiki/SRGB#Specification_of_the_transformation
> 
Thanks for the link but I'm already quite familiar with such things, 
they are part of my per day pay-job.


> It is completely incorrect to do any chromatic adaption before plugging 
> the XYZ values into the calculation.
> 
Err, no.


> FWIW, if you do attempt a chromatic adaption, eg from D50 to D65, what 
> you are in affect doing is saying "ok these colours come from a 
> reflective object lit with D50, now tell me how they will appear if I 
> had instead lit it with D65".  I don't understand why you would want to 
> do that if you simply want to show a particular xyY colour on a monitor.
>
Your main misconception seems to me that you are assuming xyY values are
some given values already there by definition, but within a real world 
work-flow they are almost always the result from measurement of a 
reflected spectrum by a spectrophotometer (like e.g. the Munsell xyY 
values or the ones for the GretagMacbeth Colour Chart or databases for 
real world materials or Pantone colors and so on...). And measurement 
indeed implies that objects are illuminated by some device.

And as you insist on your "showing on a monitor" phrase, this is in fact 
quite complicated and a different beast as using s(c)RGB just as a 
working color space e.g. within POV-Ray (and it seems to become the de 
facto standard there).
sRGB on your monitor also assumes a dominant lighting condition of about 

to take the chromatic adaption of the human visual system into account. 

sounds familiar to you, remember the D50 reference white, even if you 
still seem to thing this doesn't matter.

In other words sRGB as an output device color space requires a viewing 

Therefor *in this case* there has no (mathematical) chromatic adaption 
to be applied as the chromatic adaption is assumed to be done by *your* 
eye/brain system.
How many working places of computer users do you think will match this 
condition? Does yours?

Anyway, for professional environments - where the work flow implies full 
color-management and the closest possible visual color match on various 
devices is needed - there are much more evolved concepts around (defined 
by the CIE and ICC) for taking the environment lighting condition into 
account.

But again, all this is not relevant when using s(c)RGB as a working 
color space and there has something like the Bradford chromatic adaption 
to be applied for given xyY values to make e.g. POV-Ray calculate with 
"good" RGB values.


>> You can only ignore refrence white for e.g. converting from CIE xyz to 
>> CIE L*a*b 'cause L*a*b is also a device independent color space.
> 
> Err no, CIE L*a*b* colour space *needs* a reference white.

Very true. And it just happens that CIE L*a*b is just another 
mathematical representation of the CIE xyz color space where the same 
*need* for reference white exists.


> xyY (or XYZ, Yuv etc) does not.

Wrong. See above.

-Ive

P.S. sorry if I may sound rude when it comes to this subject but not a 
so long time ago I was forced to explain such things more than once a 
day to people who had not the faintest idea what color management is 
about but still did insist in having s strong opinion how such a thing 
should work - and I do not mean you ;). I guess it has something to do 
with the fact that color vision is such a natural thing to humans that 
*everybody* seems to think he has also a basic understanding what color 
science is about...

Post a reply to this message

> Err, my spectrophotometer has to illuminate the surface to be measured

Ah ok - I see where the confusion is now between us.  You are assuming that 
the OP wanted to reproduce the reflective surface that those xyY values were 
measured from, whereas I was just reproducing those exact xyY colours on the 
monitor.  FWIW my colour meter just measures the incoming spectrum, it has 
no light source, in fact we usually use it in a totally dark room.

> Thanks for the link but I'm already quite familiar with such things, they 
> are part of my per day pay-job.

Mine too, but mine is mainly dealing with emitted light, not reflective, I 
suspect that's where the confusion has arisen between us.

> Your main misconception seems to me that you are assuming xyY values are
> some given values already there by definition,

Yes, sorry, the link that was posted here was just a list of xyY values, I 
assumed you just wanted to reproduce those xyY values on an sRGB monitor (in 
the dark), not the colour of some reflective surface that the xyY data was 
originally generated from when viewed under sRGB standard conditions.

> Very true. And it just happens that CIE L*a*b is just another mathematical 
> representation of the CIE xyz color space where the same *need* for 
> reference white exists.

That's not strictly true.  When dealing with reflective surfaces, you need 
to specify the *illuminant* used, but with CIELAB you need to additionally 
specify a reference white - these do not necessarily need to be the same 
thing.  If you are using XYZ (or xyY, Yuv, Yu'v' etc) then you only need 
specify the illuminant.

That is why in our specs for emissive displays, if the customer wants XYZ 
values they just get XYZ values, but if they want CIELAB then the reference 
white needs to be specified for it to make sense.

Post a reply to this message

scott wrote:

> That's not strictly true.  When dealing with reflective surfaces, you 
> need to specify the *illuminant* used, but with CIELAB you need to 
> additionally specify a reference white - these do not necessarily need 
> to be the same thing.  If you are using XYZ (or xyY, Yuv, Yu'v' etc) 
> then you only need specify the illuminant.
> 
> That is why in our specs for emissive displays, if the customer wants 
> XYZ values they just get XYZ values, but if they want CIELAB then the 
> reference white needs to be specified for it to make sense.
> 

Yes, OK, but I always failed to see the reason why anybody would use
L*a*b with e.g. D65 'cause every piece of hardware and any color 
management software I could put my hands on is using D50.

Otherwise I'm happy that things seem to be clear now ;)

-Ive

Post a reply to this message

> Yes, OK, but I always failed to see the reason why anybody would use
> L*a*b with e.g. D65 'cause every piece of hardware and any color 
> management software I could put my hands on is using D50.

In some industries (eg the one I work in) D65 is the "de facto" standard 
used for everything - illuminants, CIELAB reference white, reference for 
dominant wavelength/saturation values, etc.  Every bit of kit I have and 
every piece of software/spreadsheet we use is set up for D65.  I would 
imagine that if some customer came along and started asking for D50 as the 
standard there would be *massive* confusion throughout our department and 
everything would come out wrong :-)  It's just what you're used to I guess.

Post a reply to this message

scott wrote:
> In some industries (eg the one I work in) D65 is the "de facto" standard 
> used for everything - illuminants, CIELAB reference white, reference for 
> dominant wavelength/saturation values, etc.  Every bit of kit I have and 
> every piece of software/spreadsheet we use is set up for D65.  I would 
> imagine that if some customer came along and started asking for D50 as 
> the standard there would be *massive* confusion throughout our 
> department and everything would come out wrong :-)  It's just what 
> you're used to I guess.
> 

Ok then. Somehow I did suspect that such other worlds do exist somewhere 
out in the wild ;)

-Ive

Post a reply to this message