keflavich / cube-line-extractor

4 stars 1 forks source link

Bug in width_mask #2

Closed jmangum closed 7 years ago

jmangum commented 7 years ago

Spent yesterday trying to understand how the various masking was working and ran into a problem with width_mask. Made two versions of an integrated intensity image where I have set signal_mask_limit and spatial_mask_limit to 0. For the "nowidthmask" version I have removed the masking by width_mask, while the "yeswidthmask" version includes the width_mask. As can be seen there is an issue with the yeswidthmask version. Remember that width_mask is generated as follows:

    gauss_mask_cube = np.exp(-(np.array(centroid_map)[None,:,:] -np.array(subcube.spectral_axis)[:,None,None])**2 / (2*np.array(width_map*width_map_scaling)[None,:,:]**2))
    peak_sn = max_map / noisemap

    print("Peak S/N: {0}".format(np.nanmax(peak_sn)))

    # threshold at the fraction of the Gaussian corresponding to our peak s/n.
    # i.e., if the S/N=6, then the threshold will be 6-sigma
    # (this can be modified as you see fit)
    threshold = np.exp(-(peak_sn**2) / 2.)
    print("Highest Threshold: {0}".format(np.nanmax(threshold)))
    print("Lowest Threshold: {0}".format((threshold[threshold>0].min())))

    # this will compare the gaussian cube to the threshold on a (spatial)
    # pixel-by-pixel basis
    width_mask_cube = gauss_mask_cube > threshold

Further investigation uncovered the fact that nans are being produced in the width_map. The nans in these images are transferring on to the masking and screwing things up. Suspect that the problem is in the spectral_cube moment2 calculation (the centroid_map has no nans...also attached).

-- Jeff

keflavich commented 7 years ago

It turns out this isn't a bug but an issue where a few bad pixels (negative-valued pixels) can mess up a moment2 calculation. The issue is being resolved offline.