V3.1.10: WISE now uses All-WISE data

We’re getting ready to release the next version of SkyView. The only significant change is an update to the WISE datasets which will now point to the All-WISE data release. This provides significantly deeper coverage in some areas and bands but is structurally similar to the previous data sets. Since we’ll be building up the All-WISE data available in our caches, WISE retrievals may be a little slower on average for a while since the base images will more frequently need to be downloaded from the IRSA archive. To access the All-WISE data from the SkyView-in-a-Jar you will need to download the latest jar file.

We’ll be making this the default release shortly (within the day), but if you can’t want you can get the the new release as: http://skyview.gsfc.nasa.gov/v3.1.10

For more information on the All-WISE data see this summary at IRSA.

If you have any questions or concerns or suggestions for new surveys please let us know.

Posted in Discussion, releases | Tagged , | 2 Comments

SkyView v3.1.8 with GALEX DR7 released.

A new version of SkyView, v3.1.8, has been installed as the default version. The significant change from the user perspective is that the GALEX DR7 is included. New data is mostly in the NUV. To access these data through SkyView-in-a-Jar you will need to download a new copy of the jar file.

Posted in Announce, Notices | Tagged , | Leave a comment

GALEX DR7 in SkyView

We’re testing out a new version of SkyView where we’ve upgraded the GALEX survey to include more GR7 data. There are a few minor internal changes. Most of the new data is for the NUV. When we release this survey we will probably clean out the cache of GALEX data at the SkyView site and start repopulating it with the latest files from MAST. Some of the tile files may have been updated since we last downloaded them. This may slightly slow down generation of images as we build the cache back up.

If you wish to try the new release, start at the URL


Let us know if you have any problems — or suggestions for additional changes.

Posted in Notices | Tagged , | Leave a comment

Looking for Moving Targets? Try SkyMorph

One of the restrictions on SkyView is that you need to specify a fixed position in the sky to look at. For many years the SkyView machine has hosted a companion service, SkyMorph, that allows you to look for many moving targets: asteroids, comets and some planets. It uses the Horizons service at JPL to get the position of the moving target as a function of time and then uses the epoch of various observations to find which fields of view might include the object. The primary set of observations available in SkyMorph are data from the Near Earth Asteroid Tracking (NEAT) project which has about 700,000 images of the sky. DSS and other datasets are also available. Since the NEAT project looked at some areas of the sky dozens of times, the data can also be used to look for transients or high proper motion objects.

In the next year or so SkyMorph will be leaving the SkyView host and moving to JPL. You can access SkyMorph through its ‘classic’ interface, or try the new service at JPL which is now available as an early beta version.

Posted in Discussion, Notices | Tagged , , , | Leave a comment

SkyView and SkyMorph Problems 8/24/2014

SkyView‘s disk area for user-generated images filled up on the morning of August 24 (EDT) and the problem was not corrected until about 9 AM on August 25. SkyView and SkyMorph requests during that time failed. We apologize for any inconvenience to our users.

Posted in Notices | Tagged , | Leave a comment

Babylon’s Legacy: Converting Decimal to Sexagesimal

It’s usually convenient to store and process angles and times in some simple decimal value, but we often wish to display them in a conventional sexagesimal notation or allow users to enter values that way. So we need to be able to convert from 10.3 degrees to 10d 18′ 00″ or vice versa. There are a fair number of subtleties that lead to gotchas in naive code that performs these kinds of conversions.

First lets consider transformation from sexagesimal to decimal. Seems like it should be straightforward: We just parse three integers d, m and s and
dec = d+m/60 + s/3600.

Great. But what about -10 30 30. That addition doesn’t work right. We need to make the minutes and seconds add to the magnitude of the degrees. How about

dec = abs(d) + m/60 + s/3600;
if (d < 0) dec = -dec;

That handles everything fine doesn't it? Not quite. What about -00 30 30? Typically -00 will be read the same as 0 so as soon as we naively converted the first string to integer we made an error. The code will misrepresent positions just south of the equator. I've done this myself and seen it in the wild more than once. To handle these values we need to explicitly look for the sign and if we find a - sign then invert the sign of our result. This is a really easy bug to miss since it only affects a small fraction of the sky.

So we need something like

sign = 1;
if (the coordinate string starts with a -) sign = -1;
dec = sign*(abs(d) + m/60 + s/3600);

to handle everything properly.

Any issues going the other way, converting from decimal to sexagesimal?

There are a few. There's the obvious counterpart to the the one we just handled.
E.g., if we have an input declination of -0.5, then trying
d = int(dec)
m = 60*int(dec-d)

isn't going to work. The variable d is going to be 0 and we've lost the sign. Bad things will happen. What we want to do is print out the sign first and then work on the absolute value
of the input angle.

And there is a more subtle issue that has to do with rounding...

Suppose we are looking at transforming 10.49999 degrees to sexagesimal.
Ok we have 10 degrees.
Next we see .49999*60 = 29.994 so we 29 minutes.
and .994*60 = 59.64 seconds.

So we could represent this as 10d 29' 59.64"

However we often want to format our results to some specified precision. E.g., suppose I want to output my data to arcsecond precision. I could try
10d 29' 59"
but that's silly we should be rounding to the nearest arcsecond. So we need to round up to
10d 29' 60"

Ooops... 60" isn't something I'm supposed to show. I need to go back and increment the arcminutes to get
10d 30' 00"
If the arcminutes had been 59 prior to the increment then I'd need to go back and increment the degrees... This is a bit of a pain but it needs to be done to format the data properly. If you are doing the longitude or right ascension, you may also want to deal with the special case of what happens when you round up to 360 degrees or 24 hours. Do you want to allow both 0H and 24H?

This kind of rounding issue occurs when we convert to decimal too, but it's handled by the language I/O libraries so we don't have to worry about it.

Rather than having code to respond to the increments when they happen we can convert the input value to a scaled integer early on and make sure the increments don't happen.

E.g., suppose we want to show to a precision of 0.1". We take the input angle (we've already dealt with the sign so we can assume it to be positive) and convert to units of the precision we want. E.g.,
decx = floor(36000*dec+0.5);
so we convert degrees to tenths of arcseconds by multiplying by 36000, then add 0.5 to this value and take the largest integer value equal to or less than the result. This process rounds to the nearest integer value corresponding to our input (assuming the input in positive).

Now we can use integer division and modulus operators to get the degrees and minutes and seconds. We'll need to insert the decimal point appropriately if we're displaying at fractions of seconds.

One final issue is what about objects just south of the equator? Do we want to allow both
00 00 00 and -00 00 00
where the second case arises when we've rounded a position south of but with 1/2" of the equator? We can keep them distinct or handle this special case, but we should probably do it consciously!

Posted in Discussion, Documentation | Tagged , | 2 Comments

V3.1.7: SkyView and Google Analytics

Today we will be releasing version 3.1.7 of SkyView. There are no changes to the user code, but the primary pages will now be instrumented so that usage will be tracked through Google Analytics. This implements the NASA general policy that has been linked at the bottom of our home page for some time. If you want to understand what information is recorded please look there for more details. If for some reason you would prefer to disable this tracking there are plug-ins available. You can also simply disable JavaScript. Or you can use the earlier versions of SkyView. As of now only some of the key web pages are being tracked but this will gradually expand to include all documentation, this blog and all image gallery access.

Posted in Discussion, releases | Tagged , | Leave a comment

V3.1.6: RGB Images Bug Fix

The survey descriptions for a number of our surveys (notably including some of the DSS surveys and the IRAS and IRIS surveys) had an error in them that made it impossible to create RGB images if one of the affected surveys was the first of the three images. Basically we used the keyword <Scale> to describe the size of the pixels in the survey metadata rather than <PixelScale>. This misuse conflicted with the use of the <Scale> keyword elsewhere to give the default scale for the survey. In fact the actual value usually represents the same value as <PixelScale>, but it is always given in decimal degrees while the <PixelScale> typically includes non-numeric characters (e.g., a ‘ to indicate arcminutes or ” for arcseconds) that define the units.

We will be releasing Version 3.1.6 with the updated survey descriptions. Our apologies for any problems that users may have run into.

Posted in Discussion, releases | Tagged , | Leave a comment

SkyView 3.1.5: Update to ImageJ library

SkyView uses the ImageJ software library to generate all of the quicklook (JPEG, GIF, TIFF, PNG, …) images it uses. ImageJ is a very powerful public domain package for analyzing and manipulating images. A full implementation of ImageJ is included in the SkyView jar. The last time we updated this was a several years ago when we went to ImageJ version 138k. ImageJ is now at Version 149b, and we thought it was time to catch up.

If you use the SkyView jar directly, you can run ImageJ to analyze SkyView images by just adding the ImageJ setting, e.g.,

java -jar skyview.jar position=3c273 survey=dss imagej

This will start an ImageJ session with your SkyView images loaded in. There are a lot of new capabilities in ImageJ including some for combining images to produce animations that we may use in SkyView or other tools.

The change shouldn’t affect users — unless you’re already using ImageJ as described above. Then you’ll get the benefit of several years of enhancements and upgrades to ImageJ.

Note that the version of ImageJ used in SkyView is very slightly changed from the standard distribution. The most significant change is we enhanced the text plotting capabilities to allow for text at arbitrary angles. We use that for our coordinate and contour gridding.

Posted in releases | Tagged | Leave a comment

SkyView V3.1.4: GALEX update, Memory fix

A user (thanks Steve U!) brought to our attention a problem with the GALEX survey in SkyView. SkyView uses the GALEX archive at MAST and only retrieves files when a user first requests data in a region. We keep files in a cache, so we never request the same file twice. Only about 1/2 of the GALEX GR6 data are cached, so user requests often require us to retrieve data from MAST. It turns out that MAST reprocessed a bit under 1% of the GR6 data after we got the URL locations, which meant that the URLs that we were using to point to the data were out-of-date. If we already had the image in our cache all was copacetic, but an attempt to download an updated file caused a complete failure for that survey.

Version 3.1.4 of SkyView has been released with updated survey description files for the two GALEX surveys and should address this problem. Users of the SkyView-in-a-Jar should download the latest jar if they want to retrieve GALEX data.

In testing this out, I noticed that SkyView was failing due to memory problems when trying to tile together a large number of images. This was due to a failure to deallocate memory when we were using 4-byte reals in the input images. [That was put in recently to allow us to handle larger input images.] That’s fixed too though we haven’t heard of anyone having problems with it.

Posted in Announce, releases | Tagged , | 4 Comments