This rearranges some of the photometry settings and adds an AperturePhotometry class

[mwcraig]

There are still a couple things to be resolved:

• Should single/multi image photometry become methods of AperturePhotometry?
• Is AperturePhotometry even needed?

Marking this as a draft for the moment, but if you get a chance to take a peek, @JuanCab, feedback would be welcome. WOn't get back to it myself until Sunday.

[codecov-commenter]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (f63f2cc) 70.22% compared to head (3bd9301) 70.53%.
Report is 3 commits behind head on main.

❗ Current head 3bd9301 differs from pull request most recent head fece598. Consider uploading reports for the commit fece598 to get more accurate results

Files	Patch %	Lines
stellarphot/photometry/photometry.py	96.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #275      +/-   ##
==========================================
+ Coverage   70.22%   70.53%   +0.31%     
==========================================
  Files          24       24              
  Lines        2992     3024      +32     
==========================================
+ Hits         2101     2133      +32     
  Misses        891      891              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JuanCab]

So far looks like a strong first step re-organizing the settings to be more clearly delineated and also to work toward the object-oriented model of photometry we talked about. Not "approving" because it is a draft, but looks like a lot of good stuff here.

[JuanCab]

Obviously this will need some more fleshing out, but I like that you are getting the documentation in place. You may want to mention for situations where the users may not be comfortable yet with the command line or Python programming, a Jupyter-notebook-based set of tools is available to configure stellarphot and run the photometry.

Also, do we want to note this is meant to be used on REDUCED images (or am I wrong here)? I don't remember any processing of flats/darks/etc, which I believe is because we were working with reduced images.

[JuanCab]

Isn't fname redundant if the value of file_or_directory already automatically switches whether it is single image processing or multi-image processing based on it being a file or directory. Do you want to support wildcard (e.g. glob) processing of filename?

[mwcraig]

Good point about the file name!

I think for the moment maybe we stick with just a directory for multi-image but move towards being able to process anything the ccdproc ImageFileCollection can handle.

[mwcraig]

Next up will be better documentation and fleshing out the couple of widgets that still need to be done.

[mwcraig]

@JuanCab what do you think about these two questions:

• Should single/multi image photometry become methods of AperturePhotometry?
• Is AperturePhotometry even needed?

[JuanCab]

@JuanCab what do you think about these two questions:

• Should single/multi image photometry become methods of AperturePhotometry?
• Is AperturePhotometry even needed?

Unless you somehow want to leave the possibility open for other kinds of photometry to be done as single or multi-image, it seems to make sense to me to keep AperturePhotometry as descriptive of the task it handles. I could see that just to avoid being overly long with the function names which might call them single_image and multi_image since the 'photometry' would be redundant if they are in the AperturePhotometry class.

[JuanCab]

I had to use Sublime Merge to see the changes since GitHub wasn't as clear about what changed since the last update. But the changes all look reasonable.