c3-time-domain / SeeChange

A time-domain data reduction pipeline (e.g., for handling images->lightcurves) for surveys like DECam and LS4
BSD 3-Clause "New" or "Revised" License
0 stars 4 forks source link

Store short filter names in the database #359

Open rknop opened 1 week ago

rknop commented 1 week ago

Right now, in the database "filter" field of exposure and image, we store the full filter spec as pulled from the header.

However, we also have the concept of a "short filter name". See models/instrument.py::Instrument.get_short_filter_name and the equivalent function in models/decam.py. By default, the short filter name is the same as the filter name, but notice in decam that we take just the first character of the filter name. DECam header filter names are ungainly things like "g DECam SDSS c0001 4720.0 1520.0"; we don't want that in a filename, so the short filter name is used in the filename.

It would be convenient to store the short filter name in the database, instead of the full filter name, and to use the short filter name as the "official" name everywhere in the code for interfacing with filters. This makes poking in the database to select images easier, and makes specifying filters for command-line utilities easier. For example, search for filtertranslation in pipeline/acquire_decam_refs.py (as of this writing, only on Rob's decam_swarp_reference, for which there is a draft PR); it's ugly to have to put that in a command-line utility. That kind of thing should be part of the instrument subclass.

Add a method to the instrument subclass that expands short filter name back to full filter name, for purposes of header matching. Then, go through the code, and make sure that everywhere we might save a filter to the database, we actually save the short filter, and that's what we use. The verbose filter names should only be used when pulling header fields (or finding images from the exposure source), and in the translation functions that are methods of the instrument subclass.