Re: How to keep FITS header when stacking?
Posted by Luca on Aug 15, 2017; 4:54pm
URL: http://astroimagej.170.s1.nabble.com/How-to-keep-FITS-header-when-stacking-tp725p749.html
I just followed your advice to manually change the error bars through Excel and basically multiplied them by 4 (3 times for the scintillation noise plus 1 for the red noise as calculated through my calc sheet) and found an almost too perfect "1" value for the CHI^2/dof. Now I can definitely say I am happy with the result. Obviously when I tell AstroimageJ to bin the data, it doesn't know that the red noise exists (meaning it doesn't scale the error bars correctly) so the CHI^2/dof value rises, but not that much. Adding an option for red noise (either for calculating it or just adding it manually) would be incredible, just saying.. ahah
.
This time I used non-aligned images as you implied and found that using the WIDTH_T1 parameter to detrend improves the BIC value (and the CHI^2/dof) by quite a lot... almost as much as AIRMASS actually**. A bit of improvement also comes from SKY/PIXEL_T1 and ANGLE_T1. The other parameters don't really help (FWHM_mult now is a constant value). Could you point me to a source where the detrending calculations done here are explained? I have a vague idea of what the software is doing but I would like to be sure about that.
Since you were wondering about what filter we used, I am linking it here, combining this with the CCD bandwidth we're basically catching light from 610 to 1000nm or so. By the way, the fact that the depth of the light curve is a couple of mmag low compared to the depths in the literature is due to HD189733 companion, a ~10 v_mag star that is definitely inside the aperture and as you probably know, adds a constant mag value that causes this effect. Doing the math (subtracting the light of the companion) I find that the depth is consistent with the other ones.
Thank you for your incredible and continuous support. I would gladly help to update the software if I could but you have done an amazing job already.
P.S. Yes we had some "saturation alarms" at the end but consider that our CCD is linear up to 60k counts, so it doesn't matter that much. But yes it was a first attempt and we didn't consider that during the night the focusing was going to change (increase in this case) and therefore each pixel got more counts than expected towards the end. **Thinking about it now, since the focusing changed (~sinusoidally) during the observation, might this be the cause of the high detrending effect of the WIDTH_T1 value?
P.P.S. Do you generally apply the detrending parameters to check stars as well?
URL: http://astroimagej.170.s1.nabble.com/How-to-keep-FITS-header-when-stacking-tp725p749.html
I just followed your advice to manually change the error bars through Excel and basically multiplied them by 4 (3 times for the scintillation noise plus 1 for the red noise as calculated through my calc sheet) and found an almost too perfect "1" value for the CHI^2/dof. Now I can definitely say I am happy with the result. Obviously when I tell AstroimageJ to bin the data, it doesn't know that the red noise exists (meaning it doesn't scale the error bars correctly) so the CHI^2/dof value rises, but not that much. Adding an option for red noise (either for calculating it or just adding it manually) would be incredible, just saying.. ahah
.
This time I used non-aligned images as you implied and found that using the WIDTH_T1 parameter to detrend improves the BIC value (and the CHI^2/dof) by quite a lot... almost as much as AIRMASS actually**. A bit of improvement also comes from SKY/PIXEL_T1 and ANGLE_T1. The other parameters don't really help (FWHM_mult now is a constant value). Could you point me to a source where the detrending calculations done here are explained? I have a vague idea of what the software is doing but I would like to be sure about that.
Since you were wondering about what filter we used, I am linking it here, combining this with the CCD bandwidth we're basically catching light from 610 to 1000nm or so. By the way, the fact that the depth of the light curve is a couple of mmag low compared to the depths in the literature is due to HD189733 companion, a ~10 v_mag star that is definitely inside the aperture and as you probably know, adds a constant mag value that causes this effect. Doing the math (subtracting the light of the companion) I find that the depth is consistent with the other ones.
Thank you for your incredible and continuous support. I would gladly help to update the software if I could but you have done an amazing job already.
P.S. Yes we had some "saturation alarms" at the end but consider that our CCD is linear up to 60k counts, so it doesn't matter that much. But yes it was a first attempt and we didn't consider that during the night the focusing was going to change (increase in this case) and therefore each pixel got more counts than expected towards the end. **Thinking about it now, since the focusing changed (~sinusoidally) during the observation, might this be the cause of the high detrending effect of the WIDTH_T1 value?
P.P.S. Do you generally apply the detrending parameters to check stars as well?
| Free forum by Nabble | Edit this page |