A Lossless Transfer Does Not Undo Earlier Lossy Ultrasound Compression

Consider a migration spot check: an ultrasound image arrives at the receiving archive in JPEG 2000 Lossless Only, yet its header records 01, ratio 30 and method ISO_10918_1. A colleague reports that older studies look softer after the move. The useful first question is what changed along the route, before a service team orders a probe or board.

This guide separates three decisions: what the metadata records; what evidence can locate a change; and who decides whether further compression or clinical use is acceptable. DICOM supplies the encoding and history rules. The facility supplies the authorized workflow and clinical assessment. Rongtao’s role is a qualified hardware-service enquiry when the evidence supports that route.

What do the three compression-history attributes record?

The General Image Module in DICOM PS3.3 contains the compression-history attributes. Read them together for each SOP Instance—an individual DICOM object. A study can contain multiple instances with different histories; one selected image cannot establish the state of every image or clip in the examination. ¹

In the General Image Module these three compression attributes are Type 3, meaning optional. The standard explains that the flag’s optional status preserves compatibility with older Information Object Definitions (IODs), and anticipates stronger requirements in new or substantially revised image IODs. Check the actual SOP Class and applicable IOD before judging conformance; the module table is not a universal requirement for every DICOM object. Missing ratio or method values do not disprove the recorded lossy history. ¹

Method terms also need edition context. The 2015c section lists JPEG, JPEG-LS near-lossless, JPEG 2000 irreversible, MPEG-2 and MPEG-4 AVC/H.264. The current online 2026d section additionally lists High-Throughput JPEG 2000 irreversible (ISO_15444_15), JPEG XL (ISO_18181_1) and HEVC/H.265 (ISO_23008_2). A codec family is not a reliable date stamp: ISO_10918_1 identifies JPEG lossy compression, not necessarily an old scanner or an obsolete export. ^{1 9}

Why does the flag survive decompression?

Lossy compression changes pixel information. Decoding the resulting image reconstructs the pixel values represented by that compressed stream; it does not restore the source information that was discarded. Encoding those reconstructed pixels losslessly can preserve them without an additional lossy encoding step, while leaving the earlier loss intact. ^{1 2}

PS3.3 C.7.6.1.1.5 explicitly describes an image that is decompressed and transferred uncompressed retaining 01. The flag is therefore a history statement, not a description of whether the current file is compressed. It is also ordinary metadata, not a tamper-proof audit log: the requirement to preserve it is not evidence that every implementation has done so. ¹

For a multi-frame instance, one or more frames having undergone lossy compression requires the instance flag to be 01. That does not tell you which frames were affected or that every frame had the same treatment. The standard recommends identifying affected frames in Derivation Description. Frame timing is a separate question covered in our ultrasound cine frame-timing guide. ¹

What does the transfer syntax establish?

A transfer syntax describes how the data is encoded. In a DICOM file, record the Transfer Syntax UID in File Meta Information, (0002,0010). For a network transfer, the negotiated presentation context identifies the transfer syntax; the file-meta tag is not a substitute for an association record. A retrieved file can have a different encoding from the object held inside an archive.

PS3.5 8.2.4 also describes updating pixel-related elements when JPEG 2000 data is decompressed and re-encoded in native form. For example, converting a YBR color representation to RGB changes Photometric Interpretation accordingly. Do not confuse legitimate encoding-related metadata changes with permission to remove history. Conversely, do not treat the word “lossless” as proof that no other processing, color conversion or resizing occurred along the route. ²

If the receiving system rejects an encoding rather than displaying a changed image, use the separate DICOM export and network/I/O evidence guide. This page concerns the history of images that have reached a receiver.

When should Image Type and the instance UID change?

PS3.3 C.7.6.1.1.5 distinguishes an image originally obtained in lossy form from a sensor from a lossy version made from another image. In the first case, Image Type Value 1 is ORIGINAL with flag 01. In the second, it is DERIVED; if the predecessor was a DICOM image, the resulting image receives a new SOP Instance UID. ORIGINAL therefore does not mean never compressed. ¹

Record both identities when investigating a lossy export. The source and derived instances may legitimately have different UIDs, so matching only on SOP Instance UID can miss the relationship. Obtain the export or migration record that links them. A UID change is consistent with derivation, but cannot establish the kind of processing or its authorization without that context. Do not alter UIDs or history fields to make a comparison look consistent.

Derivation alone also does not establish that ultrasound measurements remain usable. If exported calipers disagree, follow the separate region-calibration evidence check; this guide does not validate spatial calibration.

Follow one instance through a synthetic lifecycle

The following example assumes an initially uncompressed DICOM image and a documented JPEG export. A and B are symbolic identity labels, not executable UIDs. The ratio is invented for illustration, not a recommended setting. Retained identity in later rows assumes only re-encoding without another substantive transformation.

The final header supports prior lossy JPEG history in this example. It does not independently prove that Stage 2 caused it: that attribution comes from the stipulated export record. In a real investigation, an earlier acquisition path or another gateway might explain the same final trio. If the earlier copy or route log is unavailable, record that uncertainty. For archive responsibility and retention decisions, use the separate storage-commitment guide.

Does recorded history authorize another lossy step?

No. PS3.3 describes multi-valued ratio and method fields for successive lossy steps. Those provisions accommodate recording repeated compression; they are not a clinical approval for an archive to apply it. The reviewed PS3.3 history section and PS3.5 encoding sections do not establish a blanket prohibition on a second step. Equally, their support for recording one does not authorize a facility workflow. ^{1 2 3}

For example, a synthetic sequence could record (0028,2112) = 15\10 with (0028,2114) = ISO_10918_1\ISO_15444_1. These paired entries describe two successive lossy steps. Do not turn them into a clinical quality score or multiply them into a claimed fraction of diagnostic information lost. They may be nominal estimates, and the header does not establish comparable measurement methods. ¹

What does a ratio of 30 tell the receiving team?

A recorded 30 means approximately 30:1, not 30 percent and not 30 bytes. PS3.3 permits a nominal compressor setting or a measured size ratio. That distinction matters when comparing vendors: ask how each value was produced and whether it describes the same image representation. A whole-study folder size includes other objects and overhead and is not a reliable substitute for the recorded pixel-compression ratio. ¹

If ratio or method is missing, retain “not recorded” in the case record. Do not backfill a plausible value from the current lossless file’s size. An absent companion value may be consistent with optional metadata, but it leaves the earlier operation less well documented. A recorded 00 is a claim of no lossy history; absence is no such claim. Contradictory header and route evidence needs investigation, not an automatic clean bill of health.

How should a soft-image complaint be investigated?

Treat softness, blocking or a changed texture as observations. They do not uniquely identify a codec, a probe defect or a board fault. A source-versus-receiver comparison can narrow the investigation; it cannot replace qualified performance testing or a clinical review of image suitability. Two different studies from the same room are a weaker comparison because acquisition and display conditions may differ.

Use authorized, read-only inspection and preserve the original objects and logs. Ask the PACS team for a corresponding source/receiver pair, the transformation record and the actual encoding at each observed endpoint. Record whether the comparison is a screen observation or a controlled comparison of decoded pixel data, including the tool and any decoding or color-conversion differences. A visually crisp console image does not prove the hardware is healthy; a local review image is not automatically an uncompressed acquisition reference.

Stop changes to originals, history tags or retention settings while an unexplained discrepancy is being assessed. Clinical concerns go to the responsible clinical team. For the hardware differential, our probe-versus-scanner evidence guide is a separate next step; this article does not identify a failed component or authorize clinical return to service.

What do the cited ultrasound conformance statements show?

These are scoped document examples, not a comparison of current product capabilities or a prevalence survey. Match the actual model, software release, SOP Class and workflow to its applicable conformance statement. ALWAYS describes the document’s presence convention; ANAP means present as applicable. Neither label proves what a particular received file contains.

The GE paragraph illustrates why a receiver must inspect history even when negotiation results in a lossless encoding. Its printed tag discrepancy should remain visible in a source review rather than silently being quoted as the correct tag. Check field meanings against the normative standard and ask the vendor about ambiguous implementation details; this example is not authority to rewrite a patient object. ^{1 6}

Who decides whether compression is acceptable?

PS3.5 8.2.4 expressly leaves clinical acceptability and selection of JPEG 2000 lossy-compression parameters outside DICOM’s scope. A syntactically valid object is not evidence that a compression setting was approved for its clinical task. Do not recommend patient re-acquisition, accept a study for diagnosis, or enable further lossy processing solely because a history field is present. ²

Section III.B of the ACR–AAPM–SIIM Technical Standard for Electronic Practice of Medical Imaging places diagnostically acceptable irreversible compression under a qualified physician’s direction. It gives no general compression type or amount for every modality, disease or task, and calls for the responsible physician to select and periodically review the compression used. It also warns about degradation when decompression is followed by a different irreversible scheme during migration. This professional caution is material counter-evidence to treating successive-step metadata as permission. ⁷

The ACR document’s preamble describes educational guidance rather than an inflexible legal standard. The facility must apply its clinical governance, technical QA and applicable requirements. This article provides no ratio recommendation, universal acceptance threshold or jurisdiction-specific compliance conclusion. ⁷

What should the handoff record contain?

1. Equipment and route: OEM, scanner model, system software, probe model if relevant, source and receiving applications, versions where known, and the export/retrieval route. Distinguish observations from inferred intermediate steps.
2. Instance-level metadata: SOP Class, Study/Series/SOP Instance identifiers, observed transfer syntax, Image Type, flag, every ratio and method value, and available Derivation Description. Keep identifiers in the facility’s approved case record.
3. Reference comparison: Identify the corresponding source and receiving instances, how they were linked after derivation, the exact frame for a clip, comparison method and display conditions. State if the source copy is unavailable.
4. Change evidence: Approved export/migration settings and logs that identify a transformation. Preserve original records; do not edit metadata or re-compress the only copy for this investigation.
5. Disposition and owner: Archive investigation, qualified service assessment, clinical QA or unresolved. Record the next check and the person responsible rather than converting an uncertain cause into a part order.

DICOM headers and burned-in image text can identify patients. Keep patient files within approved systems and use only an agreed, secure transfer process when an authorized specialist needs them. Do not upload studies or identifying screenshots into a routine quote form. For initial enquiries, send the non-patient equipment and symptom summary; arrange any necessary image exchange separately.

Where Rongtao fits—and where it does not

Rongtao supplies component-level ultrasound board repair, probe repair and tested replacement-parts services. Archive configuration, migration integration and clinical compression policy belong with the facility’s PACS, integration and clinical teams. The history check helps prepare an appropriate service enquiry; it does not establish that an item is repairable or that a component has failed. ⁸

The published 48-hour real-machine testing commitment applies to repaired boards. Typical board-repair turnaround is 5–8 business days, and the standard warranty is typically 90 days; final timing, test scope and warranty depend on the item and service quotation. Do not extend the board commitment to every transducer, every model configuration or a facility’s complete return-to-service acceptance. ⁸

For a qualified hardware enquiry, contact Rongtao Medical with the OEM, system model/software, probe model or manufacturer part number, clear equipment-label photos and already-available board photos, symptoms/error messages, quantity and destination. Include a non-patient summary of the history values, route and reference comparison. Obtain any additional internal photos through qualified personnel; a quote request is not an instruction to open equipment.

Limits and when to recheck

This is a document-sourced investigation aid. No scanner, image set, migration log or clinical outcome was tested. The lifecycle is synthetic; the OEM rows cover only the named documents. Missing or inaccurate metadata can limit every inference. The guide estimates no frequency of compression-related complaints and offers no proof that a particular service or migration will resolve one.

Recheck the cited DICOM sections when their edition changes, the OEM document when the installed release changes, and facility policy before any proposed compression change. The useful result is a documented next check with a responsible owner.

Frequently asked questions

The syntax is lossless. Is the study now lossless?
It is currently losslessly encoded with respect to the encoder’s input, if the syntax and implementation are correct. That does not undo an earlier lossy step. Inspect history per instance rather than labeling the whole examination from one file. ^{1 2}

The flag says 01, but ratio and method are missing. What does that mean?
The header records prior lossy compression without those details. Check the applicable IOD and conformance statement, then preserve the missing values as unknown. It is not enough to locate a transformation or assess clinical quality. ¹

DERIVED and a new UID appeared after export. Is that suspicious?
Those changes are expected for lossy derivation from a predecessor DICOM image. Verify them against the authorized transformation and identity mapping. The changes alone establish neither wrongdoing nor that every change was appropriate. ¹

How do we inspect the attributes?
Use the approved viewer’s metadata inspector or a qualified DICOM support tool on a protected copy. Record the displayed values and what source was inspected; do not assume a normal image viewport exposes all history fields or that its display label establishes the negotiated network syntax.

The console image looks clear. Can we close the hardware ticket?
That is one observation, not a hardware acceptance test. Compare corresponding images, review the actual processing route and involve clinical engineering if the fault persists or remains unexplained. Archive/display and hardware problems can coexist.

Does DICOM permit us to compress the image again?
Its history attributes accommodate successive steps. That is a data-model capability, not facility authorization or a clinical recommendation. Obtain the responsible clinical and archive owners’ decision before changing the workflow. ^{1 2 7}