Repository navigation
PSF / PRF extraction method #104
Description
In this issue I'd like to discuss if the current PRF extraction and application method makes sense or whether it can be replaced by an oversampled PSF estimation.
cc @astrofrog @bsipocz @larrybradley @adonath @eteq
Current method
@adonath implemented as part of his GSoC the create_prf function, which creates a DiscretePRF object which is then used via psf_photometry for PSF fitting photometry to estimate source fluxes (and optionally positions). A full example for Spitzer data analysis using this is here.
If I understand correctly the DiscretePRF class represents the PSF pre-sampled for a 2d grid of sub-pixel positions (i.e. 100 PSF images for an oversampling factor of 10), and the way PRF estimation in create_prf works is that only stars where the position falls into a given sub-pixel are used in psf_photometry when fitting data with that PRF.
The problem
The problem with the current approach is that if the number of stars is limited, then there will be subpixels with few or no star to estimate the PSF for that subpixel, resulting in failing or poor psf_photometry results.
A proposal
How about instead of a function create_prf that estimates a DiscretePRF model, we write a create_psf function that estimates a DiscretePSF model?
But instead of being a 4-dimensional array like DiscretePRF of shape (nx, ny, n_subpix, n_subpix) it's a 2-dimensional array of shape (nx * n_subpix, ny * n_subpix), i.e. simply a high-resolution image of the PSF ... if I'm not mistaken that's also the format psfex uses.
create_psf would re-sample the stars onto this high-resolution image and then psf_photometry would re-sample the high-resolution PSF image onto the actual data grid or pre-compute a PRF object if that is actually needed for speed.
The big difference would be that the PSF used in psf_photometry for every star would contain the info from every star available for PSF estimation, thus largely getting rid of the problem described above.
Am I missing something and there's a good use case for the current method that would not be covered by this alternative proposal? If so, can you please point me to a webpage or paper describing why it's better?
Activity
astrofrog commentedon Jun 17, 2014
Deriving PSFs/PRFs
I think that there are use cases for both, and I think that both should be implemented. If we used the technique you are suggesting, going from real data -> oversampled PSF -> PRF some information is lost along the way. If enough stars are present, the current
create_prfroute is the most accurate. Butcreate_prfis not useful if there are not enough sources, as you say so I agree a different approach such as the one you are suggesting is then needed.Maybe the key here is that there is not just one way to make a PSF/PRF. One could imagine wanting to use a gaussian PSF with parameters that vary linearly over the image, and fit that to the data, etc. So maybe what we really need to figure out here is how to support various algorithms for deriving PRFs or PSFs.
Fitting PRFs/PSFs
I think there is also a case to be made for allowing both PRFs (basically pre-sampled PSFs) to be fit to data, but also allowing full PSFs to be fit. If one wants to fit a single source with a spatial model + PSF then there is no point in pre-sampling the model since it depends on the underlying spatial model. More generally, if a PSF has a parameter controlling the spatial distribution, pre-sampling is no longer worthwhile. So I think we need to allow for both cases - fitting PRFs, and fitting PSF models.
There are links between the two, such as the ability to derive a PRF from a non-spatially-dependent PSF, but other than that the two routes seem pretty different and could co-exist.
cdeil commentedon Jun 17, 2014
@astrofrog It's not clear to me what useful information is lost ... do you know of any paper that describes a use case where PRF fitting as implemented here is better (more accurate and / or faster) than an oversampled PSF as I propose above and implemented by the standard
psfextool?astrofrog commentedon Jun 17, 2014
@cdeil - actually I think I don't understand enough about how the over-sampling of the PSF is done in e.g. psfex. Is it doing some kind of bilinear interpolation? Or does it put it on a higher-resolution grid with nearest-neighbor interpolation?
I think in any case what I really mean is that we might want to allow more than one algorithm for creating PSFs/PRFs, so it's worth thinking about whether this would be handled by different functions, or a single function with a keyword argument.
It sounds like either way the algorithm you are suggesting would be more robust since it doesn't require many sources to be present, so it would be worthwhile to implement, and probably make the default.
cdeil commentedon Jun 17, 2014
@astrofrog Agreed that we can have multiple classes and methods for estimating and applying PSFs in photutils. But we should focus our limited time on the most useful method and finishing what is currently implemented in photutils is no small task (see e.g. #48, #49, #63, no docs) and I'm wondering if it wouldn't be more useful for @bsipocz (and maybe @adonath and me if we find the time) to work on a new
extract_psffunction andDiscretePSFclass and makepsf_photometrywork with those.Whether
extract_prfandDiscretePRFremains inphotutilswould then depend on whether someone has the time and motivation to add tests / docs for those before the photutils 0.1 release.Concerning your question what kind of interpolation should be done for the PSF ... that's an important implementation detail we can discuss in a new issue (probably it's not hard to support a few common methods) ... this one I labeled "question" and I just wanted to understand if it's worth finishing
extract_prfandDiscretePRFto production quality.astrofrog commentedon Jun 17, 2014
@cdeil - I completely agree. As you suggest, I'd like to keep the current PRF-related stuff somewhere in photutils for now (I was just worried you wanted to throw it out straight away). Once the new stuff is in place, I'd like to take a look over and if I think the current stuff should also stay, I can add tests/etc. for it but I'm +1 on removing it if we decide it's not useful or worthwhile maintaining.
eteq commentedon Feb 19, 2016
I'm going to close this as it seems to have been tied more to the specific time it was written. but it can be reopened if need be.