Anti-aliased apertures needed to increase numerical accuracy

[douglase]

As discussed in #106, 'gray' aperture edges, would decrease high-order aliasing and allow one-to-one comparison of POPPY Fresnel systems (#103, #108) with their PROPER equivalents.

[mperrin]

I started work on antialiasing in a private branch a while ago (> 6 months), but ran into some bugs and didn't yet have a chance to get back to debugging it. I don't recall the details now. I probably ought to go ahead and push that branch here, and perhaps we can collectively dig into it again.

I'm tied up in meetings for all this week so this probably won't happen right away.

[mperrin]

Two possible routes to implementation:

I've just noticed the photutils package has a sub package geometry which implements in Cython functions for sub pixel exact calculations of circular and rectangular apertures. We could make use of this in poppy - either by just calling that code if photutils is installed, or including a copy of that code as part of poppy (it's BSD3 and astropy affiliated so the licenses are compatible). I'm not sure we want to add a Cython module into the poppy code base given the potential installation and support headaches though?

The other path would be finishing up the implementations using the pure-python subpixel algorithms in my own code. I've just pushed the subpixel_geometry branch to here on github. Warning, this branch does not work yet! Various tests fail, I'm not sure why. I literally have not looked at this code in any detail in about a year, so my memory is hazy at best. But this presumably could be debugged if someone has attention to devote to it.

[mperrin]

Still want to get this done - but it's not happening this week.

[mperrin]

See comments on #180 for an example of the improvements from sub-pixel sampled optics. Yes, we should still come up with some more general solution for this.

For the AnalyticOpticalElement style JWST pupil shown in #180 I simply used the matplotlib.path.Path.contains_points method, implemented brute force and inefficiently for every pixel in the full and thus slowly. If we were to use something like this more generally, we'd want to be more clever about selecting only a subset of pixels near the edge to perform the detailed calculation on.