AstarVienna/ScopeSim

PSF rescaling (resampling) should probably use higher spline_order

Opened this issue · 4 comments

In the FieldConstantPSF class, if the provided PSF has a different pixel scale than the detector, the PSF is resampled (see psfs.py L634). By default, for the METIS irdb template (and probably others), the spline order for the interpolation is 1, which, from my tests, it seems to introduce quite a significant error in the morphology of the PSF. Simply increasing the spline order (e.g. 2=bi-cubic) seems to greatly improve the interpolation artifacts without introducing significant computational overhead.

Although the tests I have included in my fork of ScopeSim are very simple (resampling of a Gaussian), I have also tested simulated METIS PSFs from COMPASS, where I encountered errors upwards of 10% in PSF pixel intensity.

Probably related to Issue #247.

Additionally, I have found that in some cases (I believe it is when the PSF has even pixel size, and the central pixel is an integer - i.e. not between two pixels - e.g. METIS PSFs from COMPASS), the rescaling/resampling of the PSF introduces a shift (systematic astrometric error) in the resulting images. I believe this is due to the use of the zoom function in rescale_psf. I haven't looked in detail into this, but the zoom function probably defines the origin and target coordinates to perform inteprolation/resampling either from the centre or the edge of the array, which may result in the PSF centre not being preserved. This error is not present in images generated using GridFieldVaryingPSF, my implementation of a field-variable PSF effect, in which I explicitly define the origin and target PSF coordinates to perform the interpolation.

This is, however, a subject for another Issue when I get the time to put together a more detailed explanation and demonstration.

I changed the default setting of !SIM.computing.spline_order in AstarVienna/irdb@4564bba . I think this was after somebody complained about negative values in the image plane. While cubic interpolation does a better job at preserving the morphology, it is not positive-definite, unlike linear interpolation. A higher-order interpolation scheme that preserves positivity would be optimal, but as it is I took linear to be the conservation choice as a default value. But I'm not in charge any more.

I agree with your second point that zoom should not be used. I also used explicit interpolation between coordinate systems in the method make_psf_cube.

I changed the default setting of !SIM.computing.spline_order in AstarVienna/irdb@4564bba . I think this was after somebody complained about negative values in the image plane.

That makes sense. I am wondering if there is another way to go about it. PCHIP would (probably?) solve this, but I do not believe it can be derived for 2D data. Another possible way to overcome this limitation (although I've never seen it done for PSFs) is to interpolate log(PSF) and then exponentiate, though I don't know if this would exacerbate interpolation artifacts.

Do you perhaps have an example of a PSF (or any 2D array) where this negative overshoot happens so I can experiment with it?