Custom Image Filter

Question

Hello,
I want to create my own image filter. This filter should look for each pixel
whether the red/blue/green-pixel-value is below 25 and if so set the alpha-vlaue to 0.
I want to make those pixel translucent.
I found some samples of custom filters but I am not familar with the shift operators ( < / << / ... )
So any ideas or tutorials?
Regards,
Olek
Edited by: 848710 on 30.03.2011 13:15

Answer 1

Olek,
The hex values in my sample program serve two different purposes. In this part
a = 0xF0;
r = 0xE0;
g = 0xC0;
b = 0x80;they are the actual values for alpha, red, green, and blue. I always use hex for that because it is easy to figure out how to add another 25% here (0x40) or another 12.5% there (0x20). I chose those four values because they were distinct, easy to recognize after being packed and then unpacked, and all were guaranteed to sign-extend if treated as bytes. You are quite correct that hex values like these get used in other settings, like CSS, to specify colors. Because each pair of hex digits represents a distinct byte, it's a very simple way to specify a color in a single hex number. In my example, that number would just be 0xE0C080 (or, if you included the alpha channel, 0xF0E0C080).
Now, when it is necessary to strip off (people often say "mask") the bits you don't want from a packed four-byte integer, the hex numbers are serving a different purpose. When you use the AND operator (the "&" character), it actually operates at the level of the individual binary digits (the "bits") to produce a result. Suppose we want to get just the green value from the packed integer in my example. The integer is 0xF0E0C080. In binary, that's this:
11110000111000001100000010000000To get the green part, you need to shift these bits eight places to the right, with ">> 8." That gives you this result:
11111111111100001110000011000000A number of interesting features appear in that result. First, notice that the eight bits on the right end of the original number are gone. They get lost as a result of the shift operation. The right-most 24 bits of the result are exactly the same as the original left-most 24 bits of the number before the shift operation. That's literally what "shift" does: it moves the bits. But, most interestingly of all (perhaps) are the left-most eight bits of the result. Notice they are all "1" bits. That's because the right-shift operator (the ">>") sign-extends its result. The effect is that a negative number produces a negative result. In Java, this is always how the right-shift operator works. In other languages, including C, it's not always specified. Some C compilers will sign-extend right-shifted negative numbers, and some won't. It's up to the compiler writers to decide. In Java, it's not up to the compiler writers. The ">>" always sign-extends. Whether or not right-shifts should extend signs has been known to keep some programmers arguing for hours and hours. These types of debates are called "religious" arguments, which usually means they are not worth having. As I am a Unitarian Universalist, and my church has taken no position on sign-extension in right-shifts, I don't care one way or the other. To avoid needing to know, however, I always just use a mask to get only the bits I want, which I will explain in a second. (But, you should know, Java includes an unsigned right-shift operator, ">>>," so you have final say in your own code as to whether there will be sign-extension or not.) All of this comes from the fact that Java, C, and most languages represent signed integers with "two's-complement" arithmetic, which is a kind of numerical magic you don't want to have learn much about if you don't have to.
Now, we wanted the green byte, right? It started out packed into our four-byte integer as the ninth, tenth, eleventh, twelfth, thirteenth, fourteenth, fifteenth, and sixteenth bits, starting with the first bit as the one on the right. By shifting our integer eight bits to the right, our green byte is now in the first, second, third, fourth, fifth, sixth, seventh, and eighth bits. (Beware that most people number bits the same way that you use an array index, by calling the first one "bit zero," the second one "bit one," and so on). In my code, I masked off the bits I didn't want, and kept the bits I did want, with one of those hex values: 0xFF. The operation was this:
g = (i >> 8) & 0xFF;To understand what that does, you need again to see it in binary. The "i >> 8" part results in the 32 bits I wrote out above. The "0xFF" part is another 32-bit number, the first 24 of which are all "0," and the last eight of which are all "1" (Java conveniently treats hard-coded constants like integers, so 0xFF is treated like a 32-bit number, the same as if we had written "0x000000FF"). So, in binary, i >> 8 and 0xFF look like this:
11111111111100001110000011000000
00000000000000000000000011111111Finally, the AND operator works on the matching bits in the two values above. That is, the left-most bit of each is matched with the left-most bit of the other, the second left-most bit is matched with the other's second left-most bit, and so on. For each matched pair of bits, if one of the bits is "1" and the other bit is "1," the matching bit in the result is "1." In any other case, the result is "0." So, "(i >> 8) & 0xFF" results in this:
00000000000000000000000011000000In hex, that's "0xC0," which is our green value, which is what we wanted.
So, in some cases, my hex values were providing actual numbers, to set the values of alpha and the color channels. In other cases, they are serving as masks, to get rid of the bits I don't want and leave behind only the ones I do want, after shifting, to unpack those alpha and color values when I have them in packed form.
Hope that helps.