Page MenuHomePhabricator

Dicom import issue with MITK binaries (package) and Ubuntu
Closed, ResolvedPublic

Description

Issue:
MITK loads each slice as seperate object in the data-manager (instead of a single 3D volume).
I thought the dcm files are corrupt (missing slices etc.) - but they aren't!

How to reproduce:

OS: Ubuntu 20.04 and 18.04
MITK-version: 2018.04.2 , MITK-nightly build from Jenkins (12.08.20) or current MITK-diffusion binaries from Github

Just load the example image into MITK (DICOM Reader v2 (auto select)).

Example data:

This only occurs when binaries are used.
If I build the current MITK-master everything works fine.

Event Timeline

schererj created this task.

Checked on windows (develop branch 10.8.; binaries and build tree): DICOM Reader v2 (auto select) works correctly. Have to look into it on Ubuntu.

floca added a subscriber: gaoh.

I have checked it with the current develop head under linux (Ubuntu 18) as well. I cannot reproduce the descibed error. Everything is loaded into one volume.

@gaoh May it is an outdated MITK container?

I have checked it with the current develop head under linux (Ubuntu 18) as well. I cannot reproduce the descibed error. Everything is loaded into one volume.

@gaoh May it is an outdated MITK container?

As I understand @schererj he is not using a MITK container but the binaries from the MITK-nightly build. When he is building MITK, the problem does not occur?
So since in the docker containeres MITK is also build this should not be a problem in any of our containers?

In T27669#208866, @gaoh wrote:

As I understand @schererj he is not using a MITK container but the binaries from the MITK-nightly build.

I have checked it with the todays nightly build of MITK from CI. So this does work.
@schererj Could you give some details on what binaries you have used?

Yes I'm using the normal desktop workbench - no Docker involved :)

I tried it again with a binary from Jenkins (Sep 1, 2020 2:56:43 AM)

So it still doesn't work... is it my machine then?

Remark: It could be releated to T26451 and caused by the same underlying problem.

It is pretty weird since it even:

suggests 1 3D blocks

[1.383] [BlueBerry] BlueBerry Workbench ready
---------------------------------------------------------------
System:              e132-pc09
Processor:           Unknown P6 family
    Cache:           20480
    Clock:           2343.000
    Physical CPUs:   8
    Logical CPUs:    16
    Virtual Memory:  Total: 979             Available: 979
    Physical Memory: Total: 64184           Available: 55554
OSName:              Linux
    Release:         5.4.0-42-generic
    Version:         #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020
    Platform:        x86_64
    Operating System is 64 bit
ITK Version: 4.13.2
Name Of Probe (Time)          Iterations     Total (s)      Min (s)        Mean (s)       Max (s)        StdDev (s)     
Check input for DCM           1              0.00178719     0.00178719     0.00178719     0.00178719     0              
Condensing 3D blocks          1              9.53674e-07    9.53674e-07    9.53674e-07    9.53674e-07    0              
EquiDistantBlocksSorter       1              2.28882e-05    2.28882e-05    2.28882e-05    2.28882e-05    0              
Output                        1              5.60284e-05    5.60284e-05    5.60284e-05    5.60284e-05    0              
Reset                         1              0              0              0              2.22507e-308   0              
Sorting frames                1              0.000102997    0.000102997    0.000102997    0.000102997    0              
Sorting step 0                1              3.40939e-05    3.40939e-05    3.40939e-05    3.40939e-05    0              
Sorting step 1                1              1.28746e-05    1.28746e-05    1.28746e-05    1.28746e-05    0              
---------------------------------------------------------------
[2.183] Reader 0 (Instance Number, consecutive) suggests 1 3D blocks
---------------------------------------------------------------
System:              e132-pc09
Processor:           Unknown P6 family
    Cache:           20480
    Clock:           2339.000
    Physical CPUs:   8
    Logical CPUs:    16
    Virtual Memory:  Total: 979             Available: 979
    Physical Memory: Total: 64184           Available: 55556
OSName:              Linux
    Release:         5.4.0-42-generic
    Version:         #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020
    Platform:        x86_64
    Operating System is 64 bit
ITK Version: 4.13.2
Name Of Probe (Time)          Iterations     Total (s)      Min (s)        Mean (s)       Max (s)        StdDev (s)     
Check input for DCM           1              0.000674009    0.000674009    0.000674009    0.000674009    0              
Condensing 3D blocks          1              4.05312e-06    4.05312e-06    4.05312e-06    4.05312e-06    0              
EquiDistantBlocksSorter       1              0.000165939    0.000165939    0.000165939    0.000165939    0              
Output                        1              6.69956e-05    6.69956e-05    6.69956e-05    6.69956e-05    0              
Reset                         1              0              0              0              2.22507e-308   0              
Sorting frames                1              0.00268793     0.00268793     0.00268793     0.00268793     0              
Sorting step 0                1              0.00150895     0.00150895     0.00150895     0.00150895     0              
Sorting step 1                1              0.000982046    0.000982046    0.000982046    0.000982046    0              
---------------------------------------------------------------
[2.373] Reader 0 (Instance Number, consecutive) suggests 1 3D blocks
---------------------------------------------------------------
System:              e132-pc09
Processor:           Unknown P6 family
    Cache:           20480
    Clock:           2394.000
    Physical CPUs:   8
    Logical CPUs:    16
    Virtual Memory:  Total: 979             Available: 979
    Physical Memory: Total: 64184           Available: 55551
OSName:              Linux
    Release:         5.4.0-42-generic
    Version:         #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020
    Platform:        x86_64
    Operating System is 64 bit
ITK Version: 4.13.2
Name Of Probe (Time)          Iterations     Total (s)      Min (s)        Mean (s)       Max (s)        StdDev (s)     
Check input for DCM           1              0.000654221    0.000654221    0.000654221    0.000654221    0              
Condensing 3D blocks          1              1.90735e-05    1.90735e-05    1.90735e-05    1.90735e-05    0              
EquiDistantBlocksSorter       1              0.000322104    0.000322104    0.000322104    0.000322104    0              
Output                        1              0.014971       0.014971       0.014971       0.014971       0              
Reset                         1              9.05991e-06    9.05991e-06    9.05991e-06    9.05991e-06    0              
Sorting frames                1              0.007061       0.007061       0.007061       0.007061       0              
Sorting step 0                1              0.00244594     0.00244594     0.00244594     0.00244594     0              
Sorting step 1                1              0.00426507     0.00426507     0.00426507     0.00426507     0              
---------------------------------------------------------------

I agree to @floca and I am quite sure this is related to installer vs. starting from build directory.

It is pretty weird since it even:

suggests 1 3D blocks

That is indeed very strange. That indicates that something works differently in the final assembling of the volumes than in the first assessment of optimal readers... depending on the fact that it is installed or build on the system ?!?

@kislinsk As a linux noob please pardon my question. Can we directly debug the nightly bild by the CI on e.g. Jonas system? I would like to see some of the parts of volume generation process running to see whats happening. My be it helps us getting a lead. At least we now a setup directly on site that makes the problems.

I am not sure if that is related but today one of my cooperation partners reported that she couldn't open an 4D image in MITK (Latest develop installer).
On my laptop it just works fine. On her laptop, however, she doesn't even get to the logging point. It doesn't show anything, it just stops (She closed the workbench after 10 Minutes).
I asked her whether it was an ancient laptop, but no ;)

she doesn't even get to the logging point. It doesn't show anything, it just stops (She closed the workbench after 10 Minutes).

What do you mean with logging point?

I asked her whether it was an acient laptop, but no ;)

Depends on the definition of ancient. More interesting would be, how fast is the HDD / IO.

The log information in the console which Jonas reported doesn't turn up. So the console doesn't show any new information after the reader is selected.
I will ask about the HDD / IO.

The log information in the console which Jonas reported doesn't turn up. So the console doesn't show any new information after the reader is selected.
I will ask about the HDD / IO.

@thomass OK. So she had a running workbench and the system froze when she started loading the data? correct? Please open another task for that. Where we can sort this out further. We shouldn't mix the gathering of information at this state.

@kislinsk As a linux noob please pardon my question. Can we directly debug the nightly bild by the CI on e.g. Jonas system? I would like to see some of the parts of volume generation process running to see whats happening. My be it helps us getting a lead. At least we now a setup directly on site that makes the problems.

I don't think so since we cannot create debug installers. Maybe temporarily introducing old school console outputs?

@schererj we just discussed this in the MITK meeting. Could you try something? It would be interesting to compare the outputs of

  1. ldd on all libraries in the MITK installer, so find . -name \*.so\* | xargs ldd or simliar.
  2. Set the LD_DEBUG [1] environment variable before starting, e.g.export LD_DEBUG=all , but output will be rather long ;) [edit] LD_DEBUG=libs should be enough

Both interesting for the build and the install version. Maybe for a start the installed (failing) version is sufficient.

We could also meet for an interactive session if you like

[1] http://www.bnikolic.co.uk/blog/linux-ld-debug.html

I hope I did it right..

Did you your "release ldd" Workbench started and worked properly at all? Seems like most of the SOs could not be loaded correctly. Not even MitkCore. I would assume that workbench does not even start?!?

Yes, the workbench is starting without any issues.

@schererj we looked at the debug output, thanks. Unfortunately it seems to be complicated ... I would ask you to try another thing:

On the machine where you build MITK yourself, could you please execute a "make package" in the MITK-build folder inside of the _MITK build folder_ ? After that you should find a zip or tgz there which is a packaged version. Could you try this both on that machine and the target machine?

@nolden I tried the "make package" and it went through without any issues.
Should I upload the result here? Or is it just about the information that there are no error?
Could you please explain what you mean with "target machine"?

@nolden I tried the "make package" and it went through without any issues.
Should I upload the result here? Or is it just about the information that there are no error?
Could you please explain what you mean with "target machine"?

Sorry for the delay.

My idea was: take the zip which came out of "make package", unzip it to another folder on the machine you built it and check for the error.

Then, take the zip to target machine. "Target machine" for me was like a clean machine, docker environment etc..

You could of course also post the zip here.

PS: as an explanation, one theory is that the install-zip-package still references libraries from the build machine which causes the different behaviour

Possibly as duplicate of T26164: DICOM Query/Retrieve doesn't work at least in Ubuntu release installers. There's a workaround in the task that you could use to verify if it is the same issue.