Closed jmangum closed 2 years ago
Right, this can be inconsistent if the cubes are produced with different channel widths or from a different data set.
I think that the current behaviour was ok when cube
and cutoutcube
were always the same. Now that we allow for cube
and cutoutcube
to be different we should use max_map
calculated from cube
when calculating peak_sn
. Note, though, that there are two options. Since peak_sn = max_map / noisemap
, either max_map
needs to be changed to use cube
or noisemap
needs to be changed to use cutoutcube
. Since peak_sn
is used for setting a threshold for the gaussian mask, I think that changing max_map
to use cube
appears to be the right choice.
I have been doing quite a few tests this morning trying to make the peak_sn = max_map / noisemap
consistent by using information from just cube
or cutoutcube
to calculate peak_sn
. In the end found that basing calculation on cube
resulted in the width_mask
, which has a threshold
calculated as 1 / peak_sn
, was far to restrictive, basically excluding all emission toward most sample pixels. I think that I was not thinking about how peak_sn
was being used. Suggest that using max_map
from cutoutcube
and noisemap
from cube
is correct for setting the threshold
for a theoretical gaussian mask for a hypothetical spectral line that is based on the "tracer" line from cutoutcube
. If @keflavich agrees, we can close this issue.
I think that sounds right.
It's sounding more and more like we need to formally write up this process as a software paper or something, and show figures detailing each step. Though, this writeup is similar: https://github.com/abulatek/tutorials/blob/new/SpectralCubeReprojectMaskExample_v4p1.ipynb
Agreed. Created Issue #42 to track.
max_map
is derived from a masked version of cutoutcube, which is the so-called "brightest line cube":max_map
is used later incubelinemoment_multiline
to calculatepeak_sn = max_map / noisemap
.noisemap
is derived fromcube
(the target line cube), not fromcutoutcube
, incubelinemoment_setup
:This looks inconsistent...