[FEAT] Imviz: add fwhm to the aperture photometry plugin

[eteq]

Blocked by:

• Translator for regions and photutils #1138
• Add curve-of-growth-based FWHM estimator astropy/photutils#1298

Description

Currently the aperture photometry plugin measures the flux, centering, etc, but does not give a "quick-and-dirty" measure of the width. In many applications this is what you really want because it provides information about the size of the PSF, whether the object in question is a star or not, etc. While there are plenty of fancier ways to do this, there is a strong culture (and precedent from the iraf imexam tool) understanding that sometimes you just want "the FWHM".

So to that end I suggest adding a FWHM measured using a purely numerical approach (i.e., not an explicit model fit):

1. Start with a center and a maximum radius (or in jdaviz this can just be the subset pixels themselves and their pixel coordinates)
2. For each pixel compute the distance from the center to the pixel
3. Order the pixels by distance, and compute the cumsum at each pixel.
4. Treat the largest pixel (not necessarily the outermost, since pixel values can be negative) as the "max".
5. Starting from the inner-most pixel, move out until the first pixel that is >= half of the "max" (there's lots of more robust ways to do that, but this is the simplest one to start with), and multiply that pixel's distance by 2 to get the FWHM in pixels
6. (optional in first pass implementation) do the same as the above but have the pixels in sky coordinate units/separations instead of pixels.

Caveat: we really should implement the core algorithm in photutils and call that from jdaviz. But depending on ordering of releases in photutils that might or might not be a bit annoying. Probably depends mostly on the timing of implementation though, as long as everntually it's in photutils.

Additional context

This was recently brought up out-of-band by @janerigby as sort of a "one last missing piece" for standard quick-look use cases of this plugin. @janerigby may want to comment more on the above.

🐱

[eteq]

To be more concrete on the above, the idea here for how this would work with the existing plugin UI is:

• This would operate on a particular selected region, when the user clicks a "compute FWHM" or similar button, at which time it would populate a text field for FWHM. It would also operate on the background-subtracted values just like the aperture photometry plugin itself does.
• The default should be to use https://photutils.readthedocs.io/en/stable/api/photutils.centroids.centroid_com.html#photutils.centroids.centroid_com to compute the "center". Stretch Goal: have a dropdown menu that lets the user choose any of the centroid algorithms listed in https://photutils.readthedocs.io/en/stable/centroids.html .
• That center is used as the "center" I mention in step 1 above. The "maximum radius" is then just the pixel furthest away from the center.
• Stretch Goal: add a check box that does the sky-coordinate version (which would be greyed-out if the image has no wcs?).