Cette page est un draft de la participation CDS au DS4 Study Report.

La version complète du DS4 Study Report sera disponible sur cette page

Designs and Prototype Implementations

Multi-waveband Image Tool

[...]Independently, a number of new features were added to the Aladin Interactive Sky Atlas, as developed in the next section.

Aladin improvements

The following developments have been pushed both by scientific drivers and user requirements.

Improved color image manipulation

• Color images can now be converted to grayscale images, allowing to use features not available on RGB planes, eg computing isocontours, extracting sources, etc.

• Color images can also be saved as FITS files, thus preserving astrometry (WCS) information. The convention adopted in the generated FITS is to use the following key/value pairs : NAXIS=3, CTYPE3='RGB'. Ihis is compatible with DS9, meaning that color images created and saved in Aladin as RGB FITS can be reopened in DS9, and vice versa.

3D data access and manipulation

Support of data cubes and MEF (Multi FITS Extension) has been added to Aladin. This feature has been tested in collaboration with ESO and CADC (Daniel Durand) with CGPS and SINFONI cubes.

Some basic cube manipulation have been developped :

• once loaded, each slice of the cube is displayed as an animation. The user can choose to pause the animation, and go to a specific frame.
• the cube plane acts as a regular Aladin plane : contrast can be adjusted for the whole cube, objects from tables can be overlaid.
• when tagging a given position of the cube, Aladin builds and displays the spectrum corresponding to the pixel value of each slice at the chosen position.

On this screenshot, Aladin displays a slice of a loaded data cube. Click on the thumbnail to visualize how Aladin displays the cube as an animation.

Clicking on a given position generates the corresponding spectrum, displayed in the small view at the bottom right of the window. The current position in the cube is shown by the red bar.

Instrument footprint visualization

Aladin is a testbed for the instrument footprint standard (see section IVOA Note: Footprint Overlay Specification) : it allows to load user-defined description of instrumental footprints, to display and overlay them on top of images. The early implementation of this emerging standard allowed to provide useful feedback which led to some updating and refining of the format.

This development has been performed with 2 use cases in mind :

• preparation of telescope observation proposals. In this case, footprints can be moved, rotated, and the position and roll angle can be easily retrieved.
• visualization of the coverage of a set of observations (coming from instance from a SIAP service)

In this example, Aladin displays the footprint of the Subaru Suprime instrument (in red) as well as the footprint of the Hubble Space Telescope on top of a SDSS background image.

The properties window of a footprint plane allows to retrieve the current position angle and the roll angle. The user can also choose which parts of the footprint he wants to hide/show.

When visualizing the coverage of a set of observations, displaying translucent footprints proves to be quite useful as it gives a visual indication of which regions have been observed most.

All those improvements are already available in current version of Aladin or will be available soon in a next release.

WCS Augmented Graphics

Usual graphics formats as JPEG, PNG or GIF appear as quite interesting for data publishers as they allow to deliver lightweight color images, sufficient for quick-look or preview visualization. But they lack a metadata container mechanism able to store WCS information, crucial in astronomy since allowing to link a (x,y) position on the image to a (alpha,delta) position on the sky. We have studied 2 approaches allowing to associate the WCS info with those images.

SIA response with WCS for Graphic Files

The idea is to carry the WCS information in the SIAP query response. Here is a list of the needed FIELDs and the corresponding FITS WCS keyword :

ucd="VOX:WCS_CoordRefPixel"               CRPIX
ucd="VOX:WCS_CoordRefValue"               CRVAL
ucd="VOX:WCS_WCS_CDMatrix"                [CD matrix values]
ucd="VOX:WCS_Image_Naxis"                 NAXIS
ucd="VOX:WCS_CoordProjection"             [projection type]
ucd="VOX:STC_CoordEquinox"                
ucd="VOX:STC_CoordRefFrame"

Then, when an image is loaded, the client can easily build the astrometry from the value of those fields. A trial implementation has been developped by CDS and ESO : ESO has built a prototype SIA service delivering images along with their WCS information, and CDS updated Aladin so that it can consume this service.

This solution will work with any image format, as long as it is supported by the client.
Drawback : WCS information is separated from the data file.

Graphic files with embedded WCS

In order to keep the astrometry information in the same file as the data, we tried to integrate FITS keywords and values directly in the comment field of JPEG files. It has been successfully implemented and validated in the Aladin image server (able to produce JPEG files with embedded WCS) and in the Aladin client (able to consume such files).
This development is compatible with SDSS initiative to deliver JPEG images with WCS information. In other words, Aladin reads and supports WCS information coming with SDSS JPEG files.

Positional Cross Matcher

In VO era, being able to cross-identify objects coming from different data sources has become a crucial topic, as it allows to merge multi-wavelength information. The community is demanding for cross-matching facilities and several developments have been achieved in the DS4 frame.

Improved cross-matcher in Aladin

The cross-match tool available in Aladin, initially developed for the AVO demo, has been improved to take into account error ellipses, ie uncertainty on positions.

In this screenshot, we display the position uncertainty ellipses for the two catalogues to be cross-identified.

In this window, the user specifies for each catalogue : columns holding the position (right ascension and declination) columns holding the uncertainty ellipse major axis columns holding the uncertainty ellipse minor axis columns holding the uncertainty ellipse position angle In most cases, if the tables came with sufficient metadata, those informations are already correctly picked, on the basis of UCDs. Eventually, the user enters, as a number of sigmas, the minimum and maximum threshold to be used for the computation.

The user also has the ability to specify which columns he wants to keep in the cross-match ouput.

As a result, a new catalogue plane is created, with all kept columns from the first table, all kept columns from the second table, and with the computed number of sigmas.

Asynchronous REST cross-match service

In order to let external tools or services perform positional cross-match, we have developed a prototype REST cross-match service, based on the cross-matching algorithm used in Aladin. It allows positional cross-match of any 2 VOTables available through a URL, and follows recommendations of the first UWS for REST document.
As we want to potentially cross-match large tables, the asynchronous nature of the service is essential. Here is an overview of how a user initiates a cross-match computation and retrieve its results :

• POSTing VOTable URLs and xmatch parameters to xmatch/jobs will initiate a new cross-match task. The user gets back a job identifier.
• This identifier can then be used to query the service (GET request to xmatch/jobs/<job-id>) in order to get the status of the job (running/failed/completed)
• When the status of the job is set to completed, the result can be retrieved by a GET request to xmatch/jobs/<job-id>/result

Future development plans include the distribution of the cross-match task on a cluster of PCs, thus improving its scalability.

Positional index for VizieR

The design of a positional index on several thousand source (VizieR) catalogues started. Such an index will enable more powerful and efficient positional operations, and will notably allow :

• Fast search by position
• Fast cross-match between any 2 VizieR catalogues
• Easy creation of density maps for any catalogue with position

Current VizieR architecture

The VizieR database is made of 12,500 tables, half of them having coordinates on the sky for a total of more than 5 billion positional informations.
Tables with sky position are organized in 2 parts :

• tables with less than 10 million rows are stored in a relational database (Sybase or PostgreSQL)
• larger tables are stored as Unix binary files associated to a specific search program

With the current index architecture, the query "give ALL sources in any of the 5300 tables around a position" is a 2 steps process:

• Query the index to get the list of tables with potential matches
• Query each table to retrieve the sources around the position

If many tables are to be queried, the whole query might become slow.

New positional index design

In the new positional index scheme, full-precision positions of all catalogues will be merged and stored in a single dataset whose approximated size is circa 100 GB. Along with the positions, this index will only store the corresponding position accuracy of the table.

Indexing will be performed using Qbox, a hierarchical partitioning scheme allowing to split the celestial sphere into Qbox cells.

The main difficulty will be the maintenance of the index. As the re-creation of the whole index is a slow process, the index will most likely stand in a centralized place instead of being recreated on every VizieR mirror.

The first implementation of this index is planned for VOTech stage 5 (march-september 2007).

Summarize other work on cross matching capabilities ...

Interoperability between tools

Interoperability between tools is another key topic. This includes not only interaction between VO tools themselves, but also interaction between VO tools and legacy softwares, as IDL, MIRAF, AIPS, etc. The latter is a real challenge as it will allow astronomers to access and use VO services from their everyday tools. The following sections relate CDS effort on the topic of interoperability between Aladin and some other tools.

PLASTIC-compatible Aladin

Aladin developers have been part of the development of the PLASTIC protocol, and Aladin has been one of the first application being PLASTIC compatible.

Supporting PLASTIC allows Aladin to interact with other PLASTIC-compatible tools, and extends its capabilities. In this example, the same set of points has been cross-selected in Aladin, TOPCAT and VisIVO, enabling exploration of data from different perspectives.

For more information about motivations and lessons learnt from PLASTIC integration in Aladin, please refer to section 5.4.4.2 of the DS6 Study Report

IDL library to control Aladin

IDL (Interactive Data Language) is a data analysis package widely used in the astronomical community. Some astronomers have expressed the need for being able to use Aladin features from their IDL scripts. To fulfill this request, we have developed a set of IDL functions allowing to control Aladin. This library relies on IDL Java Bridge, a mechanism allowing to call Java methods from IDL. It allows to perform the following operations :

• launch Aladin
• load a table in Aladin from a set of IDL variables
• load an image in Aladin
• retrieve an Aladin image plane as IDL variables
• retrieve table values from an Aladin catalogue plane
• select some objects in Aladin
• retrieve pixel value at a given position
• modify Aladin color table
• set the reticle at a given position on the sky

Full documentation and installation instructions are available on this page.
A Flash tutorial is also available.

Plugin mechanism in Aladin

Since version 4, Aladin can be extended by plugins written by external developers. A set of methods allowing to access and manipulate Aladin internal objects is provided.

Gains from this modular approach are multiple :

• Simplicity : Developers can easily develop their own Aladin extensions for their own purposes without having to interact with Aladin developers
• Robustness : Aladin core code stays untouched, and is not bloated by external developments
• Flexibility : Users choose to install only plugins of their interest

Here is plugin example. Called "Aladin workflow builder", it is based on the JLOW library and allows to build and execute a sequence of script commands from a graphical interface, just by dragging and dropping some boxes (representing tasks) and linking them together.

Details about development and installation of a new plugin are available on Aladin plugins page.

-- ThomasBoch - 23 May 2007