Feedbacks about AVM tags in Aladin
jfay at microsoft.com
Tue Nov 25 08:42:57 PST 2008
AVM is about communicating astronomy to the *public*.
While Adobe created XMP, Mac OSX, iPhoto, Vista, Windows Photo Gallery and many other tools that the *public* and press uses can *read* XMP.
The read to write ratio is very high on public images. Many more people will be reading the images, than creating them. A heavier burden our writers can be sustained than for readers. The public won't know how to read (and won't care much about) FITS headers embedded in the image.
The tags for positioning on the Sky are important when they are viewed in the sky, but capturing the description, subject matter, credits and so forth in a way that can be easily read by the end user (and indexed by search engines) is the key thing that makes AVM elegant in its approach.
The information that comes from the FITS headers is a small fraction of what is carried in AVM, and the fields that are most meaningful to the public are readable because they are stored where the image viewing software expects them to be. The astronomy specific data is stored in a extensible schema that is still viewable by these tools.
As far as being dependent on a commercial software developer, the vast majority of the public is very dependent on commercial software companies for their O/S and Apps, and the commercial developers are far more likely to continue support for the broad public oriented standards such as XMP. It is not going away soon.
XMP is well supported for public reading. Once we have open source AVM writing available we won't be reliant on any commercial SDK or tool for writing the Tags.
From: Frederic V. Hessman [mailto:Hessman at Astro.physik.Uni-Goettingen.DE]
Sent: Tuesday, November 25, 2008 2:26 AM
To: Jonathan Fay; agauthier at as.arizona.edu; Pierre Fernique
Cc: Interop IVOA; IVOA semantics
Subject: Re: Feedbacks about AVM tags in Aladin
There is now an alternative to XMP and hence a way to avoid the
dependence on Adobe - indeed maintaining compatibility with the rest
of the IVOA and the semantic web: SKOS, expected to become the
official W3C recommendation for these kinds of things next month. See
the proposed IVOA recommendation "Vocabularies in the Virtual
Observatory (version 1.16, http://www.ivoa.net/Documents/latest/Vocabularies.html)
which even includes a SKOS version of the AVM vocabulary, expressed
both in Turtle and RDF/XML, and which will need only minor adjustments
when the final SKOS namespace is set by the W3C.
This proposal points the way to insure long-term usefulness of things
like AVM without artificially restricting the use to one particular
field of application or being dependent on a commercial developer.
SKOS does for these kinds of applications what FITS did for data
formats: insuring that everyone can read/write/process the information
in a non-proprietary format. The nice thing about the IVOA proposal
is that everyone is encouraged to develope and maintain their own
vocabularies (like the AVM), but in a format that everyone else is
garanteed to be able to use, since mappings between vocabularies make
it possible to "mix-and-match" as desired (e.g. we're working on an
updated SKOS version of the IAU thesaurus, which goes far beyond the
Admittedly, the amount of work required to add SKOS to your
applications is (still) probably about the same as implementing your
own XMP parser, but thereafter you have opened your application to the
semantic web and a growing number of VO-compatible tools/environments
On 24 Nov 2008, at 7:20 pm, Jonathan Fay wrote:
> I have found AVM1.1 to be extremely useful. AVM is for press release
> quality images, not for simple expression of FITS headers in a
> exactly corresponding JPEG file. It is assumed some work is going
> into the images.
> Press release images are enhanced, manipulated, mosaic and the
> published. AVM allows for more than just the coordinates. In
> contains contact, description, organization, composition of bands,
> etc. This is much more that what is contained in a FITS header.
> While FITS liberator is helps with the import of the image by
> mapping FITS tags, Photoshop can't track the crops and size changes
> the user might make. This is not a bug, but maybe an inadequacy of
> Photoshop for not understanding astronomical coordinate system!
> Tools like astrometry.Net can help recover correct information for
> adding AVM tags to processed, scaled and cropped images.
> I think XMP writing tools is a weakness in AVM. We have had to
> develop our own tools to write XMP without Photoshop. For our part
> we will publish our code for others to re-use, and as others adopt
> AVM I am sure other code libraries will come to exist and be
> As to CD matrix and embedded FITS headers. AVM 1.1 was created to
> cure the issues that exist in the ambiguity that is present when
> different software convert FITS images to JPEG, TIFF, ETC. While the
> X & Y scale tell a application how to interpret the 2d array in the
> FITS file, the arrays may be stored upside down or right-side up in
> a JPEG, TIF, PNG or other format, creating a ambiguity in how to map
> the image onto the sky with the array format from the image file and
> FITS header information. I saw an almost equal distribution of
> methods from several software packages on how this maps.
> That ambiguity led to the AVM1.1 creating a non-ambiguous way of
> mapping the scale, rotation and reference pixels so that the images
> will always have only one (the correct) way to map to the sky. The
> result is that every AVM 1.1 images I have seen maps correctly in
> the Sky in WorldWide Telescopes implementation of AVM 1.1. This is
> not the case in 1.0, and not the case for FITS headers sidecar
> images with JPEG/PNG/TIFF files. Additionally a CD matrix allows for
> non-rectangular and skewed image data. Neither is appropriate for
> press release images, as there are corrected for in the processing
> stages of image preparation.
> AVM is still new and there are still issue with code library
> availability, but I believe it is the right direction. I think we
> should concentrate on better supporting and improving AVM, rather
> than fragmenting efforts.
> Jonathan Fay
> Microsoft Research WorldWide Telescope
> -----Original Message-----
> From: Pierre Fernique [mailto:fernique at simbad.u-strasbg.fr]
> Sent: Monday, November 24, 2008 5:25 AM
> To: interop at ivoa.net; agauthier at as.arizona.edu
> Subject: Feedbacks about AVM tags in Aladin
> Dear IVOA members,
> We are pleased to announce that Aladin (beta release) is now
> the AVM tags in JPEG images (IVOA DRAFT Note 2008 May 14 -
> Concretely, it means that the Aladin users can click-and-drag a
> or a Chandra Press Release image from their browser into Aladin and
> a colored astrometrical calibrated images (from the "WCS" information
> provided in the AVM tags).
> However, we were a little bit disappointed by our experience. We have
> several points that we would like to raise to the IVOA community:
> 1) Presently, the main (unique ?) method for incorporating AVM tags in
> the image is Fits-liberator. It is a Adobe Photoshop plugin. This
> is free but not Photoshop. This plugin has a surprising behavior (bug
> ?): it does not adjust the WCS parameters if the user crops, rotates
> resamples the original image. And concretely, the press release images
> are often badly registered.
> It existed a second method presented in the AVM document as an
> Adobe-independent method but unfortunatelly this tool has been
> deprecated when Adobe modified its XMP standard (see below)
> 2) Technically, the AVM tags have to be embedded in a XMP section
> a JPEG comment segment (or equivalent for TIFF and PNG). XMP
> Metadata Platform) is a XML format defined and used by Adobe for
> describing image additional information such as EXIF data related to
> camera picture metadata. Unfortunately, IVOA has no power for
> controlling XMP format. And concretly, XMP is evolving according to
> Photoshop versioning and at the end some press release images used the
> old XMP format, and other the new one, or also a mixture of both.
> - One syntax : <avm:Spatial.ReferencePixel> <rdf:Seq>
> <rdf:li>1044</rdf:li> <rdf:li>983.5</rdf:li> </rdf:Seq>
> - other syntax : <rdf:Description
> avm:Spatial.Rotation="0.86206593355939" ...>
> 3) About WCS. Just the simplest WCS method is supported in the AVM
> And for instance the CD matrix which was supported in AVM 1.0 has been
> surprisingly deprecated in AVM 1.1. We have presently only a pixel
> reference, a sky coordinate reference, a scale factor and a rotation.
> The original image size can be also provided in order to compute a bad
> ratio factor for bypass an user resampling (but working only if the
> reference pixel is the image center - see point 1).
> To be honnest, the AVM 1.1 draft is also presenting the possibility
> writing a full FITS header in a dedicated AVM tag but the syntax is
> described (new line ? or 80 columns ?) and concretely, I was not
> able to
> find an example with a such tag. Perhaps because it could be difficult
> to put a full FITS header in a simple XML attribut (XMP new syntax).
> So, concretly we are a little bit reluctant to extend Aladin for
> writting AVM tags in JPEG output images as XMP format can change again
> without any IVOA agreement (Adobe has a trademark on XMP, and retains
> control over the specification - see the recent example point 1
> For my part, I would prefer to save the original full FITS header
> into a
> simple comment segment of the image. It is easy to read (string
> on Unix, notepad2 foo.jpg on windows), easy to generate (jhead or
> wrjpgcom tool or any other jpeg tools) and it avoids to re-invent all
> FITS keywords (and notably the WCS tags) (also implemented in the
> Aladin beta release).
> Could we compare our experience with some other IVOA members ? Other
> reader or writer experiences ?
> Best regards
> Pierre Fernique
> PS. Aladin beta release 5.901 is available via the official Aladin
> download page.
More information about the semantics