Thanks, but this is the same issue you reported yesterday. Segmentation and Multi-label segmentation share the same tools. If you test these tools on both segmentation views (cool!), I suggest to keep an eye on issues related to labels and layers other than the default ones and also different time steps in particular. For issues related to the first label in the first layer, you can verify that the issue should arise in both segmentation views.

I cannot reproduce the bug as described (and don't see it in the video), only for a specific - by the segmentation as invalid considered - last time step (like in the video).

Thank you all for reporting and clarification. :-)

While I think I understand the bug, it seems a little artificial in reproduction and high in priority. Can this be triggered in a real-world scenario without the Properties View? If not, I would vote to postpone a fix after release to have more resources for more prominent bugs i. e. related to segmentation. In particular refactoring in general like mentioned in the last paragraph is something that is prone to introduce new side effects that we are not able to detect in time with only a few days left, even though I see the benefits outside of crunch times. :)

In case of QmitkSegmentationView the preference was even hijacked for something different but the tooltip in the preferences still indicate the originally intended behavior.

The auto-selection preference should work but I think it isn't able anymore to select all other images to hide them as the used predicate was changed to also check the geometry. The predicate used for auto-selection needs to be more general.

Color is fixed with T28211. The other options really do not work or are implemented very sloppy (volume rendering). I will remove them as one can consider them dummy options at the moment.

Fixed! :) Was a line that I introduced in the VTK 9 migration. The plane geometry 3-d mapper accesses the 2-d image mapper textures to use them also for 3-d rendering. It also used the VTK properties of the 2-d mapper actors and manipulated them for 3-d rendering which also modified them for the 2-d mappers, though. During migration I changed that to a deep copy of the VTK properties. However, the deep copied VTK properties still contained some same pointers so there still was an interference. I fixed it now by manually copying only color and opacity VTK properties.

@a178n By the way. Please make the titles of the tasks a bit more telling (context). Thanks.

@a178n Well spotted!

The finding is correct (thanks @a178n ). The remark of @kalali as well. I think I missed to communicated clear enough in the wrap up meeting last wednesday. Sorry for that.

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

This is quickfixed with T28221. I keep the task open and move it to the next milestone, as the quickfix does hide the problem, but it should be handled as soon as we want to display node names in the histogram legend again. The proper fix would be to listen to changes of the node(s) that is displayed in the histogram widget and to update the labeling as soon has the name property of the node has changed.

Update: Didn't happen with October snapshot (VTK 8.1).

In T28211#218441, @kislinsk wrote:

Zoom into the image until you have big pixels. Click in a pixel, crosshair snaps to that pixel, color/opacity is not shown. Click on that pixel again and it works. You can also click, hold, and move the cursor. As soon as you move the cursor it works. Stops working as soon as you leave the pixel and the crosshair snaps to the next pixel.

I could also reproduce this bug in a build-tree version of MITK. As Hanno wrote, sometimes every render window is affected, sometimes only a few, sometime it works. So I guess there is a race condition. Good thing is, that you do not have to reopen the workbench for it to happen, it is enough to reopen the editor to eventually provoke the issue. I already added debug output to the ApplyColor() method of the 2-d image mapper, but it does what it is supposed to do.

Another impact is shown in T28245: [Segmentation] 3D Region Growing preview does not show a binary mask in Windows Installer.

Yes, same issue but good that you identified another impact.

BTW I also tested with small values and the computation did at least finish after 2 minutes on my desktop PC.

We should take the opportunity to discuss the general sense of some segmentation tools. It appears to me that quite a few tools are just there because the algorithm is mentioned in the ITK book. In particular when looking at the abstract parameters that the tools offer I highly doubt they are of use for anyone at all. "alpha", "beta", "gamma", "level", you name it. We should consider to actually remove those tools and invest our time instead in improving tools people use or the integration of the DL algorithms of our department.

Picking tool is not refactored yet. 😱
Only managed to get to the 2D tools. Picking is still missing.

Addition: time bounds of the picking result are set to [min possible value, max possible value] instead of the time bounds of the reference image.

yes the logic is flaut. I was not carefull enough when I a changed line 77ff in QmitkOtsuTool3DGUI.cpp

Sorry this was already mentioned in T27507. But I think we never discussed / decided what the purpose of picking on 4D tools should be. But not necessarily important for the release though.

Watershed tool also has very weird rendering flickers, whenever there is more than one image visible in the 2D view. Whenever the rendering bug is solved, the segmentation tools should be checked again.

Cool, one less to thing to worry about. :)

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.

I am not sure if it is realy a dublicate.

IMO not severe for the upcoming release since Otsu is not often used and it is not a show stopper...

The last thing that happens is a crash.

It is a safety measure. As soon as more then to rows are in the table (so either >1 image or >1 roi) the histogram is deactivated at the moment, because you would not be able to discreminate them accordingly. See also Tasks mentioned above. Needs substential overhaul in the internals.

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.

Since you are already working on the histogram anyways, can you check the following:

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.

The other options "Show as volume rendering" and "Enable auto-selection mode" are not working as described. Or I didn't get the description..

Ah it seems I was mistaking, at least the transparent overlay works, the color mismatch remains.

Ah, when changing the Preference of Segmenation, the mask is changed... How can I create a "Multilabel Mask"?

Yes, it is exactly as you described: static -> all timesteps, dynamic -> toolbox to apply to all timesteps or not.

I think it is the checklist. When creating a new segmentation based on a dynamic image you now can decide between a static segmentation that has a single timestep spanning over all reference image timesteps and a dynamic segmentation to have matching timesteps. In the latter case only the current timestep should be affected except the tool is explicitly giving the option to be applied to all timesteps at once. Can you confirm?

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));

For all cases the result now keeps the original level window. In case of Heart3D+t the level window property is lost otherwise. That's why it appeared in strange contrast and "lost" the level window widget.