[Insight-users] FastMarchingImageFilter extremely slow for a 3D image data

[Dan Mueller]

Hi Haiyong,

Thanks for letting us know your issue is solved.

Regarding the addition of the defines for Visual Studio: I am not
convinced adding these defines is a good solution. In your particular
case you wanted performance in debug mode, but another developer may
prefer to debug the iterators. I think the best solution is that
individual developers choose the best option for them. It is easy to
add these defines to you own project without needing them in the
toolkit itself.

Anyway, I am sure you will bump into this issue again in other parts
of the toolkit, not just in FastMarchingImageFilter. By its very
nature optimized release code will always run faster than
non-optimized debug code.

Cheers, Dan

On 30 April 2010 15:58, Haiyong Xu <haiyeong at gmail.com> wrote:
> Thanks Dan. It is the release/debug mode problem. I built it on the
> release mode and it finished within a second.
>
> Just wander why there is such huge difference between the release and
> debug mode for FastMarchingImageFilter. All my rest codes have no
> problem running in debug mode. And as a developer, I run my program in
> debug mode for thousands of times before release it. The
> FastMarchingImageFilter prevent me from debugging my program since it
> stuck whenever there is a call of fast_marching_filter->Update();
>
> After a little debugging, I found that the member variable
> FastMarchingImageFilter::m_TrialHeap can reach more than 20K nodes
> very easily in my test program. I guess that's the cause of slow
> performance because the m_TrialHeap is a std::priority_queue and
> push() operation takes long time if the heap size is large. And this
> post from MSDN's website explain the reason:
> http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/998fea17-757e-4271-89e6-8273a9e86d5b/.
> As recommended in that post, disable _HAS_ITERATOR_DEBUGGING and
> _SECURE_SCL (have no clue what this is) make my test program run much
> faster in debug mode, even though it still takes a while but it is
> endurable. It looks like that std::priority_queue in Visual Studio
> does something wrong when running in debug mode. I use Visual Studio
> 2008 Pro. Ed. Version 9.0.30729.1 SP.
>
> #define _HAS_ITERATOR_DEBUGGING 0
> #define _SECURE_SCL 0
>
> I think define these two macros in FastMarchingImageFilter.txx may
> relieve developers from the same problem in future.
>
> Also, I figured out that rather than using FastMarchingImageFilter to
> generate initial contour, I can use SignedMaurerDistanceMapFilter to
> do the same thing. The later approach does not have any slow
> performance problem in the debug mode and is much faster.
>
> Regards,
> Haiyong
>
>
>
> On Fri, Apr 30, 2010 at 1:23 AM, Dan Mueller <dan.muel at gmail.com> wrote:
>> Hi Haiyong,
>>
>> Are you compiling your code in Release mode? Compiling in Release mode
>> vs Debug mode is known to have anywhere from 3 to 300 times
>> performance improvement (depending on the platform, compiler, code).
>>
>> Running Fast Marching on a 256x256x256 floating-point image with speed
>> constant 1, stopping value 500, and a single seed in the center of the
>> image took approximately 45 seconds on my Windows Vista, 2GHz, 3GB
>> RAM, Visual Studio 2005, ITK 3.16 machine.
>>
>> You may consider looking at the following tests, which use the Fast
>> Marching filter in the manner you describe:
>>    Testing/Code/Algorithms/itkCurvesLevelSetImageFilterTest.cxx
>>    Testing/Code/Algorithms/itkLevelSetNeighborhoodExtractorTest.cxx
>>
>> Please let us know if this works for you.
>>
>> Regards, Dan
>>
>> On 30 April 2010 00:23, Haiyong Xu <haiyeong at gmail.com> wrote:
>>> Hi List,
>>>
>>> I tried to use FastMarchingImageFilter with a constant speed to
>>> generate initial levelsets. It works very well in 2D but very slow in
>>> 3D. For a relative small 3D image data (60x60x60), I run the program
>>> for 3~5 minutes and there is no result. Is that intrinsic property of
>>> FastMarchingImageFilter or my mistake in programing?
>>>
>>> Below is a test program:
>>>
>>> int main( int argc, char *argv[] )
>>> {
>>>  typedef itk::Image<float, 3> ImageType;
>>>
>>>  // set up input image
>>>  ImageType::Pointer image = ImageType::New();
>>>  ImageType::RegionType region;
>>>  ImageType::IndexType index;
>>>  index[0] = index[1] = index[2] = 0;
>>>  ImageType::SizeType  size;
>>>  size[0] = 60; size[1] = 60; size[2] = 60;
>>>  region.SetIndex(index);
>>>  region.SetSize(size);
>>>  image->SetRegions(region);
>>>  image->Allocate();
>>>
>>>  // create filter and set initial point
>>>  typedef  itk::FastMarchingImageFilter< ImageType, ImageType >
>>> FastMarchingFilterType;
>>>  FastMarchingFilterType::Pointer  fastMarching = FastMarchingFilterType::New();
>>>
>>>  ImageType::IndexType  seedPosition;
>>>  seedPosition[0] = 30;  seedPosition[1] = 30; seedPosition[2] = 30;
>>>
>>>  typedef FastMarchingFilterType::NodeContainer  NodeContainer;
>>>  NodeContainer::Pointer seeds = NodeContainer::New();
>>>
>>>  FastMarchingFilterType::NodeType node;
>>>  node.SetValue( 0 );
>>>  node.SetIndex( seedPosition );
>>>  seeds->Initialize();
>>>  seeds->InsertElement( 0, node );
>>>
>>>  fastMarching->SetInput(image);
>>>  fastMarching->SetOutputSize(size);
>>>  fastMarching->SetTrialPoints(  seeds  );
>>>  fastMarching->SetSpeedConstant(1.0);
>>>  //fastMarching->SetStoppingValue(10);
>>>
>>>  fastMarching->Update();
>>>
>>>  return 0;
>>> }
>>>
>>>
>>> The program was built upon ITK 3.16 and run on Windows XP.
>>>
>>> Thanks for help.
>>>
>>> --Haiyong
>>
>