Indeed. :-)mcallegari wrote:Alright thanks, Robert's Excel studies seem the most scientific to me :)
One thing I don't understand though: after calculations on RGB channels, what is the contribution of the white channel ? The original one (column E) ?
Basically on RGBW_equation2.xlsx I would expect to see an additional column (N ?) with the final W value.
Also, there's one more thing to consider. At the moment, RGB scripts work only on RGB channels. Changing them for additional channels would be a mess, and moreover depends on what kind of fixtures you're using.
Indeed a delicate topic...
Disregarding the UV and such channels for the moment, this is an issue of colorspace mapping, and it's similar to what takes place inside a RIP when you're going from RGB image files to CMYK toner; not only do you have to convert RGB to CMY, you then have to figure out how much black to replace the colors with, an issue that depends on the gamuts of all 4 toners.
The issue will be the same here -- for any given combination of colors, you have to decide how much of it to replace with white, and how -- and what the best way is to do it depends a lot on who the audience is and what they're using it for.
My snap reaction is that the right answer is to switch the users over to entering either HSB, or HLV, probably HSB, and then convert that to RGB or RGBW (which is usually a cool white), or RGBA, internally on the way to the fixture.
You could actually still allow entry in RGB, even; store all colors as both HSB *and* the components, and leave whichever one wasn't entered as all 0's; then convert on the way out if necessary. That allows, even, dealing with multicomponent fixtures (RGBAWU, or things like the 6-color ETC's), and puts the translation tables/formulae inside the fixture machinery, where it belongs, without keeping you from being able to access individual components if you need to.
It would also make colors stored in cue sheets portable across fixtures, as much as that's possible.