Issue with aiapy.calibrate.respike with some submap data

[nabobalis]

In GitLab by @hayesla on Nov 12, 2020, 10:54

I have found an issue when a spike coordinate lies near the edge of a submap. For example:

e.g.

>>> res = Fido.search(a.Time('2011-06-07T06:52:00', '2011-06-07T06:52:10'),
                  a.Instrument("AIA"), a.Wavelength(171*u.angstrom))
>>> f = Fido.fetch(res)
>>> my_map = sunpy.map.Map(f)
>>> bottom_left = SkyCoord(500*u.arcsec, -600*u.arcsec, frame=my_map.coordinate_frame)
>>> top_right = SkyCoord(1000*u.arcsec, -100*u.arcsec, frame=my_map.coordinate_frame)

>>> my_submap = my_map.submap(bottom_left, top_right=top_right)

>>> spikes = aiapy.calibrate.fetch_spikes(my_submap)
>>> spike_coords, _ = aiapy.calibrate.fetch_spikes(my_submap, as_coords=True)
>>> respike_smap = aiapy.calibrate.respike(my_submap, spikes=spikes)
~/sunpy_dev/aiapy/aiapy/calibrate/spikes.py in respike(smap, spikes)
     99     # transformation may be very slightly off their integer values and
    100     # casting them as int will sometimes result in an off-by-one error
--> 101     new_data[coords.y.value.round().astype(int),
    102              coords.x.value.round().astype(int)] = values
    103     # Update metadata

IndexError: index 836 is out of bounds for axis 1 with size 836

if we inspect this - looking at the spike_coords one of the coordinates returned is outside of map range (see 1000.37''):

>>> spike_coords.x
<Longitude [ 814.02113393,  754.05244157,  637.72596686,  637.72576428,
             721.03336551,  721.03316294,  721.62332623, 1000.97216768,
             999.77301538, 1000.37249025,  820.51776929,  898.43519305,
             836.67676809,  836.67656551,  641.82835524,  721.03356809,
             721.03296037] arcsec>
>>> my_submap.top_right_coord.Tx
 <Longitude 1000.29733661 arcsec>

It's only an issue near the border - for example if you change the top_right coordinate to be 1001*u.arcsec it works fine. I guess its an issue of edge cases and finding closest pixel.

[nabobalis]

In GitLab by @wtbarnes on Nov 12, 2020, 11:10

Oof ok. I'm not terribly surprised that this is an issue. The checking that we do to make sure that the spike is still within the FOV for a cropped map is pretty rudimentary: https://gitlab.com/LMSAL_HUB/aia_hub/aiapy/-/blob/master/aiapy/calibrate/spikes.py#L176

I wonder why this falls inside the FOV in pixel space but not in world space.

We should probably have a test that covers these kinds of edge cases.

[nabobalis]

In GitLab by @wtbarnes on Apr 30, 2021, 05:41

changed health status to needs attention