Wikifunctions:Type proposals/RGBA color
Summary
Having a format for colors would be nice - as they already have functions dedicated to them (opposite colour (Z13023), mix colours (string) (Z12997), and colour contrast ratio (Z13028), just to name a few.) However, all of these work either off of hex codes or natural number values - which isn't always the case. This proposal would use a range of 0-1 using Wikifunctions:Type_proposals/Rational_number for red, green, blue, and (optionally) alpha, to increase flexibility.
Uses
This would allow for more specific typing, as well as allowing uses outside of the 8-bit RGB color space.
Structure
The structure is simply an object with 4 keys - for the red, green, blue, and alpha fields - with a rational number inside each.
Example values
Value #0080ff
{
"type": "RGBA color",
"red": {
"type": "rational number",
"numerator": {
"type": "integer",
"sign": "neutral",
"absolute value": {
"type": "natural number",
"value": "0"
}
}
"denominator": {
"type": "natural number",
"value": "1"
}
},
"green": {
"type": "rational number",
"numerator": {
"type": "integer",
"sign": "neutral",
"absolute value": {
"type": "natural number",
"value": "128"
}
}
"denominator": {
"type": "natural number",
"value": "255"
}
},
"blue": {
"type": "rational number",
"numerator": {
"type": "integer",
"sign": "neutral",
"absolute value": {
"type": "natural number",
"value": "1"
}
}
"denominator": {
"type": "natural number",
"value": "1"
}
},
"alpha": {
"type": "rational number",
"numerator": {
"type": "integer",
"sign": "neutral",
"absolute value": {
"type": "natural number",
"value": "1"
}
}
"denominator": {
"type": "natural number",
"value": "1"
}
}
}
|
{
"Z1K1": "Zccccc",
"ZcccccK1": {
"Z1K1": "Zmmmmm",
"ZmmmmmK1": {
"Z1K1": "Z16683",
"Z16683K1": "Z16661",
"Z16683K2": {
"Z1K1": "Z13518",
"Z13518K1": "0"
}
}
"ZmmmmmK2": {
"Z1K1": "Z13518",
"Z13518K1": "1"
}
},
"ZcccccK2": {
"Z1K1": "Zmmmmm",
"ZmmmmmK1": {
"Z1K1": "Z16683",
"Z16683K1": "Z16661",
"Z16683K2": {
"Z1K1": "Z13518",
"Z13518K1": "128"
}
}
"ZmmmmmK2": {
"Z1K1": "Z13518",
"Z13518K1": "255"
}
},
"ZcccccK3": {
"Z1K1": "Zmmmmm",
"ZmmmmmK1": {
"Z1K1": "Z16683",
"Z16683K1": "Z16661",
"Z16683K2": {
"Z1K1": "Z13518",
"Z13518K1": "1"
}
}
"ZmmmmmK2": {
"Z1K1": "Z13518",
"Z13518K1": "1"
}
},
"ZcccccK4": {
"Z1K1": "Zmmmmm",
"ZmmmmmK1": {
"Z1K1": "Z16683",
"Z16683K1": "Z16661",
"Z16683K2": {
"Z1K1": "Z13518",
"Z13518K1": "1"
}
}
"ZmmmmmK2": {
"Z1K1": "Z13518",
"Z13518K1": "1"
}
}
}
|
Validator
The validator ensures that the fractions are in the range of 0-1, inclusive.
Identity
Two colors are the same if all keys are the same.
Converting to code
Python
A Tuple of fractions, in RGBA order. For the example value, this would be (Fraction(0, 1), Fraction(128, 255), Fraction(1, 1), Fraction(1, 1)).
JavaScript
An array of fractions, in RGBA order. For the example value, this would be [[0, 1], [128, 255], [1, 1], [1,1]]
Renderer
If the color would fit inside the typical 8-bit color hex format, it can be formatted as #rrggbbaa. Alpha should only be shown if it is not 1 (the default), and digits a-f should be in lowercase. If it doesn't fit in the normal format, it should default to showing the fractions in RGBA order. For example: [1/1, 2/3, 951/1327, 1/1].
Parsers
Parsers should be able to read the same formats the renderer puts out [hex codes or fractional representation].
Alternatives
- Instead of rational numbers, float64s could be used. They'd be a bit easier to work with without giving up too much precision.
- There are numerous other color standards that could work instead, like HSV or CIELAB.
- The alpha channel may not be necessary.
- We could store the values as bytes.
Comments
Support as proposer. infernostars (talk) (contribs) 19:40, 21 July 2024 (UTC)
Support Could be useful in dealing with color theory, effects, etc. DigitalCross (talk) 21:46, 21 July 2024 (UTC)
Support The amount of functions working on colors will only grow, it would be nice to have a standard color type for them -- ScienceD90 (talk) 21:58, 21 July 2024 (UTC)
Support -- Asked42 (talk) 19:33, 23 July 2024 (UTC)
Support -- dringsim 15:49, 13 October 2024 (UTC)
Support Feeglgeef (talk) 23:53, 16 November 2024 (UTC)
Oppose, I think CIELAB would be a better first color type.- I'm pushing for RGBA as it'd probably be easier to display, but CIELAB is also fair. I don't see why we couldn't have multiple color types, though. infernostars (talk) (contribs) 08:41, 1 January 2025 (UTC)
Support other colour formats are not in competition with this. This one looks solid to me. --99of9 (talk) 09:18, 7 February 2025 (UTC)
- Does a rational value of 1/1 correspond to 256/256 or 255/255? We may have to be careful about defining the conversions carefully near the inclusive bounds. I still support. 99of9 (talk) 03:39, 17 June 2025 (UTC)
- Apologies for the late response. I would think 255/255, since 8 bit colors are [usually?] from 0-255 inclusive. infernostars (talk) (contribs) 20:54, 14 August 2025 (UTC)
- Does a rational value of 1/1 correspond to 256/256 or 255/255? We may have to be careful about defining the conversions carefully near the inclusive bounds. I still support. 99of9 (talk) 03:39, 17 June 2025 (UTC)
Support Jérémy-Günther-Heinz Jähnick (talk) 09:42, 7 February 2025 (UTC)
Support --Ameisenigel (talk) 20:12, 7 February 2025 (UTC)
Support Other color formats can certainly come later, but this is an important starting point and a format that I think most users will be more comfortable with compared to others like CIELAB or HSV. — rae <talk> 17:20, 28 February 2025 (UTC)
Strong support we already have quite a few functions around colours that would benefit from it, see Wikifunctions:Catalogue/Colour functions. Cheers, VIGNERON (talk) 16:41, 16 March 2025 (UTC)
Support John Samuel 17:26, 16 March 2025 (UTC)
Support Dv103 (talk) 10:44, 26 April 2025 (UTC)