views:

1009

answers:

2

The common mixing of RGB colors is very different from mixing colors for paintings, it's mixing of light instead mixing of pigments.

For example:

Blue (0,0,255) + Yellow (255,255,0) = Grey (128,128,128)

(It should be Blue + Yellow = Green)

Is there any known algorithm for color mixing that works like mixing real colors?

I've already tried following:

Converting both colors to HSV and mixing hues (multiplied by coefficient computed from saturation), and simple average for saturation and value channels. Then I computed average luminance from both colors (using Rec. 709 luma coefficients) and adjusted the result color to match this luminance. This worked quite well, but the hue mixing was sometimes wrong, e. g.:

Red (Hue 0°) + Blue (Hue 240°) = Green (Hue 120°)

I've figured out that sometimes I need to shift the hue value by 360° (when the difference between hues is greater than 180°).

Red (Hue 360°) + Blue (Hue 240°) = Magenta/fuchsia (Hue 300°)

But this shifting wasn't very good too, e.g.:

Cyan (Hue 179°) + Red (Hue 0°) = Hue 89.5°
Cyan (Hue 181°) + Red (Hue 0°) --> shifting is performed (difference is greater than 180°)
Cyan (Hue 181°) + Red (Hue 360°) = Hue 270.5°

(Hue 179 + Red) and (Hue 181 + Red) results in two COMPLETELY different colors.

Then I tried CIE LAB color space (like in Photoshop), which is supposed to have realistic colors for human (or something like that). I used just simple average for each corresponding two channels, but the results weren't satisfying, for example I got pink (64, 26, -9.5) out of blue (98, -16, 93) and yellow (30, 68, -112). These coefficients were taken from Photoshop. Maybe if I used some different operation than average, it could work, but I don't know what.

CMYK didn't work too, results are just like in RGB or LAB.

There is piece of working software: http://commit-digest.org/issues/71 (Krita). They say it is the first public application that implements special technology using Kubelka and Munk equations that describe the behavior of pigments. It's two years old, but I couldn't find anything related in the current KOffice 2.0.81 source code.

+1  A: 

there are two different possibilities combining colors:

  1. additive mixing (like RGB)

  2. subtractive mixing (like CMYK)

So in subtractive color mixing the result is what you expected, but there is no blue, instead there is cyan:

Yellow + cyan = green

In general subtractive color mixing is just "taking away" (filtering) from white while additive color mixing is adding up from black. (base colors of subtractive are inverse from additive: red ->cyan; green->magenta; blue->yellow)

So if you start with white screen applying filters:

min( white (255,255,255), yellow (255,255,0), cyan (0,255,255)) = green (0,255,0)

Peter Parker
What if I try blue as Cyan+Magenta (100%, 100%, 0, 0). When I mix this with yellow, it doesn't seem very realistic and natural.
tomp
The "rule "yellow+blue=green" is a misconception. You have to mix cyan with yellow to get blue(on subtractive colors).
Peter Parker
CMYK isn't "right" either. It's an approximation model, just like RBY-. You could perhaps argue that it is "more" right than RBY-.
RBarryYoung
+8  A: 

The correct answer is NO, because there is no correct working model of how "color mixing in the real world" really works. It is FAR too complex and conditional and not really at all like the simple Red-Blue-Yellow stuff that we learned in school (it in fact requires all of Chemistry and a lot of Physics and Biology to resolve).

However, the simplistic answer is: YES, use subtractive mixing rather than Additive mixing.

The color-mixing that we learned in grade school is based on pigment combinations which are a form of subtractive color mixing (very simplistically). That is the more colors that we add together, the darker it becomes because each pigment subtracts a little bit more light.

On the other hand, almost all computer color-schemes are additive in that they are based on combining light waves (very simplistically), so they get brighter, because each color adds a little bit more light.

The RGB+ scheme is somewhat, the additive complement to the subtractive scheme that we learned in most US elementary schools (which is RBY-). However, they do not match up exactly and it can be difficult to convert between them (researching now ...)


OK, if you just want to switch from additive combinations in RGB to subtractive ones, you can use the following reverse-bayesan type formula to combine two colors:

NewColor.R = (Color1.R * Color2.R)/255
NewColor.G = (Color1.G * Color2.G)/255
NewColor.B = (Color1.B * Color2.B)/255

Adjusting for the difference in the chromatic poles (G to Y, then back to G) is a lot harder ...


It has been pointed out that this produces Black for the example problem, and technically this is correct for a true subtractive system, however, if you want more diluting/subtractive system, you could try this instead:

NewColor.R = 255 - SQRT(((255-Color1.R)^2 + (255-Color2.R)^2)/2)
NewColor.G = 255 - SQRT(((255-Color1.G)^2 + (255-Color2.G)^2)/2)
NewColor.B = 255 - SQRT(((255-Color1.B)^2 + (255-Color2.B)^2)/2)

This produces a dark grey instead of Black. But to get Yellow or anything close, you still have to fix the color-scheme's pole-alignment problem.

RBarryYoung
This formula would give black in the situation mentioned, wouldn't it?
Dolphin
Hmmm, yeah, pretty close. Let me find something better then...
RBarryYoung
So have you found something better?
tomp
No, it's pretty hard not to come up with Black in any subtractive approach because all three poles are maxed out in the source. The only solutions that I can see require re-mapping to a different scheme which I've been trying to avoid for a "simple" solution. Hmmm, ... give me a couple of hours this morning though, I may have a "simple" re-mapping to fix it...
RBarryYoung