Feedbacks about AVM tags in Aladin

[Frederic V. Hessman]

We all understand perfectly that the public needs the final images,  
and - yes - not in FITS.  The point is that the public doesn't have to  
trim, mosaic, transpose or otherwise diddle with the real images in  
any fashion which requires complicated WCS manipulation via XMP.  XMP  
should be for your images what JPEG is for FITS: you diddle with the  
real data until you've got it in the right shape and then export to a  
format which the public can enjoy.

Or am I missing something fundamental here and should be blushing ....

The XMP examples given

>> <avm:Spatial.ReferencePixel> <rdf:Seq>
>> <rdf:li>1044</rdf:li> <rdf:li>983.5</rdf:li> </rdf:Seq>
>> </avm:Spatial.ReferencePixel>
>> <rdf:Description avm:Spatial.Rotation="0.86206593355939" ...>


look like vanilla RDF/XML or a wrapper therearound to me, suggesting  
that AVM/SKOS should make life simpler (just as UCD is more accessible  
when expressed in SKOS than in text files).

(blush)

Rick

On 25 Nov 2008, at 5:42 pm, Jonathan Fay wrote:

> 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.
>
> Jonathan
>
>
>
>
> -----Original Message-----
> 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
> 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.
>>
>>
>>
>>
>>
>
>