Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PSF rescaling (resampling) should probably use higher spline_order #282

Open
joao-aveiro opened this issue Oct 4, 2023 · 4 comments
Open

Comments

@joao-aveiro
Copy link
Collaborator

joao-aveiro commented Oct 4, 2023

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.

@joao-aveiro
Copy link
Collaborator Author

Probably related to Issue #247.

@joao-aveiro
Copy link
Collaborator Author

joao-aveiro commented Oct 4, 2023

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.

@oczoske
Copy link
Collaborator

oczoske commented Oct 4, 2023

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.

@joao-aveiro
Copy link
Collaborator Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📋 Backlog
Development

No branches or pull requests

2 participants