Using the Color Class in Java

A BufferedImage lets you work with individual pixels rather than whole images. Each pixel has a color, and you can ask the image for the color at any position. The method image.getRGB(x,y) looks up the pixel at coordinates (x,y) and returns a single int that encodes that pixel's color. Before learning how that int works, notice the overall shape of the task: a position goes in, and a color comes out. This article explains how the color is stored inside that int, how to pull the red, green, and blue parts back out, and how to rebuild the int after changing a part and write it back to the image.

The source shows the basic pattern in two steps. First, the image returns the packed color number for a position. Second, that number can be wrapped in a Color object so that you work with the color through the Color class. The code below does both steps for the pixel at column 1, row 2.

Notice that getRGB returns a single number, not three numbers. The red, green, and blue information is packed into that one int, so it must be unpacked when you need the separate components. Keep this in mind, because it explains almost every step that follows.

The x value selects a column and the y value selects a row. Both must lie inside the image. The coordinates range from 0 up to one less than the image width for x, and from 0 up to one less than the image height for y. If you ask for a pixel outside that range, Java throws an exception, and the program stops unless you handle it.

The int returned by getRGB holds 32 bits. Three of the four bytes in that int store the color intensities: red, green, and blue. Each of those bytes can hold a value from 0 to 255, because one byte is eight bits and eight bits can represent 256 different values. The diagram shows where each byte sits inside the 32 bits. The top byte is the alpha byte, which controls transparency in the standard layout; the operations in this article focus on the lower three bytes that hold the three color components.

Because red sits in bits 16 through 23, green in bits 8 through 15, and blue in bits 0 through 7, you can recover each component with a shift that moves its byte down to the lowest eight positions, followed by a mask that keeps only those eight bits. The next section does exactly that.

Extraction works as a sequence of operations. For red, the source describes a shift that moves the red bits down into the lowest eight positions, then a mask that discards everything above those eight bits. The result is a number from 0 to 255. Green uses the same pattern with a shift of 8. Blue needs no shift, because it already sits in the lowest eight bits, so masking alone is enough.

The reverse process rebuilds the packed int. Each component is shifted into its own byte position: red moves up 16 bits, green moves up 8 bits, and blue stays where it is. The bitwise OR then combines the three positions into one int. Because each component is in the range 0 to 255, no two components overlap, so the OR does not mix their bits together. This means the two directions are inverses: you can split a color into components and then rebuild the same color from them.

Putting the pieces together gives a read-modify-write cycle. You read the pixel with getRGB, split the int into components, change the component you want, recombine the components into one int, and write that int back with setRGB. The diagram shows the order of these steps. The change affects only the chosen component, because the other components are carried over unchanged during the split and recombine.

The source shows two routes that lead to the same kind of packed value. In the first route, you work with the raw int and use shifts and masks directly. In the second route, you build a Color object from the int returned by getRGB, and then call c.getRGB() to get the int back so you can write it with setRGB. Both routes pass the same packed information, so the choice depends on whether you want to work with the Color class or with raw bit operations.