PSF scale not equal to 1?

[mtakahiro]

Hi,

I've been testing the pipeline in terms of flux comparison but seeing offset between input and output flux counts, with the latter smaller for most cases. Checking each possible step of mirage and pipeline, I noticed that PSF rescaling in the mirage seed step does not necessarily result in 1. I would understand that this could happen when the PSF_WING option is set to False, but even with it's set to True, I'm seeing non-unity value.

mirage/mirage/seed_image/catalog_seed_image.py

Line 3045 in 974e114

scaled_psf, min_x, min_y, wings_added = self.create_psf_stamp(

I would appreciate if you could confirm non-unity values are still expected as normal. I suspect this may not be what you originally expected, as it says "scaled_psf", and also flux is set to 1 in this line:

mirage/mirage/seed_image/catalog_seed_image.py

Line 3206 in 974e114

full_psf = library.evaluate(x=xpts_core, y=ypts_core, flux=1.0,

Indeed, forcing the scaled value to 1 (by adding scaled_psf /= np.sum(scaled_psf)) makes the input flux from catalog and output flux from final_seed_image well matched, solving this long-standing offset I've been seeing.

Any thoughts would be appreciated. Thanks!

mirage.version
'2.2.1.dev4+g5c0fc55'

[mtakahiro]

The summed values (np.sum(scaled_psf)) I see here are e.g.:

• F200W
  • w wing: ~0.99222
  • w/o wing: ~0.95676
• F277W
  • w wing: ~0.839
  • w/o wing: ~0.800
• F480M
  • w wing: ~0.84
  • w/o wing: ~0.797

[mperrin]

• F200W: ~0.99 is close enough to 1 that this seems likely to be simple numerical precision issues, in particular from finite array size.

• F277 and F480M: These (and all other filters > 2.5 microns) are used in combination with the CLEARP element in the NIRISS pupil wheel, which reduces the throughput by 16%, consistent with what you're seeing there. This is a real loss of photons within the instrument, and will be seen in real data.

[mperrin]

See for instance https://jwst-docs.stsci.edu/jwst-near-infrared-imager-and-slitless-spectrograph/niriss-observing-modes/niriss-imaging which documents this.

This is a bit subtle, because throughputs get handled in a couple different places, and we have had to be careful to avoid missing anything or double counting. In general, we've tried to have it such that any throughput effect which depends on the shape of something in the beam path (like the CLEARP mask, or AMI mask, etc) is handled in WebbPSF; whereas anything which acts as a scalar throughput on the entire beam (like mirror reflectivity or throughput of a filter) gets handled in the CRDS reference data as used by synphot or the ETC, etc.

[mtakahiro]

Thanks, @mperrin. That explains why I see more significant offsets in the red filters. Just checked additional F150W and found that it has ~0.99-1, similar to what I see in F200W.

Good to know about the loss of photons regarding those combined with the CLEARP element. It seems to me that the comparison between the input and output does not make sense until the loss is corrected during the pipeline step.

I appreciate that you confirmed this and provided those expertises. I will move ahead and focus on other steps.

[mperrin]

Glad to have helped @mtakahiro!

[mtakahiro]

Hi @mperrin ,sorry to reopen the ticket that was closed. I was working on a scene with galaxy as input, instead of point source in the question above, and found offsets toward positive direction compared to the result from ETC with the exact setup. This part of the code,

mirage/mirage/seed_image/catalog_seed_image.py

Line 4336 in 974e114

psf_image = psf_image / np.sum(psf_image)

I see the psf array is normalized but I suspect this should not happen, as far as I understand what you said earlier. Could you comment on that? Thank you.

[bhilbert4]

@mtakahiro are you seeing offsets of around ~16%? If WebbPSF is providing PSFs that include the 16% signal reduction and then Mirage is normalizing that, and the 16% factor is not included in the flux calibration table for NIRISS, then it seems like your sources will be too bright. https://github.com/spacetelescope/mirage/blob/master/mirage/config/niriss_zeropoints.list

[mtakahiro]

@bhilbert4 yes. For this specific case, I see ~18.5% more counts in the Mirage final seed compared to the output from ETC. Note that both agreed within ~2% level when I did the same test for a point source. This normalization does not seem to happen in the process of creating point-source seeds, which I understand is correct according to our previous conversation above.

[mtakahiro]

Hi @bhilbert4, any thoughts or updates on this possible issue?

[bhilbert4]

Hi @mtakahiro. Sorry for the delay. Commissioning has me busy. I looked into this a bit last week, but I wasn't convinced that we want to change the normalization for the PSF that is convolved with the galaxy stamp because the galaxy stamp should already have its signal scaled to the correct value. I need to look more closely though to be sure. I'll get to that soon.

[mtakahiro]

Hi @bhilbert4 thanks for investigating while you are busy.

because the galaxy stamp should already have its signal scaled to the correct value.

This seems to be right and I don't see any issue with it. However, the issue I raised here is that a source should further get reduced in its countrate rate, due to the effect of passing filters, as Marshall explained above. This effect is included when PSF is generated through Webbpsf (so its sum is <1), and will be corrected during the pipeline processing regardless of the input source type.

As we see above, this effect remains true for point source scene, where
psf_image = psf_image / np.sum(psf_image)
does not happen. The normalization process is, however, present in the make_galaxy_image module, which makes me wonder if this explains the ~18% excess in the mirage product compared to the ETC image.

Or, did you mean that this filter effect is already included when it defines ``stamp" in the module? I could not confirm if this is true, but if so, you are right and the normalization to the psf seems reasonable.

Thanks again!