You are correct it is likely due to change in behavior of the Mask.
The code for the SimpleITK test is automatically generated from the JSON description here:
The test does use a mask image with multiple values, I would presume that the selection of the “masked” pixels would be the pixels with non-zero values. This is likely the point that has changed in the filter, ITK is not consistent with how a mask is defined or used. That is some times a mask is, maskImage != 0, while others it is makeImage==maskValue.
EDIT: This mask behavior is exactly what has changed. The “UseMaskLabel” ivar is what is controls the behavior between the two mask behaviors above. The default ITK is with m_UseMaskLable=true, but when ITK_LEGACY_REMOVE is defined the behavior is abruptly changed so that m_UseMaskLabel is removed, and the “false” behavior is used.
It looks like the change in the depreciation did not update the documentation, so the behavior is not correctly described. Still looking into it…
This was tracked down a change of behavior defined by the default “UseMaskLabel=true” to “UseMakeLabel=false” when ITK_LEGACY_REMOVE is enabled. What I find difficult is that at the same time the default value is changed, the flag which controls the behavior is also removed.
I am considering proposing a patch which for ITK_LEGACY_REMOVE keeps the UseMaskLabel to the new behavior of “false”, but doesn’t remove the flag until “ITK_FUTURE_LEGACY_REMOVE”. What do you think of that?