https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/PIPE2D-1015 DRP 2-D Pipeline <p>This is an observation reported by <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=rhl" class="user-hover" rel="rhl">rhl</a> during an internal Princeton meeting in early March, and a report by <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=kiyoto.yabe" class="user-hover" rel="kiyoto.yabe">Kiyoto Yabe</a> made during the 2D DRP tech telecon 2022-03-28/9 may support this.</p> <p>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 <span class="image-wrap" style=""><a id="15151_thumb" href="https://pfspipe.ipmu.jp/jira/secure/attachment/15151/15151_Screen+Shot+2022-03-29+at+8.52.10+PM.png" title="Screen Shot 2022-03-29 at 8.52.10 PM.png" file-preview-type="image" file-preview-id="15151" file-preview-title="Screen Shot 2022-03-29 at 8.52.10 PM.png"><img src="https://pfspipe.ipmu.jp/jira/secure/thumbnail/15151/_thumb_15151.png" style="border: 0px solid black" /></a></span> for example, showing a CR event crossing fibers 549, 546, 543, 540...479, 477. </p> <p>However, not a single 'CR' bit mask is set in the corresponding <tt>pfsArm</tt> 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.</p> <p>Plots of the <tt>pfsArm</tt> using the <tt>display.showAllSpectraAsImage()</tt> 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.</p> PIPE2D-1015

Mask bit flags not propagated to pfsArm correctly

Task Normal Done Done price hassan Wed, 30 Mar 2022 01:02:07 +0000 Tue, 3 May 2022 18:32:41 +0000 Tue, 3 May 2022 18:32:41 +0000 0 4 <p>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.</p> <p>So let's decide what the algorithm should be, and I'll implement it. Do we want to <tt>OR</tt> 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?</p> <p>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.</p> <p>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</p> <p>No objections with changes in pull request. This is in line with the proposal by RHL above.</p> <p>Merged.</p> Development Rank 0|02qpjd:0419 Reviewers hassan Sprint 2DDRP-2022 D Story Points 2.0