SkyView Blog

Today at 6 PM EDT we celebrate the sidereal anniversary of the public release of the new Java based SkyView web site. Completely changing our server-side hardware and software, CGI scripts and documentation was a bit of a risk, but with just a few hiccups everything worked out pretty well. We have been pleased with how smoothly the initial transition went and with how the system has worked over the past year.

SkyView has generated about 1.8 million images in this year. The VLSS, IRIS, BAT and GALEX surveys have been released and the RASS background surveys have been completely updated. All of the DSS and DSS2 data is now incorporated as local data in SkyView. In the next year we plan on releasing a new survey publication interface so users can add their own surveys to SkyView. SkyView surveys have been incorporated with Microsoft’s new WorldWideTelescope and serve images to Caltech’s VIM tool.

The new Java software had lots of new capabilities and makes it much easier to adapt software to new circumstances. We’ve added a few new projections: Arc, Sfl, Stg and TOAST. There are new capabilities for running batch scripts. Users can see exactly where each output pixel is sampled. New image finders were customized to handle the GALEX surveys. A JavaScript widget that translates pixel locations to coordinates has been added to the Web display. And there are many minor changes and a few bug fixes. With our new framework it has been much easier to add new capabilities and make changes without increasing the complexity of the underlying code.

Overall we believe this has been a good year. Let us know what you’d like to see in SkyView over the coming year.

I’ve been at the International Virtual Observatory Alliance meeting in Trieste Italy this week. SkyView has had a bit of visibility here. The WorldWideTelescope use of SkyView surveys was prominently mentioned in Jonathan Fay’s presentation on the WWT, and SkyView was also prominent in the Virtual Observatory Integration and Mining (VIM) software developed at Caltech that was discussed by Roy Williams.

SkyView both uses and supports the Virtual Observatory. Users can get data from SkyView using the VO’s Simple Image Access Protocol (SIAP). SkyView gets information for catalog overlays using the VO Cone Search. If you would like to set up an SIAP, the SkyView distribution provides support for this too.

There was an error in the VO Simple Image Access (SIA) server for the SkyMorph/NEAT database.  It had an error in its error handling. When an SIA call results in an error the service is supposed to return a specified XML format which describes the error. In this case the server call failed before finishing the table. This should now be fixed. While this service is located on the SkyView server (at http://skyview.gsfc.nasa.gov/vo/sia_skm.pl) there was no error in actual SkyView code.

The release of Microsoft’s WorldWideTelescope this week made a big splash with articles in the New York Times and other media. It’s a very nice interface where you can just zoom and pan and compare data in a very elegant fashion. The ability to build tours of the sky is amazing.

When they look inside the hood of the WWT, SkyView users may find a lot of stuff that looks familiar. Most of the survey images in the initial release of WWT were taken from SkyView. The TOAST projection was added to SkyView to help support the WWT’s ingest of many of our most popular surveys.

We are very pleased to have been able to play a role in the WWT. We anticipate closer integration of SkyView and this kind of interface (WWT, GoogleSky, sky-map.org) in the future. The unprecedented ability to rapidly browse the entire survey nicely complements SkyView’s ability to create precisely tailored images. SkyView’s role as an archive for multi-wavelength survey data remains unparalleled and should be strengthened with the release of our publication interface.

Congratulations to the WWT team.

If you’ve tried the new GALEX survey from the command line, you may have noticed some messages

Warning: Multiple occurrences of key: EPOCH

popping up. Many of the GALEX FITS files have two EPOCH keywords in their headers. Fortunately they both have the same value, so this is innocuous enough. Still the FITS reader gets a bit nervous when it sees this.

It’s a little more embarrassing since the EPOCH keyword is deprecated in FITS. Epoch usually means the time of the observation, but it was explicitly defined to be the epoch of the coordinate system in the original FITS definition. To relieve the confusion this engendered EPOCH was deprecated. We’re supposed to use EQUINOX for the epoch of the coordinate system and DATE-OBS for the epoch of the observatoin.

So having even one EPOCH keyword is bad form much less two!

We’ve updated the astrometry for two DSS plates: XJ643 and XP338. These are at RA,Dec of 180.62,14.74 and 282.84,40.08 in the DSS2 Blue and Red respectively. Thanks to Sergei Goshko at sky-map.org for pointing out the discrepancies.

The GALEX release was accompanied by a few other changes. The one that some users may notice is that for surveys where the data is gzip compressed, SkyView should be a little faster. SkyView was sometimes reading the entire image when it only needed to read the FITS headers.

To support the GALEX survey the image finder code in SkyView was updated. In SkyView an image finder is used to find the input image that should be sampled for each pixel in the output image. A new abstract class RectRecurse encapsulates a basic underlying algorithm which says that if we can find a rectangle in the output image where all of the pixels on the edges of the rectangle should be sampled from the same input image, then we can sample the entire rectangle from that input. This class supports two new settings: MinEdge and MaxRad. The MinEdge setting specifies that input images should not be sampled less than MinEdge pixels from their edges. Similarly MaxRad specifies that they may not be sampled at a distance greater than MaxRad from their centers. Note that the units used are pixels in the input image.

The RectRecurse class is extended by non-abstract classes that define criteria for how to pick the best input image for a single pixel in the output image. Current classes include Border which returns the distance from the edge of the image. This is the default for all but the GALEX survey. ScaledBorder is similar except that it scales the pixel distance by the size of the image. It can be useful if the images in the survey are very different in size. Radius returns essentially the inverse of the distance between the output pixel and the center of the input image. MaxExposure returns the exposure of the input image. That is the default for GALEX (where a MaxRad value is also specified).

When putting these in place a change to the main SkyView class was also made so that the ImageFinder and Mosaicker can be specified in the survey specific settings.

SkyView now includes data from GALEX. This is a major new survey for us. GALEX provides high resolution images in the ultraviolet for about a quarter of the sky. This fills a substantial hole in the resolution/regime coverage for SkyView. The GALEX data are accessed through the Web from MAST. Currently the fourth release of GALEX data (GR4) is being ingested and we will update the survey description to include new data as it becomes available.

By default GALEX uses a different image finder than other surveys. When it needs to choose which input image to sample for a given output pixel, it looks only at images whose center is under some maximum radius from the position of the output pixel and then chooses the one of those with the longest exposure time. The maximum radius is currently set to 0.58 degrees. These settings can be overridden if you use the SkyView-in-a-Jar locally, but are fixed for the Web interface.

A three color image of M81 with Red=DSS2R, Green=GALEX Near, Blue=GALEX Far

In the past week we’ve begun the process of adding the GALEX near and far UV data into SkyView. Assuming we don’t run into unexpected problems it should be available sometime next week. One issue that did come up is that GALEX images are circular not rectangular. Normally when we look for which image to sample at a given pixel we use the candiate source image that we would sample furthest from the edge of the image. That’s the Border image finder. For GALEX a more appropriate choice is to take image whose center is nearest the pixel. There’s a new Radius image finder for that. Since the exposure and characteristics of the observation don’t vary very much within the observed circle, a still better approach would be to find the image where the pixel is within some fiducial radius of the center, but which has the longest exposure. That way we get the best image over the largest field of view. That’s a combination of the Radius and Exposure image finders in the current release. By design it’s very easy to add in an image finder with exactly these characteristics and that’s what we’ll be doing.

You may wonder why this didn’t come up in the much older SkyView ROSAT PSPC surveys — they also have circular images. If we were to build images from the PSPC the same way we do from GALEX, by dynamically combining observations in response to a user request, that’s exactly what would have happened. However SkyView ran through all of the PSPC data and created a set of rectangular tiles that added the exposure from all observations that overlapped the tile. It’s these pre-coadded tiles that are used for the PSPC surveys. An advantage of this approach is that in regions where more than one observation was made, data from multiple tiles is added together. We’ll want to make that possible for GALEX data someday too.