Option to feed aperture photometry a table of positions

[hcferguson]

Given the design of the PSF-fitting routines, which accept initial guesses for the positions as a table with columns 'x_0' and 'y_0', and return a table with columns named 'x_fit' and 'y_fit' it seems like it would be convenient to users to have the aperture photometry routines accept input positions in tabular format and be able to designate which columns correspond to x and y, perhaps defaulting to 'x_0' and 'y_0'.

[whitmore999]

Yes - This is a key capability so people can do "forced" photometry, e.g., they know there is a source at a location based on, for example, other wavelength images and they want to get a measurement (or upper limit) at the position even if they cannot centroid on it.

[hcferguson]

@whitmore999 That you can do already. In the case of aperture photometry it doesn't modify the positions anyway. In the case of psf-fitting photometry, you can set your psf_model to keep the position fixed, e.g.:

    psf_model.x_0.fixed = True
    psf_model.y_0.fixed = True

[larrybradley]

@hcferguson You can pass the positions from the table directly, e.g. aper = CircularAperture((tbl['x'], tbl['y']), r=3.). As you note, the issue with the Table input is that x and y will be stored in various column names, so either you need to enforce particular names or allow a mapping -- both of those options seemed unnecessary to me when (tbl['x'], tbl['y']) is trivial and explicit.

From an API perspective, I think CircularAperture((tbl['xcen'], tbl['ycen']), r=3) is better than CircularAperture(tbl, r=3, x_column='xcen', y_column='ycen').

However, I do think there should be consistency with the PSF photometry classes. I'll likely modify those to allow (x, y) input to init_guesses.