Bilateral Filter not working

Support
1

Slicer Ver 4.11 2019-12-16 on Windows

I’m unable to run Bilateral image filter in Simple filters. The progress bar does not move.

2

It’s a pretty slow filter, so you might give it time.

Or maybe there’s an error - did you check the error log?

3

There was no error message. I waited about 5-10 min and there was no progress. I’ll try to be patient. Thanks for your swift response.

4

Try on a small sample data set first, such as MRHead. Also try with latest stable and latest preview releases and let us know what you find.

5

I tried on the stable release (4.10.2) using sample MRHead data. The filter successfully ran and completed in 10 min 27s. But the preview release (4.11.0 2020-01-08) seems stuck at 0% even after 5 min for the sample MRHead data.

6

Could you try a preview release from a few weeks ago (before ITK version update). You can specify “offset” parameter to get access to earlier releases, for example: https://download.slicer.org/?offset=-20

7

I’ve tried with latest preview (ITK v5.1rc01) and latest stable (ITK v4.13.1) and found that the new version was a little bit faster (completed in 272s instead of 283s) but progress was not reported (stuck at 0% the whole time).

Progress reporting is mostly broken for other filters, too. Filters that complete quickly (e.g., MedianImageFilter with 3x3x3 kernel) the progress is stuck for 1-2 seconds at 0% and after that sometimes you see a quick filling up of the progress bar within a second. For filters that take longer time (e.g., MedianImageFilter with 5x5x5 kernel) we don’t see any progress (it is stuck at 0%) and then the operation is completed. Median computation is much faster with ITK5 though (with 5x5x5 kernel it takes 5s instead of 30s).

@blowekamp @thewtex Is progress reporting known to be changed/broken in ITK or SimpleITK? Or maybe this only happens in Slicer? Maybe it’s due to the new threading infrastructure?

It is interesting that for interactive use cases correct progress reporting seems to be more important than small speed improvements (users perception is that the filter is faster if they can see that the operation is making progress).

8

@lassoan Yes the progress reporting was dramatically changed in ITKv5 as a result of the multi-threading refactoring. The basic filters ( the ones that don’t have a mini-pipeline internally ) only reports progress when the a thread is completely done. That is basically at the completion for many filters which don’t have additional step in their process.

9

Wow, this is a significant regression. If the performance improvement is marginal (such as in case of bilateral filter’s 272sec vs 283sec - 5% faster) then probably many people would prefer the old behavior (slightly slower but with consistent progress reporting) for interactive use. I’ve start a discussion on this on the ITK forum (No progress reporting in ITK5 - Engineering - ITK).

1 Like
10

No intermediate progress reporting should occur only for single-threaded case. For multi-threaded case, there should be at least a few progress updates, one for each work unit finishing in the calling thread. Less for default PoolMultiThreader, more for TBBMultiThreader. The code for invoking progress updates is here, most updates should occur from these few lines:


Edit: low hanging fruit is to use TBBMultiThreader in Slicer, as Slicer already has it in its super-build. It uses many more work units by default, so progress should be reported more frequently.

1 Like
11

For a good user experience, progress reporting is needed for any computation that may take longer than a few seconds, regardless of how it is implemented internally. Let’s discuss this on the ITK forum.

Thank you, I’ll try this now and report back.

12

I was stating what should be happening given the current state of library code. Point being that there should be some progress reporting by default.

Of course, progress reporting is desirable regardless of threading.

(I accidentally edited my original post instead of quoting it here).

1 Like
13

I’ve tried ITK with TBB threading and indeed progress reporting is more granular:

  • Bilateral: 17% (after 30sec), 37%, 64%, 80%, 83%, 86%, 89%, 90%, 91%, …
  • Median: 21%, 34%, 45%, 50%, 61%, 66%, 71%, …

TBB seems to have start with large work units (first report arrives at about 20% completion) and gradually reducing their sizes (near the end, progress is reported at about every 0.1%). Unfortunately, granularity at the initial stages is too low.

@dzenanz I’m looking forward to your improvements in ITK that you’ve mentioned in the ITK topic. Let us know if there is anything we can test.

1 Like
14

You should probably make TBB the default in Slicer’s build of ITK, because it has better load balancing for unevenly complex work distribution, and plays better with non-ITK load on the CPU. Our Pool implementation is the default purely due to build convenience (no further dependencies required).

1 Like
15

OK, I’ll enable TBB for ITK builds in Slicer after Windows factory machine is restored.

Interestingly, switching to TBB also seems to dramaetically improve performance of some filters. For example, bilateral filtering processing time is decreased from 280s to 150s. It sounds almost too good, but we can do more tests once Slicer is updated.

1 Like