Ensure aperture is correct when images linked by WCS

[Jdaviz-Triage-Bot]

Reporter: pllim

Consider the following use case: Load two images in Imviz and link them by WCS. The second image has different resolution (e.g., covering the same area in sky but with twice as many pixels) or has different sky orientation.

Do the Subsets (circle, ellipse, rectangle) give correct answers when applied to the second (non-reference) image? If not, how do we fix this (a rectangle might not even be a rectangle anymore when projected on the second image)? If there is no easy fix, should we disable aperture photometry for non-reference images?

To test the seriousness of this situation, measure the correct answers first by loading only the second image in an Imviz session (maybe start with Circle, the easiest of the shapes) and run some aperture photometry. Then draw what you think is the same circle but now with this image as a non-reference image (the reference image should have different sky resolution to test this). Rerun the aperture photometry. Do the aperture sums agree within uncertainty?

The JWST images in the Imviz example notebook might be a good start, as they have different sky resolutions, I think.

🐱

Blocked by

• Remove annulus settings from Simple Aperture Photometry plugin #2190

---

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

[pllim]

As a test, I did the following in two separate sessions. In the ImvizExample.ipynb, I always test with these two files that cover about same area in the sky but with different pixel resolutions:

1. jw02727-o002_t062_nircam_clear-f090w_i2d.fits (4636, 4649) from NIRCam SHORT channel
2. jw02727-o002_t062_nircam_clear-f277w_i2d.fits (2265, 2269) from NIRCam LONG channel

Session 1

I only load image 2 so that it is the reference image. I draw Subsets as such and calculate aperture photometry for Subset 1 (red) while using Subset 2 (green) to estimate the background:

Session 2

I load both images 1 and 2, so now image 2 is not the reference image. I link them by WCS and draw what appear to be the same subsets as Session 1 above. However, this time, subsets are actually defined on image 1 that is twice the pixel dimension of image 2. Since we currently grab just the parameters defined in pixel space, while we adjust for WCS dithering for its center, the subset radius on image 2 is now twice as large even though it shows otherwise on display.

This is when I redraw the aperture subset with the radius defined in image 1 on yet another session with only image 2 loaded. This is what we are really measuring in this session for image 2:

What does this mean?

Depending on which image is the reference and their pixel and sky dimensions, aperture photometry on a non-reference image may be wrong. In the ImvizDitheredExample.ipynb using dithered HST/ACS exposures, I missed this problem because the pixel resolution was the same for both images (same detector).

In the use case presented above, the result is that image 2 accidentally got more photons counted in the aperture sum, contradicting to how the aperture is represented in the image display.

id	xcenter	ycenter	sky_center	background	sum	sum_aper_area	pixarea_tot	aperture_sum_counts	aperture_sum_counts_err	counts_fac	aperture_sum_mag	flux_scaling	min	max	mean	median	mode	std	mad_std	var	biweight_location	biweight_midvariance	fwhm	semimajor_sigma	semiminor_sigma	orientation	eccentricity	data_label	subset_label	timestamp
1	405.3608093261719	945.1304321289062	9.419932648412415,-33.70062721570121	0.11681070923805237	1.062387497684195e-10	737.5133677246463	9.33125892402186e-14	None	None	None	18.834358244233655	0.003631	0.25047099590301514	32.86998662352562	1.5428804420035707	0.6627960503101349	-1.0973727330767367	3.1380937184258775	0.433148432483082	9.84763218562395	0.6568256520659198	0.2385739626393513	11.523804072379466	5.048995670665955	4.733330590156219	-10.27291970720687	0.3480401477820819	jw02727-o002_t062_nircam_clear-f277w_i2d[DATA]	As ref	2023-04-12 13:54:14.942680
2	405.1794310589263	945.1056457328416	9.419931319780341,-33.70062420856731	0.11823157221078873	1.3166116059375336e-10	2934.9601660736735	9.33125892402186e-14	None	None	None	18.601421424580117	0.003631	0.03684151917695999	32.86856576055288	0.48060638212905915	0.13319992274045944	-0.56161299603674	1.690046913610723	0.09323136574622855	2.8562585702051306	0.12977455684397796	0.010900278793267682	19.272734233263414	8.498869015075032	7.857306685072944	-7.132642769221591	0.38115285365294155	jw02727-o002_t062_nircam_clear-f277w_i2d[DATA]	Not ref	2023-04-12 14:06:59.254038

How do we fix this?

Perhaps as @bmorris3 suggested, we could use sky region under the hood, but more thoughts needed for cases like:

• What if the second image is rotated wrt reference too? How do we accurately determine the sky angle?
• What if the second image is distorted wrt reference, such that a circular subset is no longer even a circle? photutils cannot take an arbitrary shape as aperture (according to ApertureStats) but maybe there is a way to hack it to accept aperture mask?
• What if there is a third image without WCS? Then we have to make sure the algorithm falls back to the current way of things (just take the subset as defined in reference image) without crashing.

[pllim]

My idea for the "worst case scenario" test case:

1. Image with regular FITS WCS.
2. Image with rotated and distorted GWCS and partial overlap, but still has the object of interest in view.

• Update: Distortion added too much compute time to the extend of unusable during reprojection and linking steps. So I have to abandon it but still hoping to include different pixel scale and distortion.

4. Image with no WCS (this would be linked by pixel to the reference image).

Have them all loaded into Imviz and link by WCS.

Maybe we can use photutils fake data generator to fill in a scene. But check the photutils test suite first so we can also copied over the correct answer of aperture sum. Preferably ellipse or rectangle so we can also play with theta.

If we are able to define the subset in image 2 correctly, aperture sum would agree (+/- 1%?).

Even if we cannot figure out a fix and has to disable aperture photometry for image 2, this test case will tell us what checks we need to implement. Maybe check the projected mask shape somehow?