Page History

...

• det = run.Detector(det_name)
• array = det.raw.raw(evt) returns 2D array for single-segment detectors, dict =det.raw.calib(evt) for multi-segment detectors.  similarly .  key is panel number (integer). similarly for det.raw.rawcalib(evt)
  we will return a natural shape for the above (2D for opal, dict for cspad/epix) and
  • have a
  global-
  • flag if we want
  everything to be dict
  • to return single-segment detectors as a dict as well (e.g. for uniformity in psocake)
  • maybe image(evt, array=array) should be an algorithm? det.raw.image(evt,array=None)? or could split det.raw.image(evt), det.raw.image(array=array)? ideally shouldn't have to pass evt.
  • get_calib_const(det_name, timestamp or run or evt).  Mikhail suggests we should consider det.get_calib_const(timestamp or run or evt).  cpo believes it should be separate from the detector interface (unlike LCLS1)
  • flexible number of segments (no hardwired "32" segments for a cspad).  e.g. a "full detector" may have segments 2,3,4,7,8,9.  one run may have segments 3,4,7 another run may have segments 2,3,8,9
    • calibration data must be taken and stored with all segments in the "full detector" (i.e. 2,3,4,7,8,9)
    • should det.raw.calib pad the missing segments in a given run? (e.g. for a run with segments 3,4,7 should we put zeros for 2,8,9?)
  • try to use same common-mode algorithm for all detectors (stripes/banks).  multiple passes needed for different directions. (e.g. Jungfrau and epix are currently same)
  • default geometries for single panel detectors
  • what do do about ROIs (future problem)?
    
    • dict approach for similar to det.raw.raw() multi-segment detectors could also be used for ROIsROIs 
    • ROIs also need the information about the "corner" of the ROI
    • ROIs software ROIs are really "feature extracted" data i.e. instead det.raw.image() it's det.fex.image()
    • hardware ROIs should be handled in a manner similar to hsd
  • how do we reuse the python code in the DRP which is multi-threaded C++?  cpo suggests maybe we have a python multi-process DRP.  another labor-intensive option is supporting multi-threaded C++. or write C++ and wrap with python (was complicated for the hsd, but perhaps just because we needed to avoid 1MHz malloc)
  • DRP will have to work on "one or more segments " of a full detector (probably in units of panels).  this is why it's important that the detector interface be very flexible with the panels it processes (e.g. for det.calib())