psf_photometry with masks, output as astropy.table.Table - #159

@hamogu - thanks for working on this! We've been neglecting the PSF sub-package, so it's great to see you are interested in working on it :) I'll try and provide some comments on what's here so far.

This looks good to me so far - I haven't looked in detail at all the code, but why does fit need to be defined specifically in the Gaussian PRF, as opposed to inheriting it from the Discrete class? Basically it seems that the logic in the gaussian fit method is very generic and the code shouldn't be duplicated for all classes, right?

@hamogu - just to check, what is your timescale for working on this? I was planning to have a look at some issues in create_prf but didn't want to do it if it would conflict with this PR.

I am back form vacation and back to working on this. I don't know when I will be finished, though.
If you want to get to the PRF then we can treat that separately.
Ulimately, I think the fit method should probably go into a different place anyway. Maybe a method or a mixin class...

To be clear, I don't see a reason why fit is defined where it is, I just found it there and have not moved it (yet).

@hamogu - The photutils release will be this week on Friday.
This PR is currently milestoned for the 0.2 release, but if you can finish it this week it could go in.

Unfortunately, I won't be able to make that for 0.1. I'm changing positions, move to a different house and need to get things in for astropy before the 1.0 feature freeze. I have not forgotten about the PR but it's not the top of my list currently.

OK ... thanks for the quick reply!

It would help if we could resolve astropy/imageutils#21
since that can (potentially) simplify how I deal with sources on the edge of the field.

I suspect that astropy/#3333 will not make it into 1.0, but I really want to use that here. Can I do that or do we need to support astropy 1.0?

@hamogu At the moment we support Astropy 0.4 in photutils, after the 1.0 release we can discuss if we drop 0.4 support. You can put some version of what you need in photutils/extern to make it work for now, and then at some point in the future we switch to the version in Astropy.

@hamogu, are you still working (or plan to work) on this PR?

@larrybradley : I started that when I worked on a project that needed PSF photometry. I have not worked on that project since 2014, but now I'm back on it. (Hence my recent PRs to photutils and ccdproc). I will get this far enough to do the photometry I need in the next few weeks and then wrap it up to make this PR mergable.
It might not fill all the checkboxes I put in originally (e.g. I might not touch the PRF fitting), but it will help to some degree. Remaining issues can then be kept as a new issue.

Thanks, @hamogu!

@hamogu - in an odd quirk of timing I am re-examining this stuff too (along with @larrybradley and some others at STScI). I'm imagining a more thorough re-vamping of some of this interface to make it somewhat more consistent with the way modeling works. Of particular importance is the removal of the fit method to live either in the driver aperture_photometry function or in customized Fitters that are more transparent and extendable for other kinds of PSFs.

I think a lot of that is orthogonal to what you're saying here though, so that's promising... Of particular interest to me right now is your third bullet, the Table input/output. Have you done that already on your local version? If so, maybe you can do that in an independent PR so that it can be dealt with separately? (Unless your changes make that too intermixed...)

I an really odd quirk of timing I just started working on this again yesterday afternoon (about 3 hours before this message) and decided that it's not worth fixing this in the old way the models are defined. Also, there are far too many issues that are related in some way (#254, #189, #144, #63, #49, #48, #43), most of which can be addressed easily the migrating to the new models interface.
So, I just started out fresh to migrate the models to the new modelling interface, but I did not get very far because I had to go home early.

@eteq Maybe we can have an impromtu 10 min telecon / phone call today and see how we divy that up without dublication?
I have a seminar from 11am - 1 pm - before or after would work.

@hamogu - sounds good, I sent you an email with availability (I think I sent it to the right address... Let me know if not.)

@hamogu - after a bit more thought, I'm not sure it will be so easy as I said here... RTD might have an issue installing pandoc (which is needed for the nb->RST machinery in nbconvert). I think the best thing is to just merge this and see, though. If it turns out we have to do what you say (generate the RST and check that in), then we can do that in a second PR, but it's often tough to diagnose RTD problems anywhere other than the "real" branch...

Looks like the one remaining failure is in the spitzer notebook, and I can reproduce that locally. Will try to fix that now, but if I can't do it by the end of today, shall we just re-name the extension so that it doesn't get run, and pull the trigger?

I introduced more failures during the rebase. I'm trying to diagnose that now. I'll report back in 5-10 min.

Oh, apparently I was looking at and old Travis. Agreed. Fix today or shoot.

Alright, I'm going to go ahead and merge this with a partial but not fully-functional, renamed version of the spitzer notebook. Will fix in the near future. I'll also go ahead and add some relevant issues.

Many thanks, @hamogu and @eteq!

@hamogu - This rather big PR doesn't have any trace in the changelog.