The biggest change in v3.2.0 of SkyView is that survey description files are no longer part of the SkyView jar. In v3.1.21 we added a small file that retained the mapping between survey names and the description files they referred to. In that version we only used the file to skip reading all of the survey description files — the user only needed to read the survey descriptions for the surveys they were interested in.
In v3.2.0 we took further advantage of this file by adding the information about when the survey description files were created to it. When a user requests a survey, SkyView looks to see if the survey is available as a local file (e.g., as it would be for the web site). If not it checks to see if there is a cached version of the file and if the cached version is newer than the version at the SkyView web site. If so this version is used. Otherwise the file is downloaded from the SkyView web site, placed in the cache and then processing continues. So users will always get have the latest version of the survey to work with.
There remains one possible problem. If a survey updates tile files without changing their names, then SkyView will not be able to tell that the cached data files are out of date. Fortunately most dynamic surveys change the names of the files (e.g., using a version identifier) when they update their tile data.
SkyView-in-a-Jar users will note that the new v3.2.0 SkyView jar is much smaller than the earlier versions, under 4 megabytes compared to over 15 megabytes for v3.1.21. Part of the reason is that the way we access some older surveys has been changed.
The SkyView software can look for survey data in three distinct locales: over the web using URLs, in the local file system using file names, and in the SkyView jar using resource names.
Almost all surveys use URLs. There are two special features for these. First, SkyView can notice that the URL is pointing to data on the local file system. The SkyView web site uses this to translate SkyView URLs to local file references. Second, most URLs are cached. When a user or the SkyView web site asks for a URL from, say, the SDSS, it downloads it only once. The next time that URL is requested it is retrieved from the cache. Skyview-in-a-Jar users will also cache the data from surveys stored on the SkyView machines, since for them those data are not local.
In previous versions a few survey’s data (EGRET, CompTel, nH, 1420 Mhz, 408Mhz, HEA01A2) were actually included in the jar file directly. We’ve now moved these to use URLs as above. Since these will be cached, SkyView-in-a-Jar users will only download the data once. All of these surveys are quite small and we don’t anticipate anyone will really notice the difference. The one exception is that this did allow users to test out SkyView with no network connections. This is still easy to do using the UserSurvey settings. More sophisticated
users can also provide survey description files that point to local data.
A few surveys are still provided as references to files in the local file system. This includes the Mellinger survey where our agreement is that the underlying data will not be directly visible as a URL. The other survey is the GOODSIRAC data. These data are available as URLs but it is difficult to characterize the image WCSs in a way that works with our survey description files. When specifying image URLs SkyView tries to provide enough geometry information in the description to enable the program to decide which candidate images are needed for a mosaic before downloading them. That was hard to do for this survey. As local files rather than URLs, SkyView can always use the WCS in the actual FITS file when looking at their geometry.
Next week we will be releasing version 3.2.0 of SkyView. You can play with it right now if you specify the version v3.2.0 in the SkyView URL, but it’s still being tested. There are several major changes in this release and we’ll be putting out a series of posts describing them in detail. Major changes include:
– Survey description files are now downloaded (and cached) as needed from the SkyView web site. This means that SkyView-in-a-Jar users will no longer need to update the their local copy of the JAR file to take advantage of updates to surveys.
– The SkyView jar used to contain the data for a few smaller generally fairly old surveys. To further reduce the size of the jar, these have been taken out.
– Survey description files now contain a set of fields that give simple, uniform, quantitative information on surveys (frequency, epoch, resolution, sensitivity) in a format easily used by a machine.
– There are new capabilities to extract and display these quantities as CSV downloads or in interactive plots.
We have released a new version of SkyView (V3.1.21) which includes changes in the way we gather meta data for image generation. When we build SkyView we now create a single hash file which associates all survey names and aliases with the appropriate survey descriptions. Thus SkyView only reads the survey descriptions of the surveys the user asks for. Previously it needed to read the beginning of all ~100 files. This seems to save about .2 seconds per image. We have also added a data availability check for AKARI, our new remote survey.
Two new surveys sets have been added to the next release of SkyView (v3.1.20): Four new infrared all-sky surveys taken by the AKARI FIS (wavelengths between 60 and 160 microns) are now available. We have also added the TGSS ADR1 survey, a near all-sky high-resolution survey at 150 MHz (2 meters). Breaking out the acronym this is the [Tata Institute for Fundamental Research (TIFR)] [Giant Metrewave Radio Telescope (GMRT)] Sky Survey First Alternate Data Release. Thanks to Huib Intema for help in adding this survey to SkyView.
These surveys use the VO Simple Image Access protocol to retrieve data from the archive centers at JAXA/JVO and Leiden respectively. Until we build up a local cache of data from popular regions access may be a little slower than it will ultimately be. The TGSS survey uses Lanczos resampling and Sqrt image scaling as a default, but these may be overriden by the user.
We have expanded the display of the infrared and radio surveys a little: breaking out various infrared missions and separating the radio data into GHz and MHz surveys. So there’s a bit of change in the appearance but no surveys should have been deleted.
The release also includes a few internal tweaks and bug fixes that should be invisible to users.
V3.1.20 is anticipated to be released on July 11 but is available now if you use the version explicitly.
If you have any surveys or other capabilities you would like to see added to SkyView please let us know.
We have just released V3.1.19 of SkyView. The only major change is an update to the FIRST survey which incorporates the latest data available at the MAST archive at the Space Telescope Science Institute. There is a bit more coverage and sometimes better processing in the new data. Thanks to Jean Tate for pointing out that our list of FIRST data was out of date.
V3.1.19 also includes a few tweaks to our scripts adapting to new internal locations after our move.
Last week SkyView was updated with new hardware. The SkyView interface should look the same but behind the scenes this update may add a bit more speed to queries but will mostly provide a more robust computing environment, more space for caching query results files and better sharing of processing over multiple hosts.
So far the transition has been smooth. We did discover a couple of obsolete links that may have caused some problems but these should now resolve to current URLs.
We have had a lot of interest in images centered on coordinates 13h 45m 18.2s, -08d 13m 07s recently. SkyView images of this area in the sky using the Infrared Astronomical Satellite (IRAS) survey are often added to the SkyView Image Gallery and we are asked about the unusual artifacts.
It turns out that this image is a sum of observation images taken by the Infrared Astronomical Satellite (IRAS) at times when the planet Saturn was in its field of view. The smearing affect is due to the timing of the different observations that make up the final image.
This artifact was removed in the subsequent IRIS 100: Improved Reprocessing of the IRAS Survey: 100.
There are more of the same image with nice color manipulations at our SkyView Image Gallery at http://skyview.gsfc.nasa.gov/userim…/index/2014-06-15_2.html (scroll down)
Further information: ISSA Explanatory Supplement – the table at the bottom of the page lists the coordinates of IRAS images affected by planets.
We have just released a new version of SkyView which adds the Effelsberg-Bonn HI survey: measuring the HI column density for the entire sky north of -6 declination with unprecedented resolution and sensitivity. Look for the EBHIS survey in the radio regime. This also includes the tweaks to the Lanczos resampler discussed in the previous article. Many thanks to Dr Benjamin Winkel and the survey team for their encouragement in adding this survey to SkyView.
The data currently in SkyView represents only a tiny fraction of the full survey data available. The original survey data measures a wide range of velocities and we hope to ultimately include the full three-dimensional dataset.
Please let us know if you have or know of other data sets that we could include in SkyView.
The Lanczos sampler is a truncated version of the optimal sampling function, sinc(x). The
kernel of this sampler is given as
f(x) = sinc(pi x) sinc(pi x/n) |x| < n
0 |x| >= n
Here x is given in units of pixels and the sinc function is just sin(x)/x. Take a look at Wikipedia for a sense of the function.
Let’s say we want to sample our function at 4.8 when we have measured values, f_n at the integer values of x. If we are using an order 3 Lanczos sampler then the value, m(x) we measure would be
m(4.8) = f_2 f(-2.8) + f_3 f(-1.8) + f_4 f(-0.8) +
f(5) f(0.2) + f(6) f(1.2) + f_7 f(2.2)
This is how we have used the Lanczos sampler since we introduced it into SkyView. A keen-eyed user, Benjamin Winkler, noted that his resampled images using the Lanczos sampler were slightly fainter than the originals on average. It turns out that the Lanczos sampler as given above is not quite normalized. If we integrate f(x) the total integral for n-3 is about 0.997, about 0.3% less than unity.
We have updated the Lanczos sampler to properly normalize the sampler. The correction gets smaller with increasing n.
Since SkyView samples in two directions, the introduced error is actually the square of the value in the table. The renormalized samplers will be installed in the next release of SkyView next week. Fortunately the error of order 1% or less except for the first order Lanczos sampler.
If there are any users who would prefer to use the unnormalized samplers we have added the LanczosNorm setting, but this will only be available to SkyView-in-a-Jar users.
We apologize for this long-standing issue. We greatly appreciate any feedback or concerns you have with SkyView processing.