Interpreting string-based values?

[pauldotknopf]

I have a question about some concerns I have about pre-interpreting data of certain VR types.

For example, the VR::IS is being interpreted as an [i32] internally.

Because of this, if we were to load a dicom file, and save it without making any modifications, the saved file would be normalized, in that the VR::IS would be converted into an array of integers, and then back to a string.

This would also pose a problem with implementing validation checkers. I'd like to develop a command line tool that loads a DICOM file, and validates it's contents. I can't validate any field at all if any one field prevents me from loading the entire DICOM file.

IMO, it is important to keep values that are represented with the Default Character Repertoire as characters. We could provide utilities to re-interpret the values into their typed representation (date times, date ranges, integer strings, etc) after the DICOM file is loaded.

[pauldotknopf]

A snippet from dcmtk:

static OFBool isaStringVR(DcmVR& vr)
{
    OFBool isaString = OFFalse;
    switch(vr.getEVR())
    {
    case EVR_AE:
    case EVR_AS:
    case EVR_CS:
    case EVR_DA:
    case EVR_DS:
    case EVR_DT:
    case EVR_IS:
    case EVR_LO:
    case EVR_LT:
    case EVR_PN:
    case EVR_SH:
    case EVR_ST:
    case EVR_TM:
    case EVR_UI:
    case EVR_UT:
        isaString = OFTrue;
        break;
    default:
        isaString = OFFalse;
        break;
    }
    return isaString;
}

[Enet4]

If I understand correctly, it is a planned feature to support loading a file without parsing textual values right away. There's already some code for this string-preserving parsing mechanism, although it might not be accessible at the object API, and this might also require a bit of extra code at the element struct to only parse these values on demand. At some point this should be possible indeed.