Bug 126 - Orthanc and DCMDICTPATH
Summary: Orthanc and DCMDICTPATH
Status: RESOLVED FIXED
Alias: None
Product: Orthanc
Classification: Unclassified
Component: Orthanc Core (show other bugs)
Version: unspecified
Hardware: All All
: --- normal
Assignee: Sébastien Jodogne
URL:
Depends on:
Blocks:
 
Reported: 2020-06-29 15:15 CEST by Sébastien Jodogne
Modified: 2020-06-29 15:25 CEST (History)
0 users

See Also:


Attachments
Screenshot from 2019-01-24 15-33-58.png (502.98 KB, image/png)
2020-06-29 15:17 CEST, Sébastien Jodogne
Details
Screenshot from 2019-01-22 14-00-57.png (318.99 KB, image/png)
2020-06-29 15:17 CEST, Sébastien Jodogne
Details
FixDcmDictPathUse-from-1.5.2.diff (3.35 KB, text/x-diff)
2020-06-29 15:17 CEST, Sébastien Jodogne
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sébastien Jodogne 2020-06-29 15:15:05 CEST
[BitBucket user: Luiz Eduardo Valmont]
[BitBucket date: 2019-01-20.14:27:37]

This affects at least 1.3.2.

I've noticed something odd. When I run Orthanc without specifying the DCMDICTPATH environment variable, I get this:

2019-01-18T23:53:15.024560 INFO [7f65477f6700] PluginsManager.cpp:172 Tagging image with the following command: /usr/bin/dcmodify -i "(0069,0020)=RDSL" -i "(0069,2001)=131" /var/orthanc/tmp/d5dc-b3ee-1f98-4372
E: DcmDataDictionary: Cannot open file: /usr/share/libdcmtk12
W: no data dictionary loaded, check environment variable: DCMDICTPATH
W: DcmItem: Length of element (7fe0,0010) is not a multiple of 2 (VR=OW)

But when I do specify it, I get this:

2019-01-18T23:23:12.804872 INFO [7fccab845e40] FromDcmtkBridge.cpp:206 Using DCTMK version: 362
2019-01-18T23:23:12.856255 WARNING [7fccab845e40] FromDcmtkBridge.cpp:164 Loading the external DICOM dictionary "/usr/share/libdcmtk12/diconde.dic:/usr/share/libdcmtk12/acrnema.dic:/usr/share/libdcmtk12/private.dic:/usr/share/libdcmtk12/dicom.dic/dicom.dic"
E: DcmDataDictionary: Cannot open file: /usr/share/libdcmtk12/diconde.dic:/usr/share/libdcmtk12/acrnema.dic:/usr/share/libdcmtk12/private.dic:/usr/share/libdcmtk12/dicom.dic/dicom.dic
2019-01-18T23:23:12.857114 ERROR [7fccab845e40] main.cpp:1324 Uncaught exception, stopping now: [Internal error] (code -1)
2019-01-18T23:23:12.857236 WARNING [7fccab845e40] main.cpp:1357 Orthanc has stopped

The second time around, as it seems, Orthanc tries to append a "/dicom" to the value of DCMDICTPATH treating it as purely a directory only to abort right after that. But DCMTK itself will try to conform to its specification (ref: https://support.dcmtk.org/docs/file_envvars.html).

Upon close inspection of the FromDdcmtkBridge.cpp, I found this:


```
#!python

      const char* env = std::getenv(DCM_DICT_ENVIRONMENT_VARIABLE);
      if (env != NULL)
      {
        path = std::string(env);
      }

      LoadExternalDictionary(*locker, path, "dicom.dic");

      if (loadPrivateDictionary)
      {
        LoadExternalDictionary(*locker, path, "private.dic");
      }
      else
      {
        LOG(INFO) << "The dictionary of private tags has not been loaded";
      }

```

And from Resources/WebAssembly/dcdict.h:


```
#!python

/// environment variable pointing to the data dictionary file
#define DCM_DICT_ENVIRONMENT_VARIABLE   "DCMDICTPATH"
```


Oddly enough, it started after I switched to compiling Orthanc with USE_SYSTEM_DCMTK=ON.
Comment 1 Sébastien Jodogne 2020-06-29 15:17:46 CEST
Created attachment 54 [details]
Screenshot from 2019-01-24 15-33-58.png
Comment 2 Sébastien Jodogne 2020-06-29 15:17:47 CEST
Created attachment 55 [details]
Screenshot from 2019-01-22 14-00-57.png
Comment 3 Sébastien Jodogne 2020-06-29 15:17:47 CEST
Created attachment 56 [details]
FixDcmDictPathUse-from-1.5.2.diff
Comment 4 Sébastien Jodogne 2020-06-29 15:24:03 CEST
[BitBucket user: Luiz Eduardo Valmont]
[BitBucket date: 2019-01-22.16:13:17]
Comment 5 Sébastien Jodogne 2020-06-29 15:24:03 CEST
[BitBucket user: Luiz Eduardo Valmont]
[BitBucket date: 2019-01-22.16:13:25]

Hi, Sébastien!

Because we're dealing with private tagging, I've taken the liberty to try and fix the use of DCMDICTPATH myself. I've attached the patch (output of "hg diff Core/DicomParsing/FromDcmtkBridge.cpp") and a screenshot showing the revised 1.5.2.

What has been done was this. If the environment variable is defined when Orthanc is booting, it splits its content considering the colons; it then treats the tokens as file names. If on the other hand the variable has not been defined, DCMTK_DICTIONARY_DIR is used as a directory path and its contents are listed, using the same function as in the other case after the split.

There was a warning when private dictionary is not to be loaded and I've kept it if the procedure finds a file named "private.dic" but it's not to be loaded.

One final note: because I'm not too familiar with Google Test, I've written no tests for this fix. I shall start studying it in the coming days.

HTH
Comment 6 Sébastien Jodogne 2020-06-29 15:24:20 CEST
[BitBucket user: Luiz Eduardo Valmont]
[BitBucket date: 2019-01-24.17:37:21]

Quick update. It seems the diconde.dic dictionary found in Buster's libdcmtk14 causes some issue with the DcmtkBridge. Can't tell much right now other than its presence in the DCMDICTPATH environment variable makes a simple query/retrieve from within the standard explorer fail.

Log says it can't find PatientBirthDate, which is defined in the dicom.dic dictionary. That makes it all the more weird. I'm attaching a screenshot that makes things a little clearer.
Comment 7 Sébastien Jodogne 2020-06-29 15:24:21 CEST
[BitBucket user: Luiz Eduardo Valmont]
[BitBucket date: 2019-01-24.17:37:48]
Comment 8 Sébastien Jodogne 2020-06-29 15:25:06 CEST
[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2019-02-24.08:30:19]

Fix issue #126 (Orthanc and DCMDICTPATH)

→ https://hg.orthanc-server.com/orthanc/changeset/8ed445e94486