Remodel Persistence
After discussing with Yves today, we should add a 'create persistence map' recipe and pipeline to our design. ESO will run this pipeline, and design the HDRL library for it, but it makes sense if we define the recipe, because we know what header keywords and QC parameters etc. we want.
The current, tentative, division of labor (not formally agreed upon). In reverse order:
- Applying Persistence Image:
- Scientist runs pipeline.
- MICADO creates recipe and integrates it into pipeline.
- ESO creates HDRL function for this if necessary, but existing CPL routines will probably suffice.
- Mark Neeser creates prototype (already done).
- Deriving Persistence Image
- ESO runs pipeline. Scientist might run pipeline after proprietary data period is over.
- MICADO creates recipe / pipeline, specific to MICADO, e.g. header keywords and such.
- ESO creates HDRL recipe, instrument independent. Will include uncertainty.
- Mark Neeser creates prototype.
- Deriving Persistence Parameters. E.g. how quickly does persistence decay in each specific detector.
- ESO(?) will run this pipeline / software on (lab?) calibration data, that ESO(?) will take. Will this become public?
- ESO(?) creates the recipe / pipeline to derive these parameters.
- ESO(?) creates HDRL(?) library for this.
- Mark Neeser creates prototype.
See also Jira issue: https://jira.eso.org/browse/PIPE-8686 "DMO CCB: HDRL Implementation of Infrared Detector Persistence Correction".
So we need to add at least a 'create persistence' pipeline / recipe to our standard imaging pipeline.