DSP Robotics Support

Anyone tried to play with wavelenght (visible light) to RGB conversion for color usage in FS?
No ruby...?

Where are you suggesting this "wavelength" variable would originate from?

I don't understand the question? Colors of visible light have wavelenghts. Colors of flowstone's RGB have 3 values (R-G-B), ranging from 0 to 255. I suppose there are some "curves" (templates based on assumptions) inside the RGB space, that reflect light spectra progression. If you type in google "wavelenght to rgb", you will find data on that, but I don't know how to translate them it into FS language. Besides I assume that someone played with it before me.

Yes but... even if you create a wavelength to RGB converter, you still have to feed it a wavelength value. Where would that value come from?

sorry in ruby it easy

Perfect Human Interface wrote:Yes but... even if you create a wavelength to RGB converter, you still have to feed it a wavelength value. Where would that value come from?

Ah, I see your point. There are various ways, starting from correlative measurements for example. My way is to transcode sound into color, by changing the octaves from sonic wavelenghts into visual ones. I need such specific representation for further testing and experimentation (among my reasons are some forms of synesthesia). Besides I'm curious how it looks like in raw form; mixing sounds is like mixing colors of light (i.e. additive synthesis).

Tronic wrote:

Code: Select all

# from http://www.physics.sfasu.edu/astro/color/spectra.html
def rgbFromWavelength(wl, gamma=0.8)
  rgb=case wl
      when (380..439); [-1.0*(wl-440.0)/(440.0-380.0), 0.0, 1.0]
      when (440..489); [0.0, (wl-440.0)/(490.0-440.0), 1.0]
      when (490..509); [0.0, 1.0, -1.0*(wl-510.0)/(510.0-490.0)]
      when (510..579); [(wl-510.0)/(580.0-510.0), 1.0, 0.0]
      when (580..644); [1.0, -1.0*(wl-645.0)/(645-580.0), 0.0]
      when (645..780); [1.0, 0.0, 0.0];
      end
  sss=(wl>700 && 0.3+0.7*(780.0-wl)/(780.0-700.0) ||
       wl<420 && 0.3+0.7*(wl-380.0)/(420.0-380.0) ||
       1)
  rgb.map!{|c| (sss*c)**gamma}
  def rgb.to_bytes; self.map{|c| (0xff*c)};   end
  def rgb.to_s; ('#'+'%02x'*3)%self.to_bytes; end
  rgb
end

sorry in ruby it easy

Quick question - what is provided as input here (i.e. what value), and what comes from output (shhouldn't there be 3 outs for R-G-B integers?) ? When I paste the code to ruby window, I see no inputs nor outputs related to the formula. Sorry, but I have no idea what to expand it, help

you needed to adapt it for use with the primitive I2C,
I made the changes as having 3 separate outputs for RGB values​​, and a fourth that contains them all in an array.

then copy the code in a ruby module,
set the input to float, sets three output in integer, and the last in integer array.

Okay, works, thanks. Another question - what is the formula for additive mixing of colors (i.e. like mixing the lights)? Is it a matter of just adding the RGB channels from two sources, or some sort of averaging (channels sum / n-channels)?

//edit:

Okay, i see two approaches. One is to take max value from one of channels (thus - mixing RGB produces white). Second is to take average of channels (mixing RGB produces dark grey). Or did I miss something?

I'm curious if there are other RGB mapping systems, or how "accurate" (towards "natural perception") is this one.

Adding the RGB values is certainly the conventional way to do it - and results in a colour that usually seems intuitively correct much of the time (e.g. red + yellow = orange)
But there are a couple of things to watch out for...
(NB - this is based on my knowledge of photography; I make no claim of any expertise in optical physics or perceptual models!)

1) Gamut
Whereas in reality, the intensity can just keep on increasing when adding colours, RGB has a max of 255 per channel. This badly effects colours as soon as any one of the channels reaches the max.
Not always easy to deal with - in programs like Photoshop, there are often many choices for rendering out-of-gamut colours. Some purely mathematical - like your idea of averaging to keep the proportions. But others are based on models of eye/brain colour perception, in some cases using the values of surrounding colours to bias the results.
Part of the problem is that the eye's perception of illumination is not linear - whereas RGB and the hardware of monitors is. So a simple averaging doesn't necessarily make a colour which appears to be a darker version of the desired hue.

2) Metamerism
This has to do with the equivalence of colours that are made using two different sets of 'primary' components.
As an example - even the best PC monitor calibration can never make two monitors show EVERY colour exactly the same if the red, green and blue used for the pixels are different between the two. You can get very close, but the gamuts will always be slightly different.
I mention this because, naturally, the cones in our eyes will be tuned to particular RGB components too - which probably aren't the same RGB used on a display.
I have no idea if that would affect your research, but as you are interested in biological/perceptual effects like synaesthesia, it may have some bearing. For example, research has shown that looking at an LCD monitor before bedtime affects the ability to sleep, due to too much of certain blue wavelengths - and also that this effect is not the same as viewing, say, the blue of the sky. So it would seem that precise wavelengths have some importance here, or maybe simply that the artificial light has narrow peaks rather than a diverse spectrum.

Once again, i am answering your questions with more questions - but maybe will lead you to some research that is more based on psychology than Photoshop!