Feedbacks about AVM tags in Aladin

[Frederic V. Hessman]

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  
AVM taxonomy).

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  
(e.g. VOEvent).

Rick

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  
> distributed.
>
> 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  
> supporting
> the AVM tags in JPEG images (IVOA DRAFT Note 2008 May 14 -
> http://www.virtualastronomy.org/AVM_Version1.1May312008.pdf).
> Concretely, it means that the Aladin users can click-and-drag a  
> Spitzer
> or a Chandra Press Release image from their browser into Aladin and  
> get
> 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  
> plugin
> is free but not Photoshop. This plugin has a surprising behavior (bug
> ?): it does not adjust the WCS parameters if the user crops, rotates  
> or
> 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  
> inside
> a JPEG comment segment (or equivalent for TIFF and PNG). XMP  
> (eXtensible
> 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  
> the
> 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>
> </avm:Spatial.ReferencePixel>
> - other syntax :  <rdf:Description
> avm:Spatial.Rotation="0.86206593355939" ...>
>
> 3) About WCS. Just the simplest WCS method is supported in the AVM  
> tags.
> 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  
> for
> writing a full FITS header in a dedicated AVM tag but the syntax is  
> not
> 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  
> above).
> 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  
> foo.jpg
> 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  
> cited
> Aladin beta release).
>
> Could we compare our experience with some other IVOA members ? Other  
> AVM
> reader or writer experiences ?
>
> Best regards
> Pierre Fernique
>
> PS. Aladin beta release 5.901 is available via the official Aladin
> download page.
>
>
>
>
>