This is an issue I've been gathering experience with for some months now, and I hope someone can offer a solution. At a given temperature setpoint, I've found that camera "self warm up" and ambient temperature directly affect the mean ADU level on exposures. This is easily validated by doing either of the following: - Power on the camera and set a sensor setpoint near (but below) ambient. After setpoint stabilization, begin taking short (0.1s) dark exposures regularly. Watch the mean ADU rise over time. - With the camera operating at a given setpoint, introduce an ambient temperature change (space heater, central air, put it outside, bring it inside, etc). Begin taking short dark exposures regularly. Watch the mean ADU follow the direction of the ambient temperature change. On 0.1s frames, I've seen the ADU drift upwards of 40 counts from power up. While this doesn't sound terrible (though bothersome), it really rears an ugly side when considering calibration frames are typically taken indoors, and many of us image out in the cold during winter. I ran into a remarkable situation when I had 15' Ha frames with an ADU pedestal *lower* than my 0.1s bias master taken indoors from 200 subexposures. The attached graph shows a power-up experiment I performed using 0.1s dark frames taken 15s apart over the course of 15 minutes (60 frames altogether) with a sensor setpoint of 15C. More considerable drift can be seen if altering ambient temperature. This behavior is seen whether or not "Auto Bias Level Adjust" is enabled in the driver. I've never been able to figure out what that does. I'm aware of the overscan regions, but would rather avoid this feature as a means to "calibrate out" the drift. I've never seen anything like this drift on other temp-controlled cameras, so hope there's something that can be offered in the way of a solution. Camera info: - Firmware 2.48 - sbigudrv: 4.90 build 1 - sbigu64: 2.41.0.1338 - sbigpcam: 2.46 - sbiglcam: 2.20 - sbigfcam: 2.25 - sbigfga: 2004.11.10 Thanks in advance for any thoughts.
We have observed a slight temperature-dependent drift in the STF-8300 in house. At the moment, all we can suggest is that you try and take your calibration frames as close to the same ambient temperature as your light frames as you can manage. As for Auto Bias Level Adjust, we advise not using it. It basically measures the bias level of the CCD when it takes an image, and offsets the resulting image ADU levels by that measured bias level. We advise performing a proper Dark/Bias/Flat-field correction in post-processing.
Thanks very much for your reply, Adam. That's good to know that you've confirmed this on other 8300s. For obvious reasons, the thought of keeping multiple sets of calibration frames across different ambient temps is a little daunting, though I certainly agree with and understand the reasoning. I wonder if this drift is consistent across different 8300s. I have access to an incubator (-15C - 50C), and am considering trying to characterize the drift. It may be sufficient to apply an appropriate pedestal adjustment to the light frames based on the ambient temperature at the time of the exposure (or more crudely, the average ambient over the course of the session). This might permit a single set of calibration data to provide better consistency across light frames taken at different temperatures. Of course, I (we) hope there might be a correction in the firmware or driver that'll handle this drift in the future I'll keep attention to any developments on this. Thanks again for the reply on this, as well as for the advice on the auto bias setting.
FWIW: Since I've been trying to figure out an issue with darks, I have tons of calibrations frames taken in different ambient temperature. I can confirm the issue. -- Median value of bias ambient temp 0C, set temp -5C around 1100 ADUs. -- Median value of bias ambient temo 20C, set temp -5C around 1450 ADUs. Cheers, Jose
Hi, FWIW: I also checked some sets of darks taken at different ambient temperature (CCD temp = -20C) and the ambient temperature affects the dark frames mean value in a similar way as the bias. Cheers, Jose
Thanks for your input/data Jose. Good to know of others seeing this too. The overscan regions (enabled through the driver) currently seem to be most accurate way to address this. At a quick look, I'm finding these normalize the frames well in post-processing via PixInsight, etc. The only problem with this is that some (many?) acquisition programs don't deal well with these non-signal regions for centering functions, focusing functions, etc. While I think it's nice to have the overscan data available, it might be a nice user option to have the driver automatically apply overscan correction in some way and keep it out of the downloaded frames. Real-time correction would be extremely helpful for in-the-field focusing routines where correction against a previously generated dark library is applied on the fly.
Hi funkmeisterfred, I thought the Auto Bias Level Adjust was some sort of automatic overscan correction, I tried to use it and apparently it doesn't make any difference to the images. So it looks like this feature is not implemented. I took a look to the overscan regions and something doesn't look right. For instance the overscan region mean value is smaller than the active region of bias and dark frames. The mean value should match in dark and bias frames! I use SGP and indeed overscan is not properly handled. Cheers, José
Hi José - Yes, as Adam noted above, SBIG currently advises not using the Auto Bias Level Correction. It sounds like there may be inconsistency with this feature. I'm not an expert on the overscan regions, but I do think it's normal for the region not to match the mean ADU of the active region. As opposed to the active area which includes bias and read noise, overscan represents a pure sensor offset without these other 2 components, which would explain the lower mean ADU. I think the more important characteristic is that the overscan region does appear to give a representation of the ambient drift we've seen. That said, it may be that I've mislabeled this issue as "bias drift" when it may more accurately be called "offset drift." I found that a subtraction of the overscan mean results in overcorrection on bias frames (as well as some darks). To get around this, I'm adding a pedestal of 200 ADU in PixInsight before overscan subtraction on any frame. In my limited testing, I have indeed found this to give good, steady results across ambient temperatures while retaining positive pixel values. I use SGP as well. I'm anxious for overscan support to be added there (I've already issued a feature request for this), or for an offset-correction to be added in the SBIG driver. It will be tough to calibrate light frames with overscanning until one (or both) of these is available.
The overscan region is usually used for equalizing any line-to-line variations in bias/offset - which doesn't really tend to happen on modern cameras so it's rarely used. Some very picky people (professional astronomers) will use the overscan region as part of the calibration process.
Thanks for the reply Doug. I wasn't aware of the line-to-line variation aspect of this -- very interesting. I certainly wouldn't class myself as a professional, though I am picky Do you think the (perhaps unusual) application of the overscan regions to adjust for ambient-related offset has merit? Some early testing here shows hope.
Doug, that's fantastic news! I'm really happy to hear that you'll be able to integrate a solution for this. Looking forward to being able to test it in the field whenever it's available. Keep us posted!
