Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simple Aperture Photometry: Gaussian1D fitting for radial profile #1409

Merged
merged 9 commits into from
Jul 1, 2022

Conversation

pllim
Copy link
Contributor

@pllim pllim commented Jun 22, 2022

Description

This pull request is to enable Gaussian1D fitting for radial profile in the Simple Aperture Photometry plugin.

(Screenshots a bit outdated, but you get the idea.)

Screenshot 2022-06-22 145608

Screenshot 2022-06-29 154805

TODO

Checklist for package maintainer(s)

This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.

  • Are two approvals required? Branch protection rule does not check for the second approval. If a second approval is not necessary, please apply the trivial label.
  • Do the proposed changes actually accomplish desired goals? Also manually run the affected example notebooks, if necessary.
  • Do the proposed changes follow the STScI Style Guides?
  • Are tests added/updated as required? If so, do they follow the STScI Style Guides?
  • Are docs added/updated as required? If so, do they follow the STScI Style Guides?
  • Did the CI pass? If not, are the failures related?
  • Is a change log needed? If yes, is it added to CHANGES.rst?
  • Is a milestone set?
  • After merge, any internal documentations need updating (e.g., JIRA, Innerspace)? 🐱

@pllim pllim added the 💤 enhancement New feature or request label Jun 22, 2022
@pllim pllim added this to the 2.7 milestone Jun 22, 2022
@github-actions github-actions bot added documentation Explanation of code and concepts imviz labels Jun 22, 2022
@codecov
Copy link

codecov bot commented Jun 22, 2022

Codecov Report

Merging #1409 (03f0e5f) into main (5d0511f) will increase coverage by 0.03%.
The diff coverage is 94.33%.

@@            Coverage Diff             @@
##             main    #1409      +/-   ##
==========================================
+ Coverage   85.13%   85.16%   +0.03%     
==========================================
  Files          91       91              
  Lines        8321     8359      +38     
==========================================
+ Hits         7084     7119      +35     
- Misses       1237     1240       +3     
Impacted Files Coverage Δ
...imviz/plugins/aper_phot_simple/aper_phot_simple.py 92.19% <94.33%> (-0.02%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5d0511f...03f0e5f. Read the comment docs.

@pllim pllim marked this pull request as ready for review June 22, 2022 19:44
@pllim pllim requested a review from larrybradley June 22, 2022 19:44
@larrybradley
Copy link
Member

larrybradley commented Jun 28, 2022

I don't see the fitted Gaussian1D parameters. The main use case for the fitting is to get an estimate of the FWHM of the Gaussian fit.

Also, when I use the fit on the "Raw Radial Profile" there seems to be 2 magenta lines (2 fits)?

Screen Shot 2022-06-28 at 1 41 13 PM

@pllim
Copy link
Contributor Author

pllim commented Jun 28, 2022

I don't see the fitted Gaussian1D parameters

You get the fitted model via API.

So, are you saying you want the fitted FWHM to be displayed under GUI results?

@pllim
Copy link
Contributor Author

pllim commented Jun 28, 2022

2 magenta lines (2 fits)

Looks like the previous plot didn't clear properly? I'll investigate.

@larrybradley
Copy link
Member

So, are you saying you want the fitted FWHM to be displayed under GUI results?

Yes. All of the fitted Gaussian parameters.

@pllim
Copy link
Contributor Author

pllim commented Jun 28, 2022

All of the fitted Gaussian parameters

x_mean would be pretty useless, no? It will be zero-ish.

@larrybradley
Copy link
Member

x_mean would be pretty useless, no? It will be zero-ish.

It's not because no-recentering is happening. I think we should recenter, in which case the mean would be useless.

@pllim
Copy link
Contributor Author

pllim commented Jun 28, 2022

By re-centering, do you mean moving the Subset to new center, or just in the number crunching?

@larrybradley
Copy link
Member

Number crunching, not moving the Subset. I expected the radial profile to always be centered on the source centroid. It would be very hard to manually position the Subset to be centered at the source centroid.

@pllim
Copy link
Contributor Author

pllim commented Jun 28, 2022

Re: #1409 (comment) -- turns out the data points were unsorted, not related to plot clearing. FYI.

@pllim
Copy link
Contributor Author

pllim commented Jun 28, 2022

I think I addressed most of the review comments but am waiting to hear back from @larrybradley about recentering.

@@ -379,6 +417,15 @@ def vue_do_aper_phot(self, *args, **kwargs):
f'{x:.4e} ({phot_table["aperture_sum_counts_err"][0]:.4e})'})
else:
tmp.append({'function': key, 'result': str(x)})
# Also display fit results
if fit_model is not None and isinstance(fit_model, Gaussian1D):
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The isinstance check is future-proofing because it is just a matter of time before someone asks for Moffat.

@pllim
Copy link
Contributor Author

pllim commented Jun 29, 2022

@larrybradley , I think I have addressed all your comments. Please re-review. Thanks!

to the radial profile, the last fitted model can be obtained by as follows.
See :ref:`astropy:astropy-modeling` on how to manipulate the model::

my_gaussian1d = imviz.app.fitted_models['phot_radial_profile']
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can this conflict with anything else? We don't have the model fitting plugin for imviz, so probably won't be a problem unless we every include aperture photometry in a viz that does include model fitting, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What might be Cubeviz but none of that is even planned right now. Ideas welcome though. I am just trying to hook into existing machinery instead of creating even more API.

@larrybradley
Copy link
Member

larrybradley commented Jun 29, 2022

@pllim The radial plot titles all still say "from Subset center". Those should now say "from Source centroid".

Also, I still don't see the output of the Gaussian1D fitted parameters. Where are those?

The plots look nice.

Copy link
Member

@kecnry kecnry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems to work well, and results clear from the table as would be expected when alternating between the different plot types.

@larrybradley
Copy link
Member

@pllim To be clear, the fitted Gaussian1D parameters should be in a section separate from the ApertureStats calculated values.

Comment on lines +378 to +380
gs = Gaussian1D(amplitude=y_max, mean=0, stddev=std,
fixed={'mean': True, 'amplitude': True},
bounds={'amplitude': (y_max * 0.5, y_max)})
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is hopefully now similar to spacetelescope/imexam#241 (comment) .

@larrybradley , please test this PR branch on some real data and let me know if this works as you expected. Thanks!

Copy link
Member

@larrybradley larrybradley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @pllim. This looks great.

The curve of growth plot title still says "from subset center" instead of "from source centroid."

@pllim
Copy link
Contributor Author

pllim commented Jul 1, 2022

@larrybradley , I didn't realize curve of growth was in scope too. I have pushed a commit for it. Please let me know if this is what you want. Thanks.

Copy link
Collaborator

@duytnguyendtn duytnguyendtn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ran into a bug I think? When fitting for a subset works well as expected. But when I move the subset/redefine it on another star and click "Calculate", the chart doesn't update

@duytnguyendtn
Copy link
Collaborator

Video of the above bug:

ImvizExample.-.Jupyter.Notebook.-.Brave.2022-07-01.14-39-43.mp4

@pllim
Copy link
Contributor Author

pllim commented Jul 1, 2022

Ran into a bug I think?

Yes, looks like the plugin is not listening to subset edit events. It is using cached info that is outdated. But this bug is not related to this PR, so can we open a new issue for that instead? Also, I think this plugin was written before @kecnry wrote the template mixin stuff, so I wonder if this bug will naturally go away if we refactor the plugin to use Kyle's mixin classes.

@pllim
Copy link
Contributor Author

pllim commented Jul 1, 2022

Currently, to get around the bug, if you go to the "Aperture" dropdown and reselect the subset, it will update properly.

@pllim
Copy link
Contributor Author

pllim commented Jul 1, 2022

p.p.s. When I wrote this originally, I might not have even realized you can go back and edit a subset after you finalized it.

@kecnry
Copy link
Member

kecnry commented Jul 1, 2022

Agreed this bug was not introduced here, so can probably be considered out of scope and filed as a separate bug.

But now that I did some digging, I'll report my findings here for when we do get back to it: aperture photometry does use the template mixin, but then also does its own caching which is why this is breaking. Since it is also using the change to subset to update defaults for things like the background annulus, we may want to think of ways to generalize that type of situation a little better. The quick-and-dirty fix would be to just trigger _subset_selected_changed on every SubsetUpdateMessage... but there's probably significant overhead there that can be avoided.

Copy link
Collaborator

@duytnguyendtn duytnguyendtn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the other bug I mentioned earlier being out of scope, this looks good! My only other suggestion is the ability to turn OFF the centroiding? I wonder if there are use cases we can't think of here where the user might want the raw result? Having an option to disable the centroiding might be a good option to provide? It would also clarify explicitly that centroiding is happening, beyond just the title (which some users may skim over)

@pllim
Copy link
Contributor Author

pllim commented Jul 1, 2022

My only other suggestion is the ability to turn OFF the centroiding?

I think this came up during one of the tag-ups. I am very hesitant to add more GUI to this plugin as it is already very crowded and Larry cannot think of a good reason why someone would not want centroiding.

@duytnguyendtn
Copy link
Collaborator

Perhaps I'm the minority here, in which case I'm happy to be outvoted, but I'll file my dissent here anyways :)

I'm generally a fan of providing additional functionality regardless of whether we can or cannot think of a good reason. It allows our tools to be more responsive to usecases we can't think of that are outside of our perspective; though I can understand the UI concerns, though I feel like a small crosshair icon (like for "aim assist" in FPS games) wouldn't be too obstructive in this case 🤷

@pllim
Copy link
Contributor Author

pllim commented Jul 1, 2022

Maybe centroiding toggle can be a new issue too? 😸

@kecnry
Copy link
Member

kecnry commented Jul 1, 2022

I already briefly mentioned my thoughts on the switch on the call, but I'll add them here too in case we ever revisit. I think a switch serves two purposes:

  1. allowing increased flexibility. I can imagine a case where you intentionally (maybe with the API) set the position of the subset to be off-centroid and want to see the profile as-is... although that may not be all that common. (My example was blended sources or background contamination that move the technical centroid away from the location you want).

  2. self-documents the behavior. The presence of a switch and its descriptive text also tells the user that this re-centroiding will happen by default, without having to dig into the documentation. And I think it does so more effectively than a text blurb.

(But I'm fine with postponing that decision/implementation)

@duytnguyendtn
Copy link
Collaborator

@kecnry said it much more eloquently than i did, but yes 💯 agree

@pllim
Copy link
Contributor Author

pllim commented Jul 1, 2022

Since the original intent of this PR is approved twice, I am going to merge. I opened two follow up issues here:

Thanks for the thorough reviews!

@pllim pllim merged commit 050b62d into spacetelescope:main Jul 1, 2022
@pllim pllim deleted the fit-line-to-histogram branch July 1, 2022 20:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Explanation of code and concepts imviz Ready for final review 💤 enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants