 |
Author |
Topic: verify color operation (Read 914 times) |
|
st33d
 
|
verify color operation
« on: Mar 20th, 2005, 12:52pm » |
|
I'm analysing toxi's code for tracking in the tech-notes section so I can develop a camera project.
Code:
trackR=c>>16&0xff;
trackG=c>>8&0xff;
trackB=c&0xff;
|
|
I'm a bit stupid when it comes down to math or bitwise things so I was wondering if someone could enlighten me on this. I think that what's happening in the first instance is :
Right shift c 16 places (divide by 2 16 times)
mask (modulo kind of) to hexadecimal 255
And I verified this by writing:
Code:
void cols(){
int c = pixels[mouseX + mouseY * width];
int trackR=c>>16&0xff;
int trackG=c>>8&0xff;
int trackB=c&0xff;
println("R:"+trackR+" G:"+trackG+" B:"+trackB);
}
|
|
Is this faster than red(),green(),blue()? I'm more interested personally in something that might track saturation or brightness. I've worked with HSB just recently and the effect was quite interesting. Is there some bitwise jiggery-pokery to give me ints for something like trackH, trackS, trackB?
|
I could murder a pint.
|
|
|
fry
|
Re: verify color operation
« Reply #1 on: Mar 20th, 2005, 9:49pm » |
|
yes, the bit shifting is faster than red()/green()/blue(), because the latter will give you values that are based on the current colorMode() i.e. between 0 and 1 for colorMode(RGB, 1).
if you're just using the default colorMode, it's faster to grab with the bit shifts. there's a discussion elsewhere, but basically a 'color' is an int, which is made up of 32 bits:
AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB
that pack in the alpha, red, green, and blue values. this is discussed elsewhere on the board but i couldn't find the pointer to it quickly.
int r = (pixel >> 16) & 0xff works like:
AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB
>> 16 shift right by 16 becomes
xxxxxxxxxxxxxxxxAAAAAAAARRRRRRRR
and then & 0xff gives you
000000000000000000000000RRRRRRRR
meaning just an 8 byte value that's got the value for red as a number between 0 and 255.
|
|
|
|
|
st33d
|
Re: verify color operation
« Reply #2 on: Mar 21st, 2005, 1:40am » |
|
Thanks. I tried colorMode(HSB) and reading the ints but evidently the colorMode makes no difference to the color int (which would be pretty odd anyway). I can get around it by using means, medians and differences I guess.
I'm wondering though how I should go about tracking a block. I've seen the JMyron thing do it but it doesn't work with my camera (and after a month or so they've ignored me asking how to switch video sources with the damned thing).
Should I use some kind of fuzzy logic model? I've searched the net on this subject before and come up blank.
PS: funny link on tech-notes - "some video filters" comes up with an error when I try it.
|
| « Last Edit: Mar 21st, 2005, 1:58am by st33d » |
|
I could murder a pint.
|
|
|
|
