[PIPE2D-1233] Allow flat-fielding for n while not flat-fielding b/r Created: 07/Jun/23 Updated: 09/Jun/23 Resolved: 09/Jun/23 |
|
| Status: | Done |
| Project: | DRP 2-D Pipeline |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Story | Priority: | Normal |
| Reporter: | price | Assignee: | price |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Reviewers: | rhl |
| Description |
|
We currently have a flat-field image for n1 only. We want to apply the flat for n1 without applying a flat in b/r, using a single configuration setting (so we can achieve this with a single call to reduceExposure.py or detrend.py). |
| Comments |
| Comment by price [ 08/Jun/23 ] |
|
rhl, I've added a doFlatNir configuration parameter to ISR. The NIR will have the flat-field applied if either doFlat or doFlatNir is set. For current Subaru operations, we'll set doFlat=False doFlatNir=True, which will result in the n arm having the flat applied and the b and r arms not having a flat applied. Are you satisfied with this solution? |
| Comment by rhl [ 08/Jun/23 ] |
|
How about doFlatArms="brm" instead? |
| Comment by price [ 08/Jun/23 ] |
|
I think I could make that work, by overriding the flatCorrection method of IsrTask, but there would be one annoyance: the log message, "Applying flat correction", originates from the run method, which we do not want to override (because it's very very long and involved). Then if doFlat=True but the arm being processed is not in the doFlatArms list, you would get a log message "Applying flat correction" even though we would intercept and disable the application of the flat. We could log our own message ("Hey, just kidding before, we're not actually applying the flat"), but I fear the confusion that would result. An alternative to all of this would be to generate fake flats for the optical arms that are unity everywhere, and then we wouldn't have to hack around things in the code. Hopefully this state of affairs won't last much longer, and we'll get real flats for the optical arms in the next run. |
| Comment by price [ 09/Jun/23 ] |
|
Spoke to rhl, who agreed that this current solution isn't ideal (we'd prefer being able to specify the arms to be flat-fielded) but it's good enough given the limitations. Merged to master. |