# Was itk::simple::AdaptiveHistogramEqualizationImageFilter ever multi-threaded?

**URL:** https://discourse.itk.org/t/was-itk-adaptivehistogramequalizationimagefilter-ever-multi-threaded/3424
**Category:** Engineering
**Tags:** filter, simpleitk
**Created:** [September 1, 2020, 10:13pm UTC](https://discourse.itk.org/t/was-itk-adaptivehistogramequalizationimagefilter-ever-multi-threaded/3424 "2020-09-01T22:13:14Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![gfleishman](https://discourse.itk.org/letter_avatar_proxy/v4/letter/g/b3f665/32.png) [@gfleishman](https://discourse.itk.org/u/gfleishman)
#### Post date: [September 1, 2020, 10:13pm UTC](https://discourse.itk.org/t/was-itk-adaptivehistogramequalizationimagefilter-ever-multi-threaded/3424/1 "2020-09-01T22:13:15Z")

</div>

Would like to run this filter on some real big images: ~ 8K x 10K x 2K voxels.  
Have a cluster and can multi-thread as much as necessary.  
Per: [https://itk.org/pipermail/community/2015-October/010010.html](https://itk.org/pipermail/community/2015-October/010010.html), was this filter ever multi-threaded?

Alternatively - if I wanted to run the filter on overlapping blocks of the input in separate processes, would specifying the block overlap radius equal to the filter radius guarantee the same output as if I had run on the whole image? I.e. are there any edge effects larger than the filter radius?

---

<div class="post-metadata">

### Author: ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [September 2, 2020, 1:39pm UTC](https://discourse.itk.org/t/was-itk-adaptivehistogramequalizationimagefilter-ever-multi-threaded/3424/2 "2020-09-02T13:39:10Z")

</div>

This is the commit where significant performance optimizations and multi-threading were implemented:

> <https://github.com/InsightSoftwareConsortium/ITK/commit/16ff9f92e54e9a87ef07964e83d2ca117e274354#diff-a2f8c8c379027c230796a5ed3e4b45ee>
>
> Implement the filter as a subclass of the MovingHistogramImageFilter,
> providing …more efficient updates to a histogram while moving in a
> line, and multi-threading.
> 
> There can be a significant (70x+) performance improvement with larger
> radius and multi-threading. There is reasonable scaling with
> multiple threads. However with just one thread, and a 1 radius there
> almost a 2x improvement.
> 
> The boundary condition has changed. Prior the zero flux boundary
> condition was used. Now only the image pixels are used, and the
> smaller histogram elements are uniformly weighted.
> 
> The use of a temporary float image has been remove in favor of scaling on demand.
> 
> The UseLookupTable option has been removed/deprecated.
> 
> Change-Id: Ib737905a26578878696a1da9ee10906ce9db3b45

Are you seeing anything that would indicate the current version is not multi-threaded?

> [@gfleishman](#):
>
> Alternatively - if I wanted to run the filter on overlapping blocks of the input in separate processes, would specifying the block overlap radius equal to the filter radius guarantee the same output as if I had run on the whole image? I.e. are there any edge effects larger than the filter radius?

I believe padding the blocks with the radius should address the edge artifacts from splitting the processing.

I have not tested this however, I recommend the answers to these questions are tested and verified.