The ESRF beamline control software coordinates many devices during execution of experiments. These include dozens of 2D detectors which are used for quantitative data analysis on different X-ray applications: imaging, diffraction, scattering, spectroscopy, and beam and sample monitoring. An effort has already been made to unify the control of these devices with a single TACO/TANGO interface. However, each detector offers specific hardware capabilities, and the software development kits (SDK) provided by different manufacturers are not compatible. In practice, common code was not always shared and new software features were rarely back-ported to existing detectors. In addition, improvements in the X-ray beam brilliance and detector efficiency constantly encourage faster experiments, either to explore new time-resolved phenomena or to increase the sample analysis rate.

To simplify the integration of new 2D detectors a library for image acquisition, LIMA, has been developed at the Beamline Control Unit of the ESRF ISDD Software Group. LIMA’s design followed three goals: Firstly, to be control system-independant in order to promote collaboration with other institutes; secondly, to export a common set of features for every detector, providing alternative software solutions when not implemented by hardware. Thirdly, because it is oriented towards high-performance acquisition, it aims to exploit every optimisation available in the detector and makes intensive use of parallel algorithms. The library clearly separates the roles of a low-level hardware layer, which interfaces to the detector SDK, and a control layer on top of it, responsible for configuring the generic part of the acquisition and managing the software image processing. A modular design of both layers allows the integration of new hardware capabilities and software extensions while keeping backward compatibility. This structure permits library evolution with minimal effort. Different kinds of imaging applications can be built on top of the LIMA library, including device servers for distributed control or standalone graphical user interfaces (GUI).

Several operations can be applied to an image before it is considered ready for data analysis. First, a frame reconstruction might be necessary if not performed at the hardware level on multi-chip or parallel readout designs. Next, basic geometric transformations can be activated, including pixel binning, region-of-interest (ROI) selection, horizontal/vertical mirror (flip) and standard 90/180/270° rotations. Detectors providing stripe-like data at a high frame rate are supported by the built-in stripe concatenation mode. A full stack of images is handled in a single read/save operation, notably reducing the single-frame overhead.

Constraints in some detector hardware limit the pixel integration process, either by time (ESRF Frelon) or by dose (ESRF Maxipix). This is solved in LIMA by means of software accumulation. It is activated by specifying a maximum frame exposure time; the control layer calculates the actual number of hardware frames depending of the requested total exposure time. In addition to the accumulated image, a saturation pixel mask is also obtained, necessary to detect non-linear software artifacts. Finally, depending on the experimental conditions, software operations like background subtraction, flat-field correction and pixel masking can be executed. An example sequence of these operations is shown in Figure 151.

Fig. 151: Example sequence of image operations performed by hardware (pink) and by software (yellow).

Data reduction algorithms are available for online analysis. Statistical calculations, performed on a per-ROI basis (ROI counters), and centroid determination, used in beam position monitoring applications, can be activated. User-defined image processing tasks in C++ or Python are also allowed. All of these software tasks are executed in parallel, allowing the system to scale to multi-CPU/cores when performance is an issue.

Metadata is handled in LIMA by means of (image) headers, sets of “key: value” lines. Three kinds of headers are identified: static, common and frame. The static header has constant data like the detector brand and model. The common header stores data associated with a sequence of frames (scan), like the start date and time, the sample name and a snapshot of all motor positions. The frame header contains real-time information: time-stamp, detector metadata, software processing details (execution time), as well as optional user-defined data. The library provides three triggers to save each image to disk: on user demand (manual); when the frame is ready (auto-frame); when both the frame and its associated user-defined header are ready (auto-header). Currently available file formats are EDF, CBF (crystallographic binary file) and Nexus/HDF5. In addition, LIMA allows parallel saving on multiple file streams to different destinations: the central storage server, an online data analysis workstation, or a NAS with user disks used to take data back to home.

Table 1: Detectors controlled with LIMA at the ESRF and their performances.

Although still under development, LIMA already controls around a dozen detectors and is in production on several beamlines. A summary of the supported detectors and their measured performance at the ESRF is shown in Table 1. LIMA is an active collaboration between many facilities, with contributions from SOLEIL, PETRA III, and ADSC detector manufacturer, and beta-testers/observers including ALBA, ILL, MAX-lab and the commercial company Nexeya Systems.

 

Principal publication and authors

A. Homs, S. Petitdemange, E. Papillon, L. Claustre, R. Homs and A. Kirov, Proc. of ICALEPS-2011 Conf. (JaCoW.org), WEMAU011, 676-679 (2011).

ESRF