 |
Author |
Topic: wierdness in packing colors bitwise? (Read 1188 times) |
|
Brad
|
wierdness in packing colors bitwise?
« on: Jul 11th, 2003, 6:50pm » |
|
i was trying to write an efficient itterative blur thing using all the suggestions i had seen on the board here. everything was fine until i decided to try using:
Code:| pixels[index] = (0xff<<24) | ((rsum>>6)<<16) | ((gsum>>6)<<8 ) | (bsum>>6); |
|
instead of
Code:| pixels[index] = color( rsum>>6, gsum>>6, bsum>>6 ); |
|
(thinking maybe it'd be faster)
in the white spaces there is this strange confetti.
i can't figure out why sometimes this is returning different values.
Code:| (color(r,g,b) == 0xff<<24 | r<<16 | g<<8 | b) = true; |
|
or not?
also, am i wrong in expecting that it would be faster?
here they are:
http://www.onetwothree.net/p5/blur_good_better3c/
http://www.onetwothree.net/p5/blur_good_better3d/
|
|
|
|
|
benelek
 
 
|
Re: wierdness in packing colors bitwise?
« Reply #1 on: Jul 12th, 2003, 6:52am » |
|
this is weird. the bit packing you're doing should be working, and does work in an empty applet - just not your applet.
actually, the two methods are printing out exactly the same integer in my tests. the weirdness seems to creep in when that line of code is switched to manually bit pack the color for the pixels array in your applet. when that line is changed, the two methods are still consistent, but the number going into the pixels array seems to creep by 1 or 2 in each of the r,g,b values each time. this is causing an increasing creep as the loop continues, and a pattern emerges causing your "confetti" look.
interestingly, the creep only seems to be occuring when the pixel/s under operation has at least one of its r/g/b components at 255 (maximum value).
also, altering the first value in the kernel array seems to modify the emergent pattern.
|
|
|
|
|
toxi
|
Re: wierdness in packing colors bitwise?
« Reply #2 on: Jul 15th, 2003, 9:21am » |
|
this is a classic value overflow case and it has to do with your kernel sums being to big. the reason why using color() works is because the color components are limited internally to avoid such problems. change your line to the one below and it all shoul work:
pixels[index] = min(rsum>>6,0xff)<<16 | min(gsum>>6,0xff)<<8 | min(bsum>>6,0xff);
to explain this in bit more detail:
e.g. imagine your red sum is 65*255 = 16575. now take this divided by 64 results in 258. lets compare this bitwise with 255:
258 = 1(00000010)
255 = 0(11111111)
the bits in brackets are the ones actually used for the color component. in the case of 258 this would suddenly only equal 2, hence your pattern. once bit shifted to the left, 258's most significant "1" bit (outside the bracket) would be pushed into either the next colour component or, in the case of the red sum, into the alpha byte of a packet integer.
to avoid using the min() function, make sure the sum of your kernal items doesn't exceed 64. yours does...
hth, toxi.
|
| « Last Edit: Jul 15th, 2003, 9:24am by toxi » |
|
http://toxi.co.uk/
|
|
|
|
