Add function for fixing EIS pointing by coaligning with AIA data.

[wtbarnes]

In this notebook, there is an example of how to correct the EIS pointing by cross-correlating the 195.119 Fe XII intensity map with an AIA 193 Å image. There should be a function in EISPAC that does this automatically by taking in an EIS map and an AIA map sufficiently close in wavelength and shifting the EIS pointing according to the shifts that maximize the cross-correlation.

This function could optionally query the AIA image automatically if one is not passed in. This function should also optionally operate on multiple EIS maps while only calculating the cross-correlation with one of them.

[MJWeberg]

Great idea!

I notice that the linked notebook just downloads the AIA data and loads it directly into a Map. In order to get the most precise alignment between EIS and AIA, should the new function also use aiapy to prep and update the AIA pointing beforehand?

[wtbarnes]

I'll answer this question in two parts corresponding to the two different parts of the AIA "prep" procedure:

1. By updating the AIA pointing, the pointing correction will be more accurate though at the EIS resolution I doubt this will actually make much of a difference. This also means that EISPAC would depend on aiapy. This isn't necessarily a downside, but just something to consider. Even if this doesn't happen automatically, a user could always pass in their own pointing-updated image to this function if they wanted (possibly) better accuracy.
2. With regards to registering the image, the cross-correlation will perform best if the two images have the same roll angle and resolution since you're effectively translating the EIS image around the AIA image until you find the "best match" (as quantified by the cross-correlation). As such, I think it is best to resample the AIA image to the EIS resolution and rotate it such that the two have the same roll angle.

This should probably hold off until we've sorted out the API weirdness that is in sunkit_image at the moment. See this mailing list post for more details: https://groups.google.com/g/sunpy/c/oaC4rNh9QQE

[wtbarnes]

Also, the procedure above assumes the reference pixel (CRPIX) is (0,0) (the bottom left corner of the image so this should be explicitly reset as well when doing the pointing fix.

[wtbarnes]

Also to consider: for a given raster, not all of the resulting fits will be on the same pixel grid due to the CCD offset in the y-direction which varies as a function of wavelength. As such, if the coalignment is done with only a single wavelength (e.g. the 195.119 Å to AIA 193 as suggested above), all other rasters must first be reprojected to the 195.119 WCS and then corrected.

Alternatively, we could just be careful in how the shifts are applied, e.g. calculate the shift in the 195.119 image and then make sure to apply that same shift to each raster.

[MJWeberg]

Since the shifts should, in theory, be the same for all spectral windows, I am more inclined towards the latter solution rather than mess with reprojecting the WCS.

This reminds me, it appears that the calculate_shift function in sunkit_image is still a private function. Is the recommended method now to just use calculate_match_template_shift and then convert the arcsec to instrument pixels?

[wtbarnes]

Since the shifts should, in theory, be the same for all spectral windows, I am more inclined towards the latter solution rather than mess with reprojecting the WCS.

I agree. Reprojecting is also likely to be problematic for quantities like the Doppler shift. Just to confirm, is it true that the pointing offset will be the same for every window? I would naively assume it to be true, especially if the offset is due to an uncertainty in the spacecraft position.

This reminds me, it appears that the calculate_shift function in sunkit_image is still a private function. Is the recommended method now to just use calculate_match_template_shift and then convert the arcsec to instrument pixels?

Great question. We are actually in the midst of refactoring the entire coalignment module that will have public API that makes it easy to get these shifts out. We may as well wait on that to be sorted (ideally by end of summer) before implementing this feature in eispac.