ITK 4.13 changes

Hi all,

Our image registration software elastix depends on ITK. I recently updated the ITK version from ITK 4.12 to 4.13 and noticed this changed the results in some of our regression tests:

The changes look relatively small, but I would still like to know the potential source of the changes. Any ideas from the ITK developers, where to look first?

Best regards, Marius

Have you tried running a git bisect on ITK with Elastix compiled against it? That would narrow down what change in ITK is causing the algorithm difference.

Here is a copy of a script I used to track down regressing with SimpleITK against ITK, it should give you some aid it getting started in a run script to determine if the ITK repo state is good or bad:

#!/usr/bin/env bash

cd ${ITK_DIR}
rm -rf ../ITK-prefix

ninja install || exit 125 


ninja SimpleITKUnitTestDriver3 || exit 125

ctest -R BasicFilters.LabelIntensityStatisticsImageFilter || exit 1
1 Like

Hi Brad,

Thank you for your reply. At least there is not something obvious to you related to registration changes.

No, I have not tried that, but also don’t want to spend the time to go in too much detail. Going through the git log the only commits that may be related are the changes to the threader. Have you observed changes elsewhere due to these changes to the threader?

Best regards, Marius

Hi Marius,

One possible change that may have impacted the results (I do not know if this is the culprit), was an update to the Double Conversion third party library in ITK 4.13. This library is used to improve the precision of binary to decimal conversions in ITK (this is especially import for transform parameters).

In any case, I noticed that your testing fromwork is using the B-spline text file format to store its transform parameters. You may want to consider the ITK HDF5 transform file format. This format support more transform types. It also avoids issues with decimal-binary conversion.


ThreadPool is not on by default in 4.13, so I doubt that is the culprit.

Thanks for the feedback.
I was tempted enough to go for a manual bisect:

git checkout 452703bc565b8299f922ca3b5274f1cc7108a190

  • Merge topic ‘AddMultiThreadTypedef’
    merged 1-12-2017 19:13:25
    returns green tests

git checkout af81eae6c8f05333e33311db570f2b8ec3d8f30c

  • Merge topic ‘Bruker-Position-fix’
    merged 6-12-2017 0:23:32
    failed tests

So I narrowed down the culprit between 1 and 6 December 2017. Perhaps it is related to the precision changes in metaimage. Tomorrow the hunt continues.


So it was indeed this commit:

  • Merge branch ‘upstream-metaio’
    merged 4-12-2017 15:14:47

that caused the registration differences.
Since it is a harmless change I will update my regression baselines.

Thanks for the help!