Do you use the IAS Viewer to view our JPEG2000 (JP2) image files at full-resolution (which we highly recommend!)? If you use a Mac running OSX, you might be having trouble. Don’t worry, there’s a solution!

It appears that a recent Java patch causes problems launching the IAS Viewer client and other Java-based software launched via Java Web Start. The update changed the location of the Java Web Start application so that the system opens the downloaded JNLP file as a text file, most likely with something called Dashcode. One of our system administrators found a solution on an Apple support discussion archive. You should only have to do this once to fix the problem:

(more…)

The latest, and most massive, release of HiRISE image data to the Planetary Data System includes such gems as the previously mentioned “Caught in Action: Avalanches on North Polar Scarps (PSP_007338_2640)” and “The Earth & Moon as Seen from Mars (PSP_005558_9040 and PSP_005558_9045)“.

How much data was released? 2422 observations, making up 9.9 terabytes “in over 225,599 standard PDS and extras products” according to our database specialist. This was for data between orbit ranges 4400 and 6999, or between July 05, 2007 and January 23, 2008 (which is a lot of loops around the Red Planet!)

We have now released a total of 16.8 TB worth of data, or nearly 500,000 image products. Please check out the latest images on the HiRISE website on the “March 2008: New HiRISE Images Released to the Planetary Data System” page.

These data have been processed, and reprocessed when necessary, with the latest automated pipelines on our production processing cluster. We continue to make changes to the software, however, and will have to reprocess all of these data yet again in a few months. What you see today is gorgeous and as complete as currently possible, but we always want to tweak our calibration, color, and geometry pipelines to make these even better.

This release places us very far ahead of the MRO project’s expectations for the HiRISE team. We are now working on speeding up our releases even more, so that they occur more often. That means we will probably never have such a large release again, which, as far as us downlink folks are concerned is a very good thing. Making sure 9.9 terabytes of data is ready to release is hard work. The images and new findings make it worth it, though!

• PDS Imaging Node: http://pds-imaging.jpl.nasa.gov/
• MRO PDS page: http://pds-imaging.jpl.nasa.gov/Missions/MRO_mission.html
• HiRISE Volume: http://hirise-pds.lpl.arizona.edu/PDS/

As described in a previous post, HiRISE color images are made by combining images in three different wavelengths of light, infrared (IR), red (RED) and blue-green (BG). The incoming light from the surface of Mars is separated by a filter into these three parts of the spectrum. The detectors that receive those wavelengths of light then build up the three separate images of the same place on the surface. The IR and BG detectors are above and below the RED detectors in the HiRISE focal plane, so they are imaging the same place, but at slightly different times. In order to create the color products, the three separate images have to be stacked one on top of the other. Lining up these images perfectly with each other is called coregistration.

This process seems simple in concept, but in practice it is quite complicated. There are three factors to account for:

• Relative timing
• Pixel binning
• Spacecraft jitter

First of all, HiRISE nearly always uses different resolutions for each color. For instance, RED might be at a scale of 25 cm/pixel (bin1) while IR and BG are at 1 meter/pixel (bin4). This “binning” minimizes the amount of data that has to be sent back to Earth, which is the most important constraint that HiRISE needs to deal with. Another reason for binning color is to improve the signal-to-noise ratio (SNR). This means that you can get a better signal by combining pixels at the expense of spatial resolution. In order to get the binned IR and BG images to line up properly, they must be enlarged to match the dimensions of the RED image. For example: RED is bin1, IR and BG are bin2. The RED image will be 2000 pixels wide by 40,000 pixels long (for example), the corresponding IR and BG images will be 1000 pixels wide by 20,000 pixels long. So the first step is to make the dimensions of all three images match.

Now the relative timing is easy to take care of. The start time of all images is a known quantity, and does not change from image to image. We know exactly when the BG detector starts imaging, followed by the RED detector, followed by the IR detector. So the beginning of each image is offset by a fixed amount. Once the images are shifted by this fixed offset (accounting for binning), they will be approximately lined up.

This brings us to the third factor in coregistering images — spacecraft jitter. Because HiRISE is imaging at such a high spatial resolution and at great speed, tiny motions of the MRO spacecraft cause slight variations in where the surface features appear in each of the three color detectors. Imagine that HiRISE is taking a picture of a 1m sized boulder on Mars. If the rock shows up in line 100 of the RED image, and we have already accounted for the relative offsets of the detectors and for binning, then the rock should also show up in line 100 of the BG image. But say we look and it is actually in line 99. Now when we try to stack the two images, the objects in them won’t line up exactly. Our color processing software corrects for this by holding the RED image fixed, and adjusting the corresponding BG and IR images to match it precisely. This is not a perfect process, but most of the time it works extremely well.

Producing the color HiRISE products is not a trivial process. But it is to a point where the processing is automated so new data is released without delay. Enjoy the colorful view!

One of our team members, Ross Beyer, put together a way of getting MRO data into the Google Earth tool: http://orrery.us/node/54

I finally got around to trying it out, and it’s very easy to set up following his instructions. It allows you to see the footprints of acquired HiRISE images on a larger context map, and the Google [Planet] interface is really easy to use. Clicking on a red H footprint gives you a short description of the image, and a link right to our image release page, where you can browse or download the image products. CTX footprints are available, too. If I’m understanding this right, these KML files pull all currently released data from the PDS, so whenever we release data, the new stuff is automatically included.

The basemaps aren’t in 3-D (yet – maybe someday?!), so the perspective view isn’t much use, but you can kind of trick yourself into thinking it looks 3-D with the shaded relief maps. You can “fly” over the planet, zooming in & out, which is really fun.

I had trouble trying to get two basemaps visible at once (colorized MOLA elevation over the greyscale MDIM). With just one basemap, though, it works just fine, and it’s very fast (this probably depends a lot on your internet connection).

One really nice thing about the Google interface is when there are two overlapping footprints (which all of our stereo images are), clicking on them expands the choices and allows you to pick one or the other. Other tools I’ve used don’t handle this as nicely, and sometimes it’s impossible to select the “bottom” one.

Nice job, Ross & Google!

Lately we’ve been working hard dealing with a LOT of extra data. Because Mars is getting closer to the Earth (you can visualize that in this view of the solar system), we are approaching the peak data rate for the entire primary mission. Not that we’re complaining! This just means the Targeting Specialists are planning many more images, and we’re making those images as big as we can.

Unfortunately, we can’t just make them all the largest size the instrument is capable of taking, because our camera will get too hot. If it overheats, the instrument will shut itself off in order to prevent any damage to the electronics. So we have to be careful, and only plan images that won’t overheat HiRISE. In order to predict those temperatures, we use a tool called HiTemp (of course!). Here’s what it looks like (click on the image to see a bigger version).

This program reads in our planning files, and then models the temperatures of two key spots on the focal plane of the camera. It’s our job to make sure we don’t go above the dotted red line – this gives us a comfortable buffer below the scary solid red line. That’s when HiRISE would shut off, or safe. We know from experience by now that this is a big pain in the neck – a lot of work is required to get us back up & running, and we miss observations while we’re turned off. So we watch our HiTemp plots!

Starting with the 10/10 release, color images are included for the first time. We’ll describe how we process these in the days and weeks to come. But what I’d like to do first is give a brief description of all our product types as they currently are available. You’ve no doubt noticed a mind-boggling array of new options on our product pages. They now include what we call our “NOMAP” products; NOMAP means that they are not map-projected. In other words, not rotated to the direction of north, not mapped to a coordinate system, and not scaled to any particular geometric resolution.

I’ve prepared this ugly table that outlines each of the products now available (excluding the raw EDRs). So reading the columns from left to right: there are three types of “NOMAP” products, two types of lossy “QLOOK” (Quicklook) RDRs, and two types of lossless RDRs.

With that as a reference, now I’ll try to define everything more precisely.

“NOMAP”

Non map-projected product. Always lossy compressed for smaller size and quicker viewing. These are not formal Planetary Data System products; they’re “special”, meaning there is no PDS label and no Software Interface Specification describing them. Available for IRB, RGB and RED.

RDR

Reduced Data Record: reduced in the sense of refined or processed, not raw data. Formal PDS products with accompanying labels and a detailed SIS document describing their format and processing steps. Available both in lossless and quicklook formats for both RED & COLOR.

“QLOOK”

Quicklook: a special product that is a lossy compressed version of the RDR. In a normal RDR, all of the original data is retained. But with a quicklook, some of the highest resolution detail is discarded to make for quicker viewing.

RED

The image obtained by the red-filtered CCDs. It will be over the full swath width, typically data from all ten red CCDs. Covers the visible wavelength band from 550 to 850 nanometers.

IR

Infrared. Covers the near-IR wavelengths from 800-1000 nanometers.

BG

Blue-Green, visible wavelengths from 400-600 nm.

COLOR

A color RDR. It contains data from the IR, BG and center RED ccds. Typically this will be a skinny strip (”center swath”) inside a skinny strip, or as I like to say, the bacon-strip effect.

IRB

An enhanced color NOMAP. It has the same color bands as the RDR: IR, RED and BG.

RGB

An enhanced color NOMAP. It contains only data from the RED and BG. The blue is derived from the difference between the RED and BG. The color bands are RED, BG and the synthetic blue.

EDR

Experiment Data Record, a formal PDS product that is raw uncompressed data with a label header.

Note: we will be working towards making all of these products available for all prior releases.