What's the difference between int negative color values and float negative color values?

finnhusky

In fact I have two questions. 1. how does fill() interpret big negative numbers, such as "fill(-1000)"? 2. In the following examples, type int color value makes the rect change colour from white to black to yellow, while float value makes the rect change colour simply from white to black. How does that happen(fill(-1000) vs. fill(-1000.0))?

type "int" x: int x = 255; void setup(){ size(300, 300); background(0); } void draw(){ fill(x); rect(0, 0, 100, 100); x--; println(x); }

type "float" x: float x = 255; void setup(){ size(300, 300); background(0); } void draw(){ fill(x); rect(0, 0, 100, 100); x--; println(x); }

TechWiz777

Okay, for your first question I am not so sure, I haven't tried. But for the second question, let's see, okay, an int, and you are taking away from it, in this case your int is 255, you are only going on the black to white scale. Because you only have one fill() value. Whereas with the float it is doing the same thing, but is interacting with the -1000.0 I'm thinking because the -1000.0 is more specific, and is mostly the best to use when dealing with changing objects.

TechWiz777

I mean, it is best to use a float when dealing with changing variables.

GoToLoop

Processing's color datatype represents a 32-bit Java's int datatype:
https://processing.org/reference/color_datatype.html

Processing has a complex way to determine how color parameters are interpreted:
https://processing.org/reference/color_.html

• Passing 1 argument, values between 0 and maxColor from colorMode() are interpreted as gray scale.
• Otherwise it's interpreted as an ARGB value.
• Notice that outside range values are clamped!
• As you had noticed, when that 1 argument is float, it's always gray scale!

For why colors happen to be in negative range many times, read these Wikipedia articles below: :-B

• https://en.wikipedia.org/wiki/Signedness
• https://en.wikipedia.org/wiki/Two's_complement_notation

akenaton

@GoToLoop:: with float and outside values, values are set to min or max and we remain in grayscale; but with int and values out of range it seems different; when max or min are exceeded colormode "changes" and some kind of cycle happens each 255 (510,1020...) with color(255,255,x) (from white to yellow). I dont understand why and cannot explain but the code below shows that better than words...

     int x = 256;
    int y = 255;

    void setup(){
    size(300, 300);
    background(0);
    }
    void draw(){
     frameRate(24);
     color coul = color(x);//when min value: seems to leave grayscale to cycle(each 255...510...) reached in ARGB mode (255,255,[0,255];
      fill(coul);

      rect(0, 0, 100, 100);

      fill(255,255,y);//when min value: no more change, y always == 0
      rect(0,200,100,100);
       x--;
      y--;
      println(x);

    }

GoToLoop

Thanks @akenaton for the extra info. :)>-
Although I've just focused w/ 1 parameter only for simplicity's sake! 8-X

akenaton

@GoToLoop== yes and your answer is perfectly clear! - But till now i thought that out of r values or give unpredictible results or are automatically reset into range (or throw illegalargument exception): that is not true but remains strange!

GoToLoop

Yea, very confusing! Besides corrupting result when multiple threads call them! :-@

All those crazy calculations are done by protected colorCalc() & colorCalcARGB() functions and their multiple overloaded forms:
https://github.com/processing/processing/blob/master/core/src/processing/core/PGraphics.java#L7210

finnhusky

Thank you everyone. It seems the deeper mechanism is more complicated than I expected. I'm not a math or programming person, so right now it's better for me to just remember the existing difference regardless of the real cause...

akenaton

@GoToLoop=== yes, these functions seem to be the key...knowing that colorModeX ==255; as for threading i have not tried, i will; tried with HSB:: not the same results! but finally, knowing that negative or out of range values could be a problem is the good thing to know....

GoToLoop

http://forum.processing.org/two/discussion/8086/what-is-a-color-in-processing

asimes

Colors in Processing are stored as:
- Binary: AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB
- Hexadecimal: AARRGGBB

Where A is alpha, R is red, G is green, and B is blue

When you use color(), fill(), etc. by default alpha is set to full. For example, color(0) in hexadecimal would be 0xff000000. It is not meant to be understood by Processing users what that value is in decimal because it doesn't matter (the value would be -16777216)

The reason these strange looking values are created is due to how signed integers work. Behind the scenes, a color type is an int so it has 32 bits of information (4 bytes) and the last bit is used to represent the sign of the number:
- If the last bit is a 0 then the number is positive
- If the last bit is a 1 then the number is negative
- Any color with full alpha will result in a negative number

However, it doesn't matter to Processing whether these values are positive, negative, big, small, etc. All that matters is that the 4 channels can be accessed as AARRGGBB. Whatever value that is as a signed integer doesn't make a difference

Here is a sketch to show decimal vs hexadecimal for some common colors:

void setup() {
  size(100, 100);

  // White is a negative number when view in decimal (-1)
  // It makes a lot more senes in hexadecimal (0xffffffff)
  color white = color(255);
  println("White = "+white+", white hex = "+hex(white));

  // Red in decimal: -65536
  // In hexadecimal: 0xffff0000
  color red = color(255, 0, 0);
  println("Red = "+red+", red hex = "+hex(red));

  // Green decimal: -16711936
  // In hexadecimal: 0xff00ff00
  color green = color(0, 255, 0);
  println("Green = "+green+", green hex = "+hex(green));

  println(color(0));

  exit();
}

asimes

akenaton and I went over something very similar here: http://forum.processing.org/two/discussion/comment/35719/#Comment_35719