How to read DICOM string value with backslash (VR=LO, Value="0.4323\0.2325")?

Our C++ software use ITK to write DICOM files. In it we have a Private Tag with LO (Long String) as VR and 2 decimal values as value like 0.3234\0.34223.

The LO choice is inherent to ITK.

In other java application, I use dcm4che3 to read/write them. Since it respects the DICOM protocol, backslash are forbidden, and dcm4che interpret the value as "0.3234" and never reach the second value.

All DICOM viewer applications I use can display this value.

So my question is: Is there a trick in dcm4che to read this complete value as a string "0.3234\0.34223" despite the presence of a backslash?

Below, the code I use:

     public DicomInfo uploadFile(MultipartFile file) throws IOException, ParseException {

       DicomInfo infos = new DicomInfo();

       Attributes attrs = readDicomAttributes(file);
       infos.setTags(toAttributesObject(attrs).toString());
    }

    private static JsonObject toAttributesObject(Attributes targetSeriesAttrs) 
    {
       StringWriter strWriter = new StringWriter();
       JsonGenerator gen = Json.createGenerator(strWriter);
       JSONWriter writer = new JSONWriter(gen);
       writer.write(targetSeriesAttrs);
       gen.flush();
       gen.close();
       return Json.createReader(new 
          StringReader(strWriter.toString())).readObject();
  }
  
  public Attributes readDicomAttributes(MultipartFile file) throws IOException 
  {
    DicomInputStream dis = new DicomInputStream(file.getInputStream());
    Attributes dataSet = dis.readDataset(-1, Tag.PixelData);
    Attributes fmi = dis.readFileMetaInformation();
    dis.close();

    fmi.addAll(dataSet);

    return fmi;
  }

In the JSON I get for this tag:

\"00110013\":{\"vr\":\"LO\",\"Value\":[\"0.4323\"]},

As you can see it is LO and the second part is already lost.

The method I use to get the specific attribute:

attr.getStrings(0x00110013)

send back a table with only one value, 0.4323.

The problem happens during the readDataSet function.

When I open tags with software like free dicom viewer, I have the complete data, so data is here.

Ok I found the source of the problem... It is the addAll fmi.addAll(dataSet);

In dataSet, getStrings works perfectly. In fmi after addAll, the attributes lost the second value.

So my problem is to solve this addAll issue now: https://stackoverflow.com/q/63269682/5704707

See answer from Paolo, and please believe us that the backslash is not a violation of the VR. Like he said, the attribute is 2-dimensional, i.e. it has two values of VR LO which are separated by the backslash.

I know a bit about the dcm4che project and the people behind it, and it is nearly unthinkable to me that it is generally incapable of handling this.

I strongly suspect that your problem is related to the fact that your attribute is private. That is, without any additional information to the tag and its value, dcm4che (and any other product) can never know that the attribute's value is encoded as VR LO (Long String).

The default transfer syntax in DICOM is Implicit Little Endian. This means, that the dataset does not convey an explicit information about the VR of the attributes in the dataset. This information is implicitly encoded by the Tag of the attribute, and the data dictionary (DICOM Part 6) must be used to look up the tag and obtain the corresponding VR. Obvioulsy this only works for well-known DICOM tags defined in the standard and fails for private ones.

So one option is to try encoding the dataset in Explicit Little Endian, which means that the VR is part of the attribute's encoding in the dataset. I would expect this to be sufficient.

Mature toolkits (like dcm4che) allow for extending the data dictionary by configuration, that is, you can extend the "official" data dictionary used by the tookit with your custom tag definitions - including the VR. So the tag can be looked up in the case that the VR is not explicitly given in the dataset itself.

Again, I am not an expert for dcm4che, but a quick search at google for "dcm4che private dictionary" yields this promising link.

I am more than confident that you can solve the problem in dcm4che and that you do not have to migrate to a different toolkit.

The solution of this problem is to write

dataSet.addAll(fmi);
return dataSet;

instead of

fmi.AddAll(dataSet);
return fmi;

since the addAll methods lost multiple values of private LO

LO can have multiple values separated by a backslash.

The DICOM standard says that in the VR "LO" the backslash cannot be used in values because it is used to separate the different elements.

In VRs that don't allow multiple elements then the backslash can be used in values.

So dcm4che is wrong here.