Siemens Image Calculation Environment (ICE)

• Siemens Image Calculation Environment (ICE) is the on-scanner image reconstruction framework that processes raw k-space data and performs inline quantitative parameter estimation.
• The framework uses custom C++ extensions and ONNX runtime integration to enable real-time neural network inference for qMRI and PET quantification entirely on the reconstruction server's CPU.
• ICE maintains clinical workflow integrity by embedding derived parametric maps into the scanner’s native reconstruction chain while adhering to Siemens-specific DICOM semantics.

Siemens Image Calculation Environment (ICE) is the on-scanner image reconstruction framework used by modern Siemens systems. In the reported implementations, raw k-space is sent from the scanner to a reconstruction server running ICE, which reconstructs images slice by slice and can be extended by custom C++ code for derived-image generation and quantitative processing. Recent work shows two complementary roles for ICE: first, as a native host for scanner-integrated machine learning that performs inline quantitative MRI parameter estimation and exports derived maps as standard DICOM series; second, as the kind of Siemens reconstruction or quantification chain that must respect vendor-specific DICOM semantics when computing PET standardized uptake values (SUVs) (Rot et al., 16 Jul 2025, Fritsak et al., 2024).

1. Architectural position within Siemens scanner reconstruction

In the reported qMRI deployment, ICE is the native reconstruction pipeline running on the reconstruction server of a MAGNETOM Vida 3T system. Raw k-space is sent from the scanner to this server, ICE reconstructs images slice by slice in the standard way, and custom processing is inserted after conventional image reconstruction (Rot et al., 16 Jul 2025).

The extension model is explicit. A custom reconstruction program in ICE, written in C++, receives reconstructed slices as they pass through the reconstructor, accumulates them into a higher-dimensional representation, and executes additional computation once the conventional image series has been completed. The paper further reports that, after copying the ONNX file of the trained neural networks onto the console PC, the custom ICE program was attributed to the raw data and evoked with a retrospective reconstruction call (Rot et al., 16 Jul 2025).

This placement within the scanner pipeline is significant because it distinguishes ICE from external post-processing utilities. The derived maps are produced in the same reconstruction environment that already performs the standard Siemens image-generation steps, rather than by exporting data to a separate workstation. A common misconception is that advanced quantitative estimation must remain outside the scanner workflow; the reported ICE implementation directly contradicts that assumption by embedding the estimation stage into the reconstruction chain itself (Rot et al., 16 Jul 2025).

2. Reconstruction flow and inline quantitative MRI processing

The reported inline qMRI pipeline is organized around a clear sequence of operations. The custom ICE program first accumulates slices and diffusion encodings into a 4D data structure as they are individually passed through the reconstructor. Once reconstruction of the conventional images is complete, they are normalised by the mean $b = 0\ \mathrm{s/mm^2}$ image. Inference is then performed voxel-wise with a trained neural network in ONNX format, and the resulting ODI, NDI, and FWF maps are exported as a separate DICOM series (Rot et al., 16 Jul 2025).

The normalization used by the method is

$\tilde{S}_i = \frac{S_i}{S_0},$

with $S_0$ defined as the mean of the $b=0$ images. The learned mapping can be expressed as a deterministic function $f_\theta:\mathbb{R}^{81}\to\mathbb{R}^3$, where the 81-dimensional input corresponds to the diffusion-encoded signal vector for a voxel and the three outputs correspond to ODI, NDI, and FWF (Rot et al., 16 Jul 2025).

The implementation is volume-wise rather than streaming at the voxel or slice level. Although ICE reconstructs the raw data slice by slice, inference is triggered only after the full 3D volume and all diffusion encodings have been reconstructed. This design follows directly from the model input requirements: each voxel must be represented by its full diffusion encoding vector before parameter estimation can occur (Rot et al., 16 Jul 2025).

Operationally, the inference runs on the CPU of the reconstruction server. No GPU is used in ICE; GPU hardware appears only in the offline training stage on a separate workstation. The reported inline reconstruction for the entire 3D brain volume took under 10 seconds, which includes accumulation, normalization, neural-network forward pass, and DICOM writing inside ICE (Rot et al., 16 Jul 2025).

3. ONNX integration and model deployment inside ICE

The machine-learning integration mechanism is based on ONNX Runtime. The implementation explicitly uses ONNX Runtime libraries, compiled into a custom reconstruction program in ICE using C++. The network is trained offline in PyTorch, exported to ONNX, copied onto the console PC, and then invoked within the ICE reconstruction environment (Rot et al., 16 Jul 2025).

The reported network architecture is deliberately compact. It uses 81 input nodes, three fully connected hidden layers with 120 nodes each, ELU activation with $\alpha = 0.05$, and a three-node output layer with hard sigmoid activation to constrain the outputs to $[0,1]$. The total number of parameters is 39,243. This suggests a design choice intended to satisfy the time and memory constraints of CPU-based reconstruction-server inference (Rot et al., 16 Jul 2025).

Two training regimes were evaluated. In NNMLE, the training labels are conventionally estimated parameters; in NNGT, the training labels are the ground-truth parameters used to generate synthetic training signals. The reported results generally found that NNMLE estimates were more consistent than NNGT with conventional estimates. Offline evaluation further confirms that NNMLE has comparable accuracy and slightly better noise robustness than conventional fitting, whereas NNGT exhibits compromised accuracy at the benefit of higher noise robustness (Rot et al., 16 Jul 2025).

An important framework property is the separation between ICE code and model content. The ICE program handles accumulation, normalization, tensor preparation, inference, and DICOM export, whereas the protocol-specific mapping from signal to parameters is encoded in the ONNX file. For that reason, a new qMRI protocol requires training a new neural network, though the ICE program need not be recompiled (Rot et al., 16 Jul 2025).

4. Output representation, DICOM handling, and clinical workflow

The inline outputs are ordinary scanner products rather than research-only intermediates. The resultant parametric maps of ODI, NDI, and FWF are output as a separate DICOM series, with floating point numbers stored as 12-bit integers scaled by 1000, achieving a precision of three decimal places. These maps are displayed inline on the scanner console PC and can be sent to PACS and clinical reporting systems just like conventional image series (Rot et al., 16 Jul 2025).

This output strategy has two technical consequences. First, the quantitative maps are geometrically co-registered with the source images because they are generated inside the same reconstruction environment. Second, the DICOM export step makes derived qMRI maps behave operationally like standard scanner outputs, reducing the need for external format conversions or workstation-based visualization (Rot et al., 16 Jul 2025).

The paper frames this shift as a transition from “research mode” qMRI, which relies on resource-intensive offline parameter estimation, toward “clinical mode” qMRI enabled by real-time, inline parameter estimation. In that formulation, ICE is not merely reconstructing raw images; it is also acting as the execution environment for quantitative model inversion and the publication mechanism for derived parameter maps (Rot et al., 16 Jul 2025).

A common misconception is that inline quantitative MRI necessarily requires custom hardware or external inference servers. The reported implementation instead performs the neural-network inference on the CPU of the reconstruction server and still achieves whole-brain inline NODDI estimation in under 10 seconds (Rot et al., 16 Jul 2025).

5. Siemens-specific quantification semantics: implications from PET SUV computation

Although the PET SUV technical note does not present an ICE implementation, it directly identifies the Siemens-specific DICOM semantics that an environment like Siemens ICE, or any Siemens reconstruction or quantification chain, must respect to produce correct SUVs (Fritsak et al., 2024).

For body-weight-normalized SUV, the reported formula is

$$\mathrm{SUV}_{bw} = \frac{A \cdot w}{D_i}\cdot 2^{\frac{t_c-t_i}{T_{1/2}}},$$

where $A$ is activity concentration in the image at scan time, $w$ is patient body weight, $\tilde{S}_i = \frac{S_i}{S_0},$0 is injected activity at injection time $\tilde{S}_i = \frac{S_i}{S_0},$1, $\tilde{S}_i = \frac{S_i}{S_0},$2 is the time to which the PET image is decay-corrected, and $\tilde{S}_i = \frac{S_i}{S_0},$3 is radionuclide half-life. Image values are obtained from stored pixels via

$\tilde{S}_i = \frac{S_i}{S_0},$4

using Pixel Data together with Rescale Slope and Rescale Intercept (Fritsak et al., 2024).

The technical difficulty is not the algebraic form of SUV but the vendor-specific interpretation of DICOM time references and units. For Siemens PET DICOM, the strategy relies on standard DICOM tags for injected dose, half-life, injection time, and patient weight, together with the Siemens private tag Decay Correction DateTime $\tilde{S}_i = \frac{S_i}{S_0},$5. When Units $\tilde{S}_i = \frac{S_i}{S_0},$6 = BQML and Decay Correction $\tilde{S}_i = \frac{S_i}{S_0},$7 = ADMIN, Siemens, GE, and Philips all document that images are decay-corrected to injection time, implying $\tilde{S}_i = \frac{S_i}{S_0},$8 and therefore

$\tilde{S}_i = \frac{S_i}{S_0},$9

When Decay Correction = START, Siemens uses Decay Correction DateTime $S_0$0 as the decay-correction reference time $S_0$1 (Fritsak et al., 2024).

The paper reports several Siemens-specific pitfalls that are directly relevant to ICE-style pipelines. Series Time $S_0$2 may be manually edited or modified downstream, whereas Acquisition Time $S_0$3 is stored per slice or frame and reflects actual data acquisition start. In three Siemens cases, a time difference of more than one hour between Series Time and the earliest Acquisition Time caused vendor-neutral tools that used Series Time as $S_0$4 to underestimate SUV by approximately 33%. The paper also reports Siemens data in which the private Decay Correction DateTime had the correct time but the wrong date, so naïve use of the full DateTime would introduce a 24-hour error (Fritsak et al., 2024).

The practical implication for ICE is explicit in the technical note. A correct Siemens implementation must read Decay Correction, enforce $S_0$5 for ADMIN, use Decay Correction DateTime $S_0$6 as the primary source of $S_0$7 for START, and fall back to the earliest Acquisition Time if the private tag is missing or unusable. It must also be robust against date inconsistencies in $S_0$8 and should not blindly trust Series Time as the decay-correction reference (Fritsak et al., 2024).

6. Generality, limitations, and reported significance

The qMRI paper explicitly describes the ICE-based approach as a generalisable framework. Its central design choice is to keep the reconstruction code generic while encoding the protocol-specific signal-to-parameter mapping in the ONNX model. This suggests a broader role for ICE as an inline host for quantitative inference, provided that the acquisition protocol, training data, and deployed network remain matched (Rot et al., 16 Jul 2025).

The reported framework is not unrestricted. The neural networks are independent of generic acquisition parameters such as spatial resolution or TR, although signal-to-noise ratio should be similar between training and in vivo data; however, they depend on the diffusion encoding scheme, or more generally on qMRI-specific protocol parameters. Consequently, each new qMRI protocol requires training a new network. The paper also notes that highly advanced diffusion models may still require corrections for residual eddy current effects and motion in post-processing, and it identifies scanner-integrated correction strategies as a future direction (Rot et al., 16 Jul 2025).

The SUV technical note identifies a different class of limitation: vendor-neutral “happy-path” assumptions can be quantitatively wrong in real Siemens data. The reported comparison found errors in SUV estimation reaching 33% when software did not fully account for vendor-specific DICOM attributes and PET image acquisition times. In Siemens cases, the primary failure mode was incorrect interpretation of the decay-correction reference time rather than any ambiguity in the SUV definition itself (Fritsak et al., 2024).

Taken together, these reports position ICE as both a reconstruction framework and a site of quantitative responsibility. In qMRI, it can host trained neural networks that generate scanner-native parametric maps in near-real time. In PET-style quantification chains, a plausible implication is that ICE must embody Siemens-specific DICOM logic, private-tag handling, and timing sanity checks if it is to support rigorous inline quantification. The broader significance is therefore not only computational efficiency, but also the relocation of model-based estimation and vendor-specific semantic interpretation into the scanner’s native reconstruction environment (Rot et al., 16 Jul 2025, Fritsak et al., 2024).