Discrepancy between the counts of SDSS raw and mosaic frames

[AidanRowland]

Hello,
I'm an astrophysics undergraduate that requires flux-conserved mosaics for SDSS ugriz filters in order to make spectral energy distributions of resolved galaxies. While using Montage, I repeatedly found a discrepancy between the counts of the raw images, downloaded using Montage’s mArchiveDownload, and the mosaic SDSS images in all 5 filters by almost an order of magnitude in some cases. A minimum reproducible example is attached.

In the example, data for an example star is downloaded, and mosaics for all 5 SDSS bands are created using reprojected frames (made using mProject) (Using background corrected frames made no difference). The flux of a target star is then summed and compared in all five bands between a raw frame and the mosaic frame for each filter.

Any help with solving this issue would be appreciated.
Thanks,
Aidan Rowland

Montage_Problems.ipynb

[GBruceB]

Thank you for the ticket - I have been on travel the last two weeks and will be on vacation this week. I will have a look next week - sorry for the delay.

[museleie]

Hi Aidan,

I looked into this issue and found some information that can help.

SDSS has an added flux value of 1000 in the softbias that was made in the creation of the instruments to save storage space (Source)

However, this is something that needs to be removed before pre-processing, as said below:

"On a related note, in DR1 one can also use relations similar to the above to estimate the sky level in magnitudes per sq. arcsec (1 pixel = 0.396 arcsec). Either use the header keyword "sky" in the fpC files, or remember to first subtract "softbias" (= 1000) from the raw background counts in the fpC files. Note the sky level is also given in the tsField files. This note only applies to the DR1 and later data releases. Note also that the calibrated sky brightnesses reported in the tsField values have been corrected for atmospheric extinction.” (Source)

Montage is flux-conserving, so it does not remove this additional flux value.

So, the answer here is do some additional pre-processing before continuing using montage.

Please let me know if this resolves your issue!

[AidanRowland]

Hi Rosemary,

Thank you for the response. I’m not quite sure that this is the issue.

The biggest point is that the mosaic’d image was made using these raw SDSS frames. So, regardless of whether or not there was a bias in these SDSS frames something appears to be happening in the mosaic pipeline that causes this star to lose flux.

Furthermore, comparing the photometry of the raw SDSS frames, the Montage mosaic, and photometry of this star that was pulled from VOSA, the raw SDSS frame most closely aligns with the VOSA data (see attached figure).

Lastly, a quick check of the background for the downloaded frames shows that the background is nearly zero. If there was a bias of nearly 1000 then that would be detectable here.

[GBruceB]

Hello

well I must admit thus baffles me too! At least the offset is a constant as far as I can see, so the difference is a scaling. Now I am unfamiliar with VOSA, but I will ask my colleagues who work there if they can assist. Cheers.

[AidanRowland]

Thank You,
Looking forward to hearing back from you!

[museleie]

Hi Aidan,

We looked into the flux discrepancy and the likely cause is a pixel scale mismatch: your raw SDSS frames are ~0.396"/pixel and the Montage mosaic defaults to 1.0"/pixel. Each mosaic pixel covers ~6.4x more sky area, so when you sum a 20x20 pixel box in each image you're comparing a 7.9"x7.9" region against a 20"x20" region. This is by design — Montage conserves surface brightness by default, not integrated flux.

There is actually a flag for this (energyMode=True in mProjExec) that should switch it to flux conservation mode, which would address exactly what you're seeing. We think it could work, but we need to look into it a bit more — in our testing the flag didn't appear to have the expected effect and we want to understand why before recommending it.

In the meantime, we tried photutils with a sky-coordinate aperture and it worked with your data. By defining the aperture in arcseconds rather than pixels, both images are measured over the same physical sky area regardless of pixel scale, which gives you a valid flux comparison.

If you don't already have it: pip install photutils. The key imports are:
from photutils.aperture import SkyCircularAperture, aperture_photometry
from astropy.coordinates import SkyCoord
import astropy.units as u

Let us know if this helps, we will follow up once we verify the energyMode behavior as Montage should allow what you are asking for