Table format when a list of apertures is provided

[hcferguson]

It is handy to be able to do photometry with multiple aperture radii with one call, but not so handy that the output is recorded in separate columns, and the radii aren't recorded in the output.

For my typical workflow I would prefer to have the radius as a column name and have the photometry all in a single column. Then I can just filter the output on the aperture radius (and that radius is recorded in the row with the position and the flux, which I think is generally good practice for reproducability).

[eteq]

I agree that there are some workflows where this is desirable. However for some workflows it makes sense to have the current output. For example, if I have a set of apertures where the order has meaning (i.e., derived from some other table in priority order or something), I want the output table to obey that ordering.

I think we can have our cake and eat it too, though. What @hcferguson proposes here is a fairly straightforward transformation of the existing output table. So we could have a function (multi_aperture_entry?) which takes in the output of aperture_photometry and just does the transformation to make the table @hcferguson wants. After that we could either:

1. Tell users to do multi_aperture_entry(aperture_photometry(...)) to get this
2. Add a keyword to aperture_photometry that just runs the final return value through the function if it is set.

I prefer 1, but could live with 2. Note that even in 2 multi_aperture_entry (open to a better name idea...) should be public because I might want both versions of the table but only want to run aperture_photometry (the expensive part) once.

[hcferguson]

The current output doesn't have the aperture radii even in the metadata, so I would suggest adding that to the existing table, as well as providing the alternative format.

[larrybradley]

@hcferguson I agree the aperture shape parameters should be recorded in the metadata (I thought they were already, but I see they're not there).

For a multi_aperture table format, we'd have to think carefully about how to name the columns, because only the CircularAperture can be defined with a single shape parameter (radius). For example, an EllipticalAnnulus has 4 shape parameters (a_in, a_out, b_out, theta). And in principle, the user can input any custom-defined aperture class (subclassed from Aperture). In that case there would need to be common interface where the aperture shape parameters are stored (e.g. as a str).

[larrybradley]

Does it make sense to have a table column named:

'a_in=10.71, a_out=20.323, b_in=5.487, theta=0.785398'

[hcferguson]

@larrybradley Good point!

I had forgotten that apertures can be quite general. Storing the info somehow in the metadata rather than column names seems cleaner for the general case. Sounds to me sort of like the same problem as regions, but I'm not sure how that package is serializing the regions.

Wanting to do photometry with circular apertures of different radii is common enough that it would be good to have a convenient way to get the radii into a column in the table. But now I'm convinced that should be post-processing. You could call it aperture_index to be general. Although maybe this is just my knee-jerk distaste for to having to do text processing on strings (the column names) to index into an array of fluxes.