How many levels of Black&White are allowed in the pixel alpha values? I’m trying to work this out by trial and error, and confusing myself.
The reference says the value needs to be between 0…255, but not as far as I can tell what kind of data type it needs to be.
If I define a BW color value with a literal non-integer between 0…255, it runs. But in the display window I don’t see any difference between the two greys. Whereas that shade difference should be perceptible. So, what is going on here? Is it being forgiving here and casting my float to int?
However, if I define the BW value I am testing as a color, then it will only run if it’s an int.
color THISWORKS = 200;
background(0);
noStroke();
size(600, 600);
background(THISWORKS);
color THISDOESNTWORK = 200.5;
background(0);
noStroke();
size(600, 600);
background(THISDOESNTWORK);
These two ways of creeping up on the question seem to give different answers. The end use here is that I am exploring an animation where I change an alpha value for an image that I am using in a blend.
Yes, that’s the info I needed. Thank you. (Re confusion of greyscale and alpha, my intent was to use this a simplified example. Maybe it was wrongly oversimplified. The thinking here was that when you apply a greyscale image as a mask, it then acts as an alpha. So in troubleshooting the alpha, I’ve been playing with using a greyscale then compositing.)
Boiled down a bit more, my original question was whether allowable values for a colour spec are only the discrete elements of the range[0…255] - or whether they can they be anything within that range? I am still puzzled about whether Processing is being forgiving and coercing the fractional value to int[0…255], or whether it actually is storing additional “resolution” on the colour space.
It depends on the colorMode so I strongly recommend you read the reference.
You can use colorMode to can change how parameters to fill, stroke are interpreted. For instance a colour using other modes such as HSB and different ranges such as 0.0 \le V \le 1.0
The default mode is (R,G,B,A) where each of the 4 channels is represented by an integer in the range 0 \le V \le 255
Processing will accept both float and int parameters and convert them to the default mode for storage in RAM based on the colorMode currently in force.
Color has only one byte per component and does not have further resolution. By default each component is an integer from 0 to 255. The Color type is just a convenient interface to the actual data, which is stored internally as an integer number, e.g. 0xffFFCC00.
I often find it easier to work with a different colour model and scale. To do this, stick a colorMode() statement in setup(). reference
The following snippet changes to the hue-saturation-brightness model that’s far more logical (to my way of thinking). And it also scales each value from 0 to 1 using floating point arguments. Again, much simpler to know where you are on the scale.
colorMode(HSB, 1.)
color c = color(.2, 1, 1);
As you can see, this works even if you forget the dot after the “1” since Processing tends to be forgiving about such things. (Java is not.)
Thank you. Yes, HSB I find a lot easier to work with, conceptually and perceptually. Re my original question - it makes perfect sense that allowable values depend on the colorMode, and of course you must be able to have floats if you can set the range 0…1. Of course. And it also makes perfect sense that data type of a color depends at the end of the day on the fundamental underlying representation, which is some mysterious flavour of int. Again, of course. But I found it genuinely confusing how those two things play out against each other: which is that the allowable actions differ by context in a way that’s genuinely weird at first glance. (And even after reading the documentation a dozen times.)