Skip to content
Imaging Evidence Path

Structured result vs screenshot

Tonight · ~15 min · read · energy: low · setup: none

This short lesson is the sharpest distinction in the chapter: a structured AI result (DICOM SEG/SR) is a first-class data object; a screenshot or PDF is a display artefact. Clinical AI value comes from the former. Get this one distinction right and you understand why “the AI made a picture” is not “the AI produced a result”.

The anchor: queryable, computable, linkable — or none of those

A PNG screenshot or a PDF report is a picture of a result. It is not queryable (you cannot search PACS for “all tumours > 30 ml”), not computable (you cannot re-measure or aggregate across patients), and not linkable to the source voxels (the picture does not say which voxels were tumour). A structured DICOM object is all three.

The two structured objects

  • DICOM SEG (Segmentation Storage) — a structured segmentation that references its source series/SOPs and carries geometry (Ch. 2). Machine-readable, queryable.
  • DICOM SR (Structured Report) — a tree of coded findings/measurements (name-value pairs with coded concepts), referencing source images. Machine- readable; this is how a discrete “long-axis diameter = 23 mm of lesion X” should be returned.
  • Measurements / provenance — SR can encode measurements with source-image references; some systems also use specific Measurement/Parametric Map IODs. Provenance (what model/version/inputs produced a result, when) must be captured or the result is unauditable.

What a screenshot loses

A PNG/PDF is a picture of a result — not queryable, not computable, not linkable to the source voxels, not aggregatable across patients. Structured DICOM (SEG, SR) is a first-class data object; screenshots are display artefacts. Clinical AI value comes from the former, not the latter.

The downstream consequences are concrete. From a screenshot you cannot: recompute a radiomic feature, audit a boundary voxel, aggregate tumour volumes across a cohort, feed the result into a downstream model, or verify which series the measurement came from. From a SEG/SR you can do all of these, because the object is the data, with its references and geometry intact. This is why TRACE-CT decodes SEG objects (decode_seg_file()) rather than consuming screenshots, and why the QC-bundle schema records the source references and hashes.

Why this matters for AI integration

When an AI service returns its output (lesson 5), the object type it produces determines whether the result can ever do anything beyond being looked at once. A deployment that stores screenshots has built a dead end; a deployment that stores SEG/SR has built a substrate for measurement, audit, and research. The choice is made at the return step, and it is hard to reverse later (you cannot reconstruct a SEG from a screenshot).

Stop and think — then reveal

A research collaboration asks your AI service for “the segmentation results” and you send them a folder of PNGs. They ask for per-lesion volumes and the source series UIDs. Why can you not just compute those from what you sent?

Because the PNGs carry none of that information: they have no voxel labels (so no volume can be recomputed), no geometry (so no physical measurement), and no source references (so no series UID). The structured information existed when the model produced the SEG, but you discarded it by exporting a picture. To satisfy the request you must return the SEG objects (or the mask arrays plus their reference geometry and source UIDs). The lesson: choose the return object for the downstream use, not for the prettiest visual.

What to retain

  1. Structured DICOM (SEG/SR) is a first-class, queryable, computable, linkable data object; a screenshot/PDF is a display artefact.
  2. SEG carries source references + geometry; SR carries coded findings/measurements; capture provenance (model/version/inputs/time) or the result is unauditable.
  3. From a screenshot you cannot recompute, aggregate, audit, or link — choose the return object for downstream use, not for appearance.
  4. The object type is decided at the return step and is hard to reverse later.

Next: the standards-level recipes that wire all of this together — IHE profiles as workflow recipes.