 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
