Until recently, my headshot at the end of every "Programming Snapshot" article showed a much younger version of myself, dating back 15 years, so I grudgingly shot a new one the other day. While doing this, the idea occurred to me to try out my new favorite language Go's suitability for image processing. How hard could it be to generate an artful silhouette of the person shown in the photo?

Of course, with some Gimp skills this could be done quite quickly. However, what is far more interesting is the question of how an image processing program walks through the pixels of Figure 1 and finds out which of them actually belong to the person (the foreground) and which to the lighter background. When a foreground pixel is found, the algorithm can then go ahead and set it to black, which in the digital world means it has its red, green, and blue channels set to 0,0,0. Easy enough, right?

Figure 1: The original version of my headshot fed to the algorithm.

Finding the Foreground

With a light background and a significantly darker object in the foreground, the program in Listing 1 [1] simply finds all pixels whose brightness lies below a previously defined threshold value and blacks them out completely. The Darken() function accepts a draw.Image type structure from line 9, including the width and height of the image in the width and height parameters in pixels.

The double for loop starting on line 11 runs through the pixels line by line from top to bottom, and the At() function called in Line 15 returns the color channels of the current pixel as a value of type color.Color, which the RGBA() function then converts to a red, green, and blue value and an alpha value (transparency). The latter isn't used by the algorithm; hence, line 14 tells Go to ignore it by providing an underscore in lieu of a variable name to which to assign it.

The upper eight bits of these returned values indicate the color value of the RGB channel from 0 to 255; a bit-shift operation extracts the relevant bits and compares the outcome with the experimentally determined threshold value of 180. If one of the channels lies below this value (i.e., the current pixel is darker), line 20 sets the pixel value to color.Black, that is, (0, 0, 0). The threshold value setting is the crux of the algorithm. If the value is set too low, the procedure does not find all foreground pixels (Figure 2); if it is too high, it blacks the image in places that belong to the background (Figure 3).

Figure 2: Too low a threshold for blackening gives the image a Warhol-like appeal but does not produce a silhouette.

Figure 3: A threshold value that is too high, however, also selects parts of the background.

Fancy Logging

The main program, which accepts the name of an image file in JPG format, is shown in Listing 2. In order to tell the user how to use the program, the standard flags module analyzes the command line, grabs any given flags (e.g., -v), and provides them – along with all command-line arguments – in the global flag variable after flag.Parse() was called in line 24. The image file is then found in flag.Arg(0); if it is missing, line 30 calls the usage() function defined in line 16, which displays the correct syntax for the command to the user and aborts the program.

For some user entertainment and general help to figure out what's going on, the main program uses Google's log package, glog, which gets imported in line 10. It is pure witchcraft, as it communicates behind the scenes with the flag package's command-line parser and also injects a help page explaining the glog command-line parameters, which flag will display when called incorrectly (Figure 4). Listing 2 also reports the name of the currently decoded JPG file in line 41 for information purposes.

Figure 4: Invoked with invalid parameters, the program prints out the permissible parameters of the logging module and aborts.

But to where does glog actually log? If the command-line parameter --stderrthresold=INFO, which redirects all glog messages marked as "Info" to stderr, is omitted, the log messages can be found in a logfile in your computer's /tmp directory. Figure 5 shows its names. The Flush method is also important; Listing 2 calls it in line 27 with the defer keyword, which means it kicks in at the end of the current block that belongs to the main program. Note that if you forget to call Flush(), you will be left wondering why nothing gets logged at all or some entries are missing from the logfile.

Figure 5: glog writes messages to a logfile.

To install glog in your Go path, from where the main program can then grab it at compile time, just call:

go get github.com/golang/glog

Future programs will have access to it to compile and link against.

Opening a JPG file and extracting its pixel values is not witchcraft thanks to the standard image/jpeg package that comes with Go. The jpeg.Decode() function grabs a Reader interface for the image file, as previously generated by os.Open(), and decodes the compressed data. This fails with corrupt files; line 44 thus checks the results and aborts the program with glog.Fatalf() from Go's logging module if anything smells fishy.

Juggling Internal Formats

However, the image data read by jpeg.Decode() is not yet available in a format that can be changed dynamically. This is why Listing 2 calls the draw.Draw() function from the image/draw package to copy the image data in line 54 into a newly created structure of the type image.RGBA. Going forward, Listing 1 can read from this data using At()and also change pixel values with Set(). As described in the man page that comes with the package [2], the interface in image/draw aims to warp and transform the processed image in fancy ways, but we're only performing simple pixel getter and setter functions.

The draw.Draw() function gets called on line 54, which in this case only makes the internal format writable and converts the JPG image in jimg to the draw image dimg. The constant draw.Src indicates that the target image (which in this case is empty because it was just created) is overwritten in dimg. In contrast, a value of draw.Over would have performed a source-over-destination-overlay transformation instead. The given start coordinates in bounds.Min define the coordinates of the image origin (0,0), because we're not interested in cropping but instead want to copy the whole image.