Pygame to the rescue!

I don't think I've mentioned this before, but in the project Dr. Takamiya and I have been working on we came to the conclusion (after many attempts to stave it off) that the analysis of spectra could not be done reliably by computer (too many false positives), but would need to be done by a human. And when I mention we have a total of 33,525 spectra, you'll appreciate that it's going to take some time.

Because of that, I decided to implement Project Spectra Zoo, modeled after the much more famous and polished Galaxy Zoo. Basically, it involves volunteers from the large number of incoming freshmen this semester doing the analysis for me (in return for getting their names in the paper and some valuable experience). Now, in the spectra to be analyzed, there are a lot that are not entirely clear as to how they should be classified even for someone like myself, so the idea is to have every spectrum analyzed by at least two people and then compare the results, paying attention to those cases where people disagreed. Since having some sort of standardized results would facilitate that happening, I decided to write a program to help people with the analysis.

(Now, I'd just like to say that writing this program shows just how much I have learned and grown over the past year. I used a Python package called wxPython for writing graphical user interfaces [GUI's], and it would have been completely impossible for me to have written something in it at the end of last summer. I know, because I tried for a few days, and got nowhere. Only after learning a bunch more about Python, including the concept of classes, was I able to understand how to use wxPython.)

wxPython is good at what it does, which is created programs with a native feel to them for whatever OS you're using. Using it I was able to create FluxClassify, seen below in version 0.3.0.

FluxClassify.py, V0.3.0

Briefly, each numbered checkbox represents a spectrum in the 15-by-15 array format we're working with. Users can check boxes to represent the presence of a spectral line in an image (or even activate a third state for an "I don't know" answer), save their classifications for both the red and the blue filters (each picture comes in two parts of 225 spectra each), and output a file containing all the classifications they made in an easy computer-readable format.

It's perfectly usable as it is, but it requires users to manually flip between the spectra and the program which gets distracting and slows the process down considerably. I dreamed of a new program, one more similar to Galaxy Zoo: one that would display a single spectrum, wait for the user to classify it, then move on to the next one.  With this grand vision in mind, I set about learning how to place graphics in wxPython (the spectra are all saved as JPEG files).

This turned out to be a surprisingly difficult and daunting task. It turns out that the wxPython documentation is awful. I've always found the (plain) Python documentation to be an amazingly helpful and useful resource, and never realized just how above-par it was. After a two days of bumbling around with confusing and complicated wxPython tutorials, I was ready to—well, not give up, but to look around for other options. It was looking for other options after my first tangle with wxPython that led me to the much-more-useful-for-my-purposes Python Imaging Library last summer, after all.

So a few days ago, I was considering the problem of getting graphics—images—into a program with a GUI. And then the idea came to me: what programs, out of all computer programs, tend to make the heaviest use of graphics? The answer is games. Games, more than any other program, use the most and most complicated graphics. This line of thought came to me because I had recently downloaded the Pygame package when I discovered it had a version for Python 3.2, intending to check it out later. Now, I've spent several hours over the last two days checking out Pygame's documentation, and it turns out to be much simpler getting graphics on-screen. I haven't begun writing FluxClassify's successor yet, but I'm sure it will be a lot easier. It may not look quite as polished, but it'll be more efficient and easier to use, and that's what counts.

And who knows, considering I'll have used a package intended for making games to write it, maybe I'll throw a gaming element or two in there as motivation for my volunteers to classify spectra. It doesn't hurt to make scientific research fun, after all!