Shift distorted PSFs back to correct detector position

[shanosborne]

When distorting a PSF, now the indices we interpolate from and on to have (approximately) the same center point. This fixes issue raised in #226

[shanosborne]

Tables show for different detector positions, the original offset between the center of the sci and new indices (the indices we interpolate from and to respectively). The 3rd column is the value we get from the average x/y new minus the average x/y sci value. And the last column is the new offset between the center of the sci and new indices if we subtract the value in the 3rd column from the new indices.

And this is the result: These show the same NIRCam PSF at detector position (0,0) before and after this change

Before:

After:

[mperrin]

This looks good. Can you briefly explain / summarize the changes in algorithm you made to implement this fix?

[mperrin]

We should also check with @Johannes-Sahlmann about what level of precision is appropriate here. The residuals in the table above are a few parts in 1000 of a pixel, which is indeed quite small and I expect is good enough for all current or near future purposes. Yes? Eventually I'm sure someone will be doing millipixel astrometry with JWST but not soon...

[shanosborne]

So I decided on a better/more logical way to fix this issue. Basically what happens is when the sci indices are run through the idl_to_sci transformation, the output indices are no longer exactly centered on the initially set PSF location. So what this fix does is move the sci indices back to the initial PSF location after they’ve been run through the pysiaf transformation. And I do this with the lines:

6. Shift the sci indices so they match the PSF's position again (moved slightly off from pysiaf calculation)
   xsci += xpix_center - np.median(xsci)
   ysci += ypix_center - np.median(ysci)

So now the center point of the sci indices matches the center point of the new indices, and you get the results below (this is for the (0,0) case):

[mperrin]

That makes sense.

Minor question, would it make any practical difference to use mean instead of median? It seems to me that the intent of this is something along the lines of

xsci += xpix_center - center_value_of_xsci

(i.e. force the center pixel value to be the same between xsci and xpix). In practice the median value is probably very close to the mean, and to the value at the exact center of the array, so probably I'm over-thinking this.

The Travis build appears to be failing because it's trying to run test cases on Python 2.7 still. If you git merge master back into your branch, or rebase on current master , then you ought to be able to get the updated .travis.yml file so that it only tries running the tests on Python 3.

[shanosborne]

Yes, xsci += xpix_center - center_value_of_xsci is exactly what I'm trying to do. I was also thinking about median vs mean. The difference is small (in the case of the NIRCam F200W (0,0) PSF, the difference between the mean and median for the sci indices is around 0.01. And there is no difference between the mean and median for the new indices). I thought median might be correct since we're dealing with integer pixel indices, but maybe since that idl_to_sci transformation is applied, this is the wrong way to think about it.

Also - my .travis.yml file is the same as the version in the spacetelescope master. Is it possible that that change is only in mperrin/webbpsf?

[coveralls]

Pull Request Test Coverage Report for Build 23

• 4 of 4 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.03%) to 38.209%

---

Totals
Change from base Build 15:	0.03%
Covered Lines:	1805
Relevant Lines:	4724

---

💛 - Coveralls

[shanosborne]

So I wanted to check back in with this - should I use the mean to find the center location of the PSF in this case?

[mperrin]

As discussed in email and in person - the current implementation with median is accurate to about 0.01-0.02 pixels. That’s good enough for almost all purposes. So we’re going to go ahead and merge this now, and if more carefully handling of the centering becomes necessary in the future we’ll fix it up more precisely then.