Closed ylep closed 1 year ago
Interestingly, the behaviour is exactly the same on the master
branch! (crash in cases 1 and 2, no crash in case 3)
It was an allocator problem: in SparseVolume::alloc()
the source volume allocator is used to reallocate a second one, but in the case of a numpy array, the data block is not owned by the volume, so the allocator type is "unallocated". In this case we have to force a new allocator. It's fixed in 5.1 and master, the example code does not crash any more (but I have not checked the correctness of the result).
Thanks a lot @denisri! I did not check the correctness of the result either, but it seems very unlikely that your fix affects the correctness, so I think we can close this issue!
Describe the bug FastMarching crashes when given a
Volume_S16
created from a NumPy array:I could not spot any difference on volume size, strides, etc. between the original volume in case 1. The
Volume_S16
data structure seems to be okay, since the volume can be written to a file without issue.FastMarching probably expects some property from the Volume, which is not fulfilled in the converted volume. I would have guessed maybe contiguity of the X axis, but the strides are the same (moreover, this crash happens on BrainVISA 5.1.1, before the recent changes by @denisri to allow arbitrary strides).
To Reproduce
Here is the output of that script in case 1:
Environment: