A feature name is not an operational definition

The measurement chain ends in an implementation applying a definition to prepared data. That last step is easy to under-report. Two laboratories can use the same package, the same image, and a column called original_glcm_JointEntropy, yet still have left enough unstated for the numbers to mean different things. The name is an API label. The measurement is the label together with the effective configuration that produced it.

An operationally complete report would therefore read like this: under a named implementation and version, on a named image type, after stated geometry and intensity processing, with a stated region, discretisation rule, aggregation convention, and estimator, this feature value was obtained. The point is not to make every paper long. It is to make the choices that determine the value inspectable.

What the definition has to contain

The following clauses are a compact reporting model. Their exact values belong to the protocol being studied, not to the feature name itself:

Clause	Question it answers
Mathematical feature definition	What function of the prepared data is being evaluated?
Software and version	Which implementation, defaults, and numerical behaviour are in force?
Image type and feature scope	Was the original image used, or a filtered or transformed image? Which classes and names were enabled?
Region and label	Which tissue and label were measured, and how was the region represented?
Dimensionality and geometry	Is the calculation 2D, per-slice, or 3D, and on which physical grid?
Preprocessing	What happened to intensity, resampling, clipping, normalization, and resegmentation, and in what order?
Discretisation	How were continuous intensities mapped to the grey levels used by texture matrices?
Aggregation and estimator	How were directions, distances, subjects, and moments combined?

Leaving out one of these clauses does not always make a result unusable, but it does make its reproducibility and comparison weaker. A feature name cannot tell a reader which defaults filled the gaps, whether preprocessing happened outside the extractor, or whether an apparently repeated value was calculated with the same estimand.

Effective configuration is part of the result

A parameter file is a declaration, not necessarily a complete record of execution. The extractor may fill omitted values from version-specific defaults, resolve an enabled feature list, apply a schema-defined interpretation, and receive preprocessing that happened in an earlier script. The effective configuration is what the installed implementation actually does after all of those steps have been resolved.

This is why reproducibility checks should load the parameter file through the implementation and inspect the effective settings rather than comparing YAML or JSON text by eye. In current PyRadiomics, omitting resampledPixelSpacing resolves to None, which means that the extractor performs no resampling. The same omitted field may have an implicit default in another implementation, so cross-implementation behaviour must be checked rather than inferred from omission. A file can validate correctly while still leaving important choices unstated. External preprocessing is an even quieter gap: a resampled image or clipped intensity range is not described by an extractor’s parameter file unless that operation is represented there.

The same distinction prevents two similar operations from being confused. An intensity clip revalues image samples outside a range; a resegmentation rule may remove samples from the calculation by changing the effective intensity mask. Whether a particular implementation preserves a separate morphological mask is another setting to report. Treating these operations as interchangeable can change both the histogram and the region, so their names and order belong in the measurement contract.

Resampling has the same issue. A pipeline that resamples externally should not silently resample again inside the extractor. Two interpolation operators are a different processing history from one, even when the final grid label looks the same. Conversely, a pipeline may deliberately let the extractor perform the resampling. Either design can be described; the dangerous design is leaving the choice implicit or doing both without intending to.

Aggregation is a semantic choice

Texture matrices can be constructed for several directions or distances. There are at least two plausible ways to reduce those matrices to one feature value: calculate the feature separately and average the resulting values, or combine the matrices first and calculate the feature once. For a nonlinear feature these are not generally identical operations:

feature(average_i(matrix_i)) is not generally identical to average_i(feature(matrix_i))

Neither order is made correct by the shared feature name. Weighting, symmetry, direction selection, distance selection, and dimensionality can all change the result. A report should therefore state the aggregation convention used by its implementation instead of assuming that a package’s default is a universal definition.

This is also the boundary between a standard and an implementation. IBSI provides reference definitions and values that allow an implementation to be checked, but an implementation can document deviations or additional conventions. The honest description is that a result follows a specified implementation whose definitions are aligned with, or compared against, the relevant standard. A blanket claim of compliance is not a substitute for stating the actual semantics.

What belongs in the stable book

The durable lesson is not a particular release, manifest size, hash, or tool leaderboard. Those details change and belong in a dated companion-Web case. The stable lesson is that a feature name is not a measurement until its mathematical definition and effective configuration are known. When comparing two tools, compare their complete operational definitions and, where possible, run them on the same reference images or phantom. Only then is a systematic difference a candidate implementation difference rather than evidence about tissue.

The region is one of those definitions. The next section treats it explicitly: the mask is not merely where the code happens to look, but a hypothesis about which tissue the measurement is meant to represent.

Sources

• Zwanenburg A, Vallières M, Abdalah MA, et al. The Image Biomarker Standardisation Initiative. Radiology. 2020;295(2):328-338. doi:10.1148/radiol.2020191145, PMID 32154773.
• PyRadiomics documentation — radiomic feature definitions and customizing the extraction.
• IBSI 2 — Whybra et al., Radiology. 2024. doi:10.1148/radiol.231319.