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:

1. Find any *.jnlp file in the Finder. These may be on your Desktop, or in a download folder, depending on how your web browser is configured.
2. Highlight the file by clicking on it, then select ‘Get Info’ from the File menu.
3. In the Open with: section, click on the popup menu and select ‘Other…’.
4. In the file chooser window that pops up, under Devices, pick the hard disk icon that corresponds to the name of your system hard disk (probably has the same name as your computer).
5. From there, select the System folder, then Library, then CoreServices, and scroll down to find the Java Web Start application, select it and click the ‘Add’ button. (Note, the location of Java Web Start application may differ on your system.)
6. Back in the Get Info window, click the button that says change all to apply this change to all of your JNLP files, then close the Get Info window.

When something tries to open a .jnlp file now, it should be properly handled by Java Web Start, launching the corresponding application.

Thanks to one of our twitter followers, @doug_ellison, for pointing out that many of you are having this problem!

Please note, we offer this for informative purposes, and you should make changes at your own discretion.

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.

Here is a more specific description of our old and new stretch algorithms.

Old Algorithm

Determine the min and max DN value corresponding to the following cumulative
percents into the histogram.

For the full RDRs, the stretch is linear and the output is 10-bit and
preserves the special pixel values: 0 = NULL, 1 = Low Representation Saturation, 2 = Low Instrument Saturation , 1022 = High Instrument Saturation, 1023 = High Representation Saturation.

For everything else, the stretch is linear, 8-bits per band and each band
is done independently. Special pixels are not preserved.

New Algorithm

The JPG products (browse and thumb) are be made with the original algorithm, with the following exception.

• The Color JPGs use the same stretch as the IRB JPGs. (Otherwise, the black area around the rotated image change the stretch).

The JP2 products are stretched as described above, with the following changes:

• The min and max for the stretch are determined not from a cumulative percentage
  but from the min and max DN taken by reducing the image or band by a factor of

  11 * ( binning / binning of red band )

  . The reduction averages pixels.

Notes

1. Due to PDS format restrictions, the 3 bands of the color RDR (IR-RED-BG) are not
   stretched independently.
2. The ISIS applications hirdrgen and isis2raw are used for stretching. The latter for
   RDR quicklooks and NOMAPs.

We use the IAS Viewer ourselves in most cases. A prerequisite is having Java installed already on your computer; I’m pretty sure that both Microsoft Vista and Apple’s OS X do that by default, and most older versions of those operating systems do too. You can check by going to java.com and clicking on the “Do I Have Java?” link.

I have tested the IAS Viewer on a 2001-era computer (an iMac DV) with a low-speed wireless connection. Surprisingly, it worked about as good as on our work machines (dual or quad-core Macs with gigs of memory and ultra-fast Ethernet connections to nearby servers). With much older PC’s or via dial-up it may not be usable, I expect. But the bottom line is, you do not need to have the latest and greatest in computing technology to fill your screen with a steady source of high-res HiRISE pixels.

Early in the mission, our partners at NASA Ames put together a site using a Flash applet called Zoomify. They still maintain this site; however, it takes time and effort for them to keep up with our releases. Zoomify uses “tile pyramids”, or multiple copies of image data at each zoom resolution. So not only must the data be transferred, it must then be rendered into many tiles, occupying slightly more space than the original data. For that reason, they convert to JPEG, which eliminates some of the highest resolution information. Still, it may be faster because the lower resolutions are pre-rendered and the highest resolution has been decreased. Flash, like the IAS Viewer, is supported on Windows, Mac, and (x86 flavors of) Linux.

Because it is closed-source software, we can’t make improvements to the IAS Viewer. Or, if we did, we could not redistribute them under the terms of our license agreement. But here are some features I would like to see it have someday:

• Press page-up (etc) for navigating one screenful at a time
• The ability to open a URL to a particular region at a particular resolution
• The ability to copy the URL for the view you are looking at
• Voice interface (like the zoom scene in Blade Runner)!

The middle two items would, I think, eliminate the need to email multi-megabyte screenshots around for the purposes of scientific discussion.