Add aperture_mask as a class attribute to LightCurve

The aperture mask is a part of the provenance of any Kepler/K2/TESS lightcurve procured through conventional aperture photometry conducted with pre-defined or custom-specified apertures. Storing the aperture mask as a piece of lightcurve metadata seems fair, or even natural, to enable the inter-comparison of lightcurves generated through different means.

Issue #265 revealed a strategy for how to store an optional aperture_mask metadata blob:

All the data written by LightCurve.to_fits() are currently stored as class attributes. I think we’ll want the same with aperture_mask, i.e. I think we’ll want aperture_mask to become an optional attribute that can be passed to the constructor of LightCurve? If set, to_fits would then write self.aperture_mask as an optional extension.

[barentsen]

My recommendation is to add aperture_mask as an optional argument of lc.to_fits() for now.

I don’t think we want to add it as a class attribute right now. As you point out: it is not clear that an lc.aperture_mask attribute is useful without provenance information.

I think we should focus on our immediate goal of adding a “Save Lightcurve” button to interact, which allows someone to capture the lightcurve and mask in a single fits file. This would be enabled in a very simple and effective way by accepting the mask as an optional argument in to_fits().

It would be too ambitious for Lightkurve v1.0 to provide deep reproducibility features, which is why I think it’s fine to take a pragmatic shortcut here!

[gully]

After a long discussion we all agreed we do not want to add aperture_mask as an attribute to LightCurve objects. The reason for not including this attribute is resides in the complexity to maintain an optional feature— not all LightCurve objects were created using aperture photometry, and eventually ground-based lightcurves may have different apertures altogether, so the aperture mask meaning is lost, and maybe even misleading. The aperture may also lose meaning when referring to non-standardized data products like TESS Cutout TPFs. KeplerLightCurveFiles on the other hand, are associated with apertures, and already have ways to access their default pipeline masks. Those access methods may be inconvenient (using klcf.hdu[-1].data ==3 doesn’t roll off the tongue), but they’re possible.