The Filter object we use to describe the bandpass associated with an image has always been used inconsistently, and its reliance on a global map of all known filters is now causing real trouble integrating the Gen3 middleware with more obs packages.  This is in part because Gen3 allows data from multiple instruments to exist in the same data repository, so we're actually running up against cases where we're trying to define the filters for multiple instruments in the same Python process (which I think was always impossible, or at least subject to very surprising and inconsistent behavior).  But it's perhaps more true that prior to Gen3 we mostly just accepted that inconsistent behavior as a given we had to work around, and adapted to whatever labels the Filter system produced in any particular context without any attempt to define a sane data model.

We gathered some input on what we'd want in a replacement on RFC-541, and I've sketched out a proposal for replacement classes on this gist.  Most of the proposal is there, but I've got a few additional notes:

• I've sketched out Python APIs to make them easier for most developers to parse, but I think these will have to be implemented in C++ so we can attach them to ExposureInfo.
• One of the issues I identified in RFC-541 is not addressed here: how to generate consistent unique integer IDs that depend on filters.  I think that's a hard problem, and I'd like to try to assert (at least for now) that we don't actually need to solve it:
  • Unique IDs that mangle visit+detector datasets don't an integer from the filter, because a visit (for which we will need integer IDs for other reasons) implies a physical filter.
  • The unique IDs for Objects (or the outputs of the current multi-band coadd processing) do not depend on filter, because they are explicitly merged across all bands.  While we may have processing steps that generate intermediate outputs that are specific to a certain band, and we may find it convenient for debugging to generate IDs for those that mangle tract+patch+filter, we have no requirement that those IDs remain consistent across runs (only that they be de-mangle-able).
• Those of you already familiar with the Gen3 data model for filters will note that this is fairly different; I think the Gen3 model needs to be expanded to look more like this, and I'm hoping to be able to do so without having a different dimension for each different type of filter.