(0018,1405) Relative X-Ray Exposure Relative​X​Ray​Exposure IS 1

15 views
Skip to first unread message

Mathieu Malaterre

unread,
Feb 26, 2026, 4:02:48 AMFeb 26
to DICOM Forum
Dear X-ray gurus,

Could someone please clarify part06 for me:

(0018,1405) Relative X-Ray Exposure Relative​X​Ray​Exposure IS 1

Reading the explanation from gemini it feels it should be 'DS'.

Thanks for comments,

Noor Fatima Cheema

unread,
Feb 26, 2026, 6:25:26 AMFeb 26
to DICOM Forum

Hi Mathieu,

I'd be cautious about taking Gemini's word on DICOM VR assignments, LLMs tend to reason about what a VR should be conceptually rather than what the standard actually specifies.

(0018,1405) Relative X-Ray Exposure is defined as IS in Part 6, and that's intentional. The value represents a relative integer exposure index, essentially a unitless ratio scaled to integer precision. It's not a continuous physical measurement where you'd expect arbitrary decimal places, it's meant to express relative detector dose in discrete steps.

That said, you're touching on a broader pattern worth noting: there are a few attributes in the standard where the VR choice can feel counterintuitive, sometimes for historical reasons (backward compatibility with ACR-NEMA or early negotiation decisions in the committee), sometimes because the semantics were narrower than what the attribute name might suggest. The committee minutes from those eras can be... illuminating.

If you're building a parser or validator and trying to decide how strictly to enforce VR, that's where it gets interesting, especially when you encounter real-world data where vendors have occasionally treated IS fields with decimal values anyway. The conformance gap between the standard and the wild is a topic in itself.

Happy to go deeper on any of this if it's relevant to what you're working on.

Best, Noor

noorfatim...@gmail.com

Mathieu Malaterre

unread,
Feb 26, 2026, 8:11:41 AMFeb 26
to DICOM Forum
Hi Noor,

Thanks for the quick help here, this is very much appreciated as I not an expert in this field. I agree with your general comment about Gemini (and al.) but reading of the Supp 32 was also confusing (for me):

[...]2. This may be a calculated or measured value. Examples are the detector entrance dose (KB ), the CR sensitivity value (S), or the logarithmic median (lgM).[...]

I find the wording with "Index" much clearer IMHO in later supp(s).

In any case for my immediate issue :

```
% dcmdump /path/to/cr/instance | grep "Manu\|RelativeXRayExposure\|SOPClassUID  "
(0008,0016) UI =ComputedRadiographyImageStorage         #  26, 1 SOPClassUID
(0008,0070) LO [Imaging Dynamics Company Ltd.]          #  30, 1 Manufacturer
(0008,1090) LO [XPLORER]                                #   8, 1 ManufacturerModelName
(0018,1405) IS [0.529999971389771]                      #  18, 1 RelativeXRayExposure
```

I believe the correct JSON (Part 18 - §DICOM JSON Model) representation is simply:

[...]
  "00181405": {
    "vr": "IS",
    "Value": [
      "0.529999971389771"
    ]
  },
[...]

Since note (F.2.3 DICOM JSON Value Representation) states:

```
For IS, DS, SV and UV, a JSON String representation can be used to preserve the original format during transformation of the representation, or if needed to avoid losing precision of a decimal string.
```

I will now make sure that client side can handle without error the above (eg. cornerstone).

Regards

Le jeudi 26 février 2026 à 12:25:26 UTC+1, Noor Fatima Cheema a écrit :

Hi Mathieu,

I'd be cautious about taking Gemini's word on DICOM VR assignments, LLMs tend to reason about what a VR should be conceptually rather than what the standard actually specifies.

(0018,1405) Relative X-Ray Exposure is defined as IS in Part 6, and that's intentional. The value represents a relative integer exposure index, essentially a unitless ratio scaled to integer precision. It's not a continuous physical measurement where you'd expect arbitrary decimal places, it's meant to express relative detector dose in discrete steps.

That said, you're touching on a broader pattern worth noting: there are a few attributes in the standard where the VR choice can feel counterintuitive, sometimes for historical reasons (backward compatibility with ACR-NEMA or early negotiation decisions in the committee), sometimes because the semantics were narrower than what the attribute name might suggest. The committee minutes from those eras can be... illuminating.

If you're building a parser or validator and trying to decide how strictly to enforce VR, that's where it gets interesting, especially when you encounter real-world data where vendors have occasionally treated IS fields with decimal values anyway. The conformance gap between the standard and the wild is a topic in itself.

Happy to go deeper on any of this if it's relevant to what you're working on.

Best, Noor


Reply all
Reply to author
Forward
0 new messages