Thank you very much for your quick response.

Oh, I think I might have found the issue. Ignore the comment above and in CMake/Findlz4.cmake please add lib64 to the PATH_SUFFIXES of the two calls to find_library() in lines 11 and 18 like PATH_SUFFIXES lib lib64. Does it work?

Thanks for the comprehensive report. Can you do me a favor and add message(FATAL_ERROR "include dirs: ${lz4_INCLUDE_DIR} libraries: ${lz4_LIBRARIES}") as last line to CMake/PackageDepends/MITK_lz4_Config.cmake and configure MITK (not superbuild) to get the output?

With both subtasks done, we have successfully implemented the main goal of this task. The remaining bug that deactivating a segmentation tool resets the interaction to an earlier state (the one at which the tool was activated) has been split off into T28630 because it is not critical and can be easily handled with the new feature of deactivating PACS tools.

We discussed this and came to the conclusion to abandon D535.
@s434n will take over and create split MITK config files to be consistent with the PACS config file style.
Generally, as mentioned in the previous comment, splitting the config files "into smaller chunks" [...] "allows to change only the aspects of interaction that are necessary".

True, I tried this. There is even a task for it: T28557

This could be connected to the undo/redo implementation of MITK and the creation of difference images for the undo stack. I do not know your version of MITK but the use of LZ4 compression for difference images in the latest versions could already be the or part of the solution. I agree that the operations should be much faster but they might be already as fast as the python implementation so whoever is working on this task should clock the different parts of the operation first to see what is actually taking so long and as said, if it is still the case in the latest version of MITK.

If it only affects the legacy segmentation type (not displayed as multilabel segmentation), it should be soon resolved with the segmentation refactoring anyway. I think a workaround for now could be to convert the legacy segmentation to a multilabel segmentation in MITK (Data Manager context menu?). This task is also potentially connected to T28521: multilabel segmentation add switch to disable contour.

This is already possible in the Properties view but I guess it is a good candidate to be more accessible from within the segmentation view or preference page.

I think I once looked into this specific issue and it turned out that your label values had quite some gaps between there values resulting in similar neighboring colors "by accident". Consecutive label values would be quite distinguishable. I am not sure if at least the first x colors follow a certain standard or not. This should be checked first before changing the colors.

@kleina already tried to add int64 as supported image type but it didn't work out of the box AFAIK. In theory it should be enough to add the type to the MITK_ACCESSBYITK_INTEGRAL_PIXEL_TYPES CMake variable. If we would be able to make this work, compilation time and binary size would increase noticeably, though, because of the templated nature of ITK.

Deleted branch from rMITK MITK: bugfix/T28680-removed-old-style-cast-error.

Pushed new branch to rMITK MITK: bugfix/T28680-removed-old-style-cast-error.

2. Exception Handling: leading to Segmentation fault and Workbench crash

I did some debugging and found some more insights into the situation and workarounds.

Following operations has been done:

The proposed change goes kind of in the opposite direction of recent changes that were made, specifically in D531 and part of D532. If the approach of D535 is to be continued, it would need to take into account D532, in which an additional PACS scheme was introduced that leaves the left mouse button unused.
I would personally prefer the direction we have been taking now, splitting up the config files into smaller chunks. This reduces code redundancy, instead of having almost identical config files many times.
Also, in my opinion the approach of D531 makes a lot of sense for overlapping interactions. It allows to change only the aspects of interaction that are necessary while staying oblivious to the current interaction (MITK default, with swivel, PACS, ...). If we want to use full configs, one would need any variation of each scheme for each situation where alterations may be necessary. For example 2D segmentation tools require the left mouse button, so any possible interaction scheme needs to have a corresponding version where the left mouse button is unused. If a tool requires something new, like the right mouse button, new config files have to be implemented for every existing interaction scheme instead of just one file that will be appended.

so, this is what we have tried so far:
helm updated to 3.6
microk9s to 1.22
first problem: v1beta1 version cannot be used anymore --> changed to v1 in the repo
next problem: our treafik is not compatible anymore (with 1.22)

We decided to talk to @nolden, @metzger or @reicht to learn more about the typical behavior of PACS scrolling. Could you help us here?
Two general questions:

• in MITK you have to press the wheel and move the mouse to scroll through image slices
  • with this task / differential we change this behavior to simply use the mouse wheel to scroll through image slices
  • what is the typically expected PACS behavior?