Hi there! 🙂
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 29 2022
Mar 31 2022
Dec 3 2021
Nov 10 2021
Oct 14 2021
Hi there! 🙂
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
In T27669#211004, @schererj wrote:@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"?
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
In T27669#209003, @floca wrote:@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.
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
In T27669#209010, @thomass wrote: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.
In T27669#209008, @thomass wrote: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 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 ;)
In T27669#208901, @schererj wrote:It is pretty weird since it even:
suggests 1 3D blocks
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
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?
In T27669#208859, @floca wrote: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.
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.
Aug 12 2020
Jul 29 2020
Jul 25 2020
Cleaned up naming of DICOM related modules
Jul 19 2020
Jul 8 2020
Jul 6 2020
Jul 2 2020
Jul 1 2020
Jun 25 2020
Looked into the topics. Following comments:
Jun 22 2020
@hettich Why? 🤔
Jun 19 2020
Jun 17 2020
Jun 16 2020
I am sorry for being late reply.
Jun 3 2020
@sharonYu Thanks for the data. That helped to identify the problem.
May 24 2020
As we have with T27416 a mitigation strategy for the next reales cycle, I retag it as MITK general. It should be checked somewhen, but given the current needs/information, I don't think it is necessary for the next cycle.
'
May 22 2020
Discussion result: For now (MITK 2020) we well deactivate the skipping of empty slices. But such a support would make sense longterm, but it is also a bigger issue. I have opened a dedicated Task T27439: [Segmentation] Support of Mask/Segmentations that are cropped / do not cover the whole image grid for that.
May 20 2020
May 13 2020
The reason is still unkown. But if you store the segs without skipping the empty slices, then mitk is able to load also segs with one slice.
May 11 2020
May 10 2020
Apr 22 2020
We should inform about the change and tell them that the can drag whole directories if the want to still read the whole DICOM content of a dir at once.
Apr 17 2020
Apr 16 2020
Pushed new branch T27321-Improve_DICOM_3DnT_handling.
This also might have impact on T27065 and T25702
Feb 12 2020
I would close it because we have the DICOM property view for that. This view shows the DICOM properties with also the human readable name of the tag. In addition it shows the value slice and time resolved.
Feb 2 2020
Nightly CI looks good as well.