What is a color in Processing?
Why colors are negatives? What are these strange values?
These are common questions, often seen in the forum.
Colors, in Processing, are stored actually in simple Java
ints, 32-bit values.
color pseudo-type is actually replaced by Processing with
int when generating Java code before compilation.
This type has a width of 32 bits, which is perfect as we can put 4 channels of 8 bits each inside. 8 bits allow a range of of values from 0 to 255 (included). The 4 channels are alpha (opacity), red, green, blue, the whole being often abbreviated as ARGB.
Low value of color channel means "low intensity", darkness. High value means "high intensity", lightness.
So if all channels are 0, we have black; if they are all at 255, we have white.
Alpha channel is different: 0 means low opacity, fully transparent, while 255 means high opacity, normal opaque color.
In Java, numbers are always signed. In computing, negative numbers are marked by setting the highest bit to 1. So, opaque colors, the most common kind, the default if no opacity is given, is 0xFF = 255, the high bit is set to 1, the color value is negative.
Hence the answer to the first question...
The strange values are the result of combining all the values of the channels.
Let's take a simple yellowish color. Alpha is 255 (opaque), red is 250, green is 230 and blue is, say, 20. These values are
Combined to make an
int, it gives
-334316. Hence a strange number, not very easy to decipher.
Note that Processing uses a special notation (not in the Java language) for color literals: the previous color can be written
#FAE614 (no alpha in this notation).
It is equivalent to
0xFFFAE614 or to a call to the
color(240, 130, 20);
If you want to print out color values, eg. for debugging, you have to use the
How do I get the color components?
The easiest way is to use red(), green(), blue() and alpha() functions. They return a floating point number. Also of interest are hue(), saturation() and brightness() for HSB mode.
But these functions are rather slow, because Processing takes the current colorMode() into account.
It is faster to use bitwise operations to get the components as integers between 0 and 255 (inclusive):
The idea is to shift the relevant bits to the right until they are at the lower position, then to mask them with 'and' to isolate them.
Likewise, you can build a color this way, although it is easier to use color() for that (which is, again, slower because of colorMode).