The first few cycles of the extended science phase (ESP) have been very similar to the previous primary science phase (PSP). The main difference has been that the Observation IDs start with ESP instead of PSP! (like ESP_011268_2485) We’re also adding some warm-up observations on the night side of the planet now, which is adding some extra work in the planning. Luckily (?), Mars is at its farthest distance from the Earth right now, so the data rate is very low. This means fewer images to plan, so we have some extra time to do special things like this.

The next cycle, however, will mark some changes in the way we do the planning process. This is cycle 58 (can you believe it’s been that many cycles since we started??). For most of that time, we’ve been doing things in much the same way. We’ve gotten so good at it that everyone decided they wanted to change everything & mess it all up. haha, just kidding. We’re actually trying to simplify things. Even though we’ve gotten pretty good at this, it’s still an incredibly complex process. We would like to continue doing it for a long time and still remain sane. Also, we expect that our funding will be cut in the future, and we want to make sure we can still do everything even if we have fewer people. Plus, things just wouldn’t feel right if we weren’t constantly changing something!

If you’re interested in the nitty-gritty details, here are some of the things we’re changing: (more…)

The data rate from the Mars Reconnaissance Orbiter (MRO) – in orbit around Mars on the other side of the Sun from our perspective here on the Earth – is set to increase soon, marking the end of solar conjunction and the beginning of MRO’s Extended Science Phase (ESP).  HiRISE will capture the first image of our next phase in Mars exploration this weekend.  Like all first images after the HiRISE camera has been idle for awhile, we will look especially closely for, but do not expect, any issues.

In these days leading up to the beginning of ESP the downlink team is checking our processing software and tools to make sure they are ready for the observation ID prefix change from PSP_XXXXXX_XXXX to ESP_XXXXXX_XXXX. The automated processing pipelines are ready to go.  My own validation and reporting Perl scripts make use of modules that are mission phase aware and pattern match file extensions instead of observation ID prefixes, so I think I am set. Any minor tools we miss can be easily updated as necessary.

With improvements to our tools and new procedures, we can sometimes recover image data previously stuck in the original raw data files. During this quiet period, I had an opportunity to go back to old observations, some from early in the Primary Science Phase (PSP), and recover errant channels that failed our processing software at the time.   This resulted in a few new channels of image data that we will include in a later reprocessing of our images.  For example, PSP_001746_1515 was originally processed without the RED1_0 channel. You can see this channel gap if you click on the observation’s “Full image (grayscale, non-map projected)” link.  An improved mosaic will include most of RED1_0, albeit with a small image data gap near one end.  Why did we not create this channel before?  Sometimes a data gap occurs between channels, obliterating the second channel’s science header.  The software at Jet Propulsion Laboratory’s RSDS that splits our image data into separate raw data channel files cannot figure out where to split the image data correctly within this gap and so image data from two or more channels are trapped in one raw data file.  When this jumbo raw data file hits our EDRgen processing pipeline here in Tucson, Arizona, the tool called HiRISE_Observation became confused when it discovered image data from another channel near the end of the file, and the error it flags halts the EDRgen processing pipeline.

We now have improved tools and procedures for dealing with this problem.  By running HiRISE_Observation outside of the EDRgen pipeline, it will successfully produce an EDR for the first channel before it complains about the second channel’s image data.  While we would love to get at that second (or third, or later!) channel’s image data, right now we recoverthe data that is easiest to reach.  Someday, we might have a tool that will recognize a missing science channel header, reconstruct this header, and then fit the header in correctly between the first channel and the additional channels stuck in one raw data file.

When will you see the new PSP_001746_1515 products, newly improved with the recovered RED1_0 channel?  Hopefully in a few months.  While I have recovered this EDR (as well as EDRs from other observations), we would like to wait to reprocess the entire observation until we have even better image calibration built into our processing pipelines.  It makes little sense for me to reprocess this observation now when we are just going to be reprocessing it again sometime early next year. Once all of our improvements are in place in the upgraded processing pipelines, we will reprocess ALL of our observations, a huge undertaking.

Next week we will be back to our normal downlink activities: making sure the processing pipelines behave, validating new observations, providing daily reports to the rest of the team, and processing color and RDR mosaics.  We will also add in routine creation and validation of anaglyphs and preparation for our next Planetary Data System (PDS) release in March.  The quiet time during solar conjuction was nice, but we are anxious to see new images from Mars!

After the long process of creating the HiGlyph Pipeline (anaglyphs producing software), processing the images through this pipeline and having them all properly validated, we here at HiRISE are proud to present you with a whole mess of anaglyphs (362 of them, to be exact )!

And now, for all of those curious minds out there, a brief overview of the HiGlyph Pipeline:

• Anaglyphs are created in a three-step process. The first step is to take the two images of the stereo pair and map project them. This helps the pipeline determine which image will be the left image and which will be the right image in the anaglyph.

• The second step takes the two images and looks to see if there are any improvements that can be done on them before putting them together. If there are not, the images move on. Often, due to the difference in viewing angle, the two images do not have a 100% overlap. Thus, to make the image a bit neater and easier to see, we trim off the excess portion of the image (the parts that do not overlap) and then assemble them so the left image is the red and the right image is the blue/green.

• The third and final step of this image processing is simply to prepare the images you see here and to update our catalog.

Seems complicated, right? Well luckily we have wonderful programmers that create these intricate programs. All I have to do is create a list of these images and run them through this pipeline. What really makes my job interesting is the validation process!

I have had the pleasure of being able to look at all 362 of the anaglyphs we have released today. But, you might ask, aside from looking super cool in 3-D glasses , what does it take to validate these anaglyphs? Well, at the beginning of this process the student validators and I got to ask that very same question. Since HiRISE has never had software to create images like this before, we played lab rat and came up with an entirely new technique for validation.

• You may notice that when not wearing the 3-D glasses there is a bit of a horizontal shift in the anaglyph. This shift is good because it is what allows us to see the image in 3-D. But, since the map projection of this process is not always spot on, we sometimes wind up with a vertical shift too. This is bad! Since most of us do not have googly eyes, this makes the image very difficult to see. With our validation process, we have to spot this out and fix it so that you do not have to strain your eyes (well… not too much at least ) in order to see the anaglyph.

Well, with that said, I leave you to your regularly scheduled HiRISE browsing! Enjoy!

We’re in the midst of the last cycle in MRO’s Primary Science Phase (PSP). Conjunction is coming up, when Mars is behind the Sun, so we won’t be able to communicate with the spacecraft for a few weeks. We’ll get a welcome break during that time – Uplink will have two whole planning cycles off, and Downlink will get a chance to catch up with their processing.

I can’t believe it’s been two years since the last conjunction and the start of PSP! A lot has changed since we started out with those first images. (more…)

We’ve just released 1008 new HiRISE images to the PDS! (See main page, or click here for the catalog.) This release covers orbits 8200 – 9299 of the primary mission, or in other words, the end of April through the end of July. That means we’re releasing data that’s only about 6 weeks old! This is awesome – I’m so impressed with the downlink team! The amount of work required to process these images is astounding, let alone prepare and post everything for an official release.

Here are a few examples of cool images, which were previously unreleased:

• PSP_008248_2640, Polygons and spots on defrosting dunes (right)
• PSP_008269_1395, crazy weird stuff in Hellas Planitia (be sure to look at the whole browse image on this one!)
• PSP_008322_1865, Multiple generations of slope streaks on a crater in Arabia Terra (left)
• PSP_008343_1430, Gullies on mesas in Gorgonum Chaos

I’ve only looked through the first few pages in the release. I know there are a lot more amazing images in there, so if you’re browsing through the images, post some of your favorites below!

Despite being several years into our mission, we’re still seeing fresh faces on the HiRISE team. Recently we’ve added some new hires: student validators, researchers, and Targeting Specialists (with whom I work the most). We also continue to involve new scientists in operations – Participating Scientists or post-docs who haven’t gone through the planning process before. They come to HiROC to train during their first cycle, so we have a conveyor belt of visiting scientists as well.

The first Monday in June when they all started was krazy – lots of new people wandering around, office chaos and computer confusion…. By now they’re settling in and things are cooling down somewhat, although at least for the Targeting Specialists, we consider it about a 6-month process to get fully up to speed. In the first few weeks, their eyes are usually glazed over with information overload. At this point, they probably feel like they’ve been dropped in the hot oil of confusion (it’s also 106F in Tucson, which doesn’t help), then dipped in sticky, overly detailed procedures. Sweet procedures….

While we go through this training, the new kids are keeping us veterans on our toes – I keep finding places where the procedures we told them to follow are unclear, there’s a hole in the middle where steps are missing, outdated, or just plain wrong! So it’s really a shared learning experience. Besides, it’s always good to have some fresh, hot ideas and different perspectives to keep us from getting jaded. or dangerously skinny.

I’m excited for them – the sugary thrill when their first commands execute on the spacecraft, the pride when their first beautiful images come down, the feeling of fullness and mastery when they finally become fluent in the foreign language of acronyms…. Other firsts I’m sure they’re not looking forward to are their first mistake, their first late night, their first bad image…. So not everything is warm with honeyed nostalgia.

I’m sure they’ll all do a wonderful job, though, and be valuable additions to the team. In the meantime, though, I could really use some donuts…. Welcome, newbies!

It seems like we’ve been preparing for the Phoenix mission for such a long time – and now it’s finally close to landing day! T-6 days according to our countdown clock! Things are getting pretty crazy here, and I thought a little overview of how the HiRISE team is supporting the Phoenix mission would be useful.

We’ve been imaging the northern plains for Phoenix since we started our mission (here’s a bunch of reconnaissance images on our website). The first images we got back showed lots of scary boulders (a close-up of one of our Transition images shown to the right), so we sampled other areas and searched for a relatively boulder-free landing spot. The area the Phoenix team finally chose is being called the “Green Valley“, not because of the “green light = safe to go” connotation, but rather because some geological maps made of the area happened to use green as the color for the valley. Perhaps coincidentally, Green Valley is also a town near Tucson, where both Phoenix and HiRISE are based. Whatever the reason, I like that the name has a lovely calm, comforting feel.

Once the Phoenix team picked out their landing site, we worked on a high-resolution mosaic of the entire 3-sigma landing ellipse (”3-sigma” means there is a 99% probability it will land within this area; see this great blog entry on landing ellipses at the Planetary Society). The Phoenix landing ellipse is shown to the left, along with the footprints of a number of HiRISE images. (This was before we were quite done with the mosaic.) These images have helped the Phoenix team characterize the regional geology and assess the safety of the landing site.

In addition to scouting landing sites, we’re also going to be involved with Phoenix during its prime mission on the ground. We’ve been planning and practicing several different ways of cooperating: (more…)

GeoTIFF is an industry standard for embedding geographic information in images. Beginning soon, HiRISE RDRs will include GeoTIFF info in the Jpeg-2000 files. All of the information about the image will continue to be in the RDR label (.LBL plain text file), but with this additional info in the JP2, image viewing software that supports GeoTIFF will be able to take advantage of it.

For example, such software could display the actual coordinates on Mars of the pixels you are looking at, allow you to measure features directly in physical units, or stitch together images based on their absolute location on the planet. A number of GIS (Geographical Information Systems) applications use GeoTIFF; many on our science team have been waiting patiently for this feature to be rolled out.

We have already begun to produce RDRs with GeoTIFF, and they will start appearing in our weekly releases. At some point, a major reprocessing effort will be underway to bring this feature (and others) to all of our pre-existing products.

This brings up the topic of versioning: namely, how to tell which version of a HiRISE product you are working with.

(more…)

Today, our software group provided a set of major updates to our downlink operations team. It was the first major update in many months. One of the most anticipated features is smarter “stretch” algorithm for our color products (RDR Extras). As discussed in a previous post, a stretch (in image processing terms), is a mapping between one range of pixel values and another. In our case, it provides our viewers with a better-looking image up-front, with less need to adjust parameters in display software such as IAS (though this is still often very helpful when zoomed in). As always, the full range of original data is preserved in the RDR JP2.

Our former algorithm for the NOMAP and Quicklook products said that the pixel values above the brightest 0.1% and below the darkest 0.1% would be mapped to the extreme values, with a linear fit in between. For a majority of images, this was a good choice that showed excellent contrast but prevented too much saturation.

However, 0.1% (a thousandth) of a two Gigapixel image is still two million pixels. So if there were a particularly bright spot, like a rocky outcrop amid a field of dunes, or a particularly dark spot, like a cavern opening in a plain of boulders, then all the saturation would occur in that one area, washing it out completely, and lowering contrast everywhere else in the image. So the algorithm needed to be more adaptable. After a good deal of experimentation, the algorithm we settled on looks at the brightest and darkest pixels in a thumbnail version of the image, and uses those values for the extremes, instead of the values at 0.1%. We shrink a copy of each color band to 1/11th the original scale. Pixel values in the original below the darkest in the thumbnail are mapped to pure black, while pixel values above the highest are mapped to pure white. The stretched bands are then merged to make the color image. Hence, a bright or dark spot smaller than 1/11th x 1/11th of the image size will no longer dominate the stretch.

What this ultimately means is, our RDR Extras now show more detail in areas that would be completely washed out by the old algorithm.

For example, in this ‘cave’ image, the left is from the original RGB.NOMAP.JP2, while the right is the same product using the new algorithm. As you can see, previously you could not tell if there was a floor to the hole or if it sloped away to greater depths.

The new algorithm is used strictly for the JP2’s; the browse and thumb are already scaled down enough that it would not make a substantial difference with them. The new algorithm went into effect today; coincidentally we just started orbit 8000. Images with the new stretch will likely appear in upcoming weekly releases and we plan to reprocess everything with this change (and improved calibration) during the summer.

(more…)

All downlink tasks I perform follow a particular development path: (1) I practice and jot down manual procedures; (2) over time I attempt to automate subtasks by using Perl or other tools, as best I can (I am not a software developer); and (3) our talented software developers write software that automates the task completely, or at the very least speeds it up considerably. Of course, this is always just in time for me to be assigned new tasks!One of my daily tasks is monitoring data quality and paying attention to missing or gapped raw image channel files (up to 28 channels per observations.) My tools: our internal reporting website HiReport, Terminal, and Microsoft Excel. I look through a list of observations in my web browser, click on those that appear to be missing channels or are flagged as “INCOMPLETE”, and copy and paste information about the problematic channels into Excel. I then add some additional notes and take any required actions.

A few days ago I realized that after more than a year, I was still in the manual stage of monitoring data quality and not making good use of existing tools to help streamline the process. All that cutting and pasting was beginning to get ridiculous, even more so during a period of high data rates and an increasing number of observations.

(more…)