How to pick a stamp size about piff

[rmjarvis]

There is a stamp_size argument to the draw command, which I think does what you want. See the doc string for more information.

https://github.com/rmjarvis/Piff/blob/master/piff/psf.py#L105

[rmjarvis]

Or do you mean having the PSF object try to estimate its own extent? No I don't think there's any way to do that currently.

I guess if you know the Piff configuration, you could try to estimate it more intelligently. E.g. for DES Y3, I used a 17 x 17 PixelGrid type with 0.26 arcsec/pixel. So anything outside of that box would be zeros.

But I don't think there is any API currently for accessing that information from the read in psf object. That would be a nice feature to add.

[esheldon]

Yes, I meant how can we choose the size intelligently.

By the way there are definitely cases where 17x17 was too small. Would it be good for the next DES run to pick something bigger, like 25x25 ?

attached an example

[rmjarvis]

Or probably ought to exclude fields where the seeing is so large that the PSF spills out of a 4 arcsec box... At least for WL analyses.

The running time of the slowest part of the code scales as something like npix^3 I think. (Definitely at least npix^2, but I think it's ^3.) So going to 25x25 would be like an order of magnitude slower to run.

[esheldon]

These were not that uncommon, so we might have to throw out a fair amount of data. It is probably worth looking into how many and if we can choose them algorithmically

[esheldon]

however, there does seem to be a correlation between very wide and the other failures we saw, so maybe some of these are spurious

[esheldon]

I calculate that image had 1.6'' seeing. We could indeed cut those if we wanted.

[rmjarvis]

I'll go a little bigger just to be safe. I'm already doing 0.30 arcsec pixels, so if I go to 19x19, that will be 5.7 arcsec across. Seems like that should cover everything we'll care about. And not too much slower.