N-dimensional sorting and color

[jeremydouglass]

@Pisicandru

How do you do the transformation from RGB to this negative number? I read the processing help for color, but i still don’t understand it.

They aren’t actually “negative numbers” in any meaningful sense. All values with alpha greater than 50% have their first bet set – which happens to be the “sign” bit if it was a normal number (which it isn’t).

Try searching the forum for past discussions of

AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB

Maybe this explanation will help?

Println(color) gives strange color number

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 …

Or try playing with this sketch:

/**
 * InspectColorBinary
 * 2020-04 Jeremy Douglass - Processing 3.4
 *
 * Use the Processing built-in function binary()
 * to inspect bits in a color. Colors are stored as ints.
 * All values are AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB
 *
 * See:
 * -  https://processing.org/reference/color_datatype.html
 * -  https://processing.org/reference/binary_.html
 */

int c;

void setup() {
  println("AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB\n");

  // RGB
  inspectColor( color(0, 0, 0) );
  inspectColor( color(255, 0, 0) );
  inspectColor( color(0, 255, 0) );
  inspectColor( color(0, 0, 255) );
  inspectColor( color(255, 85, 255) );
  println();
  
  // plus alpha
  inspectColor( color(0, 255, 0, 85) );
  println();
  
  // created with HSB mode
  // -- int still stores AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB
  colorMode(HSB);
  inspectColor( color(0, 255, 255) );
  inspectColor( color(127, 255, 255) );
  inspectColor( color(0, 0, 255) );
  inspectColor( color(0, 0, 255, 10) );
}

void inspectColor (int c) {
  print(binary(c), c, "\n");
}

Output:

AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB

11111111000000000000000000000000 -16777216 
11111111111111110000000000000000 -65536 
11111111000000001111111100000000 -16711936 
11111111000000000000000011111111 -16776961 
11111111111111110101010111111111 -43521 

01010101000000001111111100000000 1426128640 

11111111111111110000000000000000 -65536 
11111111000000001111111111111011 -16711685 
11111111111111111111111111111111 -1 
00001010111111111111111111111111 184549375 

The binary numbers on the left show you what is going on with the bits, and where the A, R, G, B are stored.

The numbers on the right… don’t really mean anything. They are technically what happens if you combine the color information using this equation:

B + (G * 256) + (R * 65536) + (A * 16777216)

… and then if A>127 multiply everything by -1.

There are a number of other ways we could describe this, using powers of 2
or bit shifting.

But that doesn’t help explain what is actually happening. What is actually happening is you take your A, R, G, B and arrange the bits next to each other in an int, like this:

AAAAAAAA RRRRRRRR GGGGGGGG BBBBBBBB

And those bits are what the int “means” as a color – they act like four different variables, saved in one object. There is no such thing as a negative color, in this model – only different amounts of RGB and alpha. It also doesn’t mean anything to add, multiple, or divide the int as an int – it is really four bands of bits, so if you add one, lots of blue can suddenly become a little green for no reason. Again, it isn’t useful to think of it as “a number” – that isn’t what it represents.