Please check if problem still persists as soon as T27490 is merged into develop or directly with D329 (is open for review by the way ;)

@thomass Can you confirm the problem in your todays check or is it fixed by the tasks mentioned above?

I can partly confirm it.

1. The segmentation is performed on the current selected timestep (if you switch to timestep 2 --> segmentation occurs on timestep 2 = CORRECT; maybe fixed with the task!?)
2. But if you have shift+clicked on timestep 0 and then change to timestep 2 (I guess this would not normally be done but theoretically it could), the green contour remains. (BUG)

So I would propose to fix that by reseting the contour, whenever the timestep changes.

File is FastMarchingTool.cpp

I am not sure if I am missing out any side effects, but it works correctly if the following line:

this->Reset();

is either added to function Initialize() or SetCurrentTimeStep(int t)

Initialize() is also called on activating the plugin, so it would'n't hurt but probably also wouldn't make a difference to put it there.

So I have a fix for the contour problem but what is missing is that the pointset is still drawn on timestep 0 instead of the current timestep and I have to figure out why.

In T26975#208105, @thomass wrote:

I can partly confirm it.

1. The segmentation is performed on the current selected timestep (if you switch to timestep 2 --> segmentation occurs on timestep 2 = CORRECT; maybe fixed with the task!?)

According to T27721: [Segmentation] 2D Fast Marching crashes with 4D image and static segmentation there should be a crash if 2D fast marching is performed on a static segmentation. Can you re-check?

Will be fixed (is fixed already) by the rework done in T28118.