Fix Version/s: None
Sprint:AP S21-2 (January)
butler.get('calexp').getFilterLabel() returns the correct patched value for pre-FilterLabel data (e.g. testdata_jointcal/hsc), but butler.get('calexp_filterLabel') does not. The problem is that CameraMapper._initMappings().getFilterLabel() does not call the new _setFilter() that has extra logic to fill out the filter label from the FilterDefinitions.
One question is what happens with old calexps after we remove afw.Filter. Currently, _setFilter uses the FilterDefinitions, which should be entirely independent of afw.Filter and is fairly conservative in how it determines whether to replace the as-read FilterLabel. Do we want that to be the process in the future, or do we want to e.g. modify calexps during gen2->gen3 conversion so that they have the correct FilterLabel on disk, so we don't have to have any gen3 FilterLabel logic for processed data?
I'm adding FilterDefinitionCollection.physical_to_band (dict) in
DM-27170, but I don't think helps you because your findAll is much broader in what it searches. That dict is exactly what we want for raw files, but doesn't help for calexps that could have either band or physical or some other alias in their `FILTER` header key.
The bug was detected in Gen 2, yes.
Currently there is no filter patching done in Gen 3, aside from the creation of the original FilterLabel object for raws. So unless the Gen 3 files themselves have been corrected, I would expect both get('calexp').getFilterLabel() and get('calexp.filterLabel') to potentially return incomplete information.
John Parejko, since you discovered and reported the bug, can you review it? The fixes themselves are small, but some refactoring pushes it up to 130 lines.
Thank you for the quick fix. I made one more reply about adding a comment, but otherwise this is good.
I'm marking this a blocker for
DM-27170, because I discovered it while trying to remove afw.Filter from jointcal but the calexps in testdata_jointcal are only giving `band`, not `physical`.