When SetAutoSelectNewNodes is set to true, the function should be emitting "CurrentSelectionChanged" which is connected to "OnImageNodeSelectionChanged". In case the views are open initially and have no Selected Time Series set and a dataset afterwards is loaded into the Data Manager, the dataset will be autoselected and "CurrentSelectionChanged" is emitted as expected. All good here.
However, when the dataset is loaded first into the Data Manager whilst the views are closed and then the views are opened, the "CurrentSelectionChanged" signal does not get emitted and hence the "OnImageNodeSelectionChanged" is not called and and the m_selectedImage is null. In this case the "Start Modelling" button stays inactive.

I could narrow the occurence of the inactive "Start modelling" button down some more:

I was to quick. QtCharts is no solution due to license conflict. :(

I was to quick. QtCharts is no solution due to license conflict. :(

I was to quick. QtCharts is no solution due to license conflict. :(

👍

This is still an issue also in combination with general UX improvement of AI tools. I suggest to have a closer look on that together in September so we have enough time for a nice design and implementation until v2024.12.

Deleted branch from rMITK MITK: bugfix/T30491-SwitchOffHttplibInMinimalConfig.

Pushed new branch to rMITK MITK: bugfix/T30491-SwitchOffHttplibInMinimalConfig.

In T30359#260125, @gaoh wrote:

What is with MitkCLGlobalImageFeatures, it is not expected to be part of MITK anymore? Or is it still part of it?

What is with MitkCLGlobalImageFeatures, it is not expected to be part of MITK anymore? Or is it still part of it?

Discussion result: we'll keep the task open. When eMITK builds again for the current state, try to reproduce the crash by going through the Geldosimetry workflow.
If it can't be reproduced, close the task.
If it can be reproduced, depending on the way the error expresses itself, either fix or accept as is.

Deleted branch from rMITK MITK: bugfix/T30485-HandleNaNImages.

Pushed new branch to rMITK MITK: feature/T30476-Expose_DCM_block_split_reason.

If I would be them, I also wouldn't like to have another metalayer under my belt. I think we can directly go with our own publishing. We may consider to suggest something like a registry, though, for third-party metalayers. :)

I am not knowledgeable enough to have a well informed opinion. Some thoughts to consider:

A few people reported trouble starting any MITK application with v2024.06.2. The culprit turned out to be Qt v6.7.1. I refreshed all Windows installers and packages with Qt v6.7.2.

I think you proposal is worth trying! Great idea.

In T30454#260087, @floca wrote:

Is there a defined anatomic coordinate system for blosc or the code that wrote the blosc images? Like LPS or RSA (https://www.slicer.org/wiki/Coordinate_systems) may be it differs form the assumption we have in MITK and therefore the memory layout of the pixels is different.

Is there a defined anatomic coordinate system for blosc or the code that wrote the blosc images? Like LPS or RSA (https://www.slicer.org/wiki/Coordinate_systems) may be it differs form the assumption we have in MITK and therefore the memory layout of the pixels is different.

First breakthrough: I was able to load and display the n2nd example image from @isensee. The orientation is unexpected, though. Probably rotated 180° (not mirrored?) around the axial axis. Trying to figure out the culprit. I use a the b2nd_to_cbuffer() function to copy the pixel data into the MITK image memory. If this orientation mismatch is systematic, we may be able to solve it by creating a geometry accordingly. At the moment the MITK image is just initialized via pixel type and image dimensions. As far as I am aware, the Blosc2 image does not contain any orientation meta data, right?

If you need additional files to test, I could give you one :)

c-blosc2 basically has 3 dependencies. We already fulfill an can/should use 2 of them: zlib (resp. zlib-ng) and lz4. The third one is zstd which is no issue, since c-blosc2 comes with an internal version of it if not provided externally.

Pushed new branch to rMITK MITK: feature/T30454-Blosc2.

Pushed new branch to rMITK MITK: bugfix/T30485-HandleNaNImages.

I think I found a adequate solution:

The origin of the huge level window range is the calculation of the image statistics in mitkImageStatisticsHolder.cpp:100. The function template mitk::_ComputeExtremaInItkImage() is supposed to calculate the extrema and 2nd largest/smallest extrema as well as their counts. However, it does not check for NaN and compares it against the default values (itk::NumericTraits<>::max() resp. NonpositiveMin()). Hence, these extrema stay at their initial default values.

"Empty time steps" turn out be be represented by frames filled with NaN (double). And I think this is the issue. Here's the file were I replaced all NaNs with 0s:

Sounds like a default value initialized with max possible value and the assumption that it would always be set to the actual value later on? How did you step into QmitkSliderLevelWindowWidget::paintEvent()? I always get stuck right before in Qt6Widgets.

The problem is in QmitkSliderLevelWindowWidget::paintEvent.
The example data lead to a level window range that 2*10^300 and that is why the painting takes for ages because it iterates exhaustively and it does not make realy sense.

The freeze happens at the end of QmitkSliderLevelWindowWidget::resizeEvent() but we need to install the debug files of Qt (Qt6Widgetsd.pdb) for further investigation.

Okay, maybe it is really simple and obvious: I noticed the path in video implies that the Workbench was installed in a OneDrive directory that is synced between multiple PCs. What if it really is just the DLLs missing locally since they are not synced? For example, does C:\Users\adiazpinto\OneDrive - NVIDIA Corporation\Documents\MITK v2024.06.2\bin\MitkCore\MitkModelFitIOServices.dll really exist locally?

I was finally able to play the video from the link above. This looks more like a common system DLL or something similar is missing since basically every DLL is unable to load. We can't really figure out anything without access to an affected system. In that case I would run Dependencies on the Workbench executable after making sure to set the same path as in the start batch file.

Here's the other report: T30448: MITK snapshots/2024-05-02 Workbench not restarting

I use it on Windows 11 just fine. We recently had a similar report from someone using Windows 10. I throw anti-virus / defender as culprint into the ring.

I tried installing MITK but I cannot replicate the error on Windows 10.

Deleted branch from rMITK MITK: bugfix/T29421-RemoveCPPRestSDK.

Pushed new branch to rMITK MITK: feature/T30361-pyMITK-wrapping.

Pushed new branch to rMITK MITK: hotfix/T30482-v2024.06.2.