[grlee77]

closes #335

This PR adds a function for segmentation based on active-contours. Test cases are directly from scikit-image, but the code itself was heavily refactored to make extensive use of kernel fusion via cupy.fuse(). I will add benchmark results here soon.

It should be reviewed after #318 is merged. The new commits only start from 502f41a

[grlee77]

This shows a huge speedup relative to scikit-image as image size increases (>200x):

shape	Duration (CPU)	Duration (GPU)	Acceleration
(256, 256)	0.679 +/- 0.014	0.209 +/- 0.005	3.251
(512, 512)	3.196 +/- 0.014	0.208 +/- 0.002	15.397
(1024, 1024)	14.350 +/- 0.000	0.206 +/- 0.001	69.603
(2048, 2048)	68.054 +/- 0.000	0.426 +/- 0.000	159.710
(3072, 3072)	199.156 +/- 0.000	0.874 +/- 0.000	227.748

benchmark script

import cupy as cp
import matplotlib.pyplot as plt
from cupyx.profiler import benchmark
from skimage import data, segmentation

from cucim.skimage import img_as_float
from cucim.skimage.segmentation import chan_vese


_image = img_as_float(cp.array(data.camera()))

print("shape | Duration (CPU) | Duration (GPU) | Acceleration")
print("------|----------------|----------------|-------------")
for n in [0.5, 1, 2, 4, 6]:
    if n == 0.5:
        image = _image[128:-128, 128:-128]
    else:
        image = cp.tile(_image, (n, n))
    image_cpu = cp.asnumpy(image)
    kwargs = dict(mu=0.25, lambda1=1, lambda2=1, tol=1e-3, max_num_iter=200, dt=0.5, init_level_set="checkerboard", extended_output=True)
    perf_cpu = benchmark(segmentation.chan_vese, (image_cpu, ), kwargs=kwargs, n_warmup=0, n_repeat=10, max_duration=5)
    t_cpu = perf_cpu.gpu_times
    perf_gpu = benchmark(chan_vese, (image, ), kwargs=kwargs, n_warmup=4, n_repeat=100, max_duration=5)
    t_gpu = perf_gpu.gpu_times
    print(f"{image.shape} | {t_cpu.mean():0.3f} +/- {t_cpu.std():0.3f} | {t_gpu.mean():0.3f} +/- {t_gpu.std():0.3f} | {t_cpu.mean() / t_gpu.mean():0.3f}")

[jakirkham]

@grlee77, could you please take a look at the conflict here? Think it may be related to PR ( #318 )

[grlee77]

fixed the conflict

[jakirkham]

Thanks Greg! 🙏

Had a few comments below

[jakirkham]

Given the slicing done below. Wonder if pading could be avoided by doing different slicing on the original image

[grlee77]

I'm not sure. Aside from the border it seems like it should be. Maybe we could do all but the border without padding and then handle the border explicitly. I did manage to reduce it from the upstream implementation where some of the same slices are taken multiple times.

General slicing within a CuPy fused kernel is not supported, but passing in the sliced arrays as done here works fine.

[jakirkham]

Yeah this is what I'm wondering. Maybe we can revisit after the release ( #372 ).

[jakirkham]

Similar question to above about whether pad can be avoided by using different slicing below

[jakirkham]

@gpucibot merge

[jakirkham]

Thanks Greg! 🙏