Closed wadawson closed 9 years ago
Hey @wadawson, is the plan to put the throughput data directly into each image hdf5 file? Or to just reference a filename that holds the throughput?
Either way, when reading filter data, I'd suggest placing it into some kind of prebuilt-predebugged (or at least mostly debugged) container, like a galsim.Bandpass
for instance, or possibly something from the LSST DMStack.
Good suggestion @jmeyers314. I see the available options for a galsim.bandpass
instance are:
The input parameter, throughput, may be one of several possible forms:
1. a regular python function (or an object that acts like a function)
2. a galsim.LookupTable
3. a file from which a LookupTable can be read in
4. a string which can be evaluated into a function of `wave`
via `eval('lambda wave : '+throughput)`
e.g. throughput = '0.8 + 0.2 * (wave-800)'
So, perhaps we can store the lookup table information in the HDF5 file and then use this to instantiate a galsim.bandpass
instance on load into Roaster
(or similar classes)?
Yep, if we go with galsim.Bandpass
, which I think makes sense since GalSim is already a dependency, the relevant code would look something like:
waves, throughputs = function_that_returns_waves_and_throughputs()
bandpass = galsim.Bandpass(galsim.LookupTable(waves, throughputs, interpolant='linear'))
Only tricky part is to get the units of waves
right, which are nm by default, but can be interpreted as Angstroms if you set the wave_type='ang'
keyword.
I think galsim.Bandpass
is great for what we are doing with JIF, thanks for the pointer. The two-column look-up table is our best option and closest to what is currently provided by most facilities and the format that is likely to be provided in the future. It is also trivial to store in the HDF5 file. I imagine doing so under a higher level group (e.g. ground/filters/i).
Once we get to the point of needing this it will be trivial to implement.
Currently there are attributes that specify filter properties (e.g. central, FWHM; see c86ece1) but we should really just have another subgroup that specifics filter throughput curves and just have an observation specific attribute referencing a specific filter name.