can only create images etc in main class

Newbie & Debugging Questions
#1

for some reason I cannot create images in any classes but my main one which extends applet.
When I pass main into other classes to load images or something, there are no errors but the images dont show up. Does anyone have a solution to this? thanks

#2
  1. check if image is null.
  2. it probably is, check your paths.
  3. still not working? post relevant code snippets
#3

Oh, I found out i can use Toolkit.getDefaultToolkit().getImage to load the images in other classes. Thanks.

I now have a new problem when trying to convert from Image to bufferedImage to find the colour of the pixels for collision detection. I am trying to find which pixels have 0 alpha
I am not sure if the buffered image contains anything as I can’t draw it, but the image does that I’m trying to copy from.


BufferedImage bufferedImage = new BufferedImage ( WIDTH, HEIGHT, BufferedImage.TYPE_INT_ARGB  ); 
			Graphics g = bufferedImage.getGraphics();
			g.drawImage(image/*perfectly fine, just can't get alpha from it*/, 0, 0, null);
			g.dispose();

for (int x = 0; x < WIDTH; x++)
			{
                                while (true)
				{
					Color c = new Color(img.getRGB(x, y));
					if (c.getAlpha() == 0)
					{
						break;
					}
					
					y++;
				}
}
#4

If you’ve got TYPE_INT_ARGB, you can do this to check alpha:


if (image.getRaster().getPixel(x,y, new int[4])[3] == 0)
{
    //Alpha
}

Also, you shouldn’t be using the Toolkit to read your images. Instead, use ImageIO.


BufferedImage image = ImageIO.read(new File("/Computer/folder/image.png"));
//or
BufferedImage image2 = ImageIO.read(Thread.currentThread().getContextClassLoader().getResourceAsStream("/resources/image.png");
//The first will look on your disk (or in a URL).
//The second will look in the classpath (useful for JAR files).

Usually when you read a BufferedImage from a file it isn’t INT_ARGB, so I typically will create a new BufferedImage with the correct type and then draw into that.


BufferedImage image = ImageIO.read(Thread.currentThread().getContextClassLoader().getResourceAsStream("/resources/image.png");
myImage = new BufferedImage(image.getWidth(), image.getHeight(), BufferedImage.TYPE_INT_ARGB);
myImage.getGraphics().drawImage(image, 0, 0, null);
#5

wow, thanks!
I didn’t really want to use the toolkit either, I just didn’t see an alternative other than ImageIO, and when I used that, I don’t know why but it made my speed stay at 3 fps even when they had finished loading. (Normally 70-80fps). Do you think this maybe because of some load error that kept popping up even after the image is created which slows down the program? (my program is a plain applet - not JApplet or swing or anything) and why would this happen? thanks.

#6

That slow-down could be a result of the version of Java you are using. Check you are upto-date ‘java -version’.

#7

To me, it seems more a transparency problem. Java2D can become very slow when using alpha other than 0 or 255.

#8

Yeah, Java2D kinda sucks when you want to squeeze anything out that isn’t pretty simple. Bonbon is right that transparency really hurts it - most likely when you were using ImageIO the transparency actually started working, and then of course it took a lot longer. There can also be weird problems with Java2D keeping images cached even when you don’t want it to anymore, so you can say myImage.flush() when you’re done with it to try to alleviate that.

#9

A bit too complicated (not to mention lots of created garbage).

Just use BufferedImage.getRGB(x,y)&0xff000000:
getRGB(int x, int y)
Returns an integer pixel in the default RGB color model (TYPE_INT_ARGB) and default sRGB colorspace.

Dmitri

#10

thanks for the repies. :slight_smile:
I am not using Graphics2D though
I will try BufferedImage.getRGB(x,y)&0xff000000, thanks

#11

Good, thanks for that. I haven’t ever used hex in Java before, actually. It’s one of those things I stupidly avoided for a while. I’ve always hated dealing with Raster.getPixel() because of the weirdness of having to pass in another array.

So alpha is the first byte even though usually when setting it (like with the method I posted above) at occurs last? It makes sense that it is literally A then R then G then B, but it seems in most places the paradigm is to go RGBA instead.

#12

I’d never noticed it myself, but it appears the javadoc for much of the java.awt.Color class is misleading in that regard.
In many places it refers to colors containing alpha as “RGBA”, when it infact means “ARGB”.
In particular the javadoc (and name of the int parameter!) for this constructor have been badly chosen.


public Color(int rgba,
             boolean hasalpha)

    Creates an sRGB color with the specified combined RGBA value consisting of the alpha component in bits 24-31, the red component in bits 16-23, the green component in bits 8-15, and the blue component in bits 0-7. If the hasalpha argument is false, alpha is defaulted to 255.

    Parameters:
        rgba - the combined RGBA components

Fortunately it also has the details explaining how the specific bits are interpreted, degrading it from being erroreous to just misleading.