...

• det = run.Detector(det_name)
• det.raw.raw(evt) returns 2D array for single-segment detectors, dict for multi-segment detectors.  key is panel number (integer). similarly for det.raw.calib(evt)
  • have a flag if we want 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)
• 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 similar to det.raw.raw() multi-segment detectors could also be used for ROIs 
  • ROIs also need the information about the "corner" of the ROI
  • 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 (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())
• epix/jungfrau offsets should be handled uniformly: like the Jungfrau so they can be changed without redeploying pedestals
• all python methods of an area detector should start with "_" except raw(),calib(),image() because we want to keep the ami interface simple.

Addendum on Jan. 5, 2021

• two categories (1) calibconst and (2) data access. cpo believes raw/calib/image in detector interface and calibration constants access has separate interface.  Dubrovin thinks perhaps "det.raw.calibconst" (i.e. access through detector interface).  cpo thinks bad_pixel_mask is part of "calibration constants" (category (2)) and would be used by the area detector interface (to avoid implementing it twice).
  • calibconst = CalibConst('tmo_epix')
• Mikhail highlights this example: e.g. det.raw.common_mode_level(evt) should be part of the area detector interface (category (1)) because it depends on the event data
• Mikhail proposes:
  • calibconst = det.raw.calibconst()
  • Right now ami ignores methods with "_", the above proposal would require AMI to ignore special methods like "calibconst" because it doesn't follow the det.method(evt) pattern required by AMI (with "amitypes" return type).  This is required by all det xface attributes.
• cpo believes that "everybody" uses AreaDetector, but few people use CalibConst.  That is part of the motivation for splitting up the interfaces.

2020-09-04 Proposal for Detector interface from Mikhail

...