Photometry and SED models at Nara
mcs at iaa.es
Tue Nov 30 07:58:21 PST 2010
Hi Anita and Jonathan
I just read the discussion about "colors", spectral index related with the Photometry and SED DM.
I think it is a very good case although not just affect the Photometry and SED DataModel.
(I include here the relevant lines)
>> 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.
I have several examples that are related with spectra like the one you quoted:
colors, line equivalent widths, continuum indices (as it is the ratio of two bands/wavelengths)
hardness ratios (for X rays) etc... but also, at the end, any kind of "product" where
a ratio is involved like mass-luminosity relations, abundance ratios, a lot of
theoretical results etc...
I think that a simple basic approach without a priori assumptions about which quantities
provide the "index" is more useful. In the line of the "physical quantity" presented
in "Simple Spectral Lines Data Model Version 1.0"
it would be just an extended physical quantity expressed as the composition of other two
(maybe more) physical quantities related by a mathematical operation (usually take a ratio and a log)
Of course there is an additional issue in the characterization of the resulting error since
there would be a covariance between the quantities and/or some hypothesis about the independence
of the quantities must be done but...
It is just an draft idea, I think that it is so natural and simple that
may work for a wide number of cases with a relatively easy implementation/description
in a data model.
Unfortunately It is not possible to me to attend the Nara Interop, so I
acknowledge the use of the mailing-list for discussion (I will we aware of
the presentations etc in the wiki any case :)
cheers and I hope you have a nice interop.
More information about the dm