It would help if you were to show us the code you’re using…
Anyway, mspaint only supports bitmask transparency, i.e. either a pixel is 100% transparent or it is 100% visible. The java code you are using is probably loading this image with bitmask transparency… you need to be using “translucent” transparency…
Loading an image with ImageIO usually does this automatically for you. This code shows the image correctly:
import javax.imageio.*;
import javax.swing.*;
import java.awt.image.*;
import java.awt.*;
import java.io.*;
class ImgPanel extends JPanel {
BufferedImage img;
public ImgPanel() {
img = null;
try {
img = ImageIO.read(getClass().getResource("swirl.png"));
}
catch (IOException e) {
e.printStackTrace();
}
setPreferredSize(new Dimension(img.getWidth(),img.getHeight()));
}
public void paintComponent(Graphics g) {
/* draw red rectangle to show transparency works */
g.setColor(Color.red);
g.fillRect(0,0,getWidth(),getHeight());
g.drawImage(img,0,0,null);
}
}
public class Test extends JFrame {
public Test() {
super("Test");
setDefaultCloseOperation(EXIT_ON_CLOSE);
getContentPane().add(new ImgPanel());
pack();
setVisible(true);
}
public static void main(String args[]) {
new Test();
}
}
The Transparency class outlines the different transarency options for Images
Your code example assumes the pixels of the newly constructed BufferedImage are initialised to 0x00000000, an assumption you would expect to be safe. However as far as i’m aware the BufferedImage javadoc makes no such guarantee, and I know of atleast 1 Apple VM release that did not conform to this assumption. (it initialised the pixels to an opaque grey)
So for completeness you should set the compositing rule so as to only use the alpha component of the source. (see above quoted code)
public int filterRGB(int x, int y, int rgb) {
int r = (rgb >> 16) & 0xFF;
int g = (rgb >> 8) & 0xFF;
int b = (rgb) & 0xFF;
if (r == 255 && g == 21 && b == 255) {
return 0x00000000;
}
return 0xff000000 | r >> 16 | g >> 8 | b;
}
to:
public int filterRGB(int x, int y, int rgb) {
int r = (rgb >> 16) & 0xFF;
int g = (rgb >> 8) & 0xFF;
int b = (rgb) & 0xFF;
if (r == 255 && g == 21 && b == 255) {
return 0x00000000;
}
return rgb;
}
BufferedImages are guaranteed to be initialized with 0s (even if the spec doesn’t say it), they are backed by java arrays - at least in Sun implementation. I would bet that that Apple bug that had BIs initialized to gray (could you give a link to the report?) was pre-1.5, which is for all intended purposes long gone…
It was indeed a looooong time ago - someone reported it as a bug against something i’d written, can’t remember what it was, or even if it was on this forum! (might have been on the Sun forums)
Well I’ve been assuming it’s transparent and never had a problem reported by anyone playing my game. And because I always used TYPE_INT_ARGB I don’t see that there will be a problem.
I didn’t say that the image will be initialized to transparent pixel, I said it will be init-ed with 0s. What 0 means obviously depends on the color model.
For INT_ARGB it means that pixels are transparent.