Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: daf_persistence, obs_base
-
Labels:
-
Story Points:4
-
Epic Link:
-
Sprint:AP S21-1 (December)
-
Team:Alert Production
-
Urgent?:No
Description
RFC-730 proposes a new filter system that will support only standardized names for each band or filter, but no aliases. While new aliases will no longer be introduced after DM-27167, old files may still use them in Gen 2 (Gen 3 will internally ensure that all names are standardized). To ensure that algorithmic code can safely assume standardized names in FilterLabel regardless of whether an input Exposure was loaded from Gen 2 or Gen 3, standardize the filter names in an Exposure when loading them from Gen 2.
Note that there is no standardization problem when using Filter; the problem will only emerge after Exposure starts using FilterLabel as the primary API.
Attachments
Issue Links
- is blocked by
-
DM-27169 Use FilterLabel in Exposure/ExposureInfo
- Done
-
DM-27179 Standardize filter info in CameraMapper
- Won't Fix
- is triggered by
-
RFC-730 Replace afw.image.Filter with simple label-based classes
- Implemented
- relates to
-
DM-28004 ExposureInfo may persist dummy FilterLabels
- Done
-
DM-28236 get('calexp_filterLabel') does not return a full label for pre-FilterLabel data
- Done
-
DM-27167 Stop using filter alias names in DM stack
- Won't Fix
-
DM-28583 Update fitsExposure formatter to fill in filterLabel from dataId
- Done
There may also need to be standardization of filter names inside catalogs, but this is a trickier problem because catalogs are free to have any schema, and it's not always obvious which field is a filter (let alone disambiguating between different instruments). See
DM-27167for discussion.