MainDicomTags mode: SpecificCharacterSet with multiple values results in error

General
1

Studies can have multiple values in SpecificCharacterSet and I saw that there was a recent improvement about this in version 1.12.2: orthanc: 6cb91df32207 NEWS . However, for the attached study, when trying to use MainDicomTags mode for the series metadata, Orthanc throws errors and responds with a 400 Bad Request to the series metadata request:

.../dicom-web/studies/1.2.276.0.7230010.3.1.2.2831156864.1.1707480190.795222/series/1.2.276.0.7230010.3.1.3.2831156864.1.1707480190.795223/metadata

E0209 12:58:52.695343 OrthancException.cpp:61] Bad request: Unknown encoding while creating DICOM from JSON: "ISO 2022 IR 100\\ISO 2022 IR 101"

E0209 12:58:52.696559 PluginsErrorDictionary.cpp:100] Exception inside the plugin engine: Bad request

The metadata endpoint works fine when SeriesMetadata is set to Full mode but produces the above error when SeriesMetadata is set to MainDicomTags mode.

We are using the default suggested ExtraMainDicomTags settings:

"ExtraMainDicomTags" : {
    "Instance" : [
      "Rows",
      "Columns",
      "ImageType",
      "SOPClassUID",
      "ContentDate",
      "ContentTime",
      "FrameOfReferenceUID",
      "PixelSpacing",
      "SpecificCharacterSet",
      "BitsAllocated",
      "BitsStored",

      "RescaleSlope",
      "RescaleIntercept",
      "SliceThickness",
      "WindowCenter",
      "WindowWidth",
      "PhotometricInterpretation",
      "PixelRepresentation"
    ],
    "Series" : [
      "TimezoneOffsetFromUTC",
      "PerformedProcedureStepStartDate",
      "PerformedProcedureStepStartTime",
      "RequestAttributesSequence"
    ],
    "Study": [
      "TimezoneOffsetFromUTC"
    ],
    "Patient": []
  }

This means we can’t use the OHIF viewer with MainDicomTags mode for these studies, can someone please investigate?
I’m more than happy to help and delve into the cpp codebase, but need guidance.

Study: 39b489e4-517b28a4-f40a6db0-4aa1e333-126a95dc.zip - Google Drive

2

Hi,

Before I investigate this issue… Are there any reasons not to use the “Full” mode again since we have optimized it ? It’s is supposed to be faster and more robust and a lot easier for us to maintain especially wrt “edge” files.

Best regards,

Alain.