For v2021.01 the problem is irrelevant now (legend is deactivated). But as soon as we want to support multiple statistics in the histogram widget and the widget has been reworked. This should also be covered.

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

We already removed the interpolation widgets from multi-label segmentation a while ago as they were never adapted to the plugin. I also tested to have both segmentation views open, use the multi-label segmentation, and use the interpolation of the segmentation. It works for the first label of any layer. Other labels simply are not considered as inpuit for the interpolation and are ignored.

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

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.

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