Output Format of dcmdump.exe

[dave]

When parsing the output of a file generated using dcmdump.exe, we are finding a difference of a single space between "value length" and "value mutiplicity". For example, a tag such as compensatorID (300a,00e5) from the file has a value length of 4 followed by a comma, then a space, then the value multiplicity, and looks like this in the file: 4, 1

All tag data in the file follow this format except for the CompensatorThicknessData (300a,00ec), which omits the space, so that value length and value multiplicity look like this: 10862,725

In other words, there is only the comma as a field separator for (300a,00ec) for these 2 fields. This obviously makes a difference in how we parse the file and grab the values.

Could someone please let us know if this is the intended behaviour, or whether it is unintended. Doesn't matter so much to us as long as it remains consistent.

Thanks,
dave

[Jörg Riesmeier]

The spaces are used for alignment purposes only. They are not significant, i.e. your parser should ignore them. Btw, the tool "dump2dcm" ignores anything after the "#" character.

[dave]

Jorg,

I understand your intent, i.e., that the spaces are for alignment purposes only. However, whether there is a space there or not is significant to us because we have used a 'space' as a field separator when parsing the output file from dcmdump.exe. What we've noticed is that there is an inconsistency between tag (300a,00ec), no space is present, and other tags, which add a space between the value length and value multiplicity data. And we need both of these values in our program.

We have made an inquiry to the vendor who created the file we have used as to whether something at their end can account for this difference, but we have not heard back as yet. However, it seems more likely that this is a feature of the dcmdump executable. If so, and it consistently does not create a space between VL and VM when dumping tag (300a,00ec) to ascii, then we can cope with this in the code on our end.

Again, it doesn't matter either way. We are just trying to determine if this is something that is random or systematic so that we can deal with it.

dave

[Jörg Riesmeier]

I hope the following code snippet (from "DcmObject::printInfoLineEnd()") answers your question:

Code: Select all

        /* print line end: length, VM and tag name */
        out << " # ";
        if (length == DCM_UndefinedLength)
            out << "u/l";   // means "undefined/length"
        else
            out << setw(3) << length;
        out << ","
            << setw(2) << vm << " "
            << tag->getTagName() << endl;

The difference between both tags in your example is the number of digits for value length and value multiplicity.

[dave]

Thanks, Jorg, that's very helpful.

dave