SkyView Blog

Every now and then we receive emails from SkyView users reporting problems running the SkyView-in-a-Jar application (skyview.jar) on a local machine. Most of the time the problems are due to a mismatched version of java being used to run the command. When the wrong version of the java is used the error message typically includes the following error:

Exception in thread “main” java.lang.UnsupportedClassVersionError: Bad version number in .class file

We currently have two versions of skyview.jar, one for Java 1.6 (Java SE 6) and one for Java 1.5 (Java SE 5). If you are not sure which file to download you can determine the java version from the Linux/Unix/OS X command line on your local machine by running:

java -version

Another problem a couple of users have encountered involves the use of gij, the GNU Interpreter for Java. At this time there seems to be an incompatibility between gij and the Skyview-in-a-Jar application. We are looking into this and hopefully will have this problem fixed soon. In the meantime it is advised that users install or switch to the java interpreter provided by Sun Microsystems.

As always, if you questions about any aspect of SkyView please contact us.

The image from 2009-04-20 01:54:28 shows a typical IRAS 100 micron image:

There’s a very detectable pattern of lines crossing the image from top left to bottom right. These are remnants of the scan lines used in taking the data. The team that built the IRIS survey, headed by Marc-Antoine Miville-Deschênes and Guilaine Lagache reprocessed the data to — among other things — get rid of, or at least minimize, these scan lines. If we simply choose the IRIS100 survey with identical parameters we get the image below. The scan lines are completely gone. That’s why it’s IRIS: the ‘Improved’ Reprocessing of the IRAS Survey. Nice job guys!

This image from 2009-04-27 22:10:22 seems to show a lot of disks in the sky. What’s going on here?

The image is taken from the ROSAT pointed observations. The ROSAT mission comprised two phases. In an initial phase the satellite scanned the entire sky producing the data SkyView shows in the RASS surveys. After the all-sky survey was done, ROSAT made much deeper observations of particular points in the sky. Each observation looked at a circle roughly a degree in radius. These observations are the source for the ROSAT PSPC surveys in SkyView. We took all of the observations and added them up to create all sky tiles. Only about 20% of the sky was covered in total, so a very large scale image, like this one, shows the observations as little disks in the black, unobserved, background.

The GALEX survey is very similar, though the overall sky coverage is substantially higher. However while we created a set of static tiles for ROSAT, with GALEX we add the observations together dynamically when the user makes a request. A big part of the reason is that computers have gotten much faster in the 10 or so years since we built the ROSAT surveys, so its much more feasible to do this kind of dynamic addition of data today.

SkyView development has been slowed by a concentration on some other work at the HEASARC, notably a new version of our main archive interface. However next week we’ll be releasing a new version which includes the HEALPix and WMAP data that we’d talked about a few months ago. SkyView development may be relatively light for the next few months.

One of astronomy’s primary links to the past are the constellations. We’ve just added a set of overlay files that you can use with SkyView’s standalone package to draw constellation boundaries over an image. You can download individual constellation files, or download a tar file containing all of the constellation files. A constellation overlay can be drawn over all an image using settings like

java -jar skyview.jar position=0.,0. drawfile=all.bound survey=408mhz size=100 pixels=800

The image this produces is

The constellation boundaries used are derived from the official IAU constellation boundaries. However there are a couple of caveats. The constellation boundaries are defined in terms of corners in 1875 coordinates, i.e., only the 1875 declination or 1875 right ascension varies between two consecutive corners. SkyView transforms these corner positions to the user’s requested projection and then draws straight lines between the points. Unless the user has requested B1875 coordinates in a Cartesian projection, it’s unlikely that SkyView will match the precise boundaries. However if you are looking at an image at a scale large enough to see constellations, then discrepancies are likely smaller than the width of the borders.

Another problem can arise in projections that can tile (e.g., the Cartesian projection). E.g., if we are making an image centered at 0,0 then constellations spanning RA=180 degrees will have lines that are supposed to leave the left edge of the image and return on the right. Howver SkyView’s overlay drawer simply joins the two corners with a line the runs through the middle. Using non-tiling projections (like Tan on Sin) or only including constellations within 90 degrees of the center of the image will usually take care of this.

The Clip sampler is useful when users want to exactly preserve flux or to significantly undersample the data. Basically you can think of it as overlaying the new coordinate pixel grid on top of the old pixel grid and integrating over the new pixel boundaries assuming flux is uniformly distributed within each of the old pixels.

An area where the Clip sampler can have problems is in very low resolution surveys when a single input image covers the entire sky. E.g., suppose we have a survey (say, HEAO1A) whose input data is a single Cartesian image centered at 0,0. A user wants to generate an output image centered at 180,0. If the output image has 1 degree pixels, then the corners of its central pixel would be at the coordinates

179.5,-0.5 180.5,-0.5 180.5,0.5 and 179.5,0.5

While these are close together on the sphere, they will probably get projected to opposite sides of the input image — two on the far right and two to the far left.

The old version of the clipping sampler doesn’t handle this case properly. It sees a pixel that contains almost all of the equator.

A similar problem occurs when the input image is not convex. E.g., in the COBE maps the input image covers a sideways T in the projection plane. When we sample this image, the output pixel corners may project to a quadrilateral that contains area that’s outside of the valid region of the projection.

An updated version of the Clip sampler included with version 2.6 of SkyView begins to address these. Each input pixel that is included in the output will be checked to ensure that it is a valid pixel. Pixels that wrap around should also be handled for all of low resolution surveys that we have. Basically we assume that the user doesn’t want pixels > 240 degrees on a side and treat pixels that seem to be so large specially.

There are issues with the topology of the new TOAST and TEA projections that could cause problems if input surveys were stored in these projections, but since we have no such surveys, this is a moot point for the moment.

The new version of the sampler will also ignore any pixel in which one of the corners of the output image has coordinates that include a NaN. For example, if the output image is a large scale Sine projection, then one might see NaN data values at the edge of the circular valid region of the projection. This will now be 0.

We’ll probably include both the old and new Clip samplers in the initial releases of V2.6, but only the new sampler is likely to be available through the web page.

Occasionally we go back and take a look at where people have asked for images from SkyView. The following image gives the distribution of SkyView requests as a simple Cartesian (RA,Dec) map. The Galactic plane is very prominent, and even the Ecliptic shows up as an enhancement (even though SkyView has no solar system objects). The Magellenic clouds and M31 and many other prominent targets are clearly delineated. There remains a lot of structure whose origin is quite unclear.

This represents about 2.5 million requests since the June 2007. Requests for images in fixed projections (Aitoff, Cartesian, and TOAST) are not included since what we record are the CRVALn entries in the FITS files, and it is precisely these values that are fixed in those projections.

For some while we have been looking at how to put the data from the Wilkinson Microwave Anistropy Probe (WMAP) into SkyView. The WMAP data are central to our current understanding of cosmology. However WMAP images are generally stored in a the HEALPix format. HEALPix is a recursive projection where each pixel has equal area, and pixels are arranged in rings of constant latitude. This is illustratedin the image below

Pixels are successively refined with each pixel dividing into four subpixels. The pixels are normally stored as a linear array of pixels using one of two standard orders — not as an image.

Since HEALPix didn’t seem to be a normal projection, we’d held off supporting it. The original Gorski paper does suggest that you can represent the HEALPix data in a projection plane. However the HEALPix pixels are diamonds, not rectangles — and that doesn’t fit in with how we store images.

Recently we realized that by thinking just slightly outside the box, we can get around this and treat HEALPix as a standard projection. Although the HEALPix pixels normally look like:

in the plane where the equator runs horizontally, we’re not restricted to that. If we use a projection plane rotated by 45 degrees then those same HEALPix pixels look like

In this frame the pixels are perfectly normal, so SkyView can treat HEALPix just like any other projection. SkyView doesn’t care that the equator isn’t horizontal!

In practice we still do some special handling of the HEALPix data. To use our existing code we would have to reformat HEALPix-formatted FITS files as more standard images in the rotated HEALPix frame. Instead we choose to use the original format and use a new HealPixImage class. This makes a HEALPix file look like a regular image to the rest of SkyView. We’re in the process of testing the WMAP data and the HEALPix projection but they should be showing up in the released version of SkyView shortly.

[Added:] A paper by Mark Calabretta and B.F. Roukema discusses this in much more detail and in a more general context of HEALPix like projections. I’ve read this paper in the past, so it’s not unlikely that it’s ultimately where the I got the idea as well.

This image from 2008-12-10 09:39:28 is pretty interesting…

It looks like we are seeing some very special object with rings around it. What’s going on here?

This is a COMPTEL image, one of the lowest resolution surveys we have in SkyView. It’s taken in the hard X-ray/Soft gamma ray regime where it’s very difficult to build an imaging detector at all. The method used requires a complex deconvolution and yields at best a resolution of a few degrees. So the pixels are very large and the image would - absent distortions - cover almost the entire sky. However, you can’t project such a large region of the sky onto a single plane image without very large distortions. In fact the default projection that SkyView uses, the Tangent plane or Gnomonic projection, only shows half the sky no matter how big we make our image. The great circle 90 degrees from the center of the field of view is off at infinity. It’s rather like the way Mercator maps get enormously distorted as you near the poles — and even so you can never quite get there.

The middle of the image is reasonable enough, but as we approach the edges pixels are being stretched out in a radially symmetric pattern.

Another projection can show the whole sky in a more understandable fashion. One might try an Aitoff or Cartesian projection if you know that you want to see the entire sky. However if you want to make sure that a given point is at the center of the map, then something like the ZEA (for Zenithal Equal Area) projection might be nice. Here we’ve redone the picture in that projection:

The entire sky is shown here with the point opposite the requested center forming an infinitesimally thin ring around the image. So it is still distorted, but in a way that doesn’t obscure the global features as much. Every pixel represents the same area in the sky. The plane of our Galaxy shows up clearly as a circle of enhanced emission and the bright spot is the Crab nebula.

The lesson here is that you need to adapt your projection to the application. Some projections, e.g., the Tangent or Sine projections just won’t do very well for large fields of view. Others, e.g., the Cartesian projection near the pole, can be a poor choice when looking at a particular small region of the sky.

This image from 2008-12-06 15:57:53

shows a very interesting feature that looks like a giant worm squirming amongst the stars. In fact it’s actually a tiny hair that got on the photographic plate sometime in the process of taking, developing or scanning the image.

How can we tell that this isn’t Nobel-Prize-winning stuff? The obvious giveaway is how thin the feature is. The stars in the image are point sources blurred by optical limits, telescope jitter, and especially seeing. Any real astronomical source can be no sharper than they. Our worm is much thinner.

Hairs and dust show up occasionally on all of the surveys scanned from optical plates.