SNR calcs

[brandx]

Regarding SNR calculations.  I was using Starlink GAIA to help determine optimal aperture using SNR based on photon counts.  GAIA reported counts and count_err so SNR was simply count/count_err and for similar sized apertures to those in automatically sized in AIJ I was getting ~90 to 100 SNR. The SNR calculation in AIJ appears to be calculated on flux /flux _err so same in principle (assuming counts is equivto flux) but in AIJ the SNR is consistently 0.003 ie error much greater than the measurement.  So I'm not sure how to interpret AIJ SNR calc

[karenacollins]

Are your detector read noise, dark current, and gain settings correct in aperture settings?

Karen

[brandx]

Yes - as per FITS header and read noise from instrument data

[karenacollins]

Send me an email with your measurements table and an image showing the target star and how the aperture is position on it. Make sure the aperture and sky annulus are both showing.

Karen

[brandx]

I have emailed you concverning some additional issues arising

[brandx]

I re-checked the FITS data files.  The version I was using had gone through Pixinsight to align them (I didn't realise alignment wasn't strictly necessary with WCS) and for some reason the resultant files had much lower counts.  I reverted back to the original files and all is good - decent counts and SNR.

I am now comparing the aperture sizing AIJ calculates versus doing a manual set of trial apertures in Starlink Gaia which tends to show a higher SNR for smaller apertures compared to AIJ

[SCO]

Sometimes smaller SNR can be obtained with smaller apertures but only at the expense of higher BIC values.  If the BIC starts going up as apertures get smaller and SNR goes down, it is probably best to back off a bit.

[beka]

Hi brandx,

I had similar unreasonable SNR values when I did photometry on 32 bit float format FITS files - so maybe this is the same in your case. The values when the files were 16 bit integer format were reasonable.

When I multiplied the F_* (net (background subtracted) integrated counts in the aperture in ADU) and the F_S (number of sky background counts per pixel in ADU) values in the Error formula on page 11 of this...

https://iopscience.iop.org/article/10.3847/1538-3881/153/2/77/pdf

...article by 65536 (to convert the float values to integer ADU), I get reasonable results similar to those obtained on the 16 bit fits files.

It seems to me that the calculations done by AIJ need ADU units and those in the 32 bit FITS files are floats normalized to 1.0.

Best

[karenacollins]

Even if floats have been normalized, the SNR calcc should be correct as long as you have similarly compensated noise parameters (read noise, dark current, gain) set correspondingly. Do you have an example image that you can provide that is not working? We'd also need corresponding read noise, dark current, and gain that and been adjusted appropriately if the float files have been normalized.

Karen

[beka]

Hi Karen,

The files seem to large to upload to this forum, is there another way I can share them?

Thanks

[karenacollins]

Do you have a googledrive or dropbox? If so, just upload there and let us know the link. We really just need 1 file. Note that we'll need the associated detector read noise, dark current, and gain. If the images have been calibrated, normalized, etc., the read noise, dark current, and gain should also be adjusted appropriately.

Karen

[beka]

Hi Karen,

I have linked 16bit and 32bit files - both of these were processed using Siril 1.2.0-beta1. For both measurements gain is 1.0, dark current and read noise are 0.0. While these values are of course not realistic they should give some idea that the calculation is working. My thinking is that the formula used is valid for values > 1 which should work when we are thinking of signal counts. For values < 1 the square root of the noise value will rise faster than that of the signal so it can't be right can it?

16 bit image:
https://drive.google.com/file/d/1wbWyjYzNHptlb7CxPNZALAssEsQJwuNH/view?usp=drive_link

32 bit image
https://drive.google.com/file/d/1BaxFrnpZNGkIO_2V0mAbP03q-o3icy4h/view?usp=drive_link

16 bit measurements:
Measurements_16.tbl

32 bit measurements
Measurements_32.tbl

Best

[karenacollins]

Hi Beka,

It looks like the 32 bit image has been normalized. When the calibration/image processing software changes the overall scaling of the image, it is effectively changing the gain. For instance, if your initial image values ranged from 0 to 65K, and the calibrated image ranges from 0 to 1, then the gain has changed by a factor of 64K! So, you'll need either have your image processing software NOT normalize the image values, or you'll need to know the normalization factor and include that factor in the gain setting in AIJ (multiplied by the actual detector gain). That will scale the pixels values back up for purposes of calculating SNR.

Karen

[beka]

Okay thanks Karen. I will probably be better of staying with the 16 bit images, at least until I have definitive information on how the 32 bit images are normalized.

All the best.

[karenacollins]

You might check for an option that turns off the normalization in the tool you are using prior to AIJ (if you'd prefer to continue to use the 32 bit images).