[ITK-users] Mini-pipeline filters don't obey SetNumberOfThreads()

Jim Miller millerjv at gmail.com
Thu Nov 6 07:39:13 EST 2014


That is a good point. The number of threads should be propagated down to the mini filters. This needs to be handled by the filter developers, much like properly managing the requested regions. 

We will have to think if there is a way to do this in a generic manner that may make it easier for the developer. 

In the interim, if you need to a filter that uses mini pipelines to behave like this while not restricting other filters, you might be able to tap into the start and end methods to manipulate the global number of threads as each of the filters that uses a mini pipeline executes.  

Jim

> On Nov 6, 2014, at 5:47 AM, Joël Schaerer <joel.schaerer at laposte.net> wrote:
> 
> This brings me to the second problem, which is that forcing the number of threads on mini-pipeline filters such as the NormalizeImageFilter doesn't work. That is, calling normalize_filter->SetNumberOfThreads(1) doesn't work as expected. The reason is actually pretty simple: the filter simply does not pass the information to the filters inside the mini-pipeline. I believe most other mini-pipeline filters will have the same problem.
> 
> Since the mini-pipeline filters are not accessible from outside the class, I am left with using itk::MultiThreader::SetGlobalMaximumNumberOfThreads which is of course not very satisfactory.
> 
> I don't see how to fix the problem without calling SetNumberOfThreads on each mini-pipline filter... Hopefully someone will have a better idea!


More information about the Insight-users mailing list