Page MenuHomePhabricator

DICOM plugin cannot parse DICOM directories in macOS installer
Open, HighPublic

Description

José Alonso wrote on mitk-users:

Hello MITKers!
I am trying to package and distribute a .dmg file of my application for some users who work on macOS. The project is building successfully, and the make package too.
We are finding a problem when using the DICOM reader. In the computer I built the package, this works perfectly, however when I take the .dmg file and give it to one of our users, the DICOM reader shows incorrect information and does not load any of the relevant files.
How to reproduce the error:

  • Open the DICOM reader.
  • Click Scan directory.

I have tried the super build both with the Debug and Release options with no luck. Is there anything else we should need to do?
I am sharing screenshots I took of both cases in the attached file for you to see what we mean.

Event Timeline

kislinsk triaged this task as High priority.Jul 4 2019, 8:55 AM
kislinsk created this task.
kislinsk updated the task description. (Show Details)Jul 4 2019, 12:23 PM
floca added a subscriber: floca.Jul 31 2019, 9:55 AM

It would be helpfull to see the log output in order to see if a different reader configuration was choosen and which. Please activate the log window and check the out put of the read process.

There should be outputs like this for each checked configuration. The reader always picks the configuration with the lowest number of blocks or the first that offers one block.

I tried using the Logging as @floca suggested, however I am not familiar with what I should be looking for (attached MitkWorkbench_.log file). I tried downloading the MITK Workbench binaries corresponding to v2018.04.2 and got the same error, attaching the screenshot.

floca added a comment.Jul 31 2019, 3:27 PM

@jsolislemus Thanks for the info. If I understood it correctly also the official installer shows this problem. Could you please do me a favor and check with the official installer if you have the same loading problem, if you do not use the DICOM browser, but instead the normal file open dialog or dragNdrop. With this information we can narrow it down a bit more.
Thanks.

Hello, sure. Please let me know if you need clarification, I am writing this with some haste, so I might not be as thorough or clear in my explanations.

(1) Using the Open File button -> Selected the (autoselect) -> NOT clicking on "apply the same to the remaining files" (file MitkWorkbench_MRIreadeAutoselect.log and looking as in the screenshot attached). The images were loaded individually, and not as a single dicom.

(2) Using the Open File button -> Selected the 3D reader -> NOT clicking on "apply the same to the remaining files" (got an error message, screenshot of error message attached)

floca added a comment.Aug 1 2019, 11:40 AM

Thanks.

(1) Using the Open File button -> Selected the (autoselect) -> NOT clicking on "apply the same to the remaining files" (file MitkWorkbench_MRIreadeAutoselect.log and looking as in the screenshot attached). The images were loaded individually, and not as a single dicom.

Regarding this workflow: I have another question. How many files did you select in the dialoge? One file of the stack as selection would be sufficient.

Only one file in the stack was chosen on both cases.

Thanks.
...
Regarding this workflow: I have another question. How many files did you select in the dialoge? One file of the stack as selection would be sufficient.

floca added a comment.EditedAug 2 2019, 4:40 PM

Hm, ok. Then the log output is somehow inconsistent, with what is loaded into the workbench.
@kislinsk How do one enforces the more detailed log? The logging console is capable to show more information then given in the attached log.

Two further questions:

  1. Does the (a) self generated installer package and (b) the MITKWorkbench work on the system you use to generate (a) or does the installer (one or both) work not?
  2. Could you please test if the MITKWorkbench installer for other systems show the same problems.

I am looking for indication if it is a problem more related to a specific system setup or the package setup.

Thanks.

Apologies for the delay in response..

Apologies, but I am not sure I understand your first questions, but given your last statement:

I am looking for indication if it is a problem more related to a specific system setup or the package setup.

The problem occurs (so far) when bringing a packaged version of the app (like the MITKWorkbench) from computer A, where the project was built, to computer B, where someone else wants to run the app. We have tested this on Ubuntu (18.04 and 16.04) and macOS (10.14).

That is, computer A is perfectly capable of running the packaged version. The problem comes only on computer B.

floca added a comment.Sep 6 2019, 9:26 PM

Apologies, but I am not sure I understand your first questions, but given your last statement:

No problem. A now fixed typo made it hard to understand.

As far as I have understood the Following is the case:

  • On computer B your own packaged version does not work (message from 8/29)
  • On computer B the downloaded binaries does not work (message from 7/31).

My question was, which of the versions (own, downloaded) work on computer A?

Hello,

On computer A our own built (and packaged) work well.

Hello,

I got some more feedback from one of our users which I think might be related to this problem.

Commonly,DICOM images of respiratory navigated MRI sequences are stored with images of the respiratory navigator within the same folder. These are commonly called “localisers”. These extra files seen to be a problem when importing the DICOM and need to be removed manually in order for the sequence to be recognised.

Basically, some MRI sequences have other files stored in the same folder. In MITK v2016.03 these extra files were being ignored, however in v2018.04.2 these files cause a problem to the DICOM reader. I wonder if it is all related.

Sorry for the long delay. Localisers should not be a problem per se. We also have such images in our protocols.

I must admit that only by "remote diagnistics" I am running out of ideas as we never had the problems (to my knowledge).

Would it be possible e.g. to give us a anonymized example data set? So that we can check and debug it. For what ever reason it seems that the systems read different values from the DCM tags or tread them differently and therefore load the data in other ways; e.g. splitting of a series in volumes.

Do the systems differ in there language/locale settings or something like this. This should be coverd by our code, but you never know.

floca edited projects, added MITK (2018-04-4); removed MITK.

We came to the conclusion that we need example data to reproduce this issue on our site. Can we arrange a transfer (see above)?