spaces in tags values and DcmItem::findAndGet[OF]String()

[rgarbacz]

I noticed that the methods DcmItem::findAndGetOFString() and DcmItem::findAndGetString() do not behave in the same way. The problem is when the tag's value contains spaces, the former method trims the value whilst the latter returns the value literally.

The problem was detected because of StudyID tag (0020,0010) with trailing spaces. The tag is defined as SHx1 - and SH is defined as a string which can contain spaces.

I would be very obliged for any help in this matter: which method should I use and what shell I do with the spaces - shell they make e.g. the StudyIDs different?

Thanks in advance.

[Marco Eichelberg]

Your observation is correct, and this is the intended behaviour. DcmElement::getString() returns the exact string of bytes without changing anything. If the attribute is multi-valued (contains backslash characters), the result string will contain the complete value including all backslash characters, non-significant space characters, etc.
DcmElement::getOFString(), on the other hand, provides a more intelligent API. You can access individual values of a multi-valued attribute, and leading and trailing space characters are removed by default for the VRs where these are explicitly defined as being non-significant. Note that there is an optional third parameter to this method that controls the normalization process.
In most cases you should preferrably use the getOFString method, exactly because of the pre-processing done. StudyIDs for example, may have non-significant leading and trailing whitespace characters, which means that your application must be able to treat "1234", "1234__" and "__1234" (where _ stands for the space character) as the same Study UID. Use getOFString and your code will do this automatically because in all cases you will only see "1234".

[rgarbacz]

Thank you for the answer, just one additional question to clarify the problem.

The StudyID has SH value representation and DICOM standard says for SH that the value can be padded with leading and/or trailing spaces - but there is nothing whether they are significant or not.
Does the lack of an explicit definition points to the non-significant leading/trailing spaces?
I am asking the question because e.g. for AE value representation this information (about the non-significant leading/trailing spaces) is explicitely written in the standard.

Thanks in advance.

[Marco Eichelberg]

One of the many places where the DICOM specification is ambiguous, but I think that it is absolutely safe to assume that leading and trailing space characters are non-significant.