I’ve changed my previous comment to clarify what I meant. I’ve also stepped back from saying color(string) would have appeal for everyone. The point that users can choose whether or not to use something that can be shared as Lua code has considerable weight.
Okay here’s the initial plan for color in the next version of Codea. Let me know if you have any suggestions.
Blend
result = color.blend( source, dest )
result = source:blend( dest )
This blends the two colours as if you were layering them in Photoshop. So the resulting colour is computed as:
red = source.r * source.alpha + dest.r * ( 1 - source.alpha )
green = as above
blue = as above
alpha = source.alpha + dest.alpha
One problem with implementing blend in this fashion is that it discards the destination alpha. We could pre-multiply the dest colour by its alpha, but I’m unsure if that’s appropriate.
(The above, and all following functions take into account that colours sit in the 0-255 range and normalise/clamp as appropriate.)
Mix
(Could also be named “interpolate” or “lerp”)
result = color.mix( source, dest, amount )
result = source:mix( dest, amount )
This mixes the two colours linearly. Where amount is from 0 to 1. So the result is:
red = source.r * amount + dest.r * ( 1 - amount )
green, blue and alpha = as above
Multiply
multipliedColor = color1 * color2
Computes the result as:
red = source.r * dest.r
green = as above
blue = as above
alpha = source.alpha + dest.alpha
Add
addedColor = color1 + color2
Computes the results by adding all channels and clamping to a valid range.
Equality
Equality supported as in vectors
Supporting equality has my vote.
newColor = color1:mix(color2, proportion) seems to me to be a better syntax than newColor = color1:interpolate(color2, proportion), if the meaning of ‘mix’ is documented in the in-app reference. The abbreviation for linear interpolation (lerp) might be intuitive (and, consequently, memorable) only for a small subset of potential users of Codea.
I do not know enough about the practice of users to comment on the utility of the additional functionality. I wondered: Will this save a lot of users a lot of coding, or will providing this as part of the Codea API provide functionality that is a lot faster in execution than what users could achieve coding the same functionality in Lua?
I also do not know enough about the principles to comment on the algorithms.
I did wonder if newColor = color1:blend(color2) should be consistent with the (different) algorithm for alpha blending described in this Wikipedia article.
I did wonder what ‘multiplication’ meant, conceptually, for colours with an alpha channel less than 100%. If you alpha blend two colours with 50% opacity, the result is a colour with 75% opacity (50% + 50% x 50%). Is it right that when you multiply those colours, the result is opaque (50% + 50% = 100%)?
In respect of the mathematics for different types of compositing, does the W3C SVG Compositing Specification here help?
(Update) Specifically, if I understand the specification correctly (and assuming that color1 = color(r1, g1, b1, a1) is not pre-multiplied):
Multiply
a3 = a1 + a2 - a1*a2 (clamped)
r3 = (r1 * a1 * r2 * a2 + r1 * a1 * (1 - a2) + r2 * a2 * (1 - a1))/a3 (etc)
Plus
a3 = a1 + a2 (clamped)
r3 = (r1 * a1 + r2 * a2)/a3 (clamped) (etc)
Thinking further about ‘utility’, I can imagine that people might use this functionality to composite images, pixel-by-pixel.
If that is so, a ‘faster execution’ rationale might imply the functionality should be added to the image userdata rather than the color userdata. For example:
newImage = image1:blend(image2)
or
newImage = image1:blend(image2, left, bottom)
where optional arguments left and bottom identify the location of the bottom lefthand corner of image2 relative to the bottom lefthand corner of image1.
I am still on a learning curve when it comes to compositing, but the following has occurred to me.
People could use color userdata values to represent either straight or premultiplied format colours/pixels. However, some operations to composite colours/pixels may depend on whether or not the inputs are taken to be in a straight or premultiplied format. If the color userdata does not carry with it a flag to indicate whether or not it is taken to be in premultiplied format (and I am not suggesting that it should), does that imply that some of the suggested operations supplied by the Codea API will have to make an assumption about what format the userdata is taken to be in?