Container exists immediately after running

[ptahery]

Hi,

Thank you so much for your package. I have a problem with docker container for qiicr/dcmqi. After running it exits immediately with exited (139). I tried all the below commands but they don't work.

docker run qiicr/dcmqi docker run -dit --name my_dcmqi qiicr/dcmqi docker run -dit qiicr/dcmqi docker run -it -d qiicr/dcmqi:latest docker run -t -d qiicr/dcmqi:latest docker run -it qiicr/dcmqi:latest docker run -i qiicr/dcmqi docker run -it qiicr/dcmqi

I would be grateful if you help me. Best.

[fedorov]

Perhaps this is because of how the entrypoint for the container is defined: https://github.com/QIICR/dcmqi/blob/master/docker/dcmqi/imagefiles/docker_entry.sh.

The easiest might be to make a new docker image from qiicr/dcmqi. docker run -it works as expected for me for a container definition below:

FROM qiicr/dcmqi
MAINTAINER test

ENTRYPOINT /bin/bash

[Georift]

I'm experiencing the same problem on Debian 11. I tried your solution @fedorov and the container still exits with 139.

[fedorov]

I confirm it currently works for me on mac as below. I have not yet tested on other platforms.

$ docker run qiicr/dcmqi segimage2itkimage --help
dcmqi repository URL: git@github.com:QIICR/dcmqi.git revision: 3802ee3 tag: latest-2-g3802ee3

USAGE:

   segimage2itkimage  [--returnparameterfile <std::string>]
                      [--processinformationaddress <std::string>] [--xml]
                      [--echo] [--verbose] [-t <nrrd|mhd|mha|nii|nifti|hdr
                      |img>] [-p <std::string>] [--outputDirectory
                      <std::string>] [--inputDICOM <std::string>] [--]
                      [--version] [-h]
...

[Georift]

Yeah it's a strange one, I haven't had time to debug more but I just tired your output:

➜  docker run qiicr/dcmqi segimage2itkimage --help
➜  echo $?
139
➜  docker images qiicr/dcmqi:latest
REPOSITORY    TAG       IMAGE ID       CREATED        SIZE
qiicr/dcmqi   latest    cbbc3a373e9a   2 months ago   344MB

I'll likely check this out in the coming week. Just quickly how does this project compare to the Slicer extension? I feel like I get the impression that may be more supported than the cli?

[fedorov]

The Slicer extension is a wrapper around dcmqi CLIs. I have not been able to find much time to invest into dcmqi. I feel like dcmqi serves a certain need in its current state, implementation of drastically new features is complex due to dependency on DCMTK for lower-level functionality, which is not easy to extend.

Regarding this specific issue you are facing, I would definitely appreciate any help, since my experience with docker is rather basic.

Right now the main feature I want to make the time to implement is

1. update to modern ITK and fix the testing components that will break due to that shift (I also realized just today that there are many failing tests on Slicer dashboard, since dcmqi in Slicer is built against the current ITK, not 3.12 that is used in the standalone tool here) #444
2. writing of non-overlapping segments into a single ITK file (currently, segments are saved into separate files, which has huge performance implications for SEG objects with many segments) #462

I am sorry for such a delay in responding to your question.

[Georift]

@fedorov No worries on the time to reply! no pressure here.

I'm currently using the slicer extension to prove a process I'm working on, soon I'll likely come back to this project and the container image to better automate the process.

I'm fairly comfortable with Docker but I've never encountered it crashing immediately, so it'll be an interesting debug.

Do you think the old ITK build difference between the container and slicer could have any influence in this issue?

I'll keep you posted when I get a chance, and if I find anything interesting.