Loading Images From Files in Java

Suppose a Java program needs to show a picture. The picture might already exist as a file on the hard disk, or it might not exist at all until the program draws it. In both cases the result is an image in the computer's memory, but the two cases are not the same. Java's image library gives you a single idea, the Image, that sits underneath both situations. Before you write any drawing code, it helps to know which kind of image you are holding, because the kind determines how you can use it.

In this article you will follow one image through two stages. First it is something loaded from outside the program, and then it is a surface the program builds for itself. Watch for the moment the image changes from a passive thing you receive into something you actively write on.

The class java.awt.Image represents an image stored in the computer's memory. The source identifies two fundamentally different kinds of Image. The first kind is an image read from a source outside the program, such as a file on the computer's hard disk or a network connection. For this kind, the program does not create the pixels itself. It receives them from outside.

The second kind is an image created by the program itself, by drawing to it using a graphics context. The source calls this second type an off-screen canvas. Both kinds are images in memory, but only the second kind starts blank and is filled in by your code. The comparison below lines up the two kinds so you can see where each one's pixel data comes from.

Read the two columns as a question about direction. In the left column, pixels arrive at the program from somewhere else. In the right column, pixels are produced by the program's own drawing instructions. Everything else in this article builds on that difference.

Notice what this definition does and does not promise. It says the canvas is a region of memory that can serve as a drawing surface. It does not say the canvas is always visible, and it does not say the canvas is the same thing as the window on the screen. Keeping those two ideas apart makes the rest of the article easier to follow.

An off-screen canvas can be represented by an object of the class BufferedImage. The source says this class is defined in the package java.awt.image, so to use it you refer to that package. BufferedImage is the concrete tool Java provides for the program-built kind of image you met in the previous sections.

The most important relationship is inheritance. BufferedImage is a subclass of Image. Because of this, a BufferedImage is still an Image, so it can be used anywhere the program expects an Image. The source states the practical consequence directly: once you have a BufferedImage, you can copy it into a graphics context g using one of the g.drawImage() methods, just as you would with any other image.

The source also notes that a BufferedImage can be created with a constructor. The source excerpt for this section stops before showing it, so this article does not describe the constructor's parameters. What matters here is the relationship: the object is a canvas, and it is also an Image.

Creating a canvas is only half of the story. The canvas becomes useful when something is drawn onto it. The source explains that you can draw to an off-screen image using the same Graphics class you use for drawing on the screen. The drawing code therefore looks much like the code you would write for the screen. The difference is the destination. The Graphics object points at the off-screen canvas instead of the visible window.

Once the canvas has content, the source describes a second step. A BufferedImage can be copied into a graphics context g with a g.drawImage() method. This is how a finished off-screen canvas reaches a visible surface. The diagram below traces the path the data takes from the program's drawing calls to the final copy.

Read the diagram from top to bottom as a story. The program issues drawing instructions through a Graphics object. Those instructions change the canvas, which is the highlighted node because its content is the thing being built. Only at the end does the canvas leave the picture, when a g.drawImage() call copies it into the destination graphics context g.