-
Notifications
You must be signed in to change notification settings - Fork 74
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
Conversation
33a8b7e
to
e5d71b3
Compare
|
||
# 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]] |
There was a problem hiding this comment.
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 ReportBase: 86.35% // Head: 86.37% // Increases project coverage by
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
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. |
7381626
to
31c4d6c
Compare
There was a problem hiding this 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! 🤷
jdaviz/configs/imviz/plugins/aper_phot_simple/aper_phot_simple.py
Outdated
Show resolved
Hide resolved
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? |
It looks like 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? |
This comment was marked as resolved.
This comment was marked as resolved.
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. |
85f9009
to
a507933
Compare
if Version(astropy.__version__) <= Version('5.1'): | ||
fitter_kw = {} | ||
else: | ||
fitter_kw = {'filter_non_finite': True} |
There was a problem hiding this comment.
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.
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. |
a507933
to
438c922
Compare
# Only broadcast after success. | ||
app.hub.broadcast(LinkUpdatedMessage(link_type, | ||
wcs_fallback_scheme == 'pixels', | ||
wcs_use_affine, | ||
sender=app)) |
There was a problem hiding this comment.
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.
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. | ||
|
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
# Force background auto-calculation to update when linking has changed. | ||
self._bg_subset_selected_changed() |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
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
438c922
to
6cfe418
Compare
There was a problem hiding this 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)!
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? |
There was a problem hiding this 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.
Thanks for the thorough reviews! |
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.
trivial
label.CHANGES.rst
?