Add verification of close-to-bound voxel with map_coordinates - #1270
Add verification of close-to-bound voxel with map_coordinates#1270EmmaRenauld wants to merge 3 commits into
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #1270 +/- ##
==========================================
+ Coverage 72.59% 72.61% +0.01%
==========================================
Files 301 301
Lines 26283 26304 +21
Branches 3700 3703 +3
==========================================
+ Hits 19080 19100 +20
+ Misses 5651 5650 -1
- Partials 1552 1554 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
AntoineTheb
left a comment
AntoineTheb
left a comment
There was a problem hiding this comment.
See comment. I would strongly recommend we actually deal with out of bounds coordinates in the function. Otherwise, we'll redo the same logic every time we call our own map_coordinates.
| if (np.any(np.logical_or(points[0] < 0, points[0] > data.shape[0])) or | ||
| np.any(np.logical_or(points[1] < 0, points[1] > data.shape[1])) or | ||
| np.any(np.logical_or(points[2] < 0,points[2] > data.shape[2]))) : | ||
| logging.warning("Careful! You are interpolating outside of boundaries " |
There was a problem hiding this comment.
I don't like this as it deviates from the expected behavior of the function. I would instead try to match the expected behavior of map_coordinates and return a cval if the indices are actually out of bounds instead of logging a message (which may be swallowed).
In this case, we would expect "E" to return an "out-of-bounds" value that the user can choose, not what is in the nearest voxel. |
0da3d04 to
62d396f
Compare
|
Summarizing because it has been a long time since we managed this: We have an issue with 3D images (with voxels) when using interpolation with scipy. map_coordinates manages coordinates with a origin=center manner: the first voxel (coordinate [0, 0, 0]) spans from [-0.5, -0.5, -0.5] to [0.5, 0.5, 0.5]. But scipy also considers that everything between -0.5 and 0 is outside the image, and then scipy pads the outside of the image to 0 by default. Si if we want to find the image value there, we will always get 0 if default values as used. With mode='nearest': (i.e. padding the outside values to the nearest voxel that is in the volume): we're ok. So here: splitting the voxels on the limit (the half voxels all around) and using them with nearest. Other voxels are used as usual with user choices. (I also reversed changes we made in #1102, where we added mode 'nearest' everywhere). Now it's only used for voxels on the limit. |
EmmaRenauld
changed the title
AntoineTheb
left a comment
AntoineTheb
left a comment
There was a problem hiding this comment.
Sorry to hammer on this, but I think there's still a problem with this function. IMO it should behave exactly as map_coordinate should, just with voxels instead of points, but if that's outside of the scope, it should at least let the user know if coordinates are out of bounds.
| axis=0) | ||
|
|
||
| # Points correctly managed by scipy | ||
| good_points = ~limit_points |
There was a problem hiding this comment.
Unless I missed something, this will also include points that are actually outside the volume, not just at the border. These "bad" points should return a cval imo
3 participants
In PR #1102, we changed the padding to nearest. Antoine suggested to add a verification for out-of-bound values. It was not done in PR1102 to keep it simple, but was added as issue #1206. This finishes PR1102.