Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-25921

Liaise with camera team about CTI correction

    XMLWordPrintable

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: cp_pipe, ip_isr
    • Labels:
      None

      Description

      Adam Snyder has written lots of great CTI correction code, and there was talk with Aaron Roodman in March about getting some of this DM-ified.

      Ticket is to get this conversation restarted, and put somewhere more appropriate than in private messages.

        Attachments

          Activity

          Hide
          snyder18 Adam Snyder added a comment -

          My code for the CTI/deferred charge correction is available at: https://github.com/snyder18/ctisim

          The script I use for correcting the SLAC data is: https://github.com/snyder18/ctisim/blob/master/scripts/correct_images.py

          I do bias/overscan/gain calibration but no assembly because I am just saving the results to another FITs file with the same multiple HDUs as the original image file.  

          The parameterization per amplifier are two variables for the electronics component (scale and decay time), a global CTI parameter, and the trap definition.  For traps I have been using a look-up table with values taken from the flat field overscan results, but one could also define the traps via a functional form and parameters.

          Show
          snyder18 Adam Snyder added a comment - My code for the CTI/deferred charge correction is available at:  https://github.com/snyder18/ctisim The script I use for correcting the SLAC data is:  https://github.com/snyder18/ctisim/blob/master/scripts/correct_images.py I do bias/overscan/gain calibration but no assembly because I am just saving the results to another FITs file with the same multiple HDUs as the original image file.   The parameterization per amplifier are two variables for the electronics component (scale and decay time), a global CTI parameter, and the trap definition.  For traps I have been using a look-up table with values taken from the flat field overscan results, but one could also define the traps via a functional form and parameters.
          Hide
          mfisherlevine Merlin Fisher-Levine added a comment -

          Adam Snyder that's really great, thank you!

          John Swinbank we can probably call this ticket done, right? Would you like a back-up fork made in lsst-dm or something like that, or do you think this is OK for now?

          Show
          mfisherlevine Merlin Fisher-Levine added a comment - Adam Snyder that's really great, thank you! John Swinbank we can probably call this ticket done, right? Would you like a back-up fork made in lsst-dm or something like that, or do you think this is OK for now?
          Hide
          swinbank John Swinbank added a comment -

          I don't think a fork is necessary at this stage, but I do think we should have some follow-up ticket to capture what happens next. That could either be “do the work of getting this integrated in DM”, or it could be “convene some sort of discussion about this” — I don't immediately care which as long as there's some sort of indication of outstanding work.

          Show
          swinbank John Swinbank added a comment - I don't think a fork is necessary at this stage, but I do think we should have some follow-up ticket to capture what happens next. That could either be “do the work of getting this integrated in DM”, or it could be “convene some sort of discussion about this” — I don't immediately care which as long as there's some sort of indication of outstanding work.
          Hide
          mfisherlevine Merlin Fisher-Levine added a comment -

          I think Andrés Alejandro Plazas Malagón has ended up doing/has done this work now, so this ticket should probably be marked as done, and the follow up referred to above dealt with by Andrés (which may have already happened).

          Show
          mfisherlevine Merlin Fisher-Levine added a comment - I think Andrés Alejandro Plazas Malagón has ended up doing/has done this work now, so this ticket should probably be marked as done, and the follow up referred to above dealt with by Andrés (which may have already happened).
          Hide
          plazas Andrés Alejandro Plazas Malagón added a comment -

          I was able to run Adam's code at NCSA (with Adam's help), and reproduce some of his sCTI plots from his oncoming paper for one sensor (DM-26352), but his code has not been ported to the DM stack yet.

          Show
          plazas Andrés Alejandro Plazas Malagón added a comment - I was able to run Adam's code at NCSA (with Adam's help), and reproduce some of his sCTI plots from his oncoming paper for one sensor ( DM-26352 ), but his code has not been ported to the DM stack yet.
          Hide
          rhl Robert Lupton added a comment -

          I thought we'd decided to split the "run at NCSA" from "port to DM" issues, so I think we should close this ticket on the basis of agreement on "NCSA" reductions with results derived at SLAC.

          Show
          rhl Robert Lupton added a comment - I thought we'd decided to split the "run at NCSA" from "port to DM" issues, so I think we should close this ticket on the basis of agreement on "NCSA" reductions with results derived at SLAC.
          Hide
          mfisherlevine Merlin Fisher-Levine added a comment -

          Agreed - done.

          Show
          mfisherlevine Merlin Fisher-Levine added a comment - Agreed - done.

            People

            Assignee:
            mfisherlevine Merlin Fisher-Levine
            Reporter:
            mfisherlevine Merlin Fisher-Levine
            Watchers:
            Adam Snyder, Andrés Alejandro Plazas Malagón, John Swinbank, Merlin Fisher-Levine, Robert Lupton
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: