BUG: Fixed resizing for wavelet filtering (resizing was scrambling image) #346
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The resizing in
_swt3
, which is called bygetWaveletImage
to extend images to ensure image dims are multiples of 2, causes images to be scrambled, because numpy'sresize
simply adds zeros at the end of the buffer and changes the shape of the array (see here, esp. example 3).Hence for enlarging we need to use
numpy.pad
and for shrinking back we need to use slicing (see fixed code).This causes the wavelet results to be wrong for all images/ROIs with an odd dimension (actually for only odd z it might not be, because in this case the resize "accidentally" has the expected behavior).
All the above insights and the fixed code is courtesy of Jan Moltz/Fraunhofer MEVIS, who tracked this bug down.
To reproduce and test the bug/bugfix I created test data and implemented a little test, which you can find here.
If you run the python file, it will write a "test_out.csv" with the extracted features for different images and crop settings. It will also print all features which have different outcomes among the test images/settings and the max abs difference.
PS: You will see that the LoG filter also causes differences, but rather small ones. I assume this is expected since the ITK filter used probably doesn't use a fixed kernel size but tries to approximate a real gaussian filter. However, we might consider if this is behavior we want/accept for radiomics or if we would prefer perfectly reproducible feature values.