Details
-
Type:
Improvement
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ip_isr
-
Labels:None
-
Story Points:1
-
Epic Link:
-
Team:Data Release Production
Description
The mask generated by IsrTask looks normal until the fringe is applied, after which many mask features are added. These appear to be print through of bright sources/crosstalk masks from the inputs used to construct the fringe. This is likely to be an issue in both cp_pipe and pipe_tasks fringe generation code, as both use afwMath.statisticsStack.
Attachments
Activity
It looks to be just the mask bits. I haven't re-run the fringe construction, but I think the final fringe mask plane is something like the union of all the input masks (excluding the mask planes that are used for pixel rejection in the combination: BAD, DETECTED, and NO_DATA).
For clarity, the two images attached here show a section of a test exposure at various levels of ISR processing. The additional mask features appear in the third from the final panel, corresponding to the post-fringe application stage. This can be confirmed by the fringe pattern disappearing in the same panel of the image planes.
Hi Chris, the proposed solution on the branch looks good. How do the outputs for your example above look now? In any case, happy to merge assuming no issues with Jenkins etc. Is the mask bit setting a desired feature for .scaledMinus? Naively, I wouldn't expect it to touch the mask planes when performing such an operation, but I think addressing that issue is beyond the scope of this ticket.
I've attached an updated image that should match the previous images. This is from the final postISRCCD, and the spurious masks are no longer added.
afw/image/MaskedImage.h claims that .scaledMinus subtracts images, adds variances, and OR}}s the masks. This makes sense, as if pixel 1 has a {{BAD mask in image 1, and pixel 2 in image 2 has the same, then the subtraction yields no usable values for either of those pixels. I had also looked into wiping the fringe mask entirely, but there's a step I'd forgotten in which the image and fringe masks are {{OR}}ed together so that the pixels used to measure the scale are good in both.
Jenkins run, so I can track it:
https://ci.lsst.codes/blue/organizations/jenkins/stack-os-matrix/detail/stack-os-matrix/33966/pipeline
Ah right, that makes sense, cheers Chris - sounds good!
Is this just problem with mask bits, or are there artefacts introduced into the image too?