The bad video dark issue in SAS_v15 was due to a mistake in registering the video dark detrend files in the database. All but one video dark was registered to be valid for a single second only (time_begin = time_end), resulting in that one video dark (det_id 977 | VIDEODARK | time_begin = 2009-12-09 00:00:00 | correct_time_end = 2010-01-23 00:00:00 | ref_det_id 299) being used for all times. This has been corrected. Below I show the camera stage mosaic for exp_id 356773:

Reduction Mosiac

As this seems to have resolved the problems, I will launch a new SAS-scale test, as well as replaces for the MD tests.


If the signal that creates the difference between the regular dark models and the video dark models is a constant, it should be possible to construct historical video darks based on the set of darks we currently have, as well as a master video dark. The current dark model is of the form

D = D0 + D1 * exp_time + D2 * (exp_time * ccd_temp) + D3 * (ccd_temp**2 * exp_time)

D3 is set to be 0.0 in all current dark models, as we've not been convinced that a term quadratic in temperature is useful. From this model, we can see that a plausible historical dark could be constructed by taking:

D_historical_VD = D_historical - D + D_VD

where we've assumed that the video dark signal is simply an addition to the Di terms. The following image shows o5235g0195 OTA45, processed with the standard chip processing and USE.VIDEO.MASK set to false. On the left panel, GPC1.DARKTEST.norm.862.0.XY45.fits was the dark model used. On the right, a test dark was constructed as suggested above using:

  ./immath3d --subtract GPC1.DARKTEST.norm.862.0.XY45.fits GPC1.DARKTEST.974.0.XY45.fits t1.fits
  ./immath3d --add t1.fits GPC1.DARKTEST.975.0.XY45.fits test.fits

Frankly, I'm somewhat surprised that worked so well too.


Video darks were constructed using the standard detrend creation code. No code changes were required, other than a check that a readout existed (which probably should have been included in any case). No data limits were imposed, only that dev0 (OTA columns 0,1,6,7) and dev1 (OTA columns 2,3,4,5) exposures were combined only with others of the same dev class. This then generates two VIDEODARK models, each of which is appropriate for half of the detector. A single model can be constructed by registering individual OTAs. In addition, this process could be used to construct a standard DARK model simultaneous (using those OTAs that did not have video signals during the exposure).

The main incentive for constructing video dark models is to mitigate the over-subtracted corner glows seen on OTAs that have video. For a selection of OTAs that have video cells, the current default dark model was applied (with masking disabled to prevent the video mask from disguising the issues). In addition, the appropriate video dark model was also applied.

In addition, it appears that this improved dark model helps reduce the M31 OTA offset issue described here. This figure shows the same kind of profile as was used there, although smoothed every 10 rows to reduce the influence of noise. The red curve shows OTA45, which has no video cell, and as such, does not change. The blue curve shows the profile of OTA46 with the default dark, and the green curve shows the same profile with the new video dark applied. There are slight shifts to the profile level, and although it may not fully remove this OTA-to-OTA offset, it does appear to be reduced for this case.