Photometry and SED models at Nara
jcm at head.cfa.harvard.edu
Tue Nov 30 07:03:15 PST 2010
> I am considering an 'aggregate' SED, originating from radio astronomy,
> where each point is in physical units (Jy per unit area).
Yes, that's no problem - in the Spectrum model we are able to define such
a Y axis (surface-brightness) by specifying the FluxAxis UCD appropriately.
Per Table 3 of Spectrum model:
FluxAxis.UCD = phot.flux.density.sb;em.freq
FluxAxis.unit = Jy sr**(-1)
or for Jy/beam
FluxAxis.UCD = phot.flux.density;instr.beam
FluxAxis.unit = Jy
> I notice that the SED model refers to the Photometry model. This is a
> very thorough description for optical or other 'magnitude' data; much of
> that can of source be skipped for radio but the point on Aperture
> Corrections could be extended to distinguish between the two common cases
> where the
> 'unit' of area is the entire source, and where the unit is the beam area.
There are two ways you can look at the 'flux per beam' case:
1) as a surface brightness, convertible to Jy per sq arcsec by providing the
2) as a total flux density, convertible to Jy by providing an aperture correction,
but only if it's a point source or a source of known area - so may not
be appropriate in general for a radio map.
> It would also be nice (and simple) to have a radio example. One point -
Let's work on that together!
> radio data is usually evenly spaced in frequency, I hope that we are not
> still only allowing wavelength?
We were never only allowing wavelength, Spectrum allows frequency and
so does Photometry as I've written it, although I didn't put in any explicit
frequency examples. The zero point data has magnitudes as its default
but doesn't require it (that's why there's a UCD there).
> Back to the SED, we should also consider the extensions to spectral index
> and spectral curvature (possibly higher orders) which are the coefficients
So, this concerns an image product, spectral index maps ("color maps" in the optical),
or a time series product, color versus time,
with a complicated "y" axis. It's complicated because the metadata
needs to point to two Band definitions. I think one could have a
"Photometry Color/Spectral Index" standard that tells you how to
record in metadata that a time series, image, etc. has a particular color as
its data values. That would use the Photometry standard (but not the SED)
but could be a short separate document, since colors do raise some interesting issues.
First up we should consider how to use the Photometry model to interoperably
describe what band / frequency range /etc an image is in. We could do that
trivially by taking the indirect-reference approach. Since astro images are
in practice always FITS, that means defining a FITS keyword containing a URI
pointing to a VO band definition, and possibly one giving a generic ID for
the band. In the spirit of what I've written in the document
one might have
PHBAND = "V"
PHURI = "ivo://vo.cfa.harvard.edu/filters/FLWOCCD/V"
Now we can also have that URI refer to a FITS extension in the same file containing
a FITS serialization of the Photometry band model, that will take more work.
For a spectral data cube with a continuous axis, you need to have a Spectrum-type coordinate axis;
for a cube which is e.g. a set of U,B,V planes or your example say 1.65, 4.95, 15.2 GHz planes,
you need pointers to a band definition for each plane. I'm not sure how to go about this
since I haven't kept up with what SIAv2 has been doing for image and cube products in general.
More information about the dm