Pushed new branch to rMITK MITK: release/T28750-2021-Week-42.

I guess in GIMP the behavior is somewhat similar to your second suggestion. As you are not able to set additional points, it is a "restricted region". You can still modify existing points. This is what the tool looks like in GIMP if you move one of the existing points.

Deleted branch from rMITK MITK: bugfix/T28749-libxdamage.

Pushed new branch to rMITK MITK: bugfix/T28749-libxdamage.

One comment to this: The tool was inspired by the behavior of a similar tool in GIMP. In GIMP it is not possible to add additional points after finishing the contour. So they don't have that problem.

In T28320#229111, @kalali wrote:

@floca, should we also add this for the upcoming release?

Has been fixed with the mentioned diff / task.

@floca, should we also add this for the upcoming release?

The users have 2D+t data. The current workaround is to convert the 2D+t data to a 3D volume, where one slice is one timepoint and interpolate like this. This is not a perfect solution, as the 3D interpolation tries to interpolate to something like a "round" or "organ shaped" object, which does not make sense in this case.

One solution to approach this issue is to check if NaN values are present in the data. If so, the user should be able to select the NaN handling strategy if necessary (e.g., not for case-based ranking). So what about providing the NaN handling options after the chosen ranking method is known?

I already implemented something but it is not yet finished.

I will close this now, discussion can be continued in T28741.

Good catch! Thanks

Thanks!

In T24358#228955, @kislinsk wrote:

This is a good candidate for some XML parsing errors that we see in the latest develop version of the MitkWorkbench, For example, activate any 3D segmentation tool and look at the console output:

vtkXMLParser.cxx:379 ERR| vtkXMLParser (0000027698218908): Error parsing XML in stream at line 1, column 0, byte index -1: no element found

It starts with line 162 in mitkTool.cpp (last code line in snippet):

auto displayActionEventBroadcast = dynamic_cast<DisplayActionEventBroadcast*>(us::GetModuleContext()->GetService<InteractionEventObserver>(*it));
if (displayActionEventBroadcast != nullptr)
{
  // remember the original configuration
  m_DisplayInteractorConfigs.insert(std::make_pair(*it, displayActionEventBroadcast->GetEventConfig()));
  // here the alternative configuration is loaded
  displayActionEventBroadcast->AddEventConfig(m_EventConfig.c_str()); // line 162, m_EventConfig is an empty string
}

I guess m_EventConfig is not supposed to be an empty string. Or, if it is supposed to be an empty string, AddEventConfig() should probably handle it gracefully, before the vtkXMLParser has the chance to complain.

This is a good candidate for some XML parsing errors that we see in the latest develop version of the MitkWorkbench, For example, activate any 3D segmentation tool and look at the console output:

BTW I recommend to test always with the latest snapshot installer instead of the last release.

Found the bug. The lower threshold for the region growing preview is set to itk::NumericTraits<TPixel>::min() when the region growing direction is downwards. However, itk::NumericTraits<TPixel>::min() is the wrong method as it has a different meaning for floating point values than the author obviously expected (compare to min() vs. lowest() in std::numeric_limits<>). The correct method is itk::NumericTraits<TPixel>::NonpositiveMin(), which works for all cases and is the right semantic minimum of a range of values.

Is doesn't have to be in the installer - but it has to be in the final release, meaning: It will probably be a bug found by some manual checklist testing by some random people.