-
Notifications
You must be signed in to change notification settings - Fork 103
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
Galsim Convolution vs scipy fftconvolve #1215
Comments
To me the difference image looks like a difference in centroiding conventions of some kind. Rather than a purely visual comparison, have you run As you noted, the other difference could be pixel response. I don't see in that code snippet where you've drawn |
Seems like some kind of indexing or centroiding difference-in-assumption from scipy. Note also that if you change the array size from |
I've been looking for (and so far haven't found) a thread on the Rubin slack where I described a similar problem. I was mixing numpy and scipy forward and inverse FFTs and there were subtle differences in the location of the center of the coordinate system which were causing similar issues. I think this also supports Rachel and Josh's suggestions above. |
@jecampagne Since you can look at it take a peek at: https://lsstc.slack.com/archives/C2JPL8U78/p1569271022132800 From Fred M. "Gotcha. One last tip for when you get back. The inconsistency that I mentioned is due to where the “center” is chosen for an array with an even number of pixels. I don’t remember the details but it basically comes down to the choice of choosing the center-left pixel or the center-right pixel as the center for a dimension that has an even number of pixels. Some of the numpy/scipy internal algorithms with FFTs use the center-left while others use the center-right, so their slicing algorithms are tricky to mimick." Try using an odd size (say 129 x 129) and see if the problem disappears. |
I think @cwwalter you point to the right source of pb : below see the difference of Galsim vs scipy_ fftconvolve usign either a 128x128 image or a 129x129 image. So, the source is identified +1, but I guess this numerical artifact can blow up in a another use case. |
BTW, I have used the |
This is clearly just a convention difference in where to put the center of the result. IMO, GalSIm does it right, but as long as you know what to expect in terms of centering for the others, then they aren't really wrong either. I think this can be closed. |
As Mike says, this is a convention. I found this difference when trying to mix the FFT/Convolve routines between numpy and scipy. Galsim wasn't even involved. So, the main lesson I took away from that is that you need to use a consistent set of those routines from the same package. Fred and Peter wrote their own routines for Scarlet partly for these reasons (see that discussion I linked above). If you know if is just the centering convention, and you still want to mix things, you can use the trick of picking odd sizes to remove the ambiguity. [I think trying to adjust things back and forth to make it work anyway is too dangerous, you probably won't be able to do it correctly consistently and is a recipe for mistakes] |
Ok. close the thread. Sorry to have made troubles. mea culpa. |
This was certainly confusing for me too when I first heard came across it and I also had to ask for help. So, I'm glad you were able to understand your use case too. |
Hi,
I was questioning the Galsim convolution algo and I have made a simple exo using version 2.4.8 (the Galsim version install was done through JAX-Galsim as the direct install of GalSim in Colab fails, see my previous issue)
Does one fully understand the difference between the convolution done by Galsim and FFTconvolve ?
Thanks
JE
PS: the effect of the Pixel convolution is 2 order of magnitudes smaller than the difference between Galsim and scipy fftconvolve.
The text was updated successfully, but these errors were encountered: