A change to the order of operations for ISR

Data Management
#1

The standard LSST Science Pipelines instrument signature removal (ISR), which is run as part of processCcd, includes several operations. One of these is crosstalk correction. Crosstalk occurs when a bright source in one region of an image results in a “ghost” (which may be positive or negative) to appear elsewhere due to undesired electronics coupling.

A default CrosstalkTask exists in ip_isr, but it was not being regularly used to process data for some time. Custom crosstalk correction tasks exist for both HSC and DECam (and possibly others). It was recently discovered that implementing the DECam crosstalk correction (DM-10299) broke the default CrosstalkTask in ip_isr because the order of ISR operations was changed.

The ticket to fix the default CrosstalkTask so it works with this order of operations is DM-15152. The tests will be updated to catch any future order changes in DM-15164. The initial conversation which raised this problem was on Slack in #dm-lsstcam when lsstCamera data was first being processed with obs_lsstcam. The crosstalk subtraction appeared offset in the images by 13 pixels, which is the difference between a trimmed and untrimmed image.

It is worth noting that DECam crosstalk correction was tricky to implement due to inter-CCD crosstalk. For example, on DECam, a victim amp with ccdnum=47 could have a crosstalk source originating from an amp in, say, ccdnum=50. In the default CrosstalkTask in ip_isr, it is assumed that all appreciable crosstalk happens between amps on the same CCD.

Developers and users should be aware that ip_isr presently does crosstalk correction after overscan correction but before CCD assembly. This means CrosstalkTask now operates on an untrimmed image. Previously, crosstalk correction took place later, after CCD assembly (a process which includes trimming the overscan regions), bias correction, and linearization.

#2

Comments:

  1. xtalk correction should happen after bias correction too, not before – xtalk is a real analog signal on top of the bias
  2. single-raft xtalk measurements (see Adam Snyder’s presentation at https://confluence.slac.stanford.edu/download/attachments/209355949/I%26T_xtalk_20180717.pdf?version=1&modificationDate=1531811897000&api=v2) indicate that xtalk is negligible from CCD to CCD, but he’s only measured one ITL raft so far, so that is a preliminary conclusion
  3. just a mention - both positive and negative xtalk is observed
  4. xtalk vs. linearity, ie. should the correction be made before or after linearity correction, is an open question, under current study. We are also going to look at whether the xtalk itself is linear.

Aaron

1 Like
#3

Thanks for your comments Aaron.

  1. It’s my understanding that this “bias” is usually handled via overscan correction. In the DES pipeline (DECam), for instance, the master bias images are themselves overscan- and crosstalk-corrected before being subtracted from science images. I’m not sure if this is universally true.

  2. Is there a way to view the presentation you reference without being on the SLAC Confluence?

  3. Yes indeed, I mentioned this at the beginning of my summary

  4. For what it’s worth, the DECam crosstalk correction implemented in obs_decam (and the one used by DES) only uses the linear crosstalk coefficients, though small contributions from higher order terms have been measured. It would be interesting to see if these get even more negligible if the empirical crosstalk coefficient measurement were done after linearization rather than before.