A few years ago I created a macro that returns reflective spectral power
distribution (SPD) curves, but I hesitated to publish it due to its poor
correspondence with RGB colors.  But over the past couple of months, I
developed a filter that solves this problem: you submit an RGB spec, and
it figures out what to tell the SPD generator.  For good measure, I also
threw in a true RGB generator.

  https://github.com/CousinRicky/POV-MakeSpectrum

The illustrations show three examples of X11/SVG colors passed through
my library.  For each illustration, the large spheres were pigmented
with SPDs converted to colors using Lightsys IV.  The left SPD was built
from individual red, green, and blue curves, and the right SPD is from
my original SPD generator (albeit tweaked over the years), which was
designed to generate reflective SPDs resembling those bundled with
Lightsys IV and SpectralRender.  The small sphere at the center was
simply pigmented with the straight sRGB color.

The sphere colors are all reduced to 62.5% value, corresponding to a
finish diffuse of 0.625.  The scene has the recommended assumed_gamma 1:
the library handles sRGB and gamma issues.

Post a reply to this message

Attachments:
Download 'test_makespectrum_x11-pbi003.jpg' (37 KB) Download 'test_makespectrum_x11-pbi040.jpg' (42 KB) Download 'test_makespectrum_x11-pbi100.jpg' (36 KB)

Preview of image 'test_makespectrum_x11-pbi003.jpg'

Preview of image 'test_makespectrum_x11-pbi040.jpg'

Preview of image 'test_makespectrum_x11-pbi100.jpg'

Cousin Ricky <ric### [at] yahoocom> wrote:
> A few years ago I created a macro that returns reflective spectral power
> distribution (SPD) curves, but I hesitated to publish it due to its poor
> correspondence with RGB colors.  But over the past couple of months, I
> developed a filter that solves this problem: you submit an RGB spec, and
> it figures out what to tell the SPD generator.  For good measure, I also
> threw in a true RGB generator.
>
>   https://github.com/CousinRicky/POV-MakeSpectrum
>
> The illustrations show three examples of X11/SVG colors passed through
> my library.  For each illustration, the large spheres were pigmented
> with SPDs converted to colors using Lightsys IV.  The left SPD was built
> from individual red, green, and blue curves, and the right SPD is from
> my original SPD generator (albeit tweaked over the years), which was
> designed to generate reflective SPDs resembling those bundled with
> Lightsys IV and SpectralRender.  The small sphere at the center was
> simply pigmented with the straight sRGB color.
>
> The sphere colors are all reduced to 62.5% value, corresponding to a
> finish diffuse of 0.625.  The scene has the recommended assumed_gamma 1:
> the library handles sRGB and gamma issues.

I had to lookup 'SPD curves' to understand what you did here. :)
.....very impressive.
Mike

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> A few years ago I created a macro that returns reflective spectral power
> distribution (SPD) curves, but I hesitated to publish it due to its poor
> correspondence with RGB colors.  But over the past couple of months, I
> developed a filter that solves this problem: you submit an RGB spec, and
> it figures out what to tell the SPD generator.  For good measure, I also
> threw in a true RGB generator.
>
>   https://github.com/CousinRicky/POV-MakeSpectrum
>
> The illustrations show three examples of X11/SVG colors passed through
> my library.  For each illustration, the large spheres were pigmented
> with SPDs converted to colors using Lightsys IV.  The left SPD was built
> from individual red, green, and blue curves, and the right SPD is from
> my original SPD generator (albeit tweaked over the years), which was
> designed to generate reflective SPDs resembling those bundled with
> Lightsys IV and SpectralRender.  The small sphere at the center was
> simply pigmented with the straight sRGB color.
>
> The sphere colors are all reduced to 62.5% value, corresponding to a
> finish diffuse of 0.625.  The scene has the recommended assumed_gamma 1:
> the library handles sRGB and gamma issues.

If I understand correctly, it inputs computer color(often 3- value like RGB),
output a spectral curve. This is very important for some application.

I want to research it in the future.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> A few years ago I created a macro that returns reflective spectral power
> distribution (SPD) curves, but I hesitated to publish it due to its poor
> correspondence with RGB colors.  But over the past couple of months, I
> developed a filter that solves this problem: you submit an RGB spec, and
> it figures out what to tell the SPD generator.  For good measure, I also
> threw in a true RGB generator.
>
>   https://github.com/CousinRicky/POV-MakeSpectrum
>
> The illustrations show three examples of X11/SVG colors passed through
> my library.  For each illustration, the large spheres were pigmented
> with SPDs converted to colors using Lightsys IV.  The left SPD was built
> from individual red, green, and blue curves, and the right SPD is from
> my original SPD generator (albeit tweaked over the years), which was
> designed to generate reflective SPDs resembling those bundled with
> Lightsys IV and SpectralRender.  The small sphere at the center was
> simply pigmented with the straight sRGB color.
>
> The sphere colors are all reduced to 62.5% value, corresponding to a
> finish diffuse of 0.625.  The scene has the recommended assumed_gamma 1:
> the library handles sRGB and gamma issues.


Hi Cousin Ricky,

Your post attracted my attention as I've spent some time working with spectral
power distribution myself. I had a look at your library and Ive's work (which I
didn't knew about), but couldn't check Lightsys as the link is broken.

If I understand well, your macros are intended to be used as a conversion tool
from RGB values to SPDs to be used in Ive's macros. Could you explain what are
the advantages of using your macros over Ive's D_RGB macro (which seems to me to
have the same function) ?

Regards,
Pascal

Post a reply to this message

On 2023-08-06 00:08 (-4), BayashiPascal wrote:
> 
> Your post attracted my attention as I've spent some time working with spectral
> power distribution myself. I had a look at your library and Ive's work (which I
> didn't knew about), but couldn't check Lightsys as the link is broken.

I have reposted Lightsys 4d in p.binaries.scene-files.

> If I understand well, your macros are intended to be used as a conversion tool
> from RGB values to SPDs to be used in Ive's macros. Could you explain what are
> the advantages of using your macros over Ive's D_RGB macro (which seems to me to
> have the same function) ?
I had two issues with D_RGB().  The first, as Ive made clear in the
documentation, is that it does not match the RGB colors that we are used
to.  This makes matching colors more difficult, and this task is indeed
the reason I held up publishing MakeSpectrum for so long.

The second issue is that some RGB combinations create pigments that
reflect/transmit more light than than they receive at some wavelengths.
This can be seen in the attached illustration.

I am currently looking at a potential third issue: whether or not
generating SPDs by naively combining primary colors will lead to the
same fade_color/absorption primary color bias than RGB rendering has,
but I do not have results on that yet.

Post a reply to this message

Attachments:
Download 'graph_d_rgb.png' (94 KB)

Preview of image 'graph_d_rgb.png'

Thanks for your reply.

> I had two issues with D_RGB().  The first, as Ive made clear in the
> documentation, is that it does not match the RGB colors that we are used
> to.  This makes matching colors more difficult, and this task is indeed
> the reason I held up publishing MakeSpectrum for so long.

I think I see what you mean: Ive's D_RGB() function's arguments represents a
combination of the SPDs for the D_CC_A3, D_CC_B3, D_CC_C3 color patches (used as
proxy for red, green, blue), while in your approach the RGB values in argument
stand for the 'pure' red, green, blue of "pigment {rgb <red,green,blue>}" that
POV-Ray users are used too. Right?

> The second issue is that some RGB combinations create pigments that
> reflect/transmit more light than than they receive at some wavelengths.
> This can be seen in the attached illustration.

Ok.

> I am currently looking at a potential third issue: whether or not
> generating SPDs by naively combining primary colors will lead to the
> same fade_color/absorption primary color bias than RGB rendering has,
> but I do not have results on that yet.

I don't understand what you mean here, but I guess you'll share here your
results about it, so wait-and-see.

Post a reply to this message

Le 2023-08-06 à 16:34, Cousin Ricky a écrit :

> The second issue is that some RGB combinations create pigments that
> reflect/transmit more light than than they receive at some wavelengths.
> This can be seen in the attached illustration.
> 
That part can be explained by florescence. Some of the absorbed light of 
shorter wave length get re-emitted as longer wave length.
One blue photon is absorbed and re-emitted as 2 red photons or a red and 
an infra red photon.
Notice that the excess tend to be in the dark red region of the 
spectrum, almost infra red.

Post a reply to this message

On 2023-08-07 06:35 (-4), BayashiPascal wrote:
> 
>> I am currently looking at a potential third issue: whether or not
>> generating SPDs by naively combining primary colors will lead to the
>> same fade_color/absorption primary color bias than RGB rendering has,
>> but I do not have results on that yet.
> 
> I don't understand what you mean here, but I guess you'll share here your
> results about it, so wait-and-see.

And it turns out that combining red, green, and blue SPDs does lead to
the same bias as RGB rendering.

The top right and top center images use SpectralRender, while the upper
right image is straight up RGB rendering.  Each image in the lower row
shows the SPD of the sphere in the image directly above.

You can see how the hue of the transparent prism in the top right image
very quickly drifts toward phosphor blue.  This is what drove me to
spectral rendering in the first place.  The top center image, which uses
macro MakeSp_RGB_Args() to combine red, green, and blue SPDs similarly
to D_RGB(), shows the same bias as the RGB render.  In the top left
image, which uses macro MakeSp_Meta_RGB_Args(), the transparent prism
maintains the hue of the sphere.

RGB composites are still useful for opaque pigments, as most hues cannot
be created at full 'value' with the metamer macros.  For example, the
blue in these images (H = 210) maxes out at 0.8214.  Aqua in the OP
maxes out at approximately 0.625.  But for colored transparent
materials, disconnecting the SPD from RGB modeling really makes a
difference.

Post a reply to this message

Attachments:
Download 'fade_metamer_rgb-pbi.jpg' (117 KB)

Preview of image 'fade_metamer_rgb-pbi.jpg'