We discussed this and decided to open a new task to cleanly define the problem. We thought that this task mixes many different things without stating the minimal steps to reproduce a single problem, so please continue here: T28270

I don't mind, I'm not planing to fix this before the release, so if you have time. I'm testing this with the develop branch and comparing it with the MITK 2018 installer.

Ok, I withdraw from this for now. It is useless to fix this since both views are basically the same but their implementation is different (some things are copied, others aren't). Before putting any effort into this I refer to T28142 and propose to refactor the whole thing after the release.

I tested it and now this explains T27498#217602.

In T19522#68902, @goch wrote:

Specifically it is not visible on the 2D planes in the 3D render window, this error is unrelated to volume rendering.

In T28262#219358, @kislinsk wrote:

Since we are supporting multiple images in a single scene. These images can have different time bounds and their time steps can be discretized differently. So even if you have kind of matching dynamic images but one image specifies its acquisition times at 2, 12, 22ms seconds, and the other one at 0, 10, and 20ms, you would have a very sparse discrete time line and only see either no image or at maximum a single image, but never both at the same time. So it is a pretty solid and natural assumption to define timesteps to have a duration until the next time step of the same image, if not explicitly specified otherwise. However, we also have many images that do not have time bounds stored in their files at all (in particular static images) and we need to come up with something completely artificial. It is a pretty severe issue but luckily is not very present in 99% of workflows as users rarely need to have scenes with different dynamic images aligned perfectly or at least not matching 1:1 on a time step basis instead of true time for their purposes.

It would be overkill but to get things sorted out for everyone MITK is missing a complete sophisticated time-line component were you can arrange images and change their time properties just like every video editing software allows you to do for clips.

I tested again with UltrasoundImages\4D_TEE_Data_MV.dcm and everything seems to work as expected. So this task is only valid for strange arbitrary time geometry, as the title describes it.
So I guess the refactoring done in the segmentation tools changed most of the bugs and we got now down to the problem mentioned in T28262.

In T28262#219287, @floca wrote:

In T28262#219283, @kislinsk wrote:

It is philosophical indeed, but how is any of these strategies worse than creating a time step with a duration of 0?

We should keep in mind that the whole concept of duration is purely artefical. There is no duration defined. The only things we know are the very time points where they exist.

In T28258#219285, @a178n wrote:

I have finally found the fix! This bug is due to my GPU driver.
My laptop has an AMD Radeon dedicated GPU and MITK uses it by default for rendering its "Standard Display".
I checked the crash log using Event Viewer and found that atio6axx.dll was the culprit here. This is an AMD driver related DLL file.
I switched the default GPU for Mitk workbench to the onboard integrated graphics and that's it!
Problem solved. I am attaching the working screen recording herewith :-)

If you have suggestions for a better structure, please feel free to add it to T28130. The checklists were not even existing before and my goal was to overhaul all the (multi-)label segmentation checklists to include 4D-data tests. I also strove for consistency throughout all checklists.
I see that the bold written statement reads as a new test - that could be changed. However, the test right before already dealt with 4D image data (4D Bild als Testdatensatz) so I assumed it was clear that the 3D-data tests were already finished.
I will also think about some rephrasing / different text format.

I don't know what the real world scenario is to change the Image Rendering Mode, but basically you just have to perform step 8 and 9 to see the bug (step 10).
I could imagine the Image Rendering Mode being changed to either LookupTable_Color or ColorTransferFunction_Color by a line of code inside a module or plugin, which would then make this bug appear, if the auto topmost mode was disabled.

I think there was a decision to drop the correction-tool as it is obviously not nice to work with (see https://phabricator.mitk.org/D459#14092).

There seems to be a bug inside the condition of void QmitkOtsuTool3DGUI::OnSpinboxValueAccept(), see T28243.

There seems to be a bug inside the condition of void QmitkOtsuTool3DGUI::OnSpinboxValueAccept(), see T28243.

I remember that I had a discussion about this with @floca, he recently did a lot of changes to the seg tools: https://phabricator.mitk.org/D450?vs=on&id=2056#change-lAwYLYHZrN5g
Here he added a condition to only calculate a preview if some settings have changed. Maybe there was a property missing? (check esp. lines 77, 78, 79 in void QmitkOtsuTool3DGUI::OnPreviewBtnClicked()).

I see your point. The exact task I used is not a duplicate but we discussed this problem with deactivating the tool inside the mentioned task (and you already suggested to fix the checklist). So I get why this task was not found in the first place.

The last thing that happens is a crash.

Still valid - although it was not clearly defined what happened. Sorry, too many things going on at the same time. I will add a video to show some strange behavior.

That's exactly what I wrote and defined in the checklist. The checklist is correct as it perfectly reflects what's happening in the workbench. This is - as described in the title of the corresponding section - valid for 4D test data.

I opened a review for my modifications / suggestions for a LevelWindowManagerTest. Please have a look at it: D461
I have explicitly two problems with the current test:

1. I need to load the three images / datasets for each tests since it is not possible to keep those images in memory for every new tests. Does anyone know how to solve this problem?
2. I randomly get a failed test in line 287 / 288

m_DataNode2->SetSelected(true);
CPPUNIT_ASSERT_MESSAGE("\"imageForLevelWindow\" property not correctly set", AssertImageForLevelWindowProperty(false, true, false));

I found several reasons to do a pseudo-UI test so I will come up with a draft for a test of the relevant classes.

Ok, but then we can at least close T22391.

Most of the functions that can be called from the QmitkLevelWindowWidget (meaning the slider, the line edit and the contextmenu) are covered in mitkLevelWindowTest.
However, the LevelWindowManager tests where outdated and suboptimal, so I opened T28204.

Is this obsolete know with the discussion results stated in D459?

In T28000#218153, @kislinsk wrote:

I noticed that simply merging all the changelogs section-wise doesn't work out very well and generates an overwhelming document probably noone is going to read. I propose the following for the release changelog:

• Merge the thirdparty dependency update table (simple)
• Focus on feature and bugfix oneliners and reference the original changelog if there is more related information
• Roughly sort them by importance/shinyness
• List references to original changelogs with API-breaking changes but explicitly mark the "big ones" that have migration hints/guides

I looked through the checklist and updated it to be in line with the already updated checklists (see parent task T28108).
I copied the modified document to E130-Daten\Release\Checklisten\MITK Workbench Release.

The issue has already been reported here T26754 and here T22395, so I will merge the task here.

Ok, I modified T27498#208164 to update the missing views. I say, for the release we leave the utilities the way they are (your option 1. keep it as is: user has to select manually). We keep an eye on it if this leads to some confusion.
SemanticRelations is not relevant for the release so I'll put this in another task.

Something strange happened:
I wanted to test some GUI functionality for your open diff but somehow I was not able to load data anymore: Clicking on Open File did not open a window.
Then I removed the DKFZ AppData folder to have a fresh MITK workbench. Now clicking on Open File opened a window but while I was scrolling inside this window to find the desired data, the window stopped working (did not scroll anymore - whole application was frozen).
So I did a Windows restart and opened MITK again. Now I am able to load data again and Voila: The segmentation view now automatically selects the newly added data node (patient image selector).
...
...
Tbh, I have no clue what's going on.

I'm currently on the latest develop (rMITK15ecdf8d92aa). Only a small set of plugins enabled (datastorageviewertest, (ML)segmentation, imagenavigator).
I'm doing this in Debug mode.

1. The new selection concept automatically removes non-matching segmentation nodes if the reference image was changed. A warning is shown Select or create a segmentation (Tools disabled)
2. The new selection concept does not allow to select a non-matching segmentation node
3. Selecting a matching segmentation node that is invisible results in the warning: The selected segmentation is currently not visible! (Tools disabled)
4. Showing the invisible segmentation node results in the warning: Please perform a reinit on the segmentation image! (Tools disabled)
5. Performing a reinit on the matching segmentation node enables the tools (no warning shown)

We are now using a different approach but this should be verified with the new widgets.

Is this solved?

Need to recheck after T28118: Refactoring of SegTool2D is done.