 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.11.2016 um 01:50 schrieb Mike Horvath:
> On 11/24/2016 6:43 PM, clipka wrote:
>> Am 24.11.2016 um 23:56 schrieb Mike Horvath:
>>
>>> Okay, the problem is that I want to use sRGB instead of RGB in the
>>> pigments. However, it seems to not be possible to multiply the sRGB
>>> colors and then average them like you can with regular RGB. Or is there
>>> a way to get this to work?
>>
>> Don't use sRGB when mucking around with colour spaces, unless you know
>> /exactly/ what you are doing. Colour space experts are smart enough to
>> specify colours in terms of linear light intensity, or otherwise
>> explicitly inform the readers.
>>
>
> The functions output sRGB colors with Illuminant = D65 and Observer = 2°
> (1931) according to one of the conversion websites that uses these
> formulas.
>
> I'd like the POV code to use sRGB as well.
Don't try to go via that route; it won't work with the approach I've
described.
Instead, in the function pipeline, insert a function to explicitly
convert from sRGB to RGB:
3D cartesian -> Lch -> sRGB -> RGB -> "distance"
3D cartesian -> Lch -> sRGB -> RGB -> pigments
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.11.2016 um 01:47 schrieb Mike Horvath:
> Thank you clipka! Everything is working perfectly now! Part of the
> problem was a bug in my conversion functions. Once I fixed it, I started
> getting the correct results.
>
> Do you mind if I put a LGPL license on the code an upload it to Wikipedia?
Feel free to do so.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/24/2016 8:28 PM, Mike Horvath wrote:
> I've attached the final shape, with the outside sRGB bits trimmed off.
>
> Mike
For comparison, here is the same image with the corner bits left in.
Mike
Post a reply to this message
Attachments:
Download 'cielch_color_solid_cylinder_isosurface.png' (24 KB)
Preview of image 'cielch_color_solid_cylinder_isosurface.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/24/2016 8:33 PM, clipka wrote:
> Don't try to go via that route; it won't work with the approach I've
> described.
>
> Instead, in the function pipeline, insert a function to explicitly
> convert from sRGB to RGB:
>
> 3D cartesian -> Lch -> sRGB -> RGB -> "distance"
>
> 3D cartesian -> Lch -> sRGB -> RGB -> pigments
>
Do you have a function to convert between sRGB and RGB? One was not
included with ColorMine AFAIK.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.11.2016 um 02:59 schrieb Mike Horvath:
> On 11/24/2016 8:33 PM, clipka wrote:
>> Don't try to go via that route; it won't work with the approach I've
>> described.
>>
>> Instead, in the function pipeline, insert a function to explicitly
>> convert from sRGB to RGB:
>>
>> 3D cartesian -> Lch -> sRGB -> RGB -> "distance"
>>
>> 3D cartesian -> Lch -> sRGB -> RGB -> pigments
>>
>
> Do you have a function to convert between sRGB and RGB? One was not
> included with ColorMine AFAIK.
No ready-made function; you'll need to piece things together from e.g.
https://en.wikipedia.org/wiki/SRGB.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.11.2016 um 02:33 schrieb clipka:
> Instead, in the function pipeline, insert a function to explicitly
> convert from sRGB to RGB:
>
> 3D cartesian -> Lch -> sRGB -> RGB -> "distance"
>
> 3D cartesian -> Lch -> sRGB -> RGB -> pigments
I forgot: You won't necessarily need the sRGB->RGB step for the
"distance" function, as sRGB channel values of 0 and 1 map to RGB
channel values of 0 and 1, respectively.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/24/2016 9:11 PM, clipka wrote:
> Am 25.11.2016 um 02:59 schrieb Mike Horvath:
>> On 11/24/2016 8:33 PM, clipka wrote:
>>> Don't try to go via that route; it won't work with the approach I've
>>> described.
>>>
>>> Instead, in the function pipeline, insert a function to explicitly
>>> convert from sRGB to RGB:
>>>
>>> 3D cartesian -> Lch -> sRGB -> RGB -> "distance"
>>>
>>> 3D cartesian -> Lch -> sRGB -> RGB -> pigments
>>>
>>
>> Do you have a function to convert between sRGB and RGB? One was not
>> included with ColorMine AFAIK.
>
> No ready-made function; you'll need to piece things together from e.g.
> https://en.wikipedia.org/wiki/SRGB.
>
I am looking at the "The reverse transformation" section. Do I just need
to use the C_linear function?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.11.2016 um 03:31 schrieb Mike Horvath:
> On 11/24/2016 9:11 PM, clipka wrote:
>> Am 25.11.2016 um 02:59 schrieb Mike Horvath:
>>> On 11/24/2016 8:33 PM, clipka wrote:
>>>> Don't try to go via that route; it won't work with the approach I've
>>>> described.
>>>>
>>>> Instead, in the function pipeline, insert a function to explicitly
>>>> convert from sRGB to RGB:
>>>>
>>>> 3D cartesian -> Lch -> sRGB -> RGB -> "distance"
>>>>
>>>> 3D cartesian -> Lch -> sRGB -> RGB -> pigments
>>>>
>>>
>>> Do you have a function to convert between sRGB and RGB? One was not
>>> included with ColorMine AFAIK.
>>
>> No ready-made function; you'll need to piece things together from e.g.
>> https://en.wikipedia.org/wiki/SRGB.
>>
>
> I am looking at the "The reverse transformation" section. Do I just need
> to use the C_linear function?
Yup, that's the one.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/24/2016 9:54 PM, clipka wrote:
> Am 25.11.2016 um 03:31 schrieb Mike Horvath:
>> On 11/24/2016 9:11 PM, clipka wrote:
>>> No ready-made function; you'll need to piece things together from e.g.
>>> https://en.wikipedia.org/wiki/SRGB.
>>>
>>
>> I am looking at the "The reverse transformation" section. Do I just need
>> to use the C_linear function?
>
> Yup, that's the one.
>
>
Okay, I will try that.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> May I ask the stupid question, "why not"?
>>
>> I would expect the Lch colour space to encompass all the RGB colour
>> space, so the boundaries of the latter should be sufficient to bound the
>> shape.
>>
>> My guess is that the issues you see with the shape are due to bogosities
>> in your colour conversion functions.
>>
>
> L, C and H are supposed to form a cylinder. There are some very small
> sRGB bits poking outside of the cylinder. I guess I could show the bits
> as well, as long as I explain what they are.
If sRGB is poking out of your cylinder, then Adobe RGB is going to poke
out even more, and the entire human visual range is going to be much
larger. Are you sure you've got the radius of your cylinder correct to
match your colour calculations? Also it would be surprising to me if the
human visual range came out exactly as a cylinder (after a brief glance
of the maths involved), are you sure about this?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/28/2016 3:23 AM, scott wrote:
>>> May I ask the stupid question, "why not"?
>>>
>>> I would expect the Lch colour space to encompass all the RGB colour
>>> space, so the boundaries of the latter should be sufficient to bound the
>>> shape.
>>>
>>> My guess is that the issues you see with the shape are due to bogosities
>>> in your colour conversion functions.
>>>
>>
>> L, C and H are supposed to form a cylinder. There are some very small
>> sRGB bits poking outside of the cylinder. I guess I could show the bits
>> as well, as long as I explain what they are.
>
> If sRGB is poking out of your cylinder, then Adobe RGB is going to poke
> out even more, and the entire human visual range is going to be much
> larger. Are you sure you've got the radius of your cylinder correct to
> match your colour calculations? Also it would be surprising to me if the
> human visual range came out exactly as a cylinder (after a brief glance
> of the maths involved), are you sure about this?
>
Yeah, I explain the mistake I made in this thread:
http://news.povray.org/583bd889%241%40news.povray.org
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/28/2016 3:23 AM, scott wrote:
> Also it would be surprising to me if the
> human visual range came out exactly as a cylinder (after a brief glance
> of the maths involved), are you sure about this?
>
The human visual range has a very irregular shape.
https://en.wikipedia.org/wiki/File:Cie_Chart_with_sRGB_gamut_by_spigget.png
There's a lot of blank empty space around it in every color space. (The
one in the picture is called CIExyY I think.
I would like to learn how to plot this irregular shape in the near future.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Also it would be surprising to me if the
>> human visual range came out exactly as a cylinder (after a brief glance
>> of the maths involved), are you sure about this?
>>
>
> The human visual range has a very irregular shape.
>
> https://en.wikipedia.org/wiki/File:Cie_Chart_with_sRGB_gamut_by_spigget.png
>
> There's a lot of blank empty space around it in every color space. (The
> one in the picture is called CIExyY I think.
>
> I would like to learn how to plot this irregular shape in the near future.
You just need the XYZ colour-matching functions in terms of wavelength.
Look here (just click the first "Submit" to get a basic table):
http://cvrl.ioo.ucl.ac.uk/cmfs.htm
This table then gives you the exact XYZ values for each pure wavelength.
XYZ is a linear representation of absolute colour, so you can do a lot
of math with them (eg adding, averaging, mixing etc).
To get the graph you linked to, you just need to calculate x and y for
each of those wavelengths.
x = X/(X+Y+Z)
y = Y/(X+Y+Z)
You'll then find that the x,y pairs give the outline of the graph you
linked to, which are the pure wavelengths. The internal area is formed
by mixing pure wavelengths, so roughly speaking the further you are away
from the boundary the more "wideband" the light is.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/28/2016 3:53 AM, scott wrote:
>>> Also it would be surprising to me if the
>>> human visual range came out exactly as a cylinder (after a brief glance
>>> of the maths involved), are you sure about this?
>>>
>>
>> The human visual range has a very irregular shape.
>>
>> https://en.wikipedia.org/wiki/File:Cie_Chart_with_sRGB_gamut_by_spigget.png
>>
>>
>> There's a lot of blank empty space around it in every color space. (The
>> one in the picture is called CIExyY I think.
>>
>> I would like to learn how to plot this irregular shape in the near
>> future.
>
> You just need the XYZ colour-matching functions in terms of wavelength.
> Look here (just click the first "Submit" to get a basic table):
>
> http://cvrl.ioo.ucl.ac.uk/cmfs.htm
>
> This table then gives you the exact XYZ values for each pure wavelength.
> XYZ is a linear representation of absolute colour, so you can do a lot
> of math with them (eg adding, averaging, mixing etc).
>
> To get the graph you linked to, you just need to calculate x and y for
> each of those wavelengths.
>
> x = X/(X+Y+Z)
> y = Y/(X+Y+Z)
>
> You'll then find that the x,y pairs give the outline of the graph you
> linked to, which are the pure wavelengths. The internal area is formed
> by mixing pure wavelengths, so roughly speaking the further you are away
> from the boundary the more "wideband" the light is.
>
Well, I don't understand that. Clipka did most of the work for me last
time...
Maybe you could take a look at the code on the LCH image's page on
Wikimedia and make some suggestions.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/28/2016 3:53 AM, scott wrote:
> You just need the XYZ colour-matching functions in terms of wavelength.
> Look here (just click the first "Submit" to get a basic table):
>
> http://cvrl.ioo.ucl.ac.uk/cmfs.htm
>
> This table then gives you the exact XYZ values for each pure wavelength.
> XYZ is a linear representation of absolute colour, so you can do a lot
> of math with them (eg adding, averaging, mixing etc).
>
> To get the graph you linked to, you just need to calculate x and y for
> each of those wavelengths.
>
> x = X/(X+Y+Z)
> y = Y/(X+Y+Z)
>
> You'll then find that the x,y pairs give the outline of the graph you
> linked to, which are the pure wavelengths. The internal area is formed
> by mixing pure wavelengths, so roughly speaking the further you are away
> from the boundary the more "wideband" the light is.
>
Also, I'm more interested in the 3-dimensional solid than the 2D
chromaticity diagram.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Also, I'm more interested in the 3-dimensional solid than the 2D
> chromaticity diagram.
The 3D solid of the Yxy shape is just the 2D shape you linked to
extruded upwards as a prism. That's why you don't normally see Yxy or
Yuv shown in 3D - it doesn't give any benefit over the 2D shape.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28/11/2016 09:11, Mike Horvath wrote:
> On 11/28/2016 3:53 AM, scott wrote:
>>>> Also it would be surprising to me if the
>>>> human visual range came out exactly as a cylinder (after a brief glance
>>>> of the maths involved), are you sure about this?
>>>>
>>>
>>> The human visual range has a very irregular shape.
>>>
>>> https://en.wikipedia.org/wiki/File:Cie_Chart_with_sRGB_gamut_by_spigget.png
>>>
>>>
>>>
>>> There's a lot of blank empty space around it in every color space. (The
>>> one in the picture is called CIExyY I think.
>>>
>>> I would like to learn how to plot this irregular shape in the near
>>> future.
>>
>> You just need the XYZ colour-matching functions in terms of wavelength.
>> Look here (just click the first "Submit" to get a basic table):
>>
>> http://cvrl.ioo.ucl.ac.uk/cmfs.htm
>>
>> This table then gives you the exact XYZ values for each pure wavelength.
>> XYZ is a linear representation of absolute colour, so you can do a lot
>> of math with them (eg adding, averaging, mixing etc).
>>
>> To get the graph you linked to, you just need to calculate x and y for
>> each of those wavelengths.
>>
>> x = X/(X+Y+Z)
>> y = Y/(X+Y+Z)
>>
>> You'll then find that the x,y pairs give the outline of the graph you
>> linked to, which are the pure wavelengths. The internal area is formed
>> by mixing pure wavelengths, so roughly speaking the further you are away
>> from the boundary the more "wideband" the light is.
>>
>
> Well, I don't understand that.
Which bit?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/28/2016 4:24 AM, scott wrote:
>> Also, I'm more interested in the 3-dimensional solid than the 2D
>> chromaticity diagram.
>
> The 3D solid of the Yxy shape is just the 2D shape you linked to
> extruded upwards as a prism. That's why you don't normally see Yxy or
> Yuv shown in 3D - it doesn't give any benefit over the 2D shape.
>
>
I thought there was some tapering as the Y increases? This image
suggests that is the case.
http://www.math.ubc.ca/~cass/courses/m309-03a/m309-projects/bajwa/images/cie_3d.gif
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.11.2016 um 23:21 schrieb Mike Horvath:
> On 11/28/2016 4:24 AM, scott wrote:
>>> Also, I'm more interested in the 3-dimensional solid than the 2D
>>> chromaticity diagram.
>>
>> The 3D solid of the Yxy shape is just the 2D shape you linked to
>> extruded upwards as a prism. That's why you don't normally see Yxy or
>> Yuv shown in 3D - it doesn't give any benefit over the 2D shape.
>>
>>
>
> I thought there was some tapering as the Y increases? This image
> suggests that is the case.
>
> http://www.math.ubc.ca/~cass/courses/m309-03a/m309-projects/bajwa/images/cie_3d.gif
That's not the limit of the xyY space.
That's the theoretical limit of _reflective_ colours illuminated by
standard illuminant C, plotted in xyY space.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/28/2016 6:05 PM, clipka wrote:
>> I thought there was some tapering as the Y increases? This image
>> suggests that is the case.
>>
>> http://www.math.ubc.ca/~cass/courses/m309-03a/m309-projects/bajwa/images/cie_3d.gif
>
> That's not the limit of the xyY space.
>
> That's the theoretical limit of _reflective_ colours illuminated by
> standard illuminant C, plotted in xyY space.
>
Yes, that is fine. Not sure whether to use C or D65, though.
https://en.wikipedia.org/wiki/Illuminant_D65
These images on Wikipedia use D65, so I may just stick with that.
https://en.wikipedia.org/wiki/File:Cie_Chart_with_sRGB_gamut_by_spigget.png
https://en.wikipedia.org/wiki/File:CIE1931xy_gamut_comparison.svg
https://en.wikipedia.org/wiki/File:Lab_color_space.png (I think)
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 29.11.2016 um 00:33 schrieb Mike Horvath:
> On 11/28/2016 6:05 PM, clipka wrote:
>>> I thought there was some tapering as the Y increases? This image
>>> suggests that is the case.
>>>
>>>
http://www.math.ubc.ca/~cass/courses/m309-03a/m309-projects/bajwa/images/cie_3d.gif
>>>
>>
>> That's not the limit of the xyY space.
>>
>> That's the theoretical limit of _reflective_ colours illuminated by
>> standard illuminant C, plotted in xyY space.
>>
>
> Yes, that is fine. Not sure whether to use C or D65, though.
>
> https://en.wikipedia.org/wiki/Illuminant_D65
>
> These images on Wikipedia use D65, so I may just stick with that.
>
> https://en.wikipedia.org/wiki/File:Cie_Chart_with_sRGB_gamut_by_spigget.png
> https://en.wikipedia.org/wiki/File:CIE1931xy_gamut_comparison.svg
> https://en.wikipedia.org/wiki/File:Lab_color_space.png (I think)
The first two /show/ the D65 whitepoint (or, more precisely, its xy
coordinates), but other than that they're entirely independent of any
whitepoint. The first image even shows various other whitepoints.
As for the third image, I can't see where you got the idea that it has
anything to do with any whitepoint (except maybe for the fact that the
sRGB colour space, of which a few slices are shown, is defined such that
its "upper right" corner coincides with D65).
(Of course the image files themselves may also happen to be using a
colour encoding scheme that uses D65 as its nominal whitepoint, but I
don't think that's relevant in this context.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/28/2016 6:59 PM, clipka wrote:
> Am 29.11.2016 um 00:33 schrieb Mike Horvath:
>> On 11/28/2016 6:05 PM, clipka wrote:
>>>> I thought there was some tapering as the Y increases? This image
>>>> suggests that is the case.
>>>>
>>>>
http://www.math.ubc.ca/~cass/courses/m309-03a/m309-projects/bajwa/images/cie_3d.gif
>>>>
>>>
>>> That's not the limit of the xyY space.
>>>
>>> That's the theoretical limit of _reflective_ colours illuminated by
>>> standard illuminant C, plotted in xyY space.
>>>
>>
>> Yes, that is fine. Not sure whether to use C or D65, though.
>>
>> https://en.wikipedia.org/wiki/Illuminant_D65
>>
>> These images on Wikipedia use D65, so I may just stick with that.
>>
>> https://en.wikipedia.org/wiki/File:Cie_Chart_with_sRGB_gamut_by_spigget.png
>> https://en.wikipedia.org/wiki/File:CIE1931xy_gamut_comparison.svg
>> https://en.wikipedia.org/wiki/File:Lab_color_space.png (I think)
>
> The first two /show/ the D65 whitepoint (or, more precisely, its xy
> coordinates), but other than that they're entirely independent of any
> whitepoint. The first image even shows various other whitepoints.
>
> As for the third image, I can't see where you got the idea that it has
> anything to do with any whitepoint (except maybe for the fact that the
> sRGB colour space, of which a few slices are shown, is defined such that
> its "upper right" corner coincides with D65).
>
> (Of course the image files themselves may also happen to be using a
> colour encoding scheme that uses D65 as its nominal whitepoint, but I
> don't think that's relevant in this context.)
>
Okay, sorry, I didn't think it was possible to compare different color
spaces like sRGB or Adobe RGB without selecting a white point.
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.)
I don't think I'll figure out the math though.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
