ShapeLabelMapFilter floating point exception


(Fijoy Vadakkumpadan) #1

Hello,

I’m getting a floating point exception at line #364 of:

crashing the application. The reason seems to be numerical precision issues in principal moments calculation, resulting in a call to std::sqrt() with a negative value. In my test specifically, the principalMoments array at that line contains {-2.2737367544323206e-13, 4.5474735088646412e-13, 2524.329986572267}.

Perhaps the filter could use a more robust algorithm? Alternatively, that crashing line needs to be further guarded with a check for negative values?

FYI, I’m using ITK version 4.10.1. Just by visually comparing the source above with the one in 4.10.1, I do see that there have been some updates to the moments calculation, but the underlying numerical calculations look similar.

Thanks,
–Fijoy


(Bradley Lowekamp) #2

I agree this is a bug.
Can you please create an issue on Github with this information?

Thanks.


(Bradley Lowekamp) #3

Please find a patch to prevent the sqrt of a negative number here:


(Fijoy Vadakkumpadan) #4

Hi Bradley,

I now have a test case that hits arithmetic exception at line 393 of that same file, which does “edet = std::pow(edet, 1.0 / ImageDimension);”. The exception occurs because edet is negative, which in turn is due to numerical instability. The std::pow() cannot handle negative bases when the exponent is fractional. Can we update the file to do a check on that line as well?

Thanks,
–Fijoy


(Bradley Lowekamp) #5

It would be really great if we can add this case into the regression testing. Can you reduce the problem down to a simple binary image with the problematic label as non-zero and share it?

Thanks,
Brad


(Fijoy Vadakkumpadan) #6

I’ll try to find some time for making a shareable test case. The images are private and complex, so can’t promise anything at the moment.


(Bradley Lowekamp) #7

Any progress and producing a small test case fo this problem?


(Fijoy Vadakkumpadan) #8

I tried but couldn’t isolate the one connected component that’s causing the issue for making a separate shareable image. My test image has a very large number of components, and I can’t share it as is because of privacy. I can confirm that the issue went away once I inserted the check to my copy of that ITK class. Do you think you can add the check without my specific test case since it needs to be there anyway given the documentation for std::pow()?


(Bradley Lowekamp) #9

Perhaps you could try looking over all the components in the image then extract the component, then run this filter on just the one component?