docs: ROIs/azimuthal apply to both FPGA and DECTRIS workflows

Clarify in FPGA_DATA_ANALYSIS.md that the ROI and azimuthal definitions
are also evaluated on CPU via the shared image_analysis library, so they
apply to the DECTRIS SIMPLON (EIGER) path that has no FPGA, not only the
FPGA-accelerated JUNGFRAU/PSI path. Document the three NXmx writer formats
(Legacy/VDS/Integrated) and the two acquisition workflows in CLAUDE.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

CLAUDE.md

@@ -101,6 +101,18 @@ class). Per-image arrays (one entry per frame) are written to the **data** files
 `HDF5DataFilePlugin` subclasses in `writer/`. Put shared metadata in `NXmx`, not in a data-file
 plugin.
 
+The HDF5 master/data layout is one of three `FileWriterFormat`s (`common/JFJochMessages.h`),
+all NXmx: **`NXmxLegacy`** (master + `_data_NNNNNN.h5` joined by external links),
+**`NXmxVDS`** (master + data joined by HDF5 virtual datasets — the default), and
+**`NXmxIntegrated`** (a single self-contained file, no separate data files). Per-image plugins
+must work for all three; with `NXmxIntegrated` "master" and "data" are the same file.
+
+**Two acquisition workflows:** the FPGA-accelerated path (JUNGFRAU at PSI; FPGA does masking,
+summation, spot finding, ROI/azimuthal integration, compression) and the DECTRIS SIMPLON path
+(EIGER), which has no FPGA — masking/ROI/azimuthal analysis then runs on CPU through the shared
+`image_analysis/` library. Treat ROI and azimuthal features as available in **both** workflows,
+not FPGA-only.
+
 **`jfjoch_broker`** (`broker/`) is the central online service: HTTP/REST + OpenAPI control plane,
 FPGA configuration, image building, ZeroMQ output. `JFJochStateMachine` drives acquisition state;
 `JFJochServices` wires the pieces; `OpenAPIConvert`/`JFJochBrokerParser` translate between the

docs/FPGA_DATA_ANALYSIS.md

@@ -36,6 +36,9 @@ This way 2D azimuthal integration, as needed for example by SAS-TT, cannot be cu
 One needs to be careful with per-pixel corrections - their acceptable range is constrained by 16-bit pixed point integer implementation
 and is tuned for standard SAXS/WAXS range.
 
+As with ROIs, azimuthal integration is also available on CPU through the shared analysis library,
+so it applies to both the FPGA-accelerated (JUNGFRAU/PSI) and the DECTRIS-driven (EIGER) workflows.
+
 ## Spot finding
 Jungfraujoch FPGA implements a built-in spot finder. Spot finder allows to apply the following criteria for finding strong pixels:
 1. Resolution criterion - pixels only within a provided resolution range can be considered as strong pixels (calculating resolution map needs to happen on CPU before data collection run).
@@ -58,6 +61,11 @@ Given very large box size, approximation are made, for example that `N ≈ N-1`
 Each pixel in a module can be assigned to one of 64 ROIs. For each ROIs, sum, sum of squares, max count, and number of valid pixels will be calculated.
 Jungfraujoch also calculates X and Y values weighted by pixel values, though this feature is not properly tested at the moment and not integrated in downstream analysis.
 
+ROIs are not specific to the FPGA path. The same ROI definitions — box, circle, and azimuthal
+(Q-range with an optional φ-sector) — are also evaluated on CPU by the shared `image_analysis/roi/`
+engine, so ROI statistics are produced both for the FPGA-accelerated JUNGFRAU/PSI workflow and for
+detectors driven through DECTRIS SIMPLON (e.g. EIGER), which have no FPGA acquisition path.
+
 ## Pixel statisitics
 The following statistics are collected for each module:
 * Number of masked pixels