This tag should be used to mark anything that is related to DICOM: concepts, implementations (MITK, PACS ...), new or advanced IODs like segmentation objects, parametric maps, DTI, structured reports
Apr 6 2021
Mar 15 2021
@gaoh thanks for pointing there, I will close this one as a duplicate
T28207 describes how to test it without the wDB. When searching for DICOM query retrieve there are already different tasks open with all similar problems
Mar 12 2021
Mar 10 2021
Hi there! 🙂
Nov 28 2020
Nov 25 2020
Nov 24 2020
@thomass could you check if the problem was realy just cuased by slow network drive and is solved. If this is the case, could you close the task? If the problem still exists, may be the issue solved by Stefan is a solution.
Nov 23 2020
Maybe this is related to T26164: DICOM Query/Retrieve doesn't work at least in Ubuntu release installers.
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.
Oct 9 2020
PS: as an explanation, one theory is that the install-zip-package still references libraries from the build machine which causes the different behaviour
Sep 25 2020
@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"?
@schererj we looked at the debug output, thanks. Unfortunately it seems to be complicated ... I would ask you to try another thing:
Sep 14 2020
Yes, the workbench is starting without any issues.
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?!?
I hope I did it right..
Sep 11 2020
@schererj we just discussed this in the MITK meeting. Could you try something? It would be interesting to compare the outputs of
Sep 10 2020
Sep 3 2020
Sep 2 2020
I just received an E-Mail that the problem could be related to the data source (some server or network drive) so maybe no MITK issue after all :)
Some additional questions:
- Was your laptop used to build the binaries? If yes, could you check, if yuo can produce the error behavior if you pick a non-mitk-developer maschine and try to load the data there?
- How many frames does the 4D Dicom have? What is its resolution?
Sep 1 2020
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.
What do you mean with logging point?
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 ;)
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:
Remark: It could be releated to T26451 and caused by the same underlying problem.
Yes I'm using the normal desktop workbench - no Docker involved :)
Aug 31 2020
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?
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.
Aug 28 2020
Discussion result: We close this task. All known issues still open are covered by T27568: US 2D image cannot be read: invalid tilt information. If needed we can open the task again.
Aug 24 2020
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.