New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Divison by zero? #359
Comments
If this case does contain a valid segmentation, could you share an anonymized copy so we can debug? |
I will check the segmentation again, and come back to you. (And for sure you are right) |
@aydindemircioglu There already is some checking of validity of the mask prior to feature calculation. Moreover, the division by 0 is just causing a warning, not a crash. The error you get is a format error, in that ITK is unable to format the warning message and therefore throws an error. I will look into this further... |
strange, i had to reinstall my linux OS on one of my computers, there, with python 3.5, i dont get the above error message but just "invalid value encountered in double_scalars". the mask itself it pretty large, around 13000 voxels, and from very first sight (non-radiologist and 8bit compressed image) i'm sure that there is contrast there. its also not loosely connected, as i explicitly throw out everything except for the largest region (using "all-direction" connecteness). will try to understand what happens there. |
@JoostJM
i also have a warning like Calculating Local Binary Pattern in 2D, but extracting features in 3D. Use with caution! on the command line (but i cant see it in the log file)-- i made sure to have trimesh, scipy |
mmh, this seems actually to happen much often than i thought-- i did not see it because to fix my loop i just did check if s_i == 0 if so, i return 0. maybe our images from this study have too low contrast for ngtdm to work? |
@aydindemircioglu, not necessarily, what kind of values do you get for originial_firstorder_range The problem is that for texture calculation, you need to discretize your gray values. This is controlled by the |
As to the warning "Calculating Local Binary Pattern in 2D, but extracting features in 3D. Use with caution!" that is due to the fact that PyRadiomics implements a local binary pattern filter for 2D and 3D separately (different calculation, see documentation). This warning is displayed when your extraction method (2D or 3D) does not comply with the chosen filter. Because you have both filters enabled, it gives the warning for the LBP2D filter (as your features are extracted in 3D). |
thanks for all the input. the range over all images is like this:
i just tried binWidth=5, but that doesnt help with the problem, i actually get then some other division by zero errors in other features. i also wanted to use binWidth=1, but then i guess this does not make much sense, and the matrices get quite large. so for now i just skip ntgdm, i will check if i can send you an image so you can see the problem first hand. |
@aydindemircioglu I think I discovered the error, take a look at this line from your output:
|
Hi @JoostJM , as you said , I specifed the parameter " LBP3D" in my parameter file like this: imageType: LBP3D: binWidth: 1.0 then I run it and I get this error: |
@QiChen2014, This is a bug, I'm fixing it in #364. |
i wont be able to test until next week, just in case you wonder. |
i am really sorry, but i have to defer testing to mid may :S |
ok, i took me only two month to get back to the topic :D (sorry again) this is now a completely different data set, but i have the very same problem. i followed your advise, @JoostJM, and did apply the binwidth like this:
but it did not help. also when i completely turn off the LBP computations
the error is still there.tried also with a binwidth of 0.5, 0.1 and 0.01 same thing. masks, as far as i can see them, are not constant or empty. disabling NGMT directly helps, as said. |
@aydindemircioglu Can you share your log? that really helps tracking issues like this down |
Also, can you share the results if you run only extracting firstorder Range (with all your intended filters enabled)? What kind of values do you see? |
here are the debug loggings:
i call pyradiomics with these lines (here with lbp-2d, but as said, does not seem to matter)
i relly wonder what i am doing wrong, as seemingly no one else is experiencing the problem. i will retest it on another computer to make sure i can reproduce this. |
regarding the range, i have several series (km, dce, darkfluid whatever), e.g. with darkfluid and a random image (it does not seem to depend on the image, i added a shuffle, so each time it is another image) i get 'original_firstorder_Range', 343.0 |
@aydindemircioglu, that range is a lot smaller than the range of your average CT (on which the default bin width of 25 is based). You can see this reflected in your log, with generally less than 10 bins calculated. Additionally, it is certainly too large for the LBP filter, so maybe use a custom even smaller binWidth there. I suggest trying:
Finally, as to the error you're getting, that is a bug in (Simple)ITK, not in PyRadiomics. In your older installation with python 3.5, your installed SimpleITK did not have that bug, and correctly formatted the warning it is trying to give ("invalid value encountered in double_scalars", which happens in case of a division by 0) |
thanks for all quick answer.
|
ok, adding normaliziation seems to fix the error (at least on first sight)-- and i dont' need to make binwidth smaller. though i wonder whether the default binwidth 25 is a good default choice when normalization is turned on? or should i change it to 2.5? what is also not clear to me is whether normalization is a good thing to do, do you have experience on this? usually i'd (obviously) normalize everything in sight, but am not sure if in the radiomics domain the absolut values might carry some important information? or to put the question into better words: why normalization is not turned on by default? |
@aydindemircioglu Which version of SimpleITK do you have installed? (you can find this out by running As to normalization, it is disabled as it is not always necessary and we want to prevent users from accidentally leaving it on when they don't intend to (i.e. when it's turned on, the user explicitly configured it). |
thanks for the infos on normalization, as a non-medical guy with not-so-much experience in medical imaging its very helpful to get hints from your experience. i will keep normalization then. i had used the latest version 1.1.0 i think, i downgraded to 1.0.0, but the warning is still there. but i am confused, i added some verbose pritnting into ntgdm to see whats happening, and the denominator was zero, if i recall correctly. i will look at it again, to understand whether normalization has fixed the problem or not. will report probably tomorrow. |
I tried to reproduce the issue on mac. Testing with python 3.6.1 and SimpleITK 1.0.1 (seems to be the latest), I am unable to reproduce. If I add division by zero to the feature calculation function, I get the below, as expected, using
The error message @aydindemircioglu reported
does not make sense to me - the I wonder if something got messed up in the python package installation. Can you try installing a fresh python via pyenv, installing pyradiomics from scratch and see if you can reproduce? Also please let us know the answers to the following:
|
thanks andrey for looking into the matter. first, i today again started to compute features, and when i disable ngtdm everything works without problems, had binWidth=0.05 and normalization turned on. this is now on another machine, but as i myself did the installation too, its "correlated" to my other machine. i could go ahead and reproduce in an clean virtualenv, but only on extrarequest, as i have to learn virtualevn first and i dont think it is related to the package installations. on this machine here i have python 3.6.5 and SimpleITK 1.0.1-- the latest is 1.1.0 (and i just installed it here too :D) and i usually have a recent pyradiomics working (master from monday on the other machine, here pip tells me pyradiomics==1.3.0.post69+gdffb440) when i enable ngtdm, then the error occurs as written. i also suspect it has something to do with the contrast and range of the image, so i'd also believe that with 'finetuning' the binwidth i could probably get around the problem. but for me now disabling ngtdm is a much faster workaround. second, to test where the error stems from, i now did two things: a) write out the contrast (the two denorminators) in the code and b) just plainly divide by zero, as you said. the first thing i already tested when opening the issue, and i get the same thing:
so it really seems that Ngp is 1 and as this should be the number of graylevels, i seem to have there an image+mask that becomes zero after binning (at 0.05). ok, now, if insert a plain
but if i use
so maybe this is why SimpleITK comes into play? am not any kind of expert on python classes in general or SimpleITK in special. but i'd doubt that the error stems from anywhere else than an denominator that becomes in my case zero, because of some contrast/binning issues. |
i'm closing the issue now, as the problem is really with the number of bincounts, it seems. |
I get a strange message, when enabling all features and image types:
File "/usr/local/lib/python3.6/dist-packages/radiomics/base.py", line 162, in calculateFeatures
self.featureValues[feature] = getattr(self, 'get%sFeatureValue' % feature)()
File "/usr/local/lib/python3.6/dist-packages/radiomics/ngtdm.py", line 238, in getContrastFeatureValue
contrast = (numpy.sum(p_i[:, None] * p_i[None, :] * (i[:, None] - i[None, :]) ** 2) / (Ngp * (Ngp - 1))) *
File "/usr/lib/python3.6/warnings.py", line 101, in _showwarnmsg
_showwarnmsg_impl(msg)
File "/usr/lib/python3.6/warnings.py", line 28, in _showwarnmsg_impl
text = _formatwarnmsg(msg)
File "/usr/lib/python3.6/warnings.py", line 116, in _formatwarnmsg
msg.filename, msg.lineno, line=msg.line)
TypeError: itkFormatWarning() got an unexpected keyword argument 'line'
Inspecting the line, it seems that the error occurs if the divisor, D = (numpy.sum(s_i)) / Nvp, is zero.
There is no check for this there, and probably one should be added.
(Again thanks for the great package :D)
The text was updated successfully, but these errors were encountered: