??? 06/14/10 21:44 Read: times |
#176677 - Everything depends on needs - simplification often ok Responding to: ???'s previous message |
As I mentioned in an earlier post, the candela value of a LED hides the difference in spectral sensitivity of our eyes. That means that your calculations can be simpler and just assume that R=1 and G=1 and B=1 gives the same perceived lightness.
If you use a physical presentation medium that instead specifies mW of optical output, then you need to consider weights to adjust between different color channels. HSV is not a good color space, in that the different colors the same distance from the apex do not have a constant intensity. In many cases, you can live with this defect. In some situations, you need to scale the intensity (changing the height above the apex) to maintain visual intensity. The actual constants will vary with the wavelength used for R, G and B. The values I gave ealier was for the phosphors of the NTSC video standard. sRGB, which is the standard color space used for the web and most digital cameras, instead defines .21R + .72G + .07B. Having red and blue further apart means the RGB cube can span more colors, but at the same time our eyes gets less sensitive to the specific wavelength. You could use the diagram from the following link to estimate own constants based on the wavelength of the RGB primaries. http://www.amastro2.org/at/ot/othcs.html When you can - hide the scaling constants of the color primaries in the hardware (buying suitable diodes or adjusting drive current). The reason I suggested HSV is that it has nice properties for spanning the the RGB cube while requiring simple math. And it is quite easy to do HSV->RGB and then scale the RGB values for (almost) constant perceived intensity. But one question then is if you should forbid the user to select a color of maximum white, since the perceived intensity of maximum white is higher than the maximum intensity of pure red, pure green or pure blue. There exists much nicer color spaces, but seldom suitable for a little microcntroller without good floating point capabilities - or at least with good fixed-point capabilities. HSV was developed for real-time processing with better hardware from 1970. |