Skip to content

Modeling-related changes to PSF/PRF photometry #48

Closed

Description

@astrofrog

Comments from @eteq, copied from #26:

  • First, a few comments about how astropy.modeling is used here. It looks to me like DiscretePRF and GaussianPSF are the only allowed classes, rather than arbitrary models from astropy.modeling.models. This seems to mostly stem from the use of the fit method of the PSF/PRF classes. Why is this necessary? I can certainly imagine wanting to try other PSF models (most crucially, the Moffat function). So I think it would be better if DiscretePRF and GaussianPSF obeyed standard convnetions for Fittable2DModels, and the work of massaging those models into a form appropriate for psf_photometry should be done elsewhere (either a container class or in the psf_photometry function itself. Otherwise, we effectively have two slightly different model-fitting frameworks
  • Why doesn't GaussianPSF use modeling.models.Gaussian2D? It seems to have implemented all the gaussian behavior separately?
  • Why is the fitter hard-coded into the PSF/PRF class instead of following the convention used in astro.modeling of having it be a separate object? Don't we want to allow other fitting methods?
  • I think it would make sense to try to make psf_photometry and aperture_photometry more consistent. E.g., right now aperture_photometry gets its centers from 2 arguments xc and yx, while psf_photometry accepts a single positions argument. At the very least, these should be the same. It also might be useful to allow using aperture_photometry apertures to define the region in which a star is fit (although maybe that's more of a feature request).

Activity

  1. changed the title [-]Fixes to PSF/PRF photometry[/-] [+]Modeling-related fixes to PSF/PRF photometry[/+] on May 17, 2014
  2. added this to the 0.1 milestone on May 18, 2014
  3. changed the title [-]Modeling-related fixes to PSF/PRF photometry[/-] [+]Modeling-related changes to PSF/PRF photometry[/+] on May 19, 2014
  4. adonath commented on May 21, 2014

    @adonath
    Member

    I'd like to make a few comments on the mentioned issues:

    The fit method should be definitely seperated from the models. If I remember correctly, this is a relict from the old astropy.modeling API, where the fitter had to be instantced with the model.
    Once the psf.fit method is removed from the model it should be fairly easy to make psf_photometry work with arbitrary models.

    The only, but very important, difference is that the evaluation of the GaussianPSF is implemented using the Error function. This is equivalent to integrating the model over the pixel, which avoids a bias of the size and flux for very small sources (~ 1 pixel). One drawback is, that it only works in pixel coordinates so far. It could make sense to move this to 'astropy.modeling' and introduce a Gaussian2DInt model or even have an integrate method for the Gaussian2D model? I remember that similar suggestions were made in the past. What's the status of it?

    cc @eteq

  5. larrybradley commented on May 21, 2014

    @larrybradley
    Member

    This is a more general comment, but I think it would be useful to add methods to the astropy models based on the current options in discretize_model() from the convolution subpackage, i.e. move the discretize methods to the modeling subpackage.

  6. eteq commented on May 26, 2014

    @eteq
    Member

    @adonath - Ah, I didn't appreciate the difference that the photutils version integrates over the pixels. I agree with you that it makes sense to add an integrate method that could be overridden for particular models to do fast analytic integrals to the core modeling package.

    That definitely won't make it for v0.4, though... so two ways to move forward with photutils now:

    • Use the existing class, but just add a clear note in the docstrings about this difference. And also change the name to something like SubsampledGaussianPSF or GaussianIntPSF or something like that to make the distinction clearer.
    • Change to subclassing from Gaussian2D in astropy, but add an integrate_prf method that's customized for that particular class. Then if integral functionality makes it into astropy 1.0, photutils can chagne the implementation for integrate_prf to use that as needed.

    I also agree with @larrybradley that discretize_model would be nice as a method. We welcome PRs! 😉

  7. cdeil commented on Jun 7, 2014

    @cdeil
    Member

    Just so we don't forget, @larrybradley pointed out some concrete suggestions for improvement of GaussianPSF here: #54 (comment)

  8. modified the milestones: 0.2, 0.1 on Oct 21, 2014
  9. removed this from the 0.2 milestone on Apr 29, 2015
  10. hamogu commented on Feb 5, 2016

    @hamogu
    Member

    Reply to @larrybradley (a few comment above at #48 (comment) ): opened astropy/astropy#4572 for that.

  11. added a commit that references this issue on Feb 5, 2016
  12. added 3 commits that reference this issue on Feb 18, 2016
    80d72d4
    ff2aaaa
    4d30617
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    psfphotutils.psf subpackage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions