Photometry in VO Spectrum Model

[Doug Tody]

Thinking about this some more, I suspect the use case here may in fact
be a calibrated spectrum, and we just want to express the value of each
flux point in the spectrum as a photometry point in some well-known system
such as Johnson B.  Then a zero point and a transmission curve would
be needed to convert to absolute flux.  Is this the case?  Do people
really want spectra in such an odd scaling?  Sorry for being dense,
but I have not seen spectra in this form before.  It would seem to make
it hard to intercompare spectra from different systems.  In any case,
it would help to define a little better what is intended here, and what
this would be used for.  - Doug


On Sun, 22 Oct 2006, Doug Tody wrote:

> 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
> >
>