search

spacetelescope / mirage

This code can be used to generate simulated NIRCam, NIRISS, or FGS data
https://mirage-data-simulator.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
39 stars 41 forks source link

PSF scale not equal to 1? #758

Open mtakahiro opened 2 years ago

mtakahiro commented 2 years ago

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.

https://github.com/spacetelescope/mirage/blob/974e114597759f1d703bd6883914634c1ee2edc2/mirage/seed_image/catalog_seed_image.py#L3045

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: https://github.com/spacetelescope/mirage/blob/974e114597759f1d703bd6883914634c1ee2edc2/mirage/seed_image/catalog_seed_image.py#L3206

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 commented 2 years ago

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

mperrin commented 2 years ago
mperrin commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Glad to have helped @mtakahiro!

mtakahiro commented 2 years ago

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, https://github.com/spacetelescope/mirage/blob/974e114597759f1d703bd6883914634c1ee2edc2/mirage/seed_image/catalog_seed_image.py#L4336

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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

bhilbert4 commented 2 years ago

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 commented 2 years ago

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!