[PIPE2D-1015] Mask bit flags not propagated to pfsArm correctly Created: 30/Mar/22  Updated: 04/May/22  Resolved: 04/May/22

Status: Done
Project: DRP 2-D Pipeline
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: hassan Assignee: price
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2022-03-29 at 8.52.10 PM.png    
Story Points: 2
Sprint: 2DDRP-2022 D
Reviewers: hassan

 Description   

This is an observation reported by rhl during an internal Princeton meeting in early March, and a report by Kiyoto Yabe made during the 2D DRP tech telecon 2022-03-28/9 may support this.

Looking at the processed output for SuNSS visit 71280, arm=r, the ISR corrected image shows a number of cosmic ray hits (maskplane='CR'). See for example, showing a CR event crossing fibers 549, 546, 543, 540...479, 477.

However, not a single 'CR' bit mask is set in the corresponding pfsArm file for that visit ('BAD_FIBERTRACE' and 'NO_DATA' bits are set, but not 'CR'). Please investigate why the 'CR' bits are not propagated, and fix.

Plots of the pfsArm using the display.showAllSpectraAsImage() utility also show features that do not have any corresponding bits set. This may be due to a bug or limitations in that code itself, but I report it here for completion.



 Comments   
Comment by price [ 31/Mar/22 ]

Choosing how to treat mask bits during spectrum extraction is a lot like choosing how to treat mask bits during image coaddition. Both involve combining multiple values with masks into a single value with mask. It's obvious that we don't want to include bad values in the calculation of the output value. The question is whether we want to include bad masks in the calculation of the output mask. For coaddition, we decided a long time ago that we don't want to include them, because they can end up everywhere in the coadd, and they don't relate to anything in the coadded image. For this reason, I've been deliberately ignoring the bad mask planes when we extract spectra. However, perhaps there's a good reason to do something different: spectral extraction extends only over a relatively small number of pixels (as opposed to several tens or even hundreds of pixels contributing to each output pixel in a deep coadd), and those pixels are often intimately related.

So let's decide what the algorithm should be, and I'll implement it. Do we want to OR all mask pixels in each row of the fiber trace? Or do we want to require that each mask plane exceed some threshold of fraction of the fiber profile before including it in the output? Or something else?

Comment by rhl [ 31/Mar/22 ]

For pfsArm files, I think we want to start by ORing all the bits in pixels which contribute more than some fraction of the output value. I'd start by setting that fraction to 0.0.

For the pfsMerged files I'd do the same thing, propagating bits from the pfsArm file that contribute more than some fraction of the output flux, and again I'd initially set that fraction to 0.0

Comment by hassan [ 04/May/22 ]

No objections with changes in pull request. This is in line with the proposal by RHL above.

Comment by price [ 04/May/22 ]

Merged.

Generated at Sat Feb 10 16:01:27 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.