ALEVA

Ultrasound Engineering

Ultrasound RF Replay: Validate the Importer Before Comparing Beamformers

How can an OEM team establish that two reconstruction pipelines interpret an imported RF acquisition consistently before attributing an image difference to the beamforming algorithm?

By ALEVA | Orange County, California, USA

Engineering question: How can an OEM team establish that two reconstruction pipelines interpret an imported RF acquisition consistently before attributing an image difference to the beamforming algorithm?

A raw-data file can load successfully while being interpreted incorrectly. File readability is therefore only the first acceptance condition. The importer must preserve the meaning of each axis, the sampling time reference and the acquisition configuration.

A concrete format difference illustrates the problem. The peer-reviewed GE 11L-D dataset article published in Data in Brief on September 15, 2026 describes arrays ordered by transmit angle, receive element and temporal sample. Its accompanying settings include sampling-time vectors, steering angles and probe parameters. The pyuff_ustb 2.0.0 ChannelData interface instead presents time, channel, wave and frame dimensions, with explicit sampling frequency and initial sample time. These are documented conventions, not interchangeable axis labels. [1] [2]

Open-H-RF also treats acquisition, probe and reconstruction information as part of a self-contained channel-data representation. Its October 16, 2026 version is a preprint; it supports discussion of data organization, not a claim of validated performance in an ALEVA product. [3]

Define an explicit conversion contract. Record the source format and version, destination axis order, units, numeric representation, time-origin convention and transmit-event interpretation. Preserve the original metadata alongside the normalized representation. For an RF-only importer, reject complex baseband input unless a separately specified IQ conversion path is selected. Missing timing information should produce a visible failure rather than an undocumented default.

Test the conversion before reconstruction. As a proposed software acceptance method, create a small synthetic array whose values encode their sample, channel and event indices. Check selected coordinates after conversion against an independently written mapping. Use unequal axis lengths to expose accidental transposition, then include equal-length axes so that dimension checks alone cannot pass an incorrect conversion. This fixture tests file interpretation; it is not an acoustic simulation or measured hardware result.

For a uniformly sampled fixture, verify the sample-time relationship t[n] = t0 + n/fs, with zero-based n, t0 in seconds and fs in hertz. Deliberately provide a fixture with incompatible declared units or an omitted time origin and verify the specified error path. A checksum can establish that the file bytes stayed unchanged; it cannot establish that a reader interpreted their units correctly.

Separate importer changes from algorithm changes. First compare the old and new importers using the same reconstruction implementation and settings. Only after that comparison passes should the team compare beamformers using the same normalized input. Retain intermediate arrays and define numerical tolerances before inspecting the final display.

Normalizing data at import simplifies downstream interfaces but may add conversion time, storage or memory copies. Retaining native layouts can reduce that overhead while increasing the number of format-specific paths to verify. Measure the trade-off in the intended workflow.

For an OEM/ODM handover, request the conversion specification, deterministic fixtures, failure cases and versioned reference outputs. Passing those checks establishes importer conformance within the tested cases. It does not establish probe performance, live acquisition integrity or clinical suitability. This is a proposed engineering workflow, not a report of ALEVA hardware measurements.

References: [1] Viñals and Thiran, Data in Brief, 2026, DOI: 10.1016/j.dib.2026.113259; peer-reviewed data article. [2] pyuff_ustb 2.0.0 ChannelData source documentation; undated documentation, accessed November 6, 2026. [3] Stevens et al., Open-H-RF, arXiv:2610.13616v2, October 16, 2026; preprint, DOI: 10.48550/arXiv.2610.13616.