Missing 'basisspline'

[keflavich]

A package basisspline is referenced here:

crowdsource/crowdsource/crowdsource_base.py

Line 1032 in d0bb2eb

import basisspline

Where can I get that module?

[schlafly]

Thanks Adam. Good catch. This line
https://github.com/schlafly/crowdsource/blob/master/crowdsource/crowdsource_base.py#L1032
should read from crowdsource import basisspline.

I originally intended the sky fitting & source fitting to occur simultaneously, since this is all linear and we might as well. However, at some point during DECaPS I ended up prefering to fit either a constant sky model or no sky model at all as part of the primary linear fit that fits the source fluxes. As a result the higher order sky models that use that basis have seen very little action, so it might be a good thing that there's a stumbling block here!

You're welcome to try out the higher order sky models, though perhaps we should chat about your use case. I suspect you'll be able to get away with nskyx = nskyy = 0 or 1, and let the higher order median filter absorb the sky signal. My vague recollection is that I wrote the higher order linear sky fits in a memory inefficient way, with the intent of someday returning to them---the individual basis splines will be 0 over most of the image and so call out for sparse representation, but I don't think I actually coded that up.

[keflavich]

...ok that was a trivial fix, and I should have found it on my own.

I wasn't intentionally trying to use the higher-order fitting - I just copied the usage example at the top of the file blindly. I'll try the lower-order fitting first.

My use case right now is JWST data. Specifically, extremely crowded fields in the Galactic center.

[schlafly]

Yes, sorry, the documentation could use some help.

Is the JWST PSF well sampled or not? The PSF modeling will be marginal for an undersampled PSF, because the default picture is that dPSF/dx = np.gradient(PSF), and that you can do things like ndimage.shift(...) to get rid of sub-pixel shifts. I think the code is generic enough that one could imagine adding an undersampled or a specialized Webb PSF model and it would do the right thing. If you're just going to let it fit its own PSF it will essentially presume that it's well sampled and won't get the subpixel shifting, etc., right.

[keflavich]

The PSF models can be arbitrarily well-sampled since they're produced from models of the whole optical system (https://webbpsf.readthedocs.io/en/latest/). I think in the images, they're also potentially well-sampled because of drizzling. However, the drizzling pipeline probably has imperfect registration, so the PSF is getting blurred from the optimal models.

I'm iterating with @andrew-saydjari now by e-mail - he's been helping me tune some of the parameters of crowdsource to get to a better set of solutions.

[schlafly]

I'll let you and Andrew get to it. But for what it's worth, I agree that one could sample the PSF well on some fictitious set of pixels---my question is more about how well things are sampled on the actual set of pixels that crowdsource is going to run on. Yes, if you have enough dithers and have constructed some stacks using drizzle to ~fill out the PSF, then that sounds like it could work not terribly far from "out of the box."

[keflavich]

I think at the long ends of the JWST bands (near 4 microns and near 2 microns for the long- and short-wavelength channels), it's well-sampled, but for the short ends (2.5 microns and 0.9 microns, give or take) it's not. So probably a specialized approach for undersampled pixels is going to be necessary at some point.

[schlafly]

Sounds good. Watch out for poor PSF fits on the blue end, then; I expect that when the code goes to do the subpixel shifting to center everything up, it's going to blur the PSF and lead to challenges. Likewise when we go to evaluate the PSF off center.
We'll probably need to write a special undersampled PSF module & undersampled PSF fitting module, but the main source flux fitting routine should be blind to this.