-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Update Mosviz parser doc and fix NIRSpec auto-load #2146
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #2146 +/- ##
==========================================
- Coverage 91.61% 91.50% -0.11%
==========================================
Files 147 147
Lines 16098 16142 +44
==========================================
+ Hits 14748 14771 +23
- Misses 1350 1371 +21
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 in Codecov by Sentry. |
Thank you very much. This fixes my original problem.
|
Would be nice to fix the image loader for this one too: |
17b9b5e
to
c3f00ab
Compare
For some reason, it is trying to look for RA and Dec on the image, not spectra. Not sure why. I added a fix.
Hard for me to test using the cutout off the 2GB image you provided. If this is still a problem, please be more specific on what the correct answer should be. In NIRISS, I see that the parser grab RA and Dec off a special ECSV catalog that NIRSpec does not have, so I cannot just use the NIRISS logic. And are you sure this is not the same problem as S_REGION? These are all populated by the pipeline.
I also added a fix for this. Please test your use case in #2144 with this PR too. |
""" | ||
super().load_data(data_obj, parser_reference="mosviz-image-parser", | ||
data_labels=data_labels, share_image=share_image) | ||
self._add_redshift_column() | ||
if add_redshift_column: | ||
self._add_redshift_column() |
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.
Note: Multiple calls to self._add_redshift_column()
in load_data
was what causing all the warnings Cami was seeing, so I have to disable this call in sub-calls by default to get rid of the warnings.
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 confirm I do not see the warnings anymore.
The table is nicely populated, but if I try to load the image I still get the same traceback that ends with This is the way I am calling it: |
c3f00ab
to
bfa09bb
Compare
There are just too many ways to do the same thing in Mosviz. Looks like you were using a different logic route. I have pushed a fix. By the way, you don't have to specify |
bfa09bb
to
334b743
Compare
@@ -212,7 +209,7 @@ def test_load_single_image_multi_spec(mosviz_helper, mos_image, spectrum1d, mos_ | |||
label_mouseover._viewer_mouse_event(spec2d_viewer, | |||
{'event': 'mousemove', 'domain': {'x': 10, 'y': 100}}) | |||
assert label_mouseover.as_text() == ('Pixel x=00010.0 y=00100.0 Value +8.12986e-01', '', '') | |||
assert label_mouseover.icon == 'b' | |||
assert label_mouseover.icon == 'c' |
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.
Note: I changed the loading order in load_data to fix a bug, hence this change here.
The way I was using now works, thank you! Now, I see another problem. The image viewer is not zooming on SRCRA and SRCDEC (it is quite far off). Do you see the same on your side? I can demo with the big image if you wish. The same is valid for the slit overlay. It is off from the coordinates in S_REGION. |
This comment was marked as resolved.
This comment was marked as resolved.
I was loading using directory, having moved the image under some sub-dir that it looks for. I did not try to load all 3 components separately and when I did, I could reproduce your problem (and then fix it). |
Understood. Let me try to find a different image! |
Hmm I just found the code that zoom on shared image. I forgot this is not Imviz, so maybe that is a real bug, lemme see. |
You are right!! My mistake, the image is there and the zoom is doing what it is supposed to, i.e. zooming using the number of pixels in the cross dispersion direction in the 2D image. That is apparently too small, but it not a jdaviz problem. Also the fact that the RA/Dec are not in the header is not a jdaviz problem. For the record, I did not have to put the image under an Sorry for the false alarm! This looks good to me! |
80bbca5
to
07f8025
Compare
Failures are unrelated. |
I get a test failure that appears related when I run them locally, from
I assume that you weren't seeing this locally, any idea what might be going wrong? |
@rosteen , I seen that before. I think some data was not loaded properly. I thought I fixed that. Are you testing an older version of my branch? Did you try clearing the download cache? |
The test passed after I used astropy's |
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 left a couple small questions and one small suggestion, but otherwise I think this looks good.
def set_plot_axes(self): | ||
self.figure.axes[1].tick_format = None | ||
self.figure.axes[0].tick_format = None | ||
def _mark_targets(self): |
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.
Where does this get used, anyway? This is the only instance of the string "_mark_targets" that I see in the repository.
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 needed it to debug. I wanted to see where the RA and Dec from the table actually are. I feel like we could make it public (in one way or another) in the future but I don't want that headache right now.
It comes "for free" with the Astrowidgets inheritance, but if this bothers you, I can remove it.
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.
Ah, I see. I don't think it needs to be removed then, but it would be nice to have a comment saying that it's there to help with debugging and isn't actually called internally.
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 could see this being useful eventually, why not 🤷
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.
Comment added.
from astropy.coordinates import SkyCoord | ||
from astropy.table import QTable |
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.
Depends on the answer to the question above probably, but maybe move these to the top level? I generally dislike imports in functions.
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 #2146 (comment) help you making a decision on this?
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.
If it's only used in debugging it can stay.
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 comment doesn't quite give me an answer as to why these imports should be down here. Is there a reason?
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.
Because the imports are unnecessary otherwise. If we decide to delete this method one day, it gives a cleaner diff. If you really want the imports to be high up, I can do it too. Lemme know.
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.
Understandable, but isn't this directly against PEP8? https://peps.python.org/pep-0008/#imports
Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.
Unless those particular imports take a particularly long time, I'd argue following PEP8. I'm personally comfortable with counting this as a value-add rather than a "small debugging thing that might be useful 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.
Imports moved up.
Add change log. Ignore non-FITS files in NIRSpec glob. Grab source RA/Dec from 1D spec first.
remove unnecessary ignoring of warnings that are not there.
Update change log
and disable image viewer axes
Co-authored-by: Ricky O'Steen <39831871+rosteen@users.noreply.github.com>
that it is only for debugging
9500a3c
to
50e2dd1
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.
For whatever reason, I couldn't get to Cami's nirspec example, but the nircam example worked and zoomed well. Code looks good and much more logical. Thanks Pey-Lian! A few other comments
and rename xh variable
This comment was marked as resolved.
This comment was marked as resolved.
so we just blindly ignore, not caring if it shows up or not
@rosteen and @duytnguyendtn , is this okay to merge now? Thanks for the reviews! |
* Update Mosviz parser doc and fix NIRSpec auto-load. Add change log. Ignore non-FITS files in NIRSpec glob. Grab source RA/Dec from 1D spec first. * Update Mosviz example notebook * Update tests and remove unnecessary ignoring of warnings that are not there. * Fix single image loading for mix-and-match Update change log * Fix Mosviz image zoom to target and disable image viewer axes * BUG: images not returning Path objects * Fix English typo Co-authored-by: Ricky O'Steen <39831871+rosteen@users.noreply.github.com> * Add a note about _mark_targets that it is only for debugging * Move local imports up and rename xh variable * TST: Warning gone from test_slice * OMG now warning is back so we just blindly ignore, not caring if it shows up or not --------- Co-authored-by: Ricky O'Steen <39831871+rosteen@users.noreply.github.com>
Description
This pull request is to update Mosviz doc on importing data, and also enable NIRSpec auto loader to take a single image.
And then the scope expanded and now it also fixes #2144
Change log entry
CHANGES.rst
? If you want to avoid merge conflicts,list the proposed change log here for review and add to
CHANGES.rst
before merge. If no, maintainershould add a
no-changelog-entry-needed
label.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.