can not get MeasurementUnitsCodeSequence of DICOM SR

[ichimura.t]

I use DCMTK to convert DICOM SR to xml file.
I configure read flags enough to read DICOM SR, because I find many unrightful tags in DICOM SR.
If there is NumericValue that violated DICOM standard in DICOM SR, DCMTK does not read MeasurementUnitsCodeSequence.
For example, when NumericValue violates maximum VR length.

I found the appropriate source for this issue.

Code: Select all

#dcmsr - dsrnumvl.cc
OFCondition DSRNumericMeasurementValue::readItem(DcmItem &dataset)
{
    /* read NumericValue */
    OFCondition result = DSRTypes::getAndCheckStringValueFromDataset(dataset, DCM_NumericValue, NumericValue, "1", "1", "MeasuredValueSequence");
    if (result.good())
    {
        /* read some optional attributes */
        DSRTypes::getAndCheckElementFromDataset(dataset, FloatingPointValue, "1", "1C", "MeasuredValueSequence");
        if (DSRTypes::getAndCheckElementFromDataset(dataset, RationalNumeratorValue, "1", "1C", "MeasuredValueSequence").good())
            DSRTypes::getAndCheckElementFromDataset(dataset, RationalDenominatorValue, "1", "1" /* was 1C */, "MeasuredValueSequence");
        /* read MeasurementUnitsCodeSequence */
        result = MeasurementUnit.readSequence(dataset, DCM_MeasurementUnitsCodeSequence, "1" /*type*/);
    }
    return result;
}

If NumericValue is unrightful, result of "getAndCheckStringValueFromDataset" will be "bad".
Therefore, the subsequent process does not work.

Can you change this behavior, or is this right?

[J. Riesmeier]

Could you please send the SR file by email to "info/at/dcmtk/dot/org" for further analysis.

[J. Riesmeier]

Thank you for the sample file. I analysed the problem and as you said: The maximum VR length for the NumericValue element is violated (18 instead of 16 characters).

I'll see whether it makes sense to introduce another read flag (and command line option) that reads a content item completely and does not return to the caller as soon as the first error is detected. In your case, the NumericValue is incorrect, so the MeasurementUnitsCodeSequence (and others) is not read.

[J. Riesmeier]

The issue is fixed with the latest commit, i.e. now the --invalid-item-value (-Ev) option also covers the case of numeric measurement values exceeding the maximum length (of 16 bytes).