Storage Failures

[kosherhog]

With the latest code, I'm experiencing a set of failures that seem to be caused by some build issues with dicom-dimse-native. I have a couple of them worked around (mostly to give you some indication of where I'm seeing problems) but I still haven't been able to pull up any images in the OHIF viewer. I'm running on Debian 12 (Bookworm), which is part of the python:3.11 docker image. This container is running on an M1 Mac, so everything builds on install to product ARM binaries. My installation is a source installation (per your instructions).

The two problems I've worked around so far are the missing dicom.dic file and the esdb directory. I worked around those errors by building the two components directly out of the dcmtk-3.6.8 source. I've copied the esdb folder. In the case of the former, I've added the environment variable to set DCMDICTPATH="/root/dcmtk-3.6.8/dcmdata/data/dicom.dic" before starting the server. I've also copied oficonv/data/esdb/* to /usr/local/share/dcmtk-3.6.8/esdb. This clears up a few errors when running the import and I've managed now to get as far as loading the list of studies in the viewer. I have yet to succeed in actually retrieving a study and displaying it, though. When opening the viewer to see a study, I'm getting a 'not available' error.

On oficonv, I did build and install libiconv but cmake doesn't seem to find it in /usr/local.

Some other errors that have popped up -

Failed to create table: patient
storeSCP: Database: storeRequest Failed (Success): 0000:0001 Illegal parameter
DcmSpecificCharacterSet: 'ISO 2022 IR 6' is not supported by the utilized character set conversion library 'Citrus iconv, Version FreeBSD 13.1 (modified)'

FWIW, everything worked fine as of commit c3972552b15f3368b05285912e43cc4cbce39238. That was likely prior to the move to dcmtk 3.6.8.

Happy to provide more information. Thanks for your help.

[knopkem]

I guess this is more an issue in dicom-dimse-native than here.
Anyway, regarding your problems. I did recently change the defaults on linux to include the dicom dictionary in the compiled binaries directly (this is the default on windows), so there should not be the need to set the env variable. Make sure to delete your cmake cache and use latest master, this should build and run without extra stuff. Anyway, will check this again on debian, but you can also open merge requests on that repo with your fixes.

Regarding the error that you printed. The "Failed to create table: patient" is worring as it means the sqlite somehow could not create the table. Not sure why this is, maybe permission issues to create the sqlite db?
The characterset error is probably the main difference between the previous dcmtk version and 3.6.8. Basically they added the oficonv module that should include enhanced character set support without the need for external libraries (iconv, icu).
I tried using the build in oficonv which did build but did not render characters correctly (not sure why), so for the release (prebuild libaries) I still used the external iconv libraries. Btw, indeed it is not simple for cmake to pick this up correctly in this project, so I added a special env variable to point to it, see https://github.com/knopkem/dicom-dimse-native/blob/master/CMakeLists.txt Ln 20. I also always build libiconv from source as including system packages did not work for me.

[knopkem]

I just tried on fedora 13 (amd64). Using the prebuild dicom-dimse-native library worked, then compiling from scratch (without iconv) also worked but did not render none-latin letters correct. (as written above). I did not have any issues with dicom.dic missing or the esdb folder as you wrote. Maybe it would behave different compiling on ARM but I don't have an M1.

[kosherhog]

I've incorporated the changes you made to dicom-dimse-native into my workarounds, but I'm still not quite there. I've managed to get past the libiconv - your fix partly helped along with adding /usr/local/lib to LD_LIBRARY_PATH. I still need to set DCMDICTPATH as well, but I haven't spent time working on that yet. I'm still seeing this error:

ERROR [29-02-2024 21:05:31:619]: Failed to create table: patient
ERROR [29-02-2024 21:05:31:619]: storeSCP: Database: storeRequest Failed (Success): 0000:0001 Illegal parameter

I'm certain it's not a permission error since I'm running as root in the container. I'm still working on this so I'll keep you posted with my results. I don't have any specific requests at the moment.