The tag v2023.04.2 was created on the branch hotfix/T30163-v2023.04.2, which should not be deleted.

@goetzm Thank you for the patch. We will look into it and merge it for parts that we keep (see T29649). If change your mind and want to maintain the rest of the classification code base in an extension, we can revisit it and see how we can help with merging the rest. Best Ralf

Updated document: https://hub.dkfz.de/f/55254009

Pushed new branch to rMITK MITK: hotfix/T30163-v2023.04.2.

First draft available here: https://hub.dkfz.de/f/55114850

Deleted branch from rMITK MITK: bugfix/T30159-DisableITKPathLengthCheckOnWindows.

Pushed new branch to rMITK MITK: bugfix/T30159-DisableITKPathLengthCheckOnWindows.

@floca Is this something we are already aware of (saving as .dcm crashes)?

Multistage Vertebra Segmentation
Multistage Vertebra Segmentation is an auto segmentation workflow involving multiple models namely, localization_spine, localization_vertebra & segmentation_vertebra (unexposed).
There could be several issues in this:

1. localization_spine: In practice, this gives me binary mask even though there is a whole of labels exposed in the API. This is in compliance with the documentation. But then the labels it claims to segment in the API don't make sense.

CUDA memory not cleared when out-of-memory exception occurs
Not all models have the same VRAM requirement.
When a model cannot run inferencing due to torch.cuda.OutOfMemoryError, exception occurs at server side clogging the GPU. Even if another model which could have potentially ran on the GPU, this clogging blocks it. Ideally TORCH.CUDA.EMPTY_CACHE should have been called to make room for next inferencing calls.

So far only CLGlobalImageFeatures is claimed to be needed.

In T29650#248947, @gaoh wrote:

@k656s has an example dataset. I am still at the release version before (I think 2022.10?) but I will update to the current release. Could this already help?

Yes, it could. I thought something like this was already introduced. @kislinsk, or?

@k656s has an example dataset. I am still at the release version before (I think 2022.10?) but I will update to the current release. Could this already help?
If not, I would vote for the task list view reinit after loading opiton.

@gaoh do you have example data to reproduce this situation. That would help to replicate it and search for the best solution.
Which version of MITK was it?

there is a DerivePointerAlignment option which basically unifies it on a file by file basis, in case there is no agreement. But I agree to Ralf with using the "left" style and put it next to the type

That is a first shorted list. Other apps and plugins are already ruled out (e.g. due to Vigra dependency). We no shuold assess which of those can really stay in the main mitk repo.

It's a feature.

Deleted branch from rMITK MITK: bugfix/T29636-fix-itkzlib-rpath.

Pushed new branch to rMITK MITK: bugfix/T29636-fix-itkzlib-rpath.

I figured out how to resolve it but before forking again, let's see what the upstream is doing with this information.
https://github.com/InsightSoftwareConsortium/ITK/issues/4084

One way of documenting the applied fitting pipeline in agreement with the lexicon is to export an XML file which describes the pipeline as suggested int the lexicon publication ("A community-endorsed open-source lexicon for contrast-agent based perfusion MRI (CAPLEX): A consensus guidelines report from the ISMRM Open Science Initiative for Perfusion Imaging (OSIPI)".)
In this task it is first collected if all relevant information of the fitting configuration can be extracted in order to build such an XML file.

Okay I don't really understand where the .1 comes from but it is not relevant. The issue is that the reference to libitkzlib does not use rpath like all the other dependencies:

Couldn't reproduce anymore with a fresh build.

Deleted branch from rMITK MITK: bugfix/T29634-UpgradeITK-v5.2.1-v5.3.0.

Deleted branch from rMITK MITK: bugfix/T29633-UpgradeVTK-v9.1.0-v9.2.6.

I just noticed that it tries to load lib/libitkzlib-5.3.1.dylib, where as the version should be v5.3 instead of v5.3.1. The ITK version upgrade was done from v5.2.1 to v5.3. I wonder if the .1 patch version has been carried over somehow and it can be fixed with a clean build? Let's see what the nightly clients will do tonight.

The mitkImageStatisticsHotspotTest should be fixed now. The reason was the backend of a FFT convolution filter that was not loaded, resp. the corresponding ITK object factory wasn't registered.

Deleted branch from rMITK MITK: bugfix/T29636-FixITKv5.3FailingTests.

Pushed new branch to rMITK MITK: bugfix/T29636-FixITKv5.3FailingTests.

Pushed new branch to rMITK MITK: bugfix/T29634-UpgradeITK-v5.2.1-v5.3.0.

thanks for taking care. 🙏

they are ok

@floca Can you check the two commits in the branch above if they are okay for merging?

I will migrate MatchPoint in this branch: https://phabricator.mitk.org/source/matchpoint/history/T29634-MigrateToITKv5.3/

Pushed new branch to rMITK MITK: bugfix/T29633-UpgradeVTK-v9.1.0-v9.2.6.