Patches for ITK 5.1.2

Hi folks,

The next patch (bugfix) release, ITK 5.1.2, is coming up.

Patches currently staged on the Git release branch are:

Bradley Lowekamp (4):
      COMP: Updating ITKSimpleITKFilters remote module
      BUG: Address divide by zero error in SignedMaurerDistance
      STYLE: Improve function types used in SignedMaurerDistanceMap
      BUG: Support MRC2014 mode 0 as signed 8-bit integer

Hans Johnson (1):
      BUG: itkhdf5 installed paths were incorrect with recent hdf5 versions

Lee Newberg (1):
      BUG: MinPriorityQueueElementWrapper constructor needs default constructor

Are there other patches that are missing? Patches should be critical bugfixes, improved support for compilers, and documentation fixes.

1 Like

@matt.mccormick Those are the patches that I am aware of that are needed. Thanks for the work and I’m looking forward to the tag!

1 Like

Would it be possible to still include this one with 5.1.2?

Discussed extensively at:

1 Like

I don’t see why not. Please make a PR with it to the release branch. You will probably need to rebase it on release first to avoid pulling many other commits.

Thanks @dzenanz, please check (cherry-picked from the master branch):

Glad to see the SetFixedParameters fix has just made it into the v5.1.2 ITK tag Thank you @dzenanz and @matt.mccormick ! :smiley:

@lassoan Do you think the fix can soon be included with 3D Slicer?

By the way I see that there now appear two commits, “BUG: Fix MatrixOffsetTransformBase SetFixedParameters if too few params”, at the master branch: 33e9e6b and fcb85b3. How is that possible? They contain exactly the same commit text and code changes. (I just cherry-picked the one from the master branch for the release pull request, without doing any further modification.)

Merge of release branch into master branch discarded any duplicate change sets. I don’t know whether that was done automatically, or conflicts were resolved manually.

1 Like

This is why if you anticipate a patch might need to go into the release branch it should be based on the release branch.

1 Like

OK, thanks, but isn’t is a common scenario that commits from the master branch get cherry-picked into the release?

In general I think an important bug fix may need to be committed directly at the master (in order to make the fix available quickly), as well as at the branch for the next minor release. Right?

Right! The patch is based on the release branch (e.g git checkout -b MyBugFix origin/release). The PR is first made to the master branch, reviewed and merged. Then after it is ensure the nightly dashboard is OK. Another PR can be made to the release branch.

Sometime if other style changes or more than a trivial test is added in “MyBugFix”, I’ll commit them in a second commit on the branch so that the PR for the release branch is as trivial as possible with just the first commit. ( You never know when an apparent trivial change, like to using universal initialization might trigger some compiler issue :slight_smile: )

1 Like

Yes, sure. Slicer currently uses ITK v5.1.1, and it looks there are not a lot of changes in v5.1.2. @jamesobutler you have updated Slicer’s ITK a couple of times before, would you be able to test the new ITK version and submit a pull request if if everything looks OK?


Sure. I will probably update ITK to 5.1.2 and also SimpleITK to 2.0.1. Just need to make sure I use an appropriate SimpleITKFilters tag with latest changes.

1 Like

ITK 5.1.2 update in Slicer can be tracked at

1 Like

What is the estimated release date for 5.1.2?

It has already been tagged.

1 Like

To explain further – a Git commit hash is based on the content of the files that are changed and the commit message, but also other information like the parent commit. So, we have to keep the same parent commit to keep the same hash (commit identifier).

The other release items are complete and the 5.1.2 release notes are available.