Astrowidgets API using SkyCoord confusing when coord is out of bounds in dithered images

[Jdaviz-Triage-Bot]

Reporter: pllim

This is best demonstrated by the MIRI and NIRCam galaxy/supernova images that @orifox still needs to provide. MIRI has much larger FOV but smaller in pixel dimension. NIRCam has small FOV but large pixel dimension. When linked by WCS, they overlap partially with NIRCam off to the lower right corner of the MIRI FOV. The sky coordinate of interest belongs to a known supernova that is in NIRCam image but outside of MIRI. And we are also talking about GWCS here, that purposely does not extrapolate beyond image boundary (it was a conscious design choice by GWCS).

Workflow to reproduce:

1. Load those two images into Imviz. Ori started out with loading MIRI first though I am not sure if the order matters here.
2. Link them by WCS.
3. Define a sky coordinate that is in NIRCam FOV but outside of MIRI.
4. Make sure MIRI image is on top (this gets super confusing when you have partial opacity so both images show but just make sure MIRI is on top as far as Imviz top visible layer selection is concerned.
5. imviz.default_viewer.center_on(my_skycoord)
6. See that nothing happens. This is because MIRI GWCS does not give any pixel coordinates back because that sky coordinate is invalid as far as it is concerned.

Desired outcome can be either:

• Quick fix is an informative error message that explains the situation and that user should do something to make sure NIRCam is on top or use some lower level API calls to make sure NIRCam GWCS is being called.
• Some thoughts need to go into the design if we want the API to automatically identify and work around such situations.

🐱

---

DISCLAIMER: This issue was autocreated by the Jdaviz Issue Creation Bot on behalf of the reporter. If any information is incorrect, please contact Duy Nguyen

[stscijgbot-jwql]

This issue is tracked on JIRA as JDAT-2613.

[stscijgbot-jwql]

Comment by Duy Nguyen on JIRA:

NOTICE: A corresponding GitHub issue was automatically created: #1509

[stscijgbot-jwql]

Comment by Camilla Pacifici on JIRA:

Was about to create a new ticket, then I found this. My issue is probably related:
Load a few images that are close in WCS but do not entirely overlap.
Link by WCS.
Change opacity to 50% for all the images.
Zoom out to see all the images.
Hover on the image and check the printed WCS.

For the reference image, only pixels are reported.
For the other images the position is reported as 0000NaN.
Proper WCS are reported only where two images (but not any two images) overlap.

If you already have the CEERS images on your machine, you can use:
jw01345-o002_t022_nircam_clear-f200w_i2d.fits
jw01345-o003_t023_nircam_clear-f200w_i2d.fits
jw01345-o004_t024_nircam_clear-f200w_i2d.fits
Or you can download them here:
https://stsci.box.com/s/djvnimdjdd6euin5y480grouau6cf2ew
https://stsci.box.com/s/7p650ynzepax5l1sxddrnlbosmf51njq
https://stsci.box.com/s/vjeogbw7rd2fa5w2qi4elrvb7xj53vf7

[stscijgbot-jwql]

Comment by Pey-Lian Lim on JIRA:

Camilla Pacifici , what is the desired behavior? See bottom of original post. Thanks!

[stscijgbot-jwql]

Comment by Camilla Pacifici on JIRA:

Sorry, desired behavior is to see the coordinates (both pixels and physical) everywhere, not just in a small part of the viewer. Is this feasible? I do not understand what would go into the mentioned API changes.

[stscijgbot-jwql]

Comment by Pey-Lian Lim on JIRA:

The main problem is GWCS does not allow extrapolation. So if markers are linked against reference image and that image has GWCS, any markers outside of the GWCS field-of-view will return NaN pixels. This is GWCS behavior outside our control.

If you want "everywhere," we basically have to create a mosaic WCS and use that but that would involve some third-party software to do. Or ask GWCS to support extrapolation.

[stscijgbot-jwql]

Comment by Camilla Pacifici on JIRA:

Would it be an option to use the approximated WCS instead of GWCS?

[stscijgbot-jwql]

Comment by Pey-Lian Lim on JIRA:

For JWST, FITS WCS is not to be relied on if there is distortion. Not being an expert in all the possible pipeline products, I wouldn't know when it is safe to use. If you have rules on when to give this option and how user wants to use this option, please let us know. Thanks!

[stscijgbot-jwql]

Comment by Camilla Pacifici on JIRA:

Gotcha. i2d files would be corrected for distortion, so maybe for those the approximated WCS could be used.
Potential path forward:

• find a way to tell the user that gwcs cannot be extrapolated and so coordinates informations are reported only for the reference image (although in the case of mosaics, only the overlapping part shows physical coordinates. the rest of the reference image shows only pixel coordinates. see video attached)
• think about how to handle the case of undistorted images for which the wcs approximation is ok. is this case too narrow? how can the tool figure out whether images are distortion corrected?
• other option would be to just use the approximation and warn the user that they are looking at approximated coordinates.

[stscijgbot-jwql]

Comment by Pey-Lian Lim on JIRA:

Just ignoring GWCS and load FITS WCS no matter what would be easiest but then you still have the same problem with Roman data that is pure ASDF (no FITS WCS at all). I don't think any approximation would do for Roman stuff.

[stscijgbot-jwql]

Comment by Richard O'Steen on JIRA:

This is the same underlying problem as JDAT-2980