Yeah, I was thinking that because as @bh was saying
We are not mixing pigments on a screen, We mix light!
That means it would be easier to explain
It also makes sense because RGB is additive, it is based on LIGHT; Because of this, it is very easy to program, it also makes more sense.
but of course we could try to make it pigments, I just don't think it would be very helpful for programers.(And programmers are the main audience of snap)
Next time, could you just include what you were going to say as part of the "call"? I'll see it eventually and reply.
Anyway what do you need
I need this
bump.
Yes
They did ask bh
You may need to add the originals. (mix, color, etceteras)
Yes, MIX is missing. Right now I'm focusing on constructors and selectors.
(This is why I didn't post a link before -- this is not ready for review!)
Are there other missing functions whose domain and range are both colors, besides MIX? I suppose we should also have conversion to and from CMYK, but that's so messy -- you have to say what specific printer model you're using to get the conversion right in Photoshop.
Is there a "standard" printer set.
let's just use ISO/IEC 15948
I'm confused. That's the definition of the PNG file format. I don't think it includes a specific gamut, although it does include a provision for including gamut information in a PNG file.
I think if we were going to just pick one it'd have to be sRGB.
It would also be possible to ignore the problem and just define the CMY primaries as equal to the RGB secondaries, so Cyan is RGB 00ffff, Magenta is ff00ff, and Yellow is ffff00. In principle there's no need for black ink; that's just a concession to real chemistry.
If you mix yellow and cyan pigments and then illuminate it with white light, the yellow pigment subtracts all light except for the red, yellow and green, and the cyan pigment subtracts all light except for the yellow, green and cyan. What you get left with is green, and as a result, mixing yellow and cyan subtractively yields green.
In order to express this using RGB colour values, you would start with white, subtract the opposites of yellow and cyan, which are blue and red, and then you get green. Alternatively, if the values are 0 to 1, you can also imagine it as multiplying the RGB channels of the yellow and cyan together, as only the light that both colours of pigment let through is visible. (These two ways to think about it give different results, and the multiplicative way is more accurate to real life, but both agree on the basics of subtractive colour mixing.)
I've been experimenting, and I think I've found a better way to mix two colours. Square the components of both colours before averaging them, and then take the square root of the result.
Here is the result of mixing a bright red with a bright lime, using the "regular" method:
And here is how it looks if you square and square root:
It looks a lot better. The reason this works is complicated, and relates to how computers store colour values perceptually rather than linearly, but this is close to how the two colours would blur together in real life, such as with an out of focus camera.
For inspiration for a good set of colour operators, I would look at 3D vector operations. Our perception of colours inherently has three degrees of freedom, whether they be red, green and blue, cyan, magenta and yellow, or hue, saturation and brightness, and mathematics has plenty of ideas on how to operate on three-dimensional values like that.
but to needs to be RIGHT. please share the project link so I can see.
This isn't the exact same project (the screenshots came from an experimental fork of Snap!), but you can test both colour-mixing methods with this project: