Details
-
Type:
Improvement
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ip_isr
-
Labels:None
-
Story Points:6
-
Epic Link:
-
Team:Data Release Production
Description
The brighter fatter correction convolves the image with a kernel to do the correction. In the border region of the image where the convolution is not valid there is no correction applied. We need to add a bit in the mask plane to indicate this.
Attachments
Issue Links
- mentioned in
-
Page Loading...
Activity
No longer an AP problem — Christopher Waters & Merlin Fisher-Levine are the gurus here now. As far as I can see from a cursory glance, we're still not setting mask bits in the areas which are not being corrected. Merlin & Chris, do you concur? Seems like it would be an easy fix...
I think it would. A few questions though: 1) Do we need a new mask plane for this? 2) If they're not easily spared, would just using EDGE be sufficient? I imagine the sizes would be similar, and because I'm not quite sure of the use-case for this new plane, I'm not sure how precise it needs to be. It's also possible that EDGE turns up in places that aren't the actual edge of the sensor, meaning this wouldn't be appropriate at all, so I'm not sure.
But yes, if we can spare making a new maskplane for this then it should be easy.
I'm happy to think about this a bit more, but my initial impression is that we should be setting `IsrTask.config.numEdgeSuspect` to the half-kernel size of the brighter-fatter kernel. Making this automatic (if a brighter fatter kernel is supplied, and is to be applied, then numEdgeSuspect should be at least 0.5 * kernel size) feels like the right long term solution.
I have no objection to adding additional mask planes to define this, but worry about maintaining the propagation of those planes to downstream code (i.e. with HSC's `GUIDER` plane being ignored). Is there a list somewhere defining plane names and how analysis code should be treating them?
Thanks both for your comments.
Christopher Waters — noting you set this to “in progress” — I don't think this is urgent, but if you are free to work on it, then obviously that's great. Unfortunately, I don't know of any list of mask planes beyond what exists in the code; see e.g. DM-2297.
It was a quick enough thing to do, if SUSPECT is an acceptable mask plane (plus it was a nice break from other tickets).
Do either of you have time to do the quick review?
Thanks for the quick fix!
Some minor code comments on the PR. Beyond that —
- I claim no expertise on the semantics of mask planes, but I wonder if BAD might be better than SUSPECT? I naïvely assume we would simply want to ignore data without BF correction applied, but I would defer to Jim Bosch or Bob Armstrong as to whether I'm right.
- Any chance of adding a test case?
I don't think SUSPECT is quite right (though perhaps it should be repurposed so it could be - right now it really means "high enough that nonlinearity correction may be inaccurate, but not saturated", and we've long thought we should just fix the nonlinearity corrections instead of having it). But I don't necessarily have a better suggestion; BAD means we'll just get rid of those areas entirely (it's what we use for defects). Maybe EDGE, which is what we use for other cases where kernel width means we lose pixels on the outside?
I think the important question is what downstream processing will do with whatever mask bit you choose. My familiarity with those steps w.r.t. mask planes is not what it once was, so I'm afraid I'm not much help there. Yusra AlSayyad or Lauren MacArthur may be in a better position to guess.
Changes on the PR look fine to me — thanks!
Assigning to AP since they lead on ip_isr. Simon Krughoff, do feel free to object!