PERF: Remove unnecessary computations and parallelize function.

[ntustison]

H/t to @NitramNimod and @chrisadamsonmcri for pointing out the computational bottleneck that precipitated this contribution. Further discussion is here.

Two improvements:

1. Eliminate unnecessary calls to UpdatePointSet()
2. Multi-thread UpdatePointSet() (Now called ThreadedGenerateDataForUpdatePointSetValues()).

For single-level approximation, no calls to UpdatePointSet are needed. This effects well-used code (e.g., N4 bias field correction) so I want to be cautious in submitting but the computational improvements should be relatively significant. For @thewtex , this would affect your B-spline image gradient module so please take a look if you have time.

PR Checklist

• No API changes were made (or the changes have been approved)
• No major design changes were made (or the changes have been approved)
• Added test (or behavior not changed)
• Updated API documentation (or API not changed)
• Added license to new files (if any)
• Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
• Added ITK examples for all new major features (if any)

[dzenanz]

LGTM, but someone else should review too.

[ntustison]

Thanks @dzenanz . And, yes, definitely want to be cautious with merging this.

[blowekamp]

I need more time to look into the code but I also see that "m_OutputPointData" has been removed and the Update method is modifying the input. Does this filter effectively only run "InPlace" now? That seems like a potentially unexpected change in behavior. Additionally, I'd expect a flag for that option similar to the InPlaceImageFilter.

[ntustison]

Hey @blowekamp , thanks for looking. Nice catch. Let me point out that this is a PointSetToImageFilter so the output is an image, not a point set. The contents of the point set, m_OutputPointData, were never returned to the user. Although I'm not sure, I believe this was due to a misunderstanding on my part when I originally wrote the code back in 2005 as someone who had been familiar with ITK less than a year. I lean towards removing it because there's no need for that variable and I think it hinders code readability. Also, actually computing its contents constitutes the unnecessary computations portion of the old code that this contribution is meant to address.

[ntustison]

Also, @blowekamp , your observation about overwriting the input data points to an important issue that should also be discussed. Both the current and proposed filter alter the input but only for the case of multiple fitting levels (so N4 and B-spline SyN image registration use cases do not apply). For multiple fitting levels, at the end of the filter processing, m_InputImageData will contain the residuals (i.e., difference between the input point set values and their B-spline approximation). Whether it was newbie ignorance, deviation from the original design intent of the filter, poor design choices, or some sort of combination, I certainly wouldn't design the filter this way today. Rather, I would copy the input point values to a different filter variable, e.g., m_ResidualPointSetValues, for use with multi-level fitting and leave the input alone. But that would change the behavior of the current filter, albeit in relatively less-frequent circumstances. As the filter is written now, it should be exactly equivalent, in terms of input and output, to the proposed changes.

[hjmjohnson]

@ntustison I think that we could classify overwriting the input as a longstanding "bug" and fix that as a separate patch. That's just my opinion.

[dzenanz]

Brad, could you merge this when happy with it? Otherwise provide more feedback.

[ntustison]

Thanks @hjmjohnson . Sounds good to me.