findApertures fooled by negative images from ABBA in longslit stacked data
findApertures fails to correctly identify the sources in an aligned and stacked ABBA 2-D spectrum. The negative images appear to be fooling the algorithm.
See screenshot for the interactive window of findApertures.
To reproduce:
reduce N20170609S0127_stack.fits -r findApertures -p interactive=True
The stack can be found here: https://drive.google.com/drive/folders/14sssXLi93VYdqOF3Mhm9AK1h8_1tnyR0?usp=sharing
[On Oct31, 2023, was using branch feature/niri_wavecal_merge_with_master]
findApertures() has a parameter threshold, with the description "Threshold for automatic width determination" with a default value of 0.1. It sets the edges of the apertures as a function of the distance between the peak and the nearest adjacent minimum; with such high SNR those minima are likely in the troughs, as insignificant maxima/minima are culled. Increasing threshold decreases the width of the aperture found (a value of 0.5 is the FWHM according to a comment), and 0.1 is fairly conservative, at least for GNIRS data. Increasing it to 0.25, for instance, gives the following aperture (zoomed to the inner region to show detail):
The value of
threshold may need some fine-tuning though, depending on the data; for example a value of 0.2 gives the following asymmetric aperture:
More testing would be needed, but it may be useful to have different default values of
threshold depending on the instrument and/or observing mode. (I'd be surprised if there was a "one size fits all" value.)
A related bug which have some bearing on this is that currently in master handling of adjacent minima when culling them from the list of extrema returned culls the wrong one. I don't think this is likely a big problem in most cases, but the bug is fixed in commit 1e446aed11763affdeae0711220d707e80255aa8 in xd_support. It's a simple one-line fix, and when reducing this data with that fix temporarily copied in master the second, spurious aperture present with threshold=0.1 is not found.
I've pushed a commit to the xd_support branch which should fix this issue. It should be possible to cherry-pick to other branches without problems. The underlying issue is that the code wasn't written for, and doesn't expect, negative portions of the profile. An aperture's width is determined as a fraction of the distance between its peak and the nearest minimum. This change makes it so that maxima/minima below the median are merged/set to the median of the data before determining aperture limits, since they would otherwise overwhelm the natural minima found in the continuum. In testing this causes the aperture limits to be set much more reasonably as the nearest minima are simply down in the continuum near the peak.