Photometry in VO Spectrum Model

[Doug Tody]

Hi All -

A reasonable question to ask here is why are we even doing this?
Why not just convert this "calibrated instrumental" data to a
fully calibrated form such as absolute flux, if we already know
the instrumental value and transmission curve?  VO is mainly about
publishing fully calibrated data which can be used directly for
multiwavelength analysis.  If we go to all the trouble to convert
the data to a standard data model, why not provide a more directly
usable flux vector as well?  It would be useful to know more about
the motivations for dealing with this type of data, and how many
data collections are producing data of this type, before we decide
if it is worth dealing with this case.

Spectrum does provide a limited capability for pass-through of partially
calibrated data, but since such data can be hard for general client
applications to deal with, we should do some sort of cost-benefit
analysis to decide whether it is worthwhile complicating the model.
Calibration is always going to be easier to perform on the server
side, where one can deal directly with the native project data and
associated metadata and calibrations.

	- Doug


On Sun, 22 Oct 2006, Jonathan McDowell wrote:

>
> Adding support for magnitude photometry to the Spectrum data model
> ------------------------------------------------------------------
>
> At ADASS it was requested that we add better support for magnitude
> photometry to Spectrum, specifically adding a magnitude zero point
> and a way to provide a transmission curve.
>
> I've considered several ways to do this.
>
> (A)
>  Alternative 0:
>  - the magnitude zero point allows you to go from the data values
> (in mag) to an absolute flux (in Jy or similar units). This is
> very like a coordinate system. We could add a FluxFrame specialized
> from CoordFrame with a Zero attribute with value, ucd and unit:
>   FluxFrame.Name       B
>   FluxFrame.UCD        phot.mag
>   FluxFrame.Zero.Value 4893.0
>   FluxFrame.Zero.Unit  Jy
>   FluxFrame.Zero.UCD   phot.flux.density;em.freq
>
>   Pro: Rigorous approach. Could be generalized to other
>    situations.
>   Con: We don't normally think of the y axis as a coordinate. Adding
>    a CoordFrame for it could be confusing, add complexity, and
>    reduce compatibility with STC.
>
>   Alternative 1: Just add a single value Spectrum.PhotZero
>   to the top level object, required to be in Jy
>   Con: Ugly (clutter up top level object) and inflexible (not
>    everyone wants to give the zero point in Jy?)
>
>   Alternative 2: The other obvious place to add it is in
>    Characterization. We could subclass the Char.FluxAxis (Figure 3)
>    to have a special Photom object with Photom.Name, etc.
>   Con: Reduces symmetry in the Char description. But maybe
>    not too badly.
>
>
> (B) -
>  Alternative 0 -
>   the transmission curve has been discussed in the
>   Observation/Characterization
>  data model subgroup; it is the 'level 4' characterization, or Sensitivity,
>  for the spectral coordinate. We could add a new Sensitivity object
>  to the Spectrum characterization, with a single field holding an
>  IVORN URI to another instance of Spectrum holding the transmission curve.
>  We would add the field:
>   Char.SpectralAxis.Coverage.Sensitivity.URI
>
>  Pro: a long term generalization.
>  Pro: Providing a URI is a minimal implementation change rather than adding
>   a complicated structure.
>  Pro: Since many datasets may share the same transmission curve,
>   a URI reference rather than an in-place pair of data arrays is much
>   more efficient.
>  Pro: Also works for X-ray ARF curves, needed for publishing e.g. Chandra data.
>  Con: Adding Sensitivity is something that was deliberately left out
>   of the current IVOA Characterization doc and deferred for later.
>  Con: Adding Sensitivity to Spectrum.Char.*Axis.Coverage in the object
>   model (where I argue it belongs)
>   adds it for all axes, not just the spectral axis.
>   (The TimeAxis sensitivity would represent a time-variable sensitivity,
>    and the SpatialAxis sensitivity would be a spatial QE map).
>   This added complexity is not needed for the other axes at this time.
>   However, we could just say that you should only use it for the SpectralAxis
>   case for now.
>
>  Alternative 1: Add it somewhere else in the model, e.g. at the top level.
>  Con: As for (A), it's an ugly, cheap getout to add things at the top level.
>
>  Alternative 2: Add it as an extra field to the Char.FluxAxis.Photom
>   object posed in (A)'s alternative 2 above.
>  Con: when Char does do Sensitivity, we may want to replace it.
>  So the Alternative-2 proposal becomes
>   Char.FluxAxis.Photom.Name       B
>   Char.FluxAxis.Photom.UCD        phot.mag
>   Char.FluxAxis.Photom.Zero.Value 4893.0
>   Char.FluxAxis.Photom.Zero.Unit  Jy
>   Char.FluxAxis.Photom.Zero.UCD   phot.flux.density;em.freq
>   Char.FluxAxis.Photom.Sensitivity.URI   ivo://photom/B_Johnson_KPNO2004
>
> I think either Alternative 0 or Alternative 2 are workable in each case;
> I request feedback.
>   - Jonathan
>