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.

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.

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.

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?

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.

The context menu actions are either not implemented or dysfunctional. Disable the context menu for now.

Closing as "invalid". The secret is to use the mouse wheel to navigate between time steps in the point set widget. It is not in sync with the Image Navigator. The whole plugin and widgets need a complete rewrite to actually work reliably with dynamic images, though, but this is out of scope for this task and the upcoming release.

Thanks for the hint.

Since we removed the correction tool, this task is not valid anymore. The Add or Subtract tool can be used as a replacement. Remember that pressing CTRL inverts the logic of these tools.

In T28203#218558, @kalali wrote:

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

Ralf estimates that it takes a long time to fix this so we may come up with intermediate solutions or state in the UI that only 3d images are supported.

This is not high priority. Fix other release bugs before, please. :-)

We're waiting for a fix of https://github.com/QIICR/dcmqi/issues/414 instead of further lowering precision in checks.

Similar to T28223: [ImageStatistics] Deleting a datanode after statistics leads to no histogram update for the next node.

It's definitely linked to the crosshair. If you disable the crosshair everything works immediately.

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.

Only happens in Windows installers. How do we debug this?

It is dependent of the crosshair position. If you do not see anything, carefully move the crosshair around in a 2d window and there is always at least a pixel or region, where the changes are visible. What is going on? 🐛

Wow, this is really a blocker. Didn't work in the December snapshot installer neither. Is it specific to installed versions maybe? I will try with a build-tree version...