vtkITKImageThresholdCalculator failure - due to ITK update?

Development
1

vtkITKImageThresholdCalculator fails with errors like this recently (and crashes or just provides invalid result):

Failed to compute threshold value using method Shanbhag. Details: 
itk::ExceptionObject (00000076F88F6C90)
Location: "void __cdecl itk::ImageConstIterator<class itk::Image<int,3> >::SetRegion(const class itk::ImageRegion<3> &)" 
File: c:\d\s4d\itk\modules\core\common\include\itkImageConstIterator.h
Line: 210
Description: itk::ERROR: Region ImageRegion (00000076F88F6E68)
  Dimension: 3
  Index: [0, 0, 0]
  Size: [512, 512, 9]
 is outside of buffered region ImageRegion (0000019E5F947430)
  Dimension: 3
  Index: [0, 0, 0]
  Size: [0, 0, 0]

It still worked fine in Slicer 4.11.0-2019-08-11 (revision 28433), so I guess it is due to recent ITK updates.

How to reproduce: Load a volume, go to segment editor, select Threshold effect, click on left or right arrow buttons in “Automatic threshold” row.

Does anyone have a clue why could this happen? I don’t see anything special in vtkITKImageThresholdCalculator.cxx that I would expect to break due to an ITK update.

@jcfr @Sam_Horvath @pieper @hjmjohnson

2

I have no idea. Adding @thewtex and @blowekamp to the list of people who might be able to help.

3

@blowekamp may know – this change may be involved:

4

As Matt pointed out in the PR the base class of the ImageToHistogramFilter was changed to a the new ImageSink which add streaming pipelining support. So the method called in the ITK pipeline may be a little different from ITKv4.

I expect the quick solution is to add itkImporter->UpdateLargestPossibleRegion() after it’s connected to VTK.

What is wrong with the pipeline connectivity to cause this to be needed is a harder question.

5

@blowekamp @thewtex @pieper Thanks for your help!

Adding UpdateLargestPossibleRegion() indeed fixed the problem.

It would be useful if the filter would run on the largest possible region by default.

6

Of course it should work without this extra call. I narrowed down the issue to streamed execution and the computation of the extrema with the AutoMinimumMaximum option enabled. So it’s not related to the VTK/ITK pipeline interaction as first susspected. I will work on a patch to fix this in ITK.