SkyView Blog

Included in the skyview.util package are two simple utilities that find the coordinate of a pixel in the image or the pixel corresponding to given coordinates. You can use them as:

java -cp skyview.jar skyview.util.CoordsPixel filename.fits 10.3 11.4

to find the pixel in filename.fits that is at coordinates 10.3, 11.4 (in the coordinate system used in the image) or

java -cp skyview.jar skyview.util.PixelCoords filename.fits 512 512

to find the coordinates for a given pixel (using Java counting where pixels begin at 0,0).

One of the major functions of SkyView is mosaicking multiple images together. Occasionally you may be interested in finding out which source image was used for a given pixel. The FITS header indicates which images were used somewhere, but normally that’s all the information you can get.

Recently we added a new class skyview.process.IDMosaic. You can use this class to get exact pixel source information when using SkyView (in local mode). To any request add the setting mosaicker=skyview.process.IDMosaic. This will generate an output FITS file where each pixel is the index of the image used to create it. You can compare this file with the file generated using the normal mosaicker to understand exactly how your image was generated.

A new survey including seven bands of data from the ROSAT All Sky Survey data has been added to SkyView. The RASS Background 1-7 data show the entire sky in diffuse X-ray emission. Point sources have been subtracted out. This new survey replaces the RASS 1/4, RASS 3/4 and RASS 1.5 KeV maps. Those data are still available but we no longer display the survey names on the Web page. You can still access them through the batch interfaces or using the Jar file. The new data sets have better spatial and energy resolution and were built by the Steve Snowden who also created the earlier maps.

This afternoon we released the new Jar version 2.4 of SkyView. There have been a lot of incremental changes since our original release of 2.3. Today’s release includes new or enhanced support for 3 projections (Arc, Stg and Sfl) and has support for two new surveys that should be coming on line in the next few days. There are a number of bug fixes (e.g., see the recent post on Smoothing), and our new RefCoords setting which allows fixed projections to be centered anywhere on the sky. This capability was added in response to a user request. So please let us know if there’s something you need!

A new version of the SkyView User’s Guide and a new set of the JavaDoc’s documenting the classes has also been released.

New features and surveys should be showing up in our on-line version later this week.

SkyView treats a number of projections (Aitoff, Cartesian, Sansom-Flamsteed/Sinusoidal) as fixed projections. Regardless of the position you specify, the sky is projected to the plane in the same way. All that your coordinate entry changes is the center of the image you get. Thus if you ask for an image near the pole in a Cartesian projection, you’ll find that there’s a large distortion since you are near a singularity in the projection. By contrast, projections like the Tangent and Sine projections are centered at the position you specify: that’s the point of minimum distortion.

If you wanted to make an Aitoff or Cartesian map really centered on some point other than the coordinate origin, older versions of SkyView couldn’t help you. With the version we’re releasing today, you can specify the new RefCoords setting. It takes a pair of decimal coordinates and uses that as the coordinate center for fixed projections. E.g., use RefCoords=0.,90. Position=0.,90. projection=Ait to ask for an Aitoff projection centered around the pole. Note that you still need to specify a position.

The smoothing algorithm has a problem: It propogates NaNs to the right. A new version of SkyView with this fixed will be released on April 29.

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