---
title: Siemens Image Calculation Environment (ICE)
url: https://www.emergentmind.com/topics/siemens-image-calculation-environment-ice
type: topic
---

# Siemens Image Calculation Environment (ICE)

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) [2507.12632] [2410.13348].

## 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 [2507.12632].

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 [2507.12632].

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 [2507.12632].

## 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 [2507.12632].

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 [2507.12632].

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 [2507.12632].

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 [2507.12632].

## 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 [2507.12632].

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 [2507.12632].

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 [2507.12632].

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 [2507.12632].

## 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 [2507.12632].

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 [2507.12632].

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 [2507.12632].

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 [2507.12632].

## 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 [2410.13348].

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, \(D_i\) is injected activity at injection time \(t_i\), \(t_c\) is the time to which the PET image is decay-corrected, and \(T_{1/2}\) is radionuclide half-life. Image values are obtained from stored pixels via
\[
A' = P \cdot S + I,
\]
using Pixel Data together with Rescale Slope and Rescale Intercept [2410.13348].

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 \((0071,1022)\). When Units \((0054,1001)\) = BQML and Decay Correction \((0054,1102)\) = ADMIN, Siemens, GE, and Philips all document that images are decay-corrected to injection time, implying \(t_c=t_i\) and therefore
\[
\mathrm{SUV}_{bw} = \frac{A \cdot w}{D_i}.
\]
When Decay Correction = START, Siemens uses Decay Correction DateTime \((0071,1022)\) as the decay-correction reference time \(t_c\) [2410.13348].

The paper reports several Siemens-specific pitfalls that are directly relevant to ICE-style pipelines. Series Time \((0008,0031)\) may be manually edited or modified downstream, whereas Acquisition Time \((0008,0032)\) 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 \(t_c\) 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 [2410.13348].

The practical implication for ICE is explicit in the technical note. A correct Siemens implementation must read Decay Correction, enforce \(t_c=t_i\) for ADMIN, use Decay Correction DateTime \((0071,1022)\) as the primary source of \(t_c\) 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 \((0071,1022)\) and should not blindly trust Series Time as the decay-correction reference [2410.13348].

## 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 [2507.12632].

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 [2507.12632].

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 [2410.13348].

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 [2507.12632] [2410.13348].

Source: https://www.emergentmind.com/topics/siemens-image-calculation-environment-ice