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

Fix aperture photometry result for WCS linked dithered non-reference data #1524

Merged
merged 7 commits into from
Sep 8, 2022

Conversation

pllim
Copy link
Contributor

@pllim pllim commented Jul 24, 2022

Description

This pull request is to address a critical but subtle bug where aperture photometry gives inaccurate result when photometry is performed on a non-reference data that is dithered from reference data and they are linked by WCS.

This works around glue-viz/glue-astronomy#52

Fixes #1508

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 bug Something isn't working label Jul 24, 2022
@pllim pllim added this to the 2.9 milestone Jul 24, 2022
@github-actions github-actions bot added the imviz label Jul 24, 2022

# Sometimes the mask is smaller than radial_r
if radial_cutout.shape != reg_bb.shape:
radial_r = radial_r[:radial_cutout.shape[0], :radial_cutout.shape[1]]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@larrybradley , in my test case (10 x 10 images dithered by 1 pix with mask off-limit a little for second image when linked by WCS), ApertureStat bounding box shape can be different from the cutout shape. Is this the right way to handle it?

@codecov
Copy link

codecov bot commented Aug 24, 2022

Codecov Report

Base: 86.35% // Head: 86.37% // Increases project coverage by +0.01% 🎉

Coverage data is based on head (6cfe418) compared to base (1c9fef2).
Patch coverage: 95.83% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1524      +/-   ##
==========================================
+ Coverage   86.35%   86.37%   +0.01%     
==========================================
  Files          94       94              
  Lines        9410     9428      +18     
==========================================
+ Hits         8126     8143      +17     
- Misses       1284     1285       +1     
Impacted Files Coverage Δ
...imviz/plugins/aper_phot_simple/aper_phot_simple.py 92.05% <95.65%> (+0.12%) ⬆️
jdaviz/configs/imviz/helper.py 96.61% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@pllim pllim marked this pull request as ready for review August 24, 2022 03:09
@rosteen rosteen modified the milestones: 2.9, 2.10 Aug 24, 2022
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.

Does anything (cached background, populated inputs based on the subsets, etc) in the aperture photometry plugin need to listen to changes in the linking and update?

Besides that question, it's hard to test and know what changes I should expect to see, but I couldn't get it to crash and the code looks reasonable! 🤷

@pllim
Copy link
Contributor Author

pllim commented Aug 25, 2022

aperture photometry plugin need to listen

I do not think so because the plugin grabs stuff out of data only when Calculate is pressed. So if linking has changed, etc, that would naturally propagate...

Theoretically, we can test that by expanding the unit test to relink back to pixels and check if the answer will be wrong again. Do you want me to do that?

@kecnry
Copy link
Member

kecnry commented Aug 26, 2022

I do not think so because the plugin grabs stuff out of data only when Calculate is pressed.

It looks like background_value is used by vue_do_aper_phot which defaults when the background subset is changed. I think a change to linking might just need to trigger _on_subset_update for all subsets (since the pixels the subset covers may have been affected by a change in the linking).

I wonder if there's any way we could do this from the linking plugin instead - by sending subset update events to anything that already listens to them, since this likely applies to more places than just aperture photometry?

@pllim

This comment was marked as resolved.

@pllim pllim modified the milestones: 2.10, 2.11 Aug 26, 2022
@pllim
Copy link
Contributor Author

pllim commented Aug 27, 2022

Re: #1524 (comment)

Okay, I see what you are saying. The background does not auto-update when linking is changed but it does update when you re-select the Subset.

Since you are working on a new "link message" over at #1598, maybe I can add a note about this behavior and revisit this later.

if Version(astropy.__version__) <= Version('5.1'):
fitter_kw = {}
else:
fitter_kw = {'filter_non_finite': True}
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 coverage will complain about this because this is tested in the dev deps job but we do not calculate coverage for dev deps.

@kecnry
Copy link
Member

kecnry commented Aug 29, 2022

Since you are working on a new "link message" over at #1598, maybe I can add a note about this behavior and revisit this later.

Looking through the plugins, I think photometry might be the only place affected (unless maybe subset options is as well?). But you're right, if we get #1598 in first (which is ready for review), then I think it should be as easy as listening for that event and treating all selected subsets (aperture and background) as needing updating. I think it would be nice to get it in here so that we don't need those blurbs in the docs - or we should consider disabling parts of plugins accordingly if we're not going to get it fixed soon.

@pllim
Copy link
Contributor Author

pllim commented Aug 30, 2022

@kecnry , I have updated this PR to use #1598 but I did have to move when the message is emitted to the end for this to work.

Comment on lines +572 to +576
# Only broadcast after success.
app.hub.broadcast(LinkUpdatedMessage(link_type,
wcs_fallback_scheme == 'pixels',
wcs_use_affine,
sender=app))
Copy link
Member

Choose a reason for hiding this comment

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

this move should be ok since the spinner state is updated independently of the event, the only difference will be that when calling linking from the API the spinner will now start, the linking will happen, THEN the radio buttons will update and the spinner will clear (whereas before the radio buttons would switch before the linking actually started). I can see how for other uses of checking the linking (like in this PR) it is more beneficial to receive the message after the linking has been completed.

Comment on lines +78 to +81
For the best experience, it is recommended that you decide what kind of
link you want and set it at the beginning of your Imviz session,
rather than later.

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 be removed now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I want to keep it. I think it is a good recommendation regardless.

Comment on lines 180 to 181
# Force background auto-calculation to update when linking has changed.
self._bg_subset_selected_changed()
Copy link
Member

Choose a reason for hiding this comment

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

Does self._subset_selected_changed() need to be called (or since it's only caching annulus information, is that "immune" to changes in linking)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point. I didn't test the annulus case. I'll do it when I get back, or feel free to push commits here while I am gone if this is in a rush.

If we end up needing _subset_selected_changed(), then I think we don't have to call _bg_subset_selected_changed() because the former also triggers the latter.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I pushed a commit to also fix the annulus case. Please re-review. Good catch. Thanks!

pllim and others added 7 commits September 7, 2022 09:33
done on non-reference image if images are linked by WCS.
Handle case where aperstat bbox different shape from cutout.

Properly cast radii as int for binning.
Co-authored-by: Kyle Conroy <[email protected]>
if linking is changed in the middle of a aper phot session
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.

LGTM (assuming CI still passes and assuming changes to tests are correct - I didn't double check the changed numbers)!

@pllim
Copy link
Contributor Author

pllim commented Sep 7, 2022

changed numbers

I think the test in the diff behaves as expected. It now reports consistent sky coordinates for dithered data linked by WCS, but different pixel coordinates and sums; the latter because when the aperture mask takes account of the WCS linking, in the second dataset, it is a little off the image. Does this make sense?

Copy link
Contributor

@camipacifici camipacifici left a comment

Choose a reason for hiding this comment

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

Fixes the problem on my side too.

@pllim pllim merged commit e76482f into spacetelescope:main Sep 8, 2022
@pllim pllim deleted the aperphot-wcs-dithered branch September 8, 2022 17:58
@pllim
Copy link
Contributor Author

pllim commented Sep 8, 2022

Thanks for the thorough reviews!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] Imviz: Aperture photometry may be misleading on non-reference dithered image linked by WCS
5 participants