SkyView Blog

We are working on the capability to enable users to incorporate their own data into SkyView to take advantage of the geometry engine and image processing tools that SkyView offers. User data can be shared in the SkyView-In-A-Jar application and be included on the SKyView Query Form or the user may choose to keep the data private.

The current iteration of the user interface is below. Users have the option to create a new survey or edit a previously submitted survey. At this time data uploaded must be FITS files or compressed archives of FITS files. The simplest upload requires only the survey name and a listing of the files. More survey details can be added in the Optional Information and the Metadata Information sections.

Once a survey has been uploaded and auto-validated users will be able to see their data immediately in SkyView or later by logging in again. If the user has chosen to make the survey public it will appear on the general Query Form after being checked by SkyView staff.

This new feature should be available sometime this summer.

Unless you’re interested in the SkyView internals you probably don’t need to read this one!

None of the changes discussed below will affect how SkyView is called or what it does. If you have been building your own version of SkyView classes or using SkyView Java classes in other applications you may want check to see if this will affect you.

One of the main design goals of the Java-based implementation of SkyView is to enable new capabilities by dynamically loading the major components of the system. So the projections, samplers, and such are all loaded based upon default names or settings the user has specified. Recently I’ve begun rationalizing this, so that the same scheme is used everywhere. Currently in some cases you specify the entire class name (e.g., skyview.process.imagefinder.Exposure). In others you specify a part of the name and it builds up the class, e.g., projection=Ait means load the class skyview.geometry.project.AitProjecter. In still others you can specify the class name and it will look both within a default package and for the class name exactly as you specified it.

In the next release all of these will use this last approach to create the class, calling the method:

Object x  = skyview.util.Utilities.newInstance(String name, String pkg)

This method first looks for the class with the package name prepended to the class and then for the class name alone. Each type of object (projecters, samplers imagefinders, …) has a ‘default’ package, or the user can put them in any package and give the fully qualified class name as the appropriate setting.

The effect of this is that the names of some of the low level classes in SkyView will change. The class skyview.geometry.projecter.AitProjecter becomes skyview.geometry.projecter.Ait. Similarly skyview.geometry.sampler.ClipSampler becomes skyview.geometry.sampler.Clip. The functionality of these classes is unchanged. This eliminates some redundancy from the class names, allows a more uniform handling of errors in the loading of classes, and allows shorter setting values in some cases.

Please let us know if you have questions or concerns about this upcoming change.

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.

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!

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.

Recently we had a query about how SkyView combines data where there is an overlap of plates in the Digitized Sky Survey datasets. The short answer is we don’t, but I thought the longer response might be of general interest.

For [any given pixel on] the DSS (or DSS2) plates, SkyView only ever samples data from a single plate. It never combines data from multiple images. The ‘best’ plate is always selected for each individual pixel, where best is typically defined as the plate where a given pixel is farthest from the edge of the plate (though that can be overridden).

There are a few of reasons for this…

1. Simplicity in the code.

2. Adapting to the different characteristics of multiple plates is non-trivial. Adjacent plates can have very different backgrounds and somewhat different resolutions. These are not necessarily constant over a plate so they would have to be adaptively solved for so that we would know how to deal with edges properly and combine data effectively.

3. The edges of the plates have many gross artifacts (e.g., scans beyond the edges of the emulsions, labels, calibration wedges, etc.). Detecting these is non-trivial and so simply avoiding the edges as much as possible is desirable. There are also a fair number of defects in the interiors of the plates (emulsion flakes, hairs, dust, scratches), and combining plates combines all of the defects.

4. Given the non-linear nature of the plates, analysis of combined data is non-trivial and the increase in sensitivity is at best <~2 in the rare areas where 4 plates overlap (though in that case at least one is likely to be near the edge so that its defects would dominate any small gain). One thing that I have not considered is whether the fact that the images are being regenerated from a lossy compressed image would need to be addressed. I don’t know if anyone has studied that.

SkyView does try to minimize the appearance of edges between DSS plates using a de-edgeing algorithm. SkyView recognizes that the zero point of individual plates are arbitrary. SkyView’s deedging algorithm looks at the edges between each pair of plates and looks at the histogram of jumps between adjacent pixels. It then adds an offset to each image to make the median offset between images 0. The offsets added are given in the associated FITS header. Other algorithms are also available.

Generally this simple algorithm works so long as there are only a few plates involved. When very large numbers of plates are involved, it breaks down. Some kind of relaxation method is probably appropriate there (or possible adding a non-constant backgrounds) but we haven’t adopted any.

Note that for CCD images the arguments against adding plates are much weaker, and we are looking at adding a new mosaicking tools in SkyView that would support image addition. If you have suggestions or comments about how we might do this, I’d be very interested.

This blog is intended to be our primary mechanism for talking with users about what’s happening with SkyView. This includes new features and surveys, issues that other users have encountered, interesting images, SkyView in the news or anything else that catches our fancy. This blog will take the place of our old What’s New page.

We want to go this way for two reasons:

We hope we can get feedback from and engagement with our users. Please feel free to comment on our articles and on other users’ comments. Short or long, we’re really interested in what you have to say. Initially we’ll be moderating the comments due to NASA policy, but your comments should appear quickly. Our real hope is to foster a community of users who can interchange ideas on how to use SkyView and where it can go.

Also, a ‘What’s New’ page tends to describe things that are finished. We want something less formal where we can describe work in progress, problems other users have seen, problems we’re working on, ideas for the future, … and get your feedback as early as we can. We’ll use the tagging and categories features of the blog to distinguish the release notes. We’re hoping to put out at least a few items each week to give you a sense of where things are going.

Again please feel free to join in the discussion. If you have thoughts or suggestions that you’d prefer not to share with the world, or if you’d like to see a particular topic addressed on the blog, we’ll still be listening to E-mail at skyview@skyview.gsfc.nasa.gov.

Regards,

Tom McGlynn
Laura McDonald