WWT & VO (was NG of GS & BO standards for JPEG with WCS)
dtody at nrao.edu
Thu Jan 17 13:52:52 PST 2008
Hi All -
Certainly, for interactive visualization of full sky data, a
service such as WWT and gSky provide which precomputes graphics
tiles at multiple resolutions covering wide areas, is needed.
This is different from the usual science data analysis case where
we are accessing individual science-grade datasets, where minimal
processing of the original data is desired.
Regarding open access to such graphical data, rather than invent a
new proprietary protocol, there are a couple of existing protocols
which should be considered, which could be used as-is or extended.
One is the OpenGIS Web Map Service (WMS), which is designed for rapid
remote visualization of graphical data. With the addition of some
astronomy oriented projections this could work well for graphical
data from astronomy. Unlike SIA, WMS does not require a prior query
for data access, and instead allows direct access at the pixel level
to seamless, wide area graphical imagery.
The second option would be to support SIA as an optional service
interface for accessing graphical data from services such as gSky
or WWT. Although SIA is not ideal for this purpose, it does support
access to graphical data (JPEG etc.), including precision cutouts or
client-specified precision reprojection. It also includes provision
for returning a WCS along with the graphics image. For a fast graphics
server such as WWT/gSky, access could be plenty fast enough for
astronomical client apps that just want fast access to the graphical
data (especially in the case of SIA V2.0 where we can provide more
direct support for this if required).
On Thu, 17 Jan 2008, Jonathan Fay wrote:
> As far as WWT we are planning to document all our data access interfaces, and open them up some time after we go live pending legal review.
> We have a cutout service, a high-speed tile service, and a reprojection/compositing service that are currently used internal to WWT that may be opened up as the interfaces stabilize and we confirm the legal status on the data to be served.
> The reason they exist, rather than hit the VO sources directly is they are highly tuned for large scale visualization across the sky. No current VO service is designed to service that need, so it was necessary for us to implement that service, as well as a new projection to allow full 3d sky access efficiently without singularities. The full sky tile sets are meant to be reprojected with 3d hardware, a software reprojection is necessary for integration of them into 2d imaging applications, thus our cutout and reprojection service.
> It may take a while for external access to get rolling on this given the new projections, but the cutout server one it is released should be useful for applications fairly quickly as in gives a TAN projection back as JPEG or PNG image, and won't require reprojection for display.
> Most of this data is sourced from VO sites thru the VO interfaces, but we reproject and tile as necessary to make it scale well. For instance Hubble publishes press release images thru a SIA query and VO Table. Some of which are 16k x 16k and over half a gigabyte. These images are beautiful, but too large for public download. They must be turned into tiled multi-res pyramids to be served on mass scale efficiently. Other VO services had full sky data, but the data must be projected into a tiles multi-res mosaic for visualization. That operation is not real-time friendly, but once that work has been done the result is a useful service that should (and will be) made available to others to use.
> Related to your other question is that WWT will also natively open AVM encoded images (currently a IVOA note) and display them directly in the sky. The last details of V1.1 of the proposed standard were hashed out at a meeting at AAS last week. Spitzer, Chandra and Hubble images are all going to be encoded with AVM, and many already are.
> WWT Pro, that we are co-developing with Harvard IIC/CFA will be a very rich VO client for interacting with VO images, catalogs, footprints, events, etc. While it is entirely possible to have all this functionality in the wide release version of WWT, we don't want to overload the existing VO infrastructure.
> Jonathan Fay
> Principal Research Software Design Engineer
> WorldWide Telescope
> Microsoft Research
> -----Original Message-----
> From: owner-interop at eso.org [mailto:owner-interop at eso.org] On Behalf Of Pierre Fernique
> Sent: Thursday, January 17, 2008 12:17 AM
> To: interop at ivoa.net
> Subject: Re: next generation of Sky in Google Earth
> Dear VO members,
> I would like to bring the discussion to another point related to the VO
> and Google Sky/WWT.
> I would like to ask to Google sky team and Microsoft WWT team if it is
> possible to create my own client accessing their image data base. For
> instance, if I want to add a dedicated Aladin layer displaying the HTM
> sky background images from Microsoft data base, or the sector base sky
> background images from Google, could I ? 1) Is there open standards for
> that and I can develop my own client ? 2) Could I have to plug a kind of
> proprietary libraries in Aladin ? 3) Or perhaps it is not possible at
> all (technically ? strategically ? no documented ?) Obviously, the first
> solution will be the best for my VO point of view.
> I really appreciate to offer to Aladin users these astronomical data.
> Exactly in a symetric way that WWT and Google Sky use Simbad opened
> standards (object resolver, ...), or VizieR catalog access, and other VO
> Pierre Fernique
More information about the interop