An important thing to understand is that, from Processing’s perspective, there is no “negative bit” in a color. The bits are AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB.
Because the actual storage for a color is an int, if you println() the int, it is interpreted as having a sign bit – but that is just an interpretation of a list of 0s and 1s, and not a helpful one. As long as you don’t try to println(c), there isn’t a hastle – looking at the default print of a color is confusing, because Java’s default interpretation of that primitive value isn’t the way that the bits are meant to be interpreted. However, wrapping each color value (e.g. a pixel) in an object with an attached print method doesn’t make sense for high speed graphics processing – they are stored in ints (rather than Color or Pixel objects) for performance, and you use alpha() red() green() blue() helper methods – rather than Pixel.print() or print(Pixel). But the fastest way to do it is with bit-shifting, and this is generally what Processing is doing when working with color channels – it is grabbing the relevant bits directly. There is an example on the reference page for >> (right shift):
Here is a slightly expanded version of that example:
color c = color(127, 63, 31);
int a = c >> 24 & 0xff;
int r = c >> 16 & 0xff;
int g = c >> 8 & 0xff;
int b = c >> 0 & 0xff;
println(a, r, g, b);
// 255, 63, 127, 255
println(binary(a));
println(binary(r));
println(binary(g));
println(binary(b));
// 00000000000000000000000011111111
// 00000000000000000000000001111111
// 00000000000000000000000000111111
// 00000000000000000000000000011111