<p>GAIN in SExtractor has the usual meaning of electrons/ADU (ADU = analog-to-digital units, aka &quot;counts&quot;). SExtractor assumes the pixel values are in ADUs, which is why it wants to know the gain value, so it can convert them into electrons/pixel and then make noise estimates based on the usual Gaussian approximation to Poisson noise. (SExtractor also estimates background noise from directly measured pixel-to-pixel variations, something for which the gain is unnecessary.)</p>
<p>If you tell SExtractor the gain is 0, then you are saying that all pixels have values of 0 electrons. Which is obviously nonsense. (Plus, as you can see, you'll get division-by-zero errors.)</p>
<p>If you want really correct errors, then I think you need to figure out how to convert the image values back into ADU/pixel before running SExtractor, and use the correct GAIN value for the instrument. Or (more or less equivalently) figure out the numerical transformation from electrons/pixel to MJy/sr for those images, and use <em>that</em> as the &quot;gain&quot;.</p>
<p>Failing that, I'd suggest setting GAIN = 1, and just accept that the flux errors will be somewhat wrong.</p>

CC BY-SA 4.0
2024-08-10T13:04:28.480Z
I would require a correct error for my science case. As you mentioned the conversion factor for JWST NIRCAM I saw as (NIRCam images in units of MJy/sr are derived from data rate images (rate.fits), in units of counts/s  (DN/s). The conversion factor is stored in the FITS header under the PHOTMJSR, keyword, which has units of (MJy/sr) / (DN/s)) (https://jwst-docs.stsci.edu/jwst-near-infrared-camera/nircam-performance/nircam-absolute-flux-calibration-and-zeropoints#gsc.tab=0)
Walker
CC BY-SA 4.0
2024-08-10T13:04:52.950Z
Can I use this PHOTMJSR for GAIN or
Will it be dependent on the EXPOSURE TIME also . 'XPOSURE = 5669.016000000001 / [s] Effective exposure time' and 'PHOTMJSR= 0.4907999932765961 / Flux density (MJy/steradian) producing 1 cps' for a particular filter (XPOSURE/PHOTMJSR will be a very big value)
Walker
CC BY-SA 4.0
2024-08-10T13:28:15.937Z
You want a conversion that turns MJr/sr into total electrons, so you need to use PHOTMJSR *and* the exposure time *and* the actual A/D gain of the detector (which, [according to this](https://jwst-docs.stsci.edu/jwst-near-infrared-camera/nircam-instrumentation/nircam-detector-overview/nircam-detector-performance#gsc.tab=0)], is about 2.0).
Peter Erwin
CC BY-SA 4.0
2024-08-11T05:38:53.100Z
Thank you for the reply again. But I am not getting it. multiplying them will be a very large value right?
Walker
CC BY-SA 4.0
2024-08-11T08:41:00.320Z
It’s a cumulative exposure time of over an hour and a half on a 6.5m telescope; you should probably expect large values.
Peter Erwin
CC BY-SA 4.0
2024-08-11T14:11:06.767Z
Okay , Thank you . So  I can  use GAIN = XPOSURE / (PHOTMJSR * detector gain) which comes around 5772 for this case ?
Walker
CC BY-SA 4.0
2024-08-11T18:09:35.543Z
It would be GAIN = detector_gain * XPOSURE / PHOTMJSR .
Peter Erwin
CC BY-SA 4.0
2024-08-13T05:56:04.687Z
Thanks. 
My images are in units of MJy/sr , yet why are my sextractor output showing that it is in units of count. 
'#  11 FLUX_APER              Flux vector within fixed circular aperture(s)              [count]'

which means , I have to do a conversion here again into flux in Jy ?

Flux (Jy)=(FLUX_APER (counts)×PHOTMJSR (MJy/sr)×10e−6)/XPOSURE (s) 
 
​
Walker
CC BY-SA 4.0
2024-08-13T11:45:08.057Z
SExtractor doesn't know about flux or surface-brightness values; it only knows about pixel values in the data array, which it assumes are cumulative ADUs. (If you supply a magnitude zero point, then it will also calculate *magnitudes*, but that's about it.)
Peter Erwin
CC BY-SA 4.0
2024-08-13T11:47:21.630Z
Note that MJy/sr are *surface brightness* units, so your conversion needs to account for the pixel area in sr.
Peter Erwin
CC BY-SA 4.0
2024-08-14T07:08:39.203Z
Okay. For getting the AB magnitude I am providing the zeropoint.
So for the conversion of flux , I can use flux_aper(mjy) = flux_aper(count) * PHOTMJSR*PIXAR_SR

(where PIXAR_SR is the  Nominal pixel area in steradians and PHOTMJSR is the flux density (MJy/steradian) producing 1 cps)
Walker
CC BY-SA 4.0
2024-08-10T11:39:05.097Z
2024-08-10T11:39:05.097Z
Peter Erwin
<p>I'm using SExtractor for source detection from JWST CEERS NIRCam images. I'm using the fully reduced mosaics provided in CEERS website (The mosaics are on pixel scales of 0.03&quot;/pix and are pixel-aligned across all filters. The science images are in units of MegaJansky per steradian (MJy/sr)) . Since my images are in units of MJy/sr I thought of using 0 for GAIN parameter. But it seems that flux_err is using GAIN in its calculation (<a href="https://sextractor.readthedocs.io/en/latest/Photom.html" rel="nofollow noreferrer">https://sextractor.readthedocs.io/en/latest/Photom.html</a>) <a href="https://i.sstatic.net/GPfGXtHQ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/GPfGXtHQ.png" alt="enter image description here" /></a></p>
<p>What value should I give for GAIN for source extraction from my images ?</p>

<photometry><hubble-telescope><james-webb-space-telescope>
GAIN in Sextractor
Walker
# GAIN in Sextractor

(Asked by: username_0 on 2024-08-09)

I'm using SExtractor for source detection from JWST CEERS NIRCam images. I'm using the fully reduced mosaics provided in CEERS website (The mosaics are on pixel scales of 0.03"/pix and are pixel-aligned across all filters. The science images are in units of MegaJansky per steradian (MJy/sr)) . Since my images are in units of MJy/sr I thought of using 0 for GAIN parameter. But it seems that flux\_err is using GAIN in its calculation (<https://sextractor.readthedocs.io/en/latest/Photom.html>) [![enter image description here](https://i.sstatic.net/GPfGXtHQ.png)](https://i.sstatic.net/GPfGXtHQ.png)

What value should I give for GAIN for source extraction from my images ?

**Tags:** photometry, hubble-telescope, james-webb-space-telescope


---

## 1 answers

### Answer by username_1 on 2024-08-10. Score: 1

GAIN in SExtractor has the usual meaning of electrons/ADU (ADU = analog-to-digital units, aka "counts"). SExtractor assumes the pixel values are in ADUs, which is why it wants to know the gain value, so it can convert them into electrons/pixel and then make noise estimates based on the usual Gaussian approximation to Poisson noise. (SExtractor also estimates background noise from directly measured pixel-to-pixel variations, something for which the gain is unnecessary.)

If you tell SExtractor the gain is 0, then you are saying that all pixels have values of 0 electrons. Which is obviously nonsense. (Plus, as you can see, you'll get division-by-zero errors.)

If you want really correct errors, then I think you need to figure out how to convert the image values back into ADU/pixel before running SExtractor, and use the correct GAIN value for the instrument. Or (more or less equivalently) figure out the numerical transformation from electrons/pixel to MJy/sr for those images, and use *that* as the "gain".

Failing that, I'd suggest setting GAIN = 1, and just accept that the flux errors will be somewhat wrong.

> **Comments:**
> **username_0**: I would require a correct error for my science case. As you mentioned the conversion factor for JWST NIRCAM I saw as (NIRCam images in units of MJy/sr are derived from data rate images (rate.fits), in units of counts/s  (DN/s). The conversion factor is stored in the FITS header under the PHOTMJSR, keyword, which has units of (MJy/sr) / (DN/s)) (https://jwst-docs.stsci.edu/jwst-near-infrared-camera/nircam-performance/nircam-absolute-flux-calibration-and-zeropoints#gsc.tab=0)  
> **username_0**: Can I use this PHOTMJSR for GAIN or Will it be dependent on the EXPOSURE TIME also . 'XPOSURE = 5669.016000000001 / [s] Effective exposure time' and 'PHOTMJSR= 0.4907999932765961 / Flux density (MJy/steradian) producing 1 cps' for a particular filter (XPOSURE/PHOTMJSR will be a very big value)  
> **username_1**: You want a conversion that turns MJr/sr into total electrons, so you need to use PHOTMJSR *and* the exposure time *and* the actual A/D gain of the detector (which, [according to this](https://jwst-docs.stsci.edu/jwst-near-infrared-camera/nircam-instrumentation/nircam-detector-overview/nircam-detector-performance#gsc.tab=0)], is about 2.0).  
> **username_0**: Thank you for the reply again. But I am not getting it. multiplying them will be a very large value right?  
> **username_1**: It’s a cumulative exposure time of over an hour and a half on a 6.5m telescope; you should probably expect large values.  
> **username_0**: Okay , Thank you . So  I can  use GAIN = XPOSURE / (PHOTMJSR * detector gain) which comes around 5772 for this case ?  
> **username_1**: It would be GAIN = detector_gain * XPOSURE / PHOTMJSR .  
> **username_0**: Thanks.  My images are in units of MJy/sr , yet why are my sextractor output showing that it is in units of count.  '#  11 FLUX_APER              Flux vector within fixed circular aperture(s)              [count]'  which means , I have to do a conversion here again into flux in Jy ?  Flux (Jy)=(FLUX_APER (counts)×PHOTMJSR (MJy/sr)×10e−6)/XPOSURE (s)    ​  
> **username_1**: SExtractor doesn't know about flux or surface-brightness values; it only knows about pixel values in the data array, which it assumes are cumulative ADUs. (If you supply a magnitude zero point, then it will also calculate *magnitudes*, but that's about it.)  
> **username_1**: Note that MJy/sr are *surface brightness* units, so your conversion needs to account for the pixel area in sr.  
> **username_0**: Okay. For getting the AB magnitude I am providing the zeropoint. So for the conversion of flux , I can use flux_aper(mjy) = flux_aper(count) * PHOTMJSR*PIXAR_SR  (where PIXAR_SR is the  Nominal pixel area in steradians and PHOTMJSR is the flux density (MJy/steradian) producing 1 cps)  

---

