Thank you, thank you, thank you. I got quite a few great suggestions for a name for the new HiRISE stereo pair application I mentioned previously. Here they are:

Through Twitter:

  • Pairendipity
  • Opportune Viable Extraneous Results Lending to Awesome Parallax: OVERLAP
  • Over Observed Possible Stereoscopic: OOPS
  • Super Mega Ultra Hyper Stereo Seeker
  • Cyclic Redundant Observations Search for Stereo-Effect-Yielding Extra Data: CROSSEYED
  • Twin Hunter
  • RENA
  • HiDyad
  • Coke Bottle Glasses
  • Coincidental Binary Groupings
  • Cypress Hill

Through comments:

  • HiRISE Serendipitous Accidental Pairs (HiSAP)
  • HiRISE Serendipitous Observations Accidentally Recorded (HiSOAR)
  • HiRISE Advanced Research in Explorative Stereo Software (HiARESS)
  • HiRISE Software of Topographical Explorative Research in Extraterrestrial Observations (HiSTEREO)
  • HiRISE Stereo PRojection Interface TEchnology/TElemetry (HiSPRITE)
  • High-resolution Analysis of Data Exploration in Stereo (HADES)
  • Serendipity
  • MarsUpilami
  • HiThere
  • HiRISE Stereo Pair Inspector (HiSPI)
  • Marvin

Of all of these, my favorite is Pairendipity, suggested by @avdflight through Twitter. It was also the very first suggestion I got, and I immediately fell in love with it. It captures the accidental stereo nature of the software quite marvelously.

I predict one or two team members will groan, but I think the whole rest of the team will be as delighted as I am. Thanks a bunch everyone, and thanks especially to @avdflight!


Help Me Name a New HiRISE Application

I need your help. I have a new HiRISE application, and it desperately needs a name. There’s no prize for this, although if the name is particularly ridiculous or groan-inducing, you’ll have the satisfaction of knowing you’re making me smile every time a team member has to use the app or talk about it.

The application hunts through our database of acquired observations and tracks down accidental stereo pairs. By “accidental stereo pair,” I mean a pair of observations that were not planned as a stereo pair but which happen to make a decent set.

The easiest example to imagine is the case where we’ve done a seasonal repeat monitoring series of a particular location, where we might have two, three, four, or more observations of the same site that were taken at different look angles. Odds are high there’s a good stereo pair in there.

Less easy is the case where we took a couple of observations that happen to overlap significantly. Maybe we were putting together a mosaic, for example. Maybe there’s a nice stereo pair in there, too.

So what kind of name do I want, you’re wondering. The application we use for planning stereo pairs in advance is called HiSEAS: the HiRISE Stereo Effect Analysis Software. I like this name. It’s got a nice, adventurous feel to it that brings to mind exploration and, well, pirates. But it’s also got a horrible homophonous pun in the name related to vision. That’s a good name, but it can’t be the name of this software.

Right now, this new application is called Find_Stereo_Pairs, which is very dull. I want something better, and I want you to help me with it. It does not have to start with “Hi,” nor does it have to be an action phrase (“find stereo pairs”).

You can try commenting below with names, but probably the best way to get me a name is to tweet it at me: @HiCommander. Like I said, there are no prizes beyond the knowledge that a HiRISE team member will probably have to say it at some point. The deadline is Friday morning, January 11, 2013, at 10 AM US Mountain Standard Time (UTC-7:00).

By the way, when I say, “I have a new HiRISE application,” I mean a student programmer, Ashley in this case, wrote a new HiRISE application for me. Nice!

Hi There

It’s been a long while since I last updated this thing. I see the most recent post is about a game I haven’t played in over a year. (It’s still a cool game, especially when you’re waiting in line.) Since I advertise this site in my Twitter info, maybe I should start writing here more.

I’m a software developer for HiRISE.

HiRISE is a big, badass camera currently in orbit around Mars. It’s carried by a gorgeous pelican-like spacecraft called the Mars Reconnaissance Orbiter, MRO.

Your typical spacecraft is a box with an antenna, some sort of power source, and a bunch of bits sticking out. Some thrusters, too, of course. Gotta have thrusters. On MRO, the antenna is huge. The power source is a giant pair of wing-like solar arrays. HiRISE is the biggest bit that isn’t the HGA (high-gain antenna) or the SAs (solar arrays). It’s a huge telescope barrel pointing down at the surface of Mars in MRO’s normal flight configuration.

Mars Reconnaissance Orbiter

Artist’s concept illustration of MRO over Mars. (NASA/JPL)

Here’s a picture. I’ll give you three guesses as to which of these things is HiRISE. Some clues: Does it look like a big, foil-wrapped radio dish? That’s not HiRISE. Does it look like solar arrays? Not us. The next thing you think might be us is, in fact, us.

(Here’s a link to a picture of a pelican. See? MRO kind of looks like a pelican.)

As I say, I’m a software developer. Sometimes people like to call me a software engineer, but I don’t really think of myself as an engineer.

I started out in planetary science after an undergrad journey through physics and astronomy. If you’ve heard of Jay Melosh or Rick Greenberg, they were my grad school advisors. If you haven’t heard of them, they were still my advisors but it’s not critical that you know who they are so let’s skip forward a bit.

I love space. I love planets. I love science. I love doing all the dicking around that comes with science. I’m not fond of the follow-through, though. That’s the publishing part, the giving-of-talks part, and that’s in many ways the most important part of science.

I can, however, turn a lot of my dicking around into something other scientists can use to do their thing more easily, and since much of my dicking around turns out to be computer programming, that was the clear path forward.

So I do that. I write software that scientists use. In this case, it happens to be software that is used to plan images that are then taken by a camera orbiting Mars on a what is basically a foil-wrapped box. I also write the software that we use to generate commands for that camera; these are almost always imaging commands.

The planning tool is called HiPlan. The commanding tool is called HiCommand. Other fun names of tools that I’ve developed include these: HiTemp, HiSEAS, Data Slacker, The HOGG, and HIPHOP. I’ll explain those some day, but let me just say for the record how awesome it is to hear the science team talking about “hiphopping” and “hogging” the latest image. I giggle a little bit inside every single time.

Because the commanding tool is called HiCommand, I call myself HiCommander on Twitter and elsewhere.

I don’t do my thing alone. I often work with one or two student programmers, with exotic names like Steve, Missy, a different Steve, Shawn, Josh, Jeremy, Arjang, Ben, Brian, and Drew. I’m worried I might have forgotten some. A plurality of the time, when they leave, they go off to the DoD or one of its subcontractors. Missy went off to State, though, and that makes me especially happy. By “State” I mean “The United States Department of State.” She’s in the diplomatic corps. I love that.

In addition to the student programmers, members of the science team often generate prototype tools that I then take under my wing. HIPHOP started out as an IDL program written by science team member Nick. HiTemp started out as an IDL program written by science team member Laz. HiSEAS started out as an IDL program written by science team member Shane. Data Slacker started out as a Python program written by science team member Ross.

There are three other full-time software developers on the team, each responsible for software in different areas of HiRISE operations. I’m the lead on the planning and commanding, though, and for that, it’s just me, my student or two, and the occasional science team member who puts together a prototype.

Right now, in the middle of August 2012, you might be most aware of HiRISE because of what we’ve done in support of the Mars Science Laboratory, Curiosity. I prefer to call it MSL, because I like TLAs.

MSL landed on Mars on August 5th or 6th, depending on where you were. I was in Tucson, gathered together with a bunch of other HiRISE folk, and we watched it in our main conference room, so that was August 5th for us. After MSL had landed, our work really began, because, you see, a few minutes before MSL touched down on Mars, we had taken a picture of it.

We had taken a picture of it at the end of its parachute, racing through the very thin atmosphere of Mars.

So we spent the night waiting for the data to get to us, then waiting for it to be processed, and then combing through the—oh, wow, targeting specialist Nicole found it pretty quickly. Way to go, Nicole!


Sharpened image of MSL on its parachute as taken by HiRISE. (NASA/JPL/University of Arizona)

We showed it off at the press conference the morning of the 6th, according to the clocks in JPL and in Tucson. You might have seen it. You probably thought, wow, MSL is really cool and the landing mechanism is crazy, but holy shit did we really take a picture of it on its chute, racing through Martian air?

Yes we did. This is it, here.

Like I said, HiRISE is a badass camera. The best part about it is that we did it 2008, too, for the Phoenix lander.

Did I really just write that the best part of the MSL image is that we’d already done a similar image four years earlier? What?

Obviously the best part about the MSL descent image is the MSL descent image.

In any case, yes, the world was reminded once again about HiRISE when MSL landed on Mars. When you see images taken from space of the rover and the area in which it’s working, that will be us as well. Sometimes the world forgets we’re there. Frowny face.

During the press conference on August 7th, MSL mission manager Mike Watkins said something along the lines of “Engineers hate surprises.” Implied as part of the larger story he was telling was that scientists love them.

This is why I don’t consider myself a software engineer. I love surprises, where “surprises” here means “bugs.” Bugs are mostly fun for me. Sure, they can be quite annoying, like the time I broke HiCommand when targeting specialist Anjani needed to generate some commands at 8 PM a number of years ago. But on the whole, they are fun to track down. Fun to pick apart. Fun to test.

Bugs are so fun, I award gold foil stars to our targeting specialists when they find one. I stick the stars on the nameplates on the doors to their offices. (It started when targeting specialist Ingrid jokingly asked if she would get a gold star for finding a bug. I thought, “Hell yes,” and ran off to the campus bookstore to buy a pack. Really good bugs earn a chocolate star, which is just a chocolate candy bar of slightly better quality than something produced by the Mars company, which I realize is a pretty unlikely thing for me to say.)

I also stick red foil stars of shame on my own nameplate when I really screw something up. Breaking HiCommand was a double red-star affair.

(Since I’m describing the HiPlan/HiCommand bug reward system, I should maybe note that finding a gold-star bug does not necessarily mean I get a matching red star. Indeed, it’s almost always one or the other, on my judgment. I am judge, jury, and deliverer of foil stars.)

So, no, I don’t hate surprises when it comes to my software. I love them. Ergo, I’m not really a software engineer. I guess you could say I’m a software scientist, except that’s not a thing anyone says, ever. “Computer scientist” is usually the term, but to me that means “AI researcher,” and I’m not that.

So there it is. Nice to meet you. I hope to talk more about HiRISE here, especially HiPlan and other tools.

JFreeChart’s (Ab)Normal Distribution Function

I’ve got a long-running project that’s very nearly completed, in which I’m converting some old IDL code to Java for the modeling of Martian photometry as observed by HiRISE. I use JFreeChart in this project (and all of my projects that require charts, in fact).

I happened to be digging into the source code for the NormalDistributionFunction2D class and I found this piece of madness:

public double getValue(double x) {

  return Math.exp(-1.0 * (x - this.mean) * (x - this.mean)

    / (2 * this.std * this.std)) / Math.sqrt(2 * Math.PI

    * this.std * this.std);


“std” is the function’s standard deviation, set at construction.

The madness is in the denominator of the function: the square root of…a constant times the standard deviation squared. Isn’t that just the standard deviation times the square root of a constant? And the square root of a constant is itself a constant.

So why isn’t the denominator just a constant times the standard deviation? Why have four multiplications in there followed by a call to the math library? This expression is evaluated every single time the NormalDistributionFunction2D’s getValue method is called!

Because the standard deviation could be negative! Wait, what? No, it can’t. Even if there was some sense to it, the only computation in this code involves squaring the standard deviation, effectively stripping it of its sign. The denominator really ought to be a pre-computed constant times the standard deviation.

Also, since the class doesn’t let standard deviation be changed after construction, the entire denominator can be pre-computed at construction, as can the denominator of the exponent used in the numerator. Neither component ever changes once the object has been constructed.


This is in version 1.0.10 of JFreeChart, by the way. Maybe it’s been fixed by now. I probably ought to be a good open source citizen and submit a fix myself if it’s not been fixed.