findApertures fooled by negative images from ABBA in longslit stacked data about dragons HOT 2 OPEN

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.

from dragons.

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.

from dragons.