 |
Author |
Topic: colorMode (Read 2227 times) |
|
benelek
 
 
|
colorMode
« on: Apr 22nd, 2003, 4:01am » |
|
as per usual, im not sure if this's a bug or what.
in the sketch i'm currently working on, i've set colorMode(RGB,800), yet getPixel(x,y) still returns color values between 0 and 255.
-jacob
|
|
|
|
|
REAS
|
Re: colorMode
« Reply #1 on: Apr 22nd, 2003, 2:45pm » |
|
That is how getPixel() is currently implemented. Regardless of your color space and range, it always returns values in RGB from 0 to 255.
|
|
|
|
|
fry
|
Re: colorMode
« Reply #2 on: Apr 22nd, 2003, 9:30pm » |
|
getPixel returns a 'color' (which is a packed int internally)
if you want the color in the range controlled by colorMode(), use red(), green(), blue() etc on the value returned from getPixel.
|
|
|
|
|
benelek
|
Re: colorMode
« Reply #3 on: Apr 23rd, 2003, 8:20am » |
|
ahh, i see. p5-specific functions such as colorMode and getPixel are only translators, and the actual color information (in bit format) always runs from 0 to 255.
but this seems to cause problems with using color values that are not cleanly divisible by 255. try the following:
Code:size(600,200);
background(255,255,255);
//let's work between 0 and 800.
colorMode(RGB,800);
color c = color(511,0,0);
//"511" is what is set.
setPixel(50,50,c);
println(red(getPixel(50,50)));
//"508.23532" is what is printed. |
|
-jacob
|
|
|
|
|
toxi
|
Re: colorMode
« Reply #4 on: Apr 23rd, 2003, 1:15pm » |
|
benelek this is because due to rounding errors of float->int conversions...
800/255.0 = 3.1373
511/3.1373 = 162.8789
162*3.1373 = 508.2426
note the pixels[] array is only storing integers, and getpixel() will only take an integer and then scale it to the currently set resolution of the colour mode (i think) IMHO there's no need to work with higher res colour modes if you have to read out (low res) colours (from the pixels[] array) in the process. maybe knit your own high precision float pixel buffer if you can't live with rounding errors.
hth, toxi.
|
http://toxi.co.uk/
|
|
|
fry
|
Re: colorMode
« Reply #5 on: Apr 23rd, 2003, 6:31pm » |
|
yep, that's it.
the function for red/green/blue is:
(max color for mode, i.e. 800) * (value from 0 to 255) / (255.0)
so you'll get some rounding when you go larger than 255.
|
|
|
|
|
benelek
|
Re: colorMode
« Reply #6 on: Apr 24th, 2003, 7:30am » |
|
mk, easy enough.
i've got another question with regards to color values, though this time it's bitwise operations that's the topic.
Code:int a=color(0,102,0);
//should be 1111111100000000GGGGGGGG00000000
int b=a>>8;
//should be 000000001111111100000000GGGGGGGG
int c=b&0xff;
//should be 000000000000000000000000GGGGGGGG
int d=(0xff<<16)|c;
//should be 000000001111111100000000GGGGGGGG
int theCol=d<<8;
//should be 1111111100000000GGGGGGGG00000000 |
|
q1. how come the value of 'a' is a negative number?
q2. how come the value of 'b' is -65434, while the value of 'd' is 16711782?
the two of these questions could quite possibly be related to my lack of understanding of the whole bit/digit area!
thanks,
-jacob
|
|
|
|
|
toxi
|
Re: colorMode
« Reply #7 on: Apr 24th, 2003, 12:49pm » |
|
well, here's a longish answer: java doesn't have (unlike C/C++) so called unsigned number types. in other words this means the top most bit of a byte or integer is used to indicate if a number is positive (bit is 0) or negative (bit is set).
now, bit shifting operations can also be understood as divisions (shifting right) or multiplications (shifting left) by powers of 2. so if you start out with a negative number, shifting it 8 bits to the right is the same as dividing it by 2^8 (256) - this means the result still has to be a negative number, so the top most bit basically stays intact when using right shifts >> (in java)
to your questions:
1) "a" is negative because the top most bit is set. this happens because you haven't specified an alpha value for the colour and it defaults to fully set (255)
2) "b" is negative because "a" is negative (see above). however "d" is positive, because you masked off all higher bits (including the negative sign of b) when building "c".
you should also see that the final "theCol" is a negative number again as you shifted a positive number "too far" left and the top most bit is set again. this is also called "number overflow".
an integer number is in the range of -2^31...2^31-1
a byte number is in the range of -2^7...2^7-1
|
http://toxi.co.uk/
|
|
|
|
