 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm converting a bunch of CIE xyY coordinates to SRGB. Obviously, most
(if not all) colors lies outside the SRGB gamut. However, what's the
best way to "fake" it?
Should I normalize each color based on the minimum and maximum of all
the colors? Should I simply clip values below 0 and above 1?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 10 Nov 2009 01:18:28 +0100, SharkD <mik### [at] gmail com> wrote:
> I'm converting a bunch of CIE xyY coordinates to SRGB. Obviously, most
> (if not all) colors lies outside the SRGB gamut. However, what's the
> best way to "fake" it?
There is no "best" way of dealing with out-of-gamut colours. It depends on
what you want from the image.
Do you want to preserve...
...the in-gamut colours?
...the relationship between colours?
...colour saturation?
Colour space conversion is a complicated subject.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/9/2009 8:07 PM, Fredrik Eriksson wrote:
> There is no "best" way of dealing with out-of-gamut colours. It depends
> on what you want from the image.
>
> Do you want to preserve...
> ...the in-gamut colours?
> ...the relationship between colours?
> ...colour saturation?
>
> Colour space conversion is a complicated subject.
Well, at this stage I'd like to know how to do all three.
However, I am running into additional problems. I am converting the 1929
Munsell data set (http://www.cis.rit.edu/mcsl/online/munsell.php), and
*not a single one* of the colors lies completely within the SRGB gamut.
You can test this by using the color converter found here:
http://www.brucelindbloom.com/index.html?ColorCalculator.html
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD wrote:
> I'm converting a bunch of CIE xyY coordinates to SRGB. Obviously, most
> (if not all) colors lies outside the SRGB gamut. However, what's the
> best way to "fake" it?
>
> Should I normalize each color based on the minimum and maximum of all
> the colors? Should I simply clip values below 0 and above 1?
>
> Mike
Your color conversion from xyY to sRGB as used within your file in
p.b.sf is plain wrong for 3 reasons:
1.) The luminance values given in the table are obviously within a range
of 0 to 100 (thats commonly used) but your xyY -> xyz conversion assumes
luminance within the 0.0 to 1.0 range.
2.) For the xyY to sRGB color conversion you *NEED* also chromatic
adaption (Bradford adaption is commonly used) because xyY uses reference
white D50 while sRGB uses the D65 whitepoint.
3.) No gamma correction for the rgb values! Just set assumed_gamma to
1.0 for POV version prior 3.7.
For an example how it is done right you may want to look at Jaime's
lightsysIV.
Within the file "demo_indoor2.pov" (written by me and part of lightsys)
is the transformation from xyY to rgb used to calculate the colors for
the GretagMacbeth(tm) Color Checker Chart.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/10/2009 8:02 AM, Ive wrote:
> SharkD wrote:
>> I'm converting a bunch of CIE xyY coordinates to SRGB. Obviously, most
>> (if not all) colors lies outside the SRGB gamut. However, what's the
>> best way to "fake" it?
>>
>> Should I normalize each color based on the minimum and maximum of all
>> the colors? Should I simply clip values below 0 and above 1?
>>
>> Mike
>
>
> Your color conversion from xyY to sRGB as used within your file in
> p.b.sf is plain wrong for 3 reasons:
>
> 1.) The luminance values given in the table are obviously within a range
> of 0 to 100 (thats commonly used) but your xyY -> xyz conversion assumes
> luminance within the 0.0 to 1.0 range.
Thanks! That made a big difference.
> 2.) For the xyY to sRGB color conversion you *NEED* also chromatic
> adaption (Bradford adaption is commonly used) because xyY uses reference
> white D50 while sRGB uses the D65 whitepoint.
I think this has already been taken care of since the results of the
function are so similar to the Lindbloom color converter whith SRGB
output set to D65.
> 3.) No gamma correction for the rgb values! Just set assumed_gamma to
> 1.0 for POV version prior 3.7.
I'm not so concerned with whether the colors in the output image are a
100% match since I'm also applying lighting and radiosity and so on.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD wrote:
>> 2.) For the xyY to sRGB color conversion you *NEED* also chromatic
>> adaption (Bradford adaption is commonly used) because xyY uses reference
>> white D50 while sRGB uses the D65 whitepoint.
>
> I think this has already been taken care of since the results of the
> function are so similar to the Lindbloom color converter whith SRGB
> output set to D65.
>
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). You'll see the difference also within Bruce' calculater (when
used right).
>> 3.) No gamma correction for the rgb values! Just set assumed_gamma to
>> 1.0 for POV version prior 3.7.
>
> I'm not so concerned with whether the colors in the output image are a
> 100% match since I'm also applying lighting and radiosity and so on.
>
Especially when you are applying "lighting and radiosity and so on"
you'll have to work within a linear color space (call it scRGB), this
has nothing to do with a 100% match, but I'm not as patient as Christoph
regarding the explanation of gamma issues...
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/10/2009 10:11 AM, Ive 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). You'll see the difference also within Bruce' calculater (when
> used right).
The CIE Color Calculator uses a whitepoint of D65 and Bradford adaption,
an I get nearly identical results.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I looked at lightsys, and is this all I need to do to convert the colors?
color rgb MapGamut(xyz2RGB(ChromaMatchSource(xyY2xyz(coo_xyY))))
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD wrote:
> I looked at lightsys, and is this all I need to do to convert the colors?
>
> color rgb MapGamut(xyz2RGB(ChromaMatchSource(xyY2xyz(coo_xyY))))
>
Yes ;) but don't forget to scale the Y to 0.0 - 1.0 range before feeding
it in. The returned rgb values are not gamma corrected and are in scRGB
color space when CIE.inc is used with the default settings.
For your original question about gamut mapping you can use the macro
CIE_GamutMapping(MAPPING_FUNCTION) where MAPPING_FUNCTION can be
0 - no mapping, keep negative values
1 - clip negative values
2 - triangle intersection
3 - desaturation
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Do you want to preserve...
>> ...the in-gamut colours?
>> ...the relationship between colours?
>> ...colour saturation?
>>
>> Colour space conversion is a complicated subject.
>
> Well, at this stage I'd like to know how to do all three.
Well if you only want to preserve the in-gamut colours then obviously you
only need to tinker with the out-of-gamut ones. For these colours I would
tempted to move the colour in the xy plane towards the white point until it
became in-gamut. Of course here you lose any "difference" perception
between in-gamut and out-gamut colours with similar hues.
If you want to preserve the relationship, then it gets harder because
colours in the Yxy or sRGB spaces are not spaced evenly for human perception
of "difference". If you want to do it properly, convert your Yxy data into
CIELAB or similar, I'd then choose three new primaries (not the sRGB
primaries) that allow all your colour points to be represented as positive
combinations of the primaries. Of course here no colours will be properly
displayed, but the relationships should be preserved.
You could also do a combination of the above two, whereby if a colour is
within say the central 50% of sRGB you map it exactly, but then further out
the colours get compressed to fit in the sRGB space, but still maintaining
some sort of difference. I think I saw some display processor from Philips
once that did this.
> However, I am running into additional problems. I am converting the 1929
> Munsell data set (http://www.cis.rit.edu/mcsl/online/munsell.php), and
> *not a single one* of the colors lies completely within the SRGB gamut.
Just by looking at the numbers, the first one is xy=0.3532,0.2957 with a
brightness of 3.126 cd/m2, that surely is within the sRGB space?
> You can test this by using the color converter found here:
>
> http://www.brucelindbloom.com/index.html?ColorCalculator.html
The first one comes out as RGB=(2.0,1.5,2.0) (rounded), seems to be within
sRGB to me!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
5000° Kelvin - so make sure your room is lit properly ;) - in an attempt
to take the chromatic adaption of the human visual system into account.
Note that this is NOT the D65 whitepoint from sRGB but maybe 5000°K
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
condition where the dominant light source is about 5000° Kelvin.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive schrieb:
> 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.
I don't get it. On one hand, you are saying that reference white does
not matter for sRGB as a working color space (unless I misunderstand
you, which I guess I do), on the other hand yo're saying some adaption
/must/ be applied?
I'm pretty sure somehow that the /spectrum/ of the whitepoint should
matter for such things as dispersion, but where and why adaption come
into play still eludes me.
Let me think aloud for a moment to try to sort this out, and kick me
where I'm wrong:
So the starting point is the /tristimulus/, which (basically) models how
strongly the three different color receptors ("cones") in the human eye
react to different wavelengths. (To my knowledge we can count the "rod"
receptors out, probably because they only contribute in dim conditions,
right? Otherwise we should be able to distinguish four different
primaries, as the rods' spetral response is yet again different than the
cones'.)
Experiments were conducted to measure this per-wavelength response (a
bit indirectly) in a manner that, to my understanding, only yielded
/relative/ results: Conclusion could be drawn how much stronger a
particular cone type is stimulated by wavelength A compared to some
other wavelength B, but there was no way to infer how much stronger a
particular wavelength stimulated cone type A as compared to cone type B.
Thus, the immediate conclusions drawn from these experiments left open
the question what "white" is (which comes as no surprise, given that it
depends on the viewing conditions, i.e. the eye's "calibration").
However, I'm a bit worried at this point already: I guess the
wavelengths to test were generated from a "white" light source by means
of a prism; did they actually measure the physical light intensity of
the light source at that particular wavelength, to compensate for any
nonlinearities in intensity in their results? Or is there a hidden
"whitepoint" in the original data already, due to the light source used?
Duh - I haven't even really /started/ thinking about the problem of
whitepoint, and it gets in my way already...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/12/2009 8:49 AM, scott wrote:
> 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.
Actually, the object I am rendering also has its ambient level set to 1,
so it is *both* an emissive *and* a reflective surface.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm pretty sure somehow that the /spectrum/ of the whitepoint should
> matter for such things as dispersion, but where and why adaption come into
> play still eludes me.
They were talking about (which I didn't get initially) how to make a certain
*surface* look correct on a monitor, not a particular spectrum/colour.
Obviously the colour a surface appears to your eye depends on what colour
light you use to illuminate it with. Adaption comes into play when someone
else has measured the "apparent" surface colour using one type of
illuminant, but you want to know what colour it will look when lit with
another illuminant. If you know the viewing conditions under which you are
looking at your monitor (eg D50 illuminant) then you can work out what to
display on your monitor to make it look identical to if you had the actual
surface next to your monitor.
> So the starting point is the /tristimulus/, which (basically) models how
> strongly the three different color receptors ("cones") in the human eye
> react to different wavelengths.
Tristimulus values can be any 3 parameters that you decide to use, a bit
like how you can use (almost) any set of 3 vectors to describe all points in
3D space. The most common used are XYZ, and they don't really match with
the cone response curves, they're just 3 parameters.
> Experiments were conducted to measure this per-wavelength response (a bit
> indirectly) in a manner that, to my understanding, only yielded /relative/
> results:
No, I think they were able to generate pretty accurate colour matching
functions, which mapped exactly how the intensity of each wavelength
corresponded to the tristimulus values. You end up with a chart like the
one on wikipedia:
http://en.wikipedia.org/wiki/File:CIE_1931_XYZ_Color_Matching_Functions.svg
> Thus, the immediate conclusions drawn from these experiments left open the
> question what "white" is
The only universal "scientific" definition of "white" I can think of is
equal energy at all wavelengths, this gives XYZ=(1,1,1). Other whites are
usually related to the colour of a hot object, eg D65 is the colour of an
object at 6500K.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Ive schrieb:
>
> I don't get it. On one hand, you are saying that reference white does
> not matter for sRGB as a working color space (unless I misunderstand
> you, which I guess I do), on the other hand yo're saying some adaption
> /must/ be applied?
>
Three cases for given xyY values.
These values refer to a reflective spectrum (as it is the case with
Munsell color definitions or one of the many "real world" material
databases out there, one of those is e.g. the Aster spectral library at
http://speclib.jpl.nasa.gov/ containing among other things data for all
moon stones collected at the various Apollo mission landing sides).
All these databases and all measurement hardware that I'm aware of is
using D50 as reference white (but as scott pointed out there are also
others).
Now, assuming we are using scRGB (sRGB primaries and whitepoint but
without gamma correction) as the POV-Ray internal RGB *working* color
space we have to apply chromatic adaption for these xyY values to make
them consistent with RGB values from other sources and especially with
the RGB values for light sources that are used within POV-Ray to
illuminate them.
Now, speaking of light sources within POV-Ray, the second case are xyY
values that refer to those and then must *no* chromatic adaption be applied.
The third case (IMO not relevant for POV-Ray anyway) is the usage of
sRGB as output device color space (as opposed to working color space)
where the sRGB standard implies an environment lighting/viewing
condition of about 5000°K. In this case the chromatic adaption is
assumed to be done by the human visual system and therefor no chromatic
adaption has to be applied when calculating RGB values from given xyY.
IMHO it is at least questionable how useful this 5000°K assumption is
and within the business I'm working in it is ignored and so does also
e.g. Adobe - not that I'm saying what they are doing is always right;)
> I'm pretty sure somehow that the /spectrum/ of the whitepoint should
> matter for such things as dispersion, but where and why adaption come
> into play still eludes me.
>
Well, in fact there is no chromatic adaption needed and I think that the
whitepoint of the POV-Ray internal RGB working color space shouldn't
matter at all for calculating dispersion samples (besides that it is
needed for the xyz->rgb conversion). I seem to remember in some quick
response I did state otherwise and in case this is true I'm sorry for
the confusion this might have caused.
> Let me think aloud for a moment to try to sort this out, and kick me
> where I'm wrong:
>
> So the starting point is the /tristimulus/, which (basically) models how
> strongly the three different color receptors ("cones") in the human eye
> react to different wavelengths. (To my knowledge we can count the "rod"
> receptors out, probably because they only contribute in dim conditions,
> right? Otherwise we should be able to distinguish four different
> primaries, as the rods' spetral response is yet again different than the
> cones'.)
>
Within the CIE standard observer experiments the rods are just ignored.
> Experiments were conducted to measure this per-wavelength response (a
> bit indirectly) in a manner that, to my understanding, only yielded
> /relative/ results: Conclusion could be drawn how much stronger a
> particular cone type is stimulated by wavelength A compared to some
> other wavelength B, but there was no way to infer how much stronger a
> particular wavelength stimulated cone type A as compared to cone type B.
> Thus, the immediate conclusions drawn from these experiments left open
> the question what "white" is (which comes as no surprise, given that it
> depends on the viewing conditions, i.e. the eye's "calibration").
>
There is such a thing as the Grassmann law. Google it for more details.
> However, I'm a bit worried at this point already: I guess the
> wavelengths to test were generated from a "white" light source by means
> of a prism; did they actually measure the physical light intensity of
> the light source at that particular wavelength, to compensate for any
> nonlinearities in intensity in their results? Or is there a hidden
> "whitepoint" in the original data already, due to the light source used?
>
No. They did use mercury (and other metals) vapor lamps to produce 3
different monochromatic light beams at three different wavelengths. Out
of my head theses have been around 435nm, 545nm and 700nm and as a side
note these values are not completely willingly chosen, they had also to
deal with the kind of vapor lamps that where available in 1931.
The "observer" could then adjust the intensity of the three beams until
the color that did result from the mixture did match a given one. So
there is no "hidden" whitepoint and no dealing with "what is white" at all.
> Duh - I haven't even really /started/ thinking about the problem of
> whitepoint, and it gets in my way already...
Don't worry ;)
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott schrieb:
>> Experiments were conducted to measure this per-wavelength response (a
>> bit indirectly) in a manner that, to my understanding, only yielded
>> /relative/ results:
>
> No, I think they were able to generate pretty accurate colour matching
> functions, which mapped exactly how the intensity of each wavelength
> corresponded to the tristimulus values. You end up with a chart like
> the one on wikipedia:
Not really: They used various other assumtions to get to the XYZ color
model, which were not part of the original tristimulus experiments (for
instance results from an experiment that tested for how people percieve
the brightness of spectral colors in relation to one another).
> http://en.wikipedia.org/wiki/File:CIE_1931_XYZ_Color_Matching_Functions.svg
>
>> Thus, the immediate conclusions drawn from these experiments left open
>> the question what "white" is
>
> The only universal "scientific" definition of "white" I can think of is
> equal energy at all wavelengths, this gives XYZ=(1,1,1). Other whites
> are usually related to the colour of a hot object, eg D65 is the colour
> of an object at 6500K.
Given that "white" is what we humans /percieve/ as "white", that
equal-energy definition is not really reliable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive schrieb:
> Now, assuming we are using scRGB (sRGB primaries and whitepoint but
> without gamma correction) as the POV-Ray internal RGB *working* color
> space we have to apply chromatic adaption for these xyY values to make
> them consistent with RGB values from other sources and especially with
> the RGB values for light sources that are used within POV-Ray to
> illuminate them.
Wouldn't it be more logical in the case of reflective surfaces to apply
chromatic adaption to the /light source/ in the scene?
>> I'm pretty sure somehow that the /spectrum/ of the whitepoint should
>> matter for such things as dispersion, but where and why adaption come
>> into play still eludes me.
>>
> Well, in fact there is no chromatic adaption needed and I think that the
> whitepoint of the POV-Ray internal RGB working color space shouldn't
> matter at all for calculating dispersion samples (besides that it is
> needed for the xyz->rgb conversion). I seem to remember in some quick
> response I did state otherwise and in case this is true I'm sorry for
> the confusion this might have caused.
Yes, you mentioned some chromatic adaptation. Apologies accepted, but I
still seem to be confused :-)
>> Experiments were conducted to measure this per-wavelength response (a
>> bit indirectly) in a manner that, to my understanding, only yielded
>> /relative/ results: Conclusion could be drawn how much stronger a
>> particular cone type is stimulated by wavelength A compared to some
>> other wavelength B, but there was no way to infer how much stronger a
>> particular wavelength stimulated cone type A as compared to cone type
>> B. Thus, the immediate conclusions drawn from these experiments left
>> open the question what "white" is (which comes as no surprise, given
>> that it depends on the viewing conditions, i.e. the eye's "calibration").
>>
> There is such a thing as the Grassmann law. Google it for more details.
Hum... okay... so I googled it up. But I have no idea how it fits into
the whole smash...
> No. They did use mercury (and other metals) vapor lamps to produce 3
> different monochromatic light beams at three different wavelengths. Out
> of my head theses have been around 435nm, 545nm and 700nm and as a side
> note these values are not completely willingly chosen, they had also to
> deal with the kind of vapor lamps that where available in 1931.
Yes, I read that.
> The "observer" could then adjust the intensity of the three beams until
> the color that did result from the mixture did match a given one. So
> there is no "hidden" whitepoint and no dealing with "what is white" at all.
Well, this is exactly the point I'm after here: This "given [color]"
must have come from somewhere. From the experiment description, it was
this very color (a spectral one, I presume) that they "measured" with
the experiment.
This color must have had some intensity, and I guess the test persons
did not just try to match the color, but the apparent brightness as
well. I mean, after all, for instance both 700 nm and 740 nm are
percieved as pretty much the same hue of red, except that one is
percieved as brighter than the other.
So, was the intensity deliberately "normalized" to equal physical
brightness?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Not really: They used various other assumtions to get to the XYZ color
> model, which were not part of the original tristimulus experiments (for
> instance results from an experiment that tested for how people percieve
> the brightness of spectral colors in relation to one another).
Well I don't know the details of exactly what experiments and calculations
they conducted to end up with the colour matching functions, but today they
are a standard to convert from a spectrum (which you can measure
scientifically) to XYZ, which is the basis for all colour spaces. If you
are given a spectrum, you can get out only one possible XYZ colour, there is
no reliance on any concept of "white" to make that conversion step.
> Given that "white" is what we humans /percieve/ as "white", that
> equal-energy definition is not really reliable.
That isn't very scientific though, usually "white" in a strictly scientific
way means equal energy across all relevant wavelengths (see "white noise" in
audio). The CIE colour matching functions were designed to give equal XYZ
values when presented with a spectrum of "white" light such as this.
Obviously the human perception of what is "white" light varies greatly with
the surrounding illumination (which often comes from the sun/sky), our
psychological concept of what "should" be white etc, this is why various
other whites are defined as standards.
I guess you could think up of an experiment in a completely dark room where
you show a subject two near-white coloured light sources and ask them which
is "whiter" than the other. Repeat until you find "white". Someone has
probably done that already...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Wouldn't it be more logical in the case of reflective surfaces to apply
> chromatic adaption to the /light source/ in the scene?
>
Err, no. Let me put it this way: we use chromatic adaption for the
reflective surface because we want to rule out the influence the used
hardware did have for measuring its reflectivity. From this point of
view raytracing is about having some objective surface color that is
illuminated by some freely chosen colored light source and we are after
the reflected color that is the same as if the real world thing would be
illuminated by our light source. We are definitely no longer interested
in e.g. what kind of lamp was used to *measure* reflectivity and so
(again) in this case chromatic adaption for the given spectral data or
xyY value or whatever has to be used.
>>> Experiments were conducted to measure this per-wavelength response (a
>>> bit indirectly) in a manner that, to my understanding, only yielded
>>> /relative/ results: Conclusion could be drawn how much stronger a
>>> particular cone type is stimulated by wavelength A compared to some
>>> other wavelength B, but there was no way to infer how much stronger a
>>> particular wavelength stimulated cone type A as compared to cone type
>>> B. Thus, the immediate conclusions drawn from these experiments left
>>> open the question what "white" is (which comes as no surprise, given
>>> that it depends on the viewing conditions, i.e. the eye's
>>> "calibration").
>>>
>> There is such a thing as the Grassmann law. Google it for more details.
>
> Hum... okay... so I googled it up. But I have no idea how it fits into
> the whole smash...
>
I was referring to the linearity within human color perception as stated
by Grassmann and one of the major problems within the CIE rgb color
space that e.g. various vectors but of *equal* length within the CIE xy
diagram would represent *different* human perception of color difference
(or DeltaE as this is called).
But I might get you completely wrong in what you are after here.
>> No. They did use mercury (and other metals) vapor lamps to produce 3
>> different monochromatic light beams at three different wavelengths.
>> Out of my head theses have been around 435nm, 545nm and 700nm and as a
>> side note these values are not completely willingly chosen, they had
>> also to deal with the kind of vapor lamps that where available in 1931.
>
> Yes, I read that.
>
>> The "observer" could then adjust the intensity of the three beams
>> until the color that did result from the mixture did match a given
>> one. So there is no "hidden" whitepoint and no dealing with "what is
>> white" at all.
>
> Well, this is exactly the point I'm after here: This "given [color]"
> must have come from somewhere. From the experiment description, it was
> this very color (a spectral one, I presume) that they "measured" with
> the experiment.
>
AFAIR: the test colors have been also produced by metal vapor lamps with
known wavelength but those where easier to build at this time as they
had not to be made adjustable in brightness. I have a book at work with
exact description of the Wright/Guild experiments and in case I'm wrong
here I will correct myself in the next week ;)
> This color must have had some intensity, and I guess the test persons
> did not just try to match the color, but the apparent brightness as
> well. I mean, after all, for instance both 700 nm and 740 nm are
> percieved as pretty much the same hue of red, except that one is
> percieved as brighter than the other.
>
> So, was the intensity deliberately "normalized" to equal physical
> brightness?
There was not a *single* color matching experiment, it was performed
during almost 10 years with different people, different lamps and even
slightly different setups. The resulting data was then assembled to give
this *ideal* CIE 1931 2° observer. I do not think they did care much
about 'brightness' issues, guessing they were quite happy to make the
lamps work anyhow.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott schrieb:
> That isn't very scientific though, usually "white" in a strictly
> scientific way means equal energy across all relevant wavelengths (see
> "white noise" in audio). The CIE colour matching functions were
> designed to give equal XYZ values when presented with a spectrum of
> "white" light such as this.
Okay, I think I get that.
So in /that/ context, there is no "whitepoint" involved, right? Or am I
getting something wrong here?
And when you add two spectral colors, still the whitepoint would not
come into play - presuming that color perception is linear, which seems
to be the case from all that scientists have found out. (Stop me when
I'm talking nonsense).
And with the sRGB color model, the same principle applies, because it is
just another choice of the coordinate axes in 3D color space (leaving
the transport function aside for now).
So as long as we're talking about some light color which we intend to
convert from XYZ to sRGB, we can happily forget about whitepoint: If we
shove a XYZ color into the transformation matrix that represents "white"
in the physical sense, then the sRGB color we get will just as well
represent "white" in the physical sense - right?
Thus, in order to "render" light of a certain color with know XYZ
coordinates on an sRGB "output channel" (be it a device, a file, or
whatever), we should just take the XYZ value we have, shove it through
the transformation matrix as defined in the sRGB standard, and live
happily ever after. As for viewing conditions, I would expect these to
be taken care of automatically by a properly calibrated display.
I just toyed around with the sRGB transformation matrix, leading me to
the conclusion that the XYZ color model must be using illuminant *E* (!)
(that is, equal physical light intensity) as its native "white" (i.e.
<1,1,1> - heck, I could have guessed that from the x,y coordinates of
the various illuminants), while "the" sRGB "white" (again <1,1,1>)
matches D65. (Ah-hah! So that's what the "display whitepoint" is
denoting in the sRGB specs.)
Okay, so I think I got it, as far as light goes. Now for the color of
surfaces:
In my naive mind, I would have presumed that to specify the color of a
surface via the CIE XYZ color system, one would specify the XYZ
coordinates of the diffusely reflected light when the surface in
question is subject to physically white light (i.e. illuminant E);
however, from your explanations I gather that this is /not/ the case, right?
Which raises the (possibly trivial) question, what exactly /is/ then
specified for color pigments? Is it, as I now tend to presume, the XYZ
coordinates of the diffusely reflected light when subject to illuminant
D65 instead?
Gee, that doesn't make it easier to come up with a sensible way of
proper color handling in POV-Ray...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So in /that/ context, there is no "whitepoint" involved, right? Or am I
> getting something wrong here?
You're right, "whitepoint" has no relevance or meaning when you're talking
solely about a tristimulus value or a specific spectrum.
> And when you add two spectral colors, still the whitepoint would not come
> into play
Nope.
> And with the sRGB color model, the same principle applies, because it is
> just another choice of the coordinate axes in 3D color space (leaving the
> transport function aside for now).
You have to deal with linear sRGB to be able to "add" the values together,
but yes it's just the same because XYZ -> (linear)sRGB is just a linear
relationship.
> So as long as we're talking about some light color which we intend to
> convert from XYZ to sRGB, we can happily forget about whitepoint: If we
> shove a XYZ color into the transformation matrix that represents "white"
> in the physical sense, then the sRGB color we get will just as well
> represent "white" in the physical sense - right?
Yes, XYZ <-> sRGB is a 1-1 fixed mapping that has no dependence on any white
point.
> Thus, in order to "render" light of a certain color with know XYZ
> coordinates on an sRGB "output channel" (be it a device, a file, or
> whatever), we should just take the XYZ value we have, shove it through the
> transformation matrix as defined in the sRGB standard, and live happily
> ever after. As for viewing conditions, I would expect these to be taken
> care of automatically by a properly calibrated display.
Yes exactly. This is what I assumed the OP wanted at the beginning of this
thread. But it turns out the "XYZ" they "knew" was actually measured from a
reflective surface under a certain light source. They wanted to display
"the surface" on their monitor as if it was lit from a different light
source. In order to achieve this you need to calculate a new XYZ value
first to account for the different illuminant, then convert to sRGB. I
think it's confusing to call the illuminant a "reference white", but hey.
> I just toyed around with the sRGB transformation matrix, leading me to the
> conclusion that the XYZ color model must be using illuminant *E* (!) (that
> is, equal physical light intensity) as its native "white" (i.e. <1,1,1> -
> heck, I could have guessed that from the x,y coordinates of the various
> illuminants), while "the" sRGB "white" (again <1,1,1>) matches D65.
> (Ah-hah! So that's what the "display whitepoint" is denoting in the sRGB
> specs.)
:-) I was going to say earlier you could start with sRGB=<1,1,1> and work
back to XYZ to find out what "white" meant in sRGB space.
> Okay, so I think I got it, as far as light goes. Now for the color of
> surfaces:
>
> In my naive mind, I would have presumed that to specify the color of a
> surface via the CIE XYZ color system, one would specify the XYZ
> coordinates of the diffusely reflected light when the surface in question
> is subject to physically white light (i.e. illuminant E); however, from
> your explanations I gather that this is /not/ the case, right?
That is one option, but generally illuminant E is not available or not
desired (for whatever reason), so D50, D65 or some other can be used. So
long as you specify the XYZ value *and* the illuminant used then it's enough
to define the absolute reflective colour of the surface and how it will
appear under any other illuminant.
> Which raises the (possibly trivial) question, what exactly /is/ then
> specified for color pigments? Is it, as I now tend to presume, the XYZ
> coordinates of the diffusely reflected light when subject to illuminant
> D65 instead?
We only use D65 in the display industry because the reflective colour of
LCDs only becomes visible under very bright conditions (eg outside when it's
sunny) - then D65 is a good approximation of the illuminant and thus allows
direct comparison of the transmissive and reflective xyY values (obviously
you want them to match as closely as possible so things don't change colour
when the sun comes out!).
If your reflective surfaces will mostly be viewed under some other lighting
conditions then it probably makes sense to use that illuminant as your
reference.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
