Reference Coordinates in Fixed Projections

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.

Posted in Documentation | Tagged , , | Leave a comment

Smoothing bug

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.

Posted in Notices | Tagged , | Leave a comment

DSS question

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.

Posted in Discussion | Tagged | Leave a comment

Welcome to the new SkyView Blog!

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

Posted in Discussion, Notices | 4 Comments