| Reply | « Previous Thread | Next Thread » |
|
Hi all!
Can someone please give me a code example of using getPixels and drawPixels for, lets say, displaying the red pixels in a png image as blue. Thanks a lot! Itsik |
|
This assumes the TYPE_USHORT_4444_ARGB and will only convert "pure red". But here goes.
You just get the pixels into an array, scan the array for red pixels and change them to blue. Note that you have to compare the values taking the format into consideration. Code:
Image convertRedToBlue(Image src) {
short red = (short)(0xff00); // red in TYPE_USHORT_4444_ARGB format
short blue = (short)(0xf00f); // blue in TYPE_USHORT_4444_ARGB format
// get width and height and source DirectGraphics
int w = src.getWidth();
int h = src.getHeight();
DirectGraphics dgSrc = DirectUtils.getDirectGraphics(src.getGraphics());
// create an array and populate it with the pixels
short[] pixels = new short[w * h];
dgSrc.getPixels(pixels,0,w,0,0,w,h,DirectGraphics.TYPE_USHORT_4444_ARGB);
// transverse the array and change pure red into pure blue
for (int i = 0; i < w * h; i++) {
System.out.print("Before : " + pixels[i]);
if (pixels[i] == red) {
pixels[i] = blue;
}
System.out.println(" After : " + pixels[i]);
}
// create a new image (you could just use the source if you like)
// and draw the converted pixels onto it.
Image dest = Image.createImage(w,h);
DirectGraphics dgDest = DirectUtils.getDirectGraphics(dest.getGraphics());
dgDest.drawPixels(pixels,true,0,w,0,0,w,h,0,DirectGraphics.TYPE_USHORT_4444_ARGB);
return dest;
}
shmoove |
|
OK, I don't know why I was too lazy to do this in the first place, but here is the for loop that converts a more general red into blue:
Code:
// transverse the array and change "reddish" into pure blue
for (int i = 0; i < w * h; i++) {
r = (pixels[i] & 0x0f00) >> 8; // red channel
g = (pixels[i] & 0x00f0) >> 4; // green channel
b = (pixels[i] & 0x000f); // blue channel
if (r > 0xd && b < 2 && g < 2) { // very red and little blue and green
pixels[i] = blue;
}
}
|
|
Thanks a lot man!!!
I always knew that the Israeli people are the nicest in the world ;) Itsik |
|
lol, how political. A perhaps wiser approach would be to increase blue more of the red component is stronger. I've used this before and it works nicely. So (pseudo) :
color = r, g, b; newr = 0; newb = Math.min(15, b + r); newcolor = newr, g, newb; Give it a go, it doesnt use tresholds and therefore will generate a completely smooth transition. |
|
Nice one. You definitely know your CG :-)
Though it depends on what the purpose of the conversion is. Your algorithm moves the whole red channel into the blue channel, and doesn't give a second look to the green channel, so it will also change colors that are not even close to red. For example, yellow (r=15,g=15,b=0) will be transformed into turquoise (r=0,g=15,b=15). I'm not sure that was the OP's intention. shmoove |
|
Thanks a lot to both of you (Ok ok, the dutch people are nice too! :) )
But I have another question. I saw that series 60 support the 4444 type, and serieses 30 and 40 support 444 (am I correct?) Does 444 mean that I will lose the transperancy when manipulating the pixels (No alpha component...) ? Thanks again, Itsik |
|
I think it does, but all the Series 40 phones I've used also supported the 4444 type. It might not be native format (DirectGraphics.getNativePixelFormat()), but it doesn't mean it's not supported. I tried my example on a 3300, a 3105 and a 3510i (Series 30), and it worked OK.
shmoove |
|
Oh, that's good to know, I though that "native format" is the best supported format... :)
Thanks again, Itsik |
|
The native format is the best supported format. Like the name says, it's the phone's native format, ie, it's the format that will be saved into the video buffer. That means that you'll get the best performance out of those DirectGraphics methods if you use the native format. But other formats are supported, the phone will just have to do a conversion at runtime to actually read and write the pixels.
So if this conversion is something that you need to perform very fast then implementing in native format might be a good idea. shmoove |
|
Oh, I see, thanks for the clarification!
Where do you work? What do you do? |
|
It's in my profile.
shmoove |
|
Hi again,
I tried this method on the 7210 emulator, and it generates a non-transparent image, although I'm creating it from a transparent source... Any ideas how I can avoid it? Thanks! |
|
What do you mean? What parts are losing transparency?
Try debugging the code. Print out the values of all the channels (including alpha) before and after the conversion, and see what's getting screwed up there: Code:
// transverse the array and change "reddish" into pure blue
for (int i = 0; i < w * h; i++) {
r = (pixels[i] & 0x0f00) >> 8; // red channel
g = (pixels[i] & 0x00f0) >> 4; // green channel
b = (pixels[i] & 0x000f); // blue channel
a = (pixels[i] & 0xf000) >> 12; // alpha channel
// print out the channels before the transformation
System.out.println("pixel " + i + " :\tred=" + r + "\tblue=" + b + "\tgreen=" + g + "\talpha=" + a);
if (r > 0xd && b < 2 && g < 2) { // very red and little blue and green
pixels[i] = blue;
}
r = (pixels[i] & 0x0f00) >> 8; // red channel
g = (pixels[i] & 0x00f0) >> 4; // green channel
b = (pixels[i] & 0x000f); // blue channel
a = (pixels[i] & 0xf000) >> 12; // alpha channel
// print out the channels after the transformation
System.out.println("pixel " + i + " :\tred=" + r + "\tblue=" + b + "\tgreen=" + g + "\talpha=" + a);
}
|
|
The entire image loses transperancy... It comes out as a white image...
I'll try to print it. Thanks |
| Reply | « Previous Thread | Next Thread » |
| Thread Tools | Search this Thread |
|---|---|