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-541is 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.
RFC-730 Replace afw.image.Filter with simple label-based classes
- is triggering
DM-21333 Implement afw.image.Filter replacement(s)
- relates to
DM-26069 Create requirements list for new Filter implementation
DM-26181 Ensure that filters are defined in pipetask multiprocessing
RFC-541 Design better (and Gen3-friendly) way of representing bandpass filters in code
- mentioned in
I think this has converged aside from the question of whether to make this a class hierarchy (the original proposal) or use a single struct that may have some optional attributes. At this point I think it makes sense to just adopt the RFC and see how both of those approaches fit within the codebase on the implementation ticket, especially as the participants in that conversation have dwindled to just me and Krzysztof Findeisen.
The new filter system will be implemented as described in
Hmm... I could swear I set the resolution to "Duplicate", yet it's been changed to "Done".
I think "Retired" implies "Done"; there's no distinction in resolution in the RFC project.
I think tagged classes would be a greater evil than a class hierarchy – we already have to work around way too many possibly-null values in our code. Your example had only full_name, so I assumed that everything could be normalized to that form. But it sounds like you're saying that clients do need to be able to distinguish between different kinds of filters.