We're currently using the Kernel3d enum (Star and Full) as the only choices for kernels.
The advantage is that we're quite fast because we know exactly where the "weights" are. This makes it possible to hardcode the conditions. For example, we're around 5 times faster than SciPy in morphology operations.
While this is nice, the problem is that the user can't choose it's own special kernel. I have personally never seen a non-start or non-full kernel choice in the wild, but it could happen.
Ideas:
A possible idea is to add an enum choice like Other(arr). We would know when it's a special kernel and we would be able to take a special path. It creates no useless allocation. I'm not a fan of templated enum however.
Another idea is to always receive an array for the kernel. At the start of the function, we analyze it and determine if it's a Star or Full. If it is, we take the fast paths. It forces us to allocate but we could remove the enum.
In brief, I want to keep being faster than SciPy and add all kernel choices. I tested an algo that offers more choices.
// Indices for the Star kernel
let indices = vec![(0, 1, 1), (1, 0, 1), (1, 1, 0), (1, 1, 1), (1, 1, 2), (1, 2, 1), (2, 1, 1)];
// Erosion
Zip::from(mask.windows((3, 3, 3)))
.map_assign_into(zone, |w| !indices.iter().any(|&idx| !w[idx]));
// Dilation
Zip::from(mask.windows((3, 3, 3)))
.map_assign_into(zone, |w| indices.iter().any(|&idx| w[idx]));
It's not too bad. We're still a little faster than SciPy and we're accepting all kernels. I just wonder if there's a way to keep our advantages :)
nilgoyette
commented
1 year ago
We're currently using the
Kernel3denum (Star and Full) as the only choices for kernels.The advantage is that we're quite fast because we know exactly where the "weights" are. This makes it possible to hardcode the conditions. For example, we're around 5 times faster than SciPy in morphology operations.
While this is nice, the problem is that the user can't choose it's own special kernel. I have personally never seen a non-start or non-full kernel choice in the wild, but it could happen.
Ideas:
Other(arr). We would know when it's a special kernel and we would be able to take a special path. It creates no useless allocation. I'm not a fan of templated enum however.In brief, I want to keep being faster than SciPy and add all kernel choices. I tested an algo that offers more choices.
It's not too bad. We're still a little faster than SciPy and we're accepting all kernels. I just wonder if there's a way to keep our advantages :)