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

Release 3.1.3: SkyView, DS9, Aladin and SAMP

For some while we’ve supported the Virtual Observatory Simple Application Messaging Protocol (SAMP) for SkyView when you are using the jar file. The idea is that you can run a command like:

java -jar skyview.jar position=3c273 survey=dss samp=true

and any SAMP-aware application will be notified about the new image. Such tools include Aladin and the popular DS9 image viewer (and many others). Using SAMP you can pop an image directly into these interfaces. However we weren’t including the SAMP library so you needed to add this into the Java class path to get this to work.

Another thing you had to worry about is that SAMP needs a running SAMP hub. The way SAMP works is that all of the coordinated tasks talk to a single hub task which relays messages as appropriate. Some tools, e.g., Aladin, start up a hub for you so that you don’t need to worry about this, but others, including DS9 do not.

We’ve added the full JSAMP 1.2 JAR (developed by Mark Taylor at Bristol University) inside the SkyView jar to version 3.1.3 of SkyView. That’s pretty much the only change to this version. This not only makes it easier to use the capability — you don’t need to link an outside JAR — it also includes the code for a SAMP hub, so you can use the SkyView jar to start one up for you.

So to push images to Aladin — or any task that starts its own hub — just start Aladin (or other task) and then run SkyView requests.


java -jar Aladin.jar &

java -jar skyview.jar position=3c273 survey=dss
java -jar skvyiew.jar position=3c274 survey=dss

To send data to DS9, we add a command to start up a hub using the JSAMP code included in the SkyView jar:

java -cp skyview.jar org.astrogrid.samp.hub.Hub &
ds9 &

java -jar skyview.jar position=3c273 survey=dss
java -jar skvyiew.jar position=3c274 survey=dss

In both cases the generated images should magically appear in the viewing applications.

In our examples we’ve run the commands in sequence in the same shell, but you can use different windows if you prefer, but they must all be running on the same machine. You should start the Hub before you start DS9. It’s OK to use the second approach with tasks that run their own hub. Hubs’ initialization code checks to see if a hub is already running and they won’t start up if one is found.

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

V3.1.2 released. Fixes to Mellinger survey

Version 3.1.2 of SkyView has been released.

Three bugs all related to the Mellinger optical surveys have been fixed in this latest release. All relate to use of the the Mellinger data. The errors were present only in images of less than 30 degrees and should not have affected all-sky images. Since release 3.0.0 the high resolution data was improperly scaled. Mellinger data is byte-scaled to values from 0-255, but values > 127 had 256 subtracted from them, so the high values were showing up as negative values. Since June 2012 the red and blue Mellinger high resolution data were transposed. Finally, due to a formatting error in the survey description file, users could not use the default values for the size (in degrees) of the field of view. The query failed without producing any image. Any queries which specified a field of larger than 30 degrees on a size should not have been affected by these problems.

We apologize for the errors which should have been caught by our regression tests — these have been updated. Many thanks for Ignacio Cisneros for graciously but persistently pointing out the problems.

Posted in Notices, releases | Tagged , , | 2 Comments