@isensee

1. Does it work if you select two normal images (not segmentations)?
2. Does the seg fault also happens if you use the Registration Evaluator plugin with the image and the segmentation?
3. Could you provied example data, please?

Also if checking validity, consider T24766.

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

Side note: https://fdossena.com does provide 64-bit builds now.

Cool! 👍🏻
Will look into this on Community Day.

Requested code changes in pull request.

Merged into releases/2018-04.

Pushed new branch T26655-GizmoFix.

Not yet working. Tree doesn't collapse only the first time.

In T26451#186376, @jsolislemus wrote:

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.

Will be solved if D214 is accepted and merged.

Apologies for the delay in response..

Is this still valid? I looked at it but couldn't reproduce the bug.
If you can reproduce it, could you try to reproduce it with Pic2DplusT and MITK-Data/3D+t-ITKIO-TestData as well?

I created such a segmentation on the 3D+t-heart dataset and stored the segmentation as *.nrrd. The I loaded the *.nrrd-segmentation again and I now I can only see the segmentation on the first timestep.
Important: The timesteps of the *.nrrd-segmentation are now from 0 - 3 and with a duration of 1ms. The original 3D+t-Heart was [0,103] [103,160] [160, 160]. This was also true for the original segmentation. If I store the 3D+t-Heart image as *.nrrd and reopen it again the original timesteps are preserved.

I also tried it with MITK-Data/3D+t-ITKIO-TestData and everything works fine (segmentation and time-slider). However, a difference between all these time-images and the 3D+t-Heart// image is, that the Heart-image does not actually have a third timepoint, as the third timepoint is of length 0ms.
So maybe there is a problem with the matching of time points and the segmentation is displayed for the last time point, as the lats time point is actually non-existent and wraps around to the time point 0.

I just tried this and I can reproduce it with MITK-Data/3D+t-Heart. But when I used Pic2DplusT the segmentation was only created on a single timestep.
Additionally, when I clicked on the arrows of the time-slider of the image navigation plugin the time slider sometimes wraps around the last time step and returns to timestep 0. This was already mentioned here T25030. However, this does not happen If I use the Pic2DplusT image so maybe the 3D+t-Heart image is corrupt?

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.

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

In T26451#184491, @jsolislemus wrote:

(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.

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.

@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.

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.

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.

This is some output of the GuidelinesSupportLibrary.cmake external project file in the MITK-ProjectTemplate:

Pushed new branch T25882-RewriteCTestScript.

Built Mesa. Same result. Mesa keeps reporting OpenGL 3.1 with GLSL 1.40. If we figure out how to squeeze the correct OpenGL context out of Mesa, it could be the breakthough.

According to https://mesamatrix.net/, Mesa (llvmpipe) should be able to 100% support OpenGL 3.3 with GLSL 3.30 and hence OpenGL 3.2 with GLSL 1.50. Next test: build Mesa by myself.

I did the same for the Qt contextinfo example. When creating a 2.1 context Mesa is reporting:

Wrote my own minimal Qt application with QVTKOpenGLNativeWidget and it basially has the same problems.

Cherry-picked into releases/2018-04. Peter's fixes do not affect code available there.

Built MITK in 32bit and tried again just in case the 64bit binaries of Mes3D for Windows would have a problem. Same error, though. Next step would probably be a stand-alone VTK app with geometry shaders and if it works a stand-alone app based on VTK's Qt render window.

Dashboard is red. Many errors related to missing overload of operator <<. I guess this is related to changing many ref types of catch blocks without adapting the code in the catch blocks.

May be worth cherry-picking these commits into releases/2018-04 as well.

VTK has a little bug in vtkShader.cxx around line 76: GLuint handle = glCreateShader(type);. The handle is not tested against 0 which leads into a misleading error message like above. The actual problem is that vertex and fragment shaders can be created (and compiled successfully) but not geometry shaders.

In T26427#182768, @kislinsk wrote:

Our example steps do not work, they start however. Render window is just black.

Also experimented with environment variable QT_OPENGL=software and QT_OPENGL=angle. VTK's GLEW is already unable to initialize with these settings.

Our example steps do not work, they start however. Render window is just black.

Pushed new branch T26413-Nifti2.

Potential conflicts: Multiple render windws, Qt resp. shared OpenGL context with Qt.

I tried the VTK MarbleShader example and it works.

Tried every combination of options but it's always the same error:

Important for T26144 (and also open office virtual desktops).

64bit builds of Mesa 3D for Windows: https://github.com/pal1000/mesa-dist-win/releases

Added ITK example to project template.

Pushed new branch T26426-EPCustomization.

Works with NSIS 2.51.

@neher Please base the fix on the releases/2018-04 branch.

It turned out that if I load the file holding the segmentation alone and the right click -> convert to segmentation, everything works as expected. Only if I load the raw image plus the corresponding segmentation simultaneously (which is my usual workflow), the bug above arises.

Alright, thanks!

HI Peter, MITK (2018-04-4) the the current milestone. I nearly missed this task as you put it in the already archived milestone MITK (2018-04). The safest way to raise awareness is to just set the task priority to Needs Triage and stick with the MITK tag. ❤

@kislinsk Thanks for your quick fix. I had a look into your changes, this looks very much like an overdue cleanup. Thanks again!

Pushed new branch T26356-MisalignedRenderWindowFrames.

Frame is encapsuled by vtkMitkRectangleProp class.

Thank you! 👍

Pushed new branch T24860-LevelWindowInitLocation.

I think @kislinsk suggestion would cover most use cases since the plane you work in is usually the one that is maximized. In this cases the working window will be the one that was clicked the last time.

Ok, I tested it on my current developing build, which is branched off of master from 2019-04-29 (a0ba9d263118bc2df2aa922c124c3db57acbd2dc). I can reproduce the error as described in the description. So I guess to answer your question @kislinsk: The status is "still open".

I forgot to enable the segmentation plugin... I'll test it tomorrow.

I can reproduce it. I did exactly the steps in the task description. I used MITK.2018.4.0 installer. I'll check on a (more or less) current master.

Wait for it...

I couldn't reproduce it. @kleina Can you? (maybe it occurred only due to missing reinit?)

@kausch What's the status on this task?

Pushed new branch T26252-BoostInstallError.

I really tried but I was not able to reproduce this issue. For example, I created a segmentation and clicked multiple times on "Create smoothed polygon model" and "Create polygon model". Worked every time. I then created another segmentation in the same scene and did the same there with the same results.

To get an overview of MITK subprojects:

Pushed new branch T25882-CDash-v2.6.