`_compute_center_splodge()` output location does not match the central splodge

[vandalt]

Hello,

I'm not 100% sure about this, but from what I understand the goal of _compute_center_splodge() is to find the central splodge location, both in the shifted and non-shifted power spectrum. I observed two things with the function:

1. (Pretty sure this one is a bug) The "centered" version (second element of the output) is always empty, because the meshgrid call in the function uses integers instead of vectors as input. It does return a splodge-shaped set of points when fixing that. This product does not seem to be re-used anywhere, so this does not affect other parts of AMICAL.

2. (I don't 100% understand this one) Both versions have a *0.6 factor on the np.where() output. This seems to bring the splodge in the middle of the power spectrum instead of in the corners for the shifted case, and it moves it off the center for the centered one. I was wondering why this 0.6 factor was there (@DrSoulain) ? Removing it seems to bringi the indices back to the central splodge for NIRISS data I've tested. If this is indeed a bug, it probably does not affect anything as the pixels fromt he *0.6 fall in regions where the PS is already zero, so no other splodges are masked (and the matched filter does not match the central splodge so this does not affect the extraction in this way either).

Here is an example that generates the index (the printed outptut contains both products from above):

from amical.mf_pipeline.ami_function import _compute_center_splodge
from amical.get_infos_obs import get_pixel_size, get_wavelength

npix = 80
filt = get_wavelength("NIRISS", "F480M")
pixelsize = get_pixel_size("NIRISS")
print(_compute_center_splodge(npix, pixelsize, filt))

[vandalt]

Attaching a plot to show the case where the central splodge is in the corners (on a constant 80x80 grid)

But I would have expected something more like this (result without the *0.6):

(Again, I might have misunderstood the function, sorry about the noise if that's the expected behaviour)

[DrSoulain]

Hi @vandalt, did you manage to understand your problem? Actually, the 0.6 factor comes from the IDL version of the code. It has been developed for many years, so they probably forgot precisely what it is. In your tests, did you try to remove this factor and see if there are any effects on the observables?