[ITK] ProgressReporter and Multi-Threading

[Wood, Tobias]

Hello again,


For posterity, and in case anyone else has similar problems, I ended up using itkSliceBySliceImageFilter as an example, and created a subclass of my filter that processes 1 slice at a time. Now I can get progress reports after each slice, so the user has an idea what is happening. Some process faster than others depending on the mask, but at least there is *some* kind of feedback.


Many thanks,

Toby


________________________________
From: Community <community-bounces at itk.org> on behalf of Wood, Tobias <tobias.wood at kcl.ac.uk>
Sent: 15 June 2015 16:18
To: Bradley Lowekamp
Cc: community at itk.org
Subject: Re: [ITK] ProgressReporter and Multi-Threading


Hello Brad,


Thanks for the input. After monitoring EndEvent and a bit more debugging, I think the problem is that this filter can have a mask set, which skips pixels, and unmasked pixels can take several seconds to process. Perhaps unsurprisingly, the unmasked region tends to be in the centre of the image. I assume that each thread gets a contiguous region to process, and that thread 0 is given one of the corner regions to process? If so the way I have implemented things I think thread 0 is likely to get a region that contains no or few pixels to process, while other threads get the heavy work to do. I don't want to add anything complicated, so I will have to think about what user feedback to provide.


If you are interested, the filter in question is at https://github.com/spinicist/QUIT/blob/master/Source/Filters/ApplyAlgorithmFilter.hxx. I apologise in advance as this code would not meet the ITK style guide! The actual "algorithm" definitions are in the main files in the /Source directory. This isn't an image registration project, but I have found the ITK framework extremely useful regardless.


Best wishes,

Toby


________________________________
From: Bradley Lowekamp <blowekamp at mail.nih.gov>
Sent: 15 June 2015 13:51
To: Wood, Tobias
Cc: community at itk.org
Subject: Re: [ITK] ProgressReporter and Multi-Threading

Hello,

There are lots of reasons this could occur.

1) You are correct that it could be because you algorithms is horribly unbalanced and not making even use of the threads. I don't know your filter.
2) Your filter could be completed, then your program is doing something else. Observe other events such EndEvent to know when all threads in the filter have completed.
3) This ITK approach is generally reasonably accurate, and more complicated thread locking methods are generally not worth the trouble or performance penalty.

I suspect there is a problem with your algorithm or how you are using the progress reporter.

HTH,
Brad

On Jun 15, 2015, at 5:15 AM, Wood, Tobias <tobias.wood at kcl.ac.uk<mailto:tobias.wood at kcl.ac.uk>> wrote:

Hello,

I am using ITK 4.7.2. I added a ProgressReporter to the ThreadedGenerateData() method of a filter I am writing, with the following definition:


ProgressReporter progress(this, threadId, region.GetNumberOfPixels(), 10);


as per the documentation here: http://www.itk.org/Doxygen/html/classitk_1_1ProgressReporter.html. I then added a simple itk::Command subclass to print progress in percent.


However, when I run the program, the progress quite quickly reaches 100%, then no further ProgressEvents are raised. The program continues to execute and does finish eventually. After looking at the code for ProgressReporter, I assume this is because thread 0 somehow out-competes the other threads and finishes its processing quite fast. The other threads then continue to run peacefully, but they don't touch the Progress counter.


Is there a way to get a more accurate Progress report with multi-threading? Am I missing something?


Thanks in advance,

Toby



_______________________________________________
Community mailing list
Community at itk.org<mailto:Community at itk.org>
http://public.kitware.com/mailman/listinfo/community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20150617/4c3fe875/attachment.html>