[Bug] Jupyter notebook kernel crashes with pyclesperanto but not pyclesperanto_prototype

[TimMonko]

Pre-requist tasks

• [x ] My device drivers are up to date.
• [x ] The troublemaking solutions did not solved my issue.

Describe the bug In a juptyer notebook, kernel crashes sporadically. Usually, the first time I write code with import pyclesperanto as cle, the kernel does not crash. However, upon re-running the same code block or after restarting the kernel, the kernel will always crash. Switching to import pyclesperanto_prototype as cle results in the kernel never crashing. I'm mostly posting this in case this can be a spot where this can start to be tracked down. I have had this occur in a few different projects over the past few weeks, and always find the fix is to fall back to the prototype, but I haven't kept track if it is particular functions or not.

To Reproduce I have no idea. I have tried to create a test notebook where this happens. With a random numpy array it never seems to happen. With image data that is the same size it sometimes happens. The most consistent time that it occurs, is when I have a napari viewer open in that kernel. This should be enough to crash the kernel, if it was consistent, but this does not do it regularly:

import numpy as np
import pyclesperanto as cle
# import pyclesperanto_prototype as cle

# Calculate the number of elements for a 5MB array with uint16 elements
num_elements = (5 * 1024 * 1024) // 2
# Create a 5MB, 2D array
array_5mb_2d = np.random.randint(
    0, 
    65536, 
    size=(1024, num_elements // 1024), 
    dtype=np.uint16
)

def background_subtraction(img, gb_sigma=1, th_sigma=10):
    gb = cle.gaussian_blur(img, sigma_x=gb_sigma, sigma_y=gb_sigma)
    th = cle.top_hat_box(gb, radius_x=th_sigma, radius_y=th_sigma)
    return th

img_bs = background_subtraction(array_5mb_2d, gb_sigma=2, th_sigma=30)

Screenshots If applicable, add screenshots to help explain your problem. Expected results, vs actuall results. Or the output error message if any.

Configuration details:

• OS: Windows 11
• Device: NVIDIA RTX 3060 12GB
• Device type: dedicated GPU

Additional context Add any other context about the problem here.

[StRigaud]

Thanks for raising the issue! I was able to reproduce on a Silicon M2 quickly.

It seems that having a napari running in the jupyter kernel while calling a pyclesperanto operation make the jupyter kernel crash. Without any napari running, I did not have any issues.

My first guess is an issue related an error in the pyclesperanto.array API in perspective of the numpy.array API. We will try to solve this quickly.

[TimMonko]

I'm glad my description was helpful enough to figure that out. I was quite tired last night when writing that out... I can confirm that this code minimally reproduces the crash. Commenting out instantiating the viewer prevents the crash as does switching to prototype.

import numpy as np
import napari
import pyclesperanto as cle
# import pyclesperanto_prototype as cle

viewer = napari.Viewer()
img = np.random.randint(0, 65536, size=(1024, 1024), dtype=np.uint16)
img_gb = cle.gaussian_blur(img, sigma_x=2, sigma_y=2)

[StRigaud]

Yes, I though at start it was due to some incompatibility between numpy memory beeing used in napari and clesperanto but simply having a napari viewer is enough for crashing the kernel, even if the data is not loaded in the viewer.

I will need to search a bit on how to solve this ... thanks for pointing this to us !

[StRigaud]

Reverting to 0.10.3 seems to solve the issue.

[TimMonko]

I just tested and 0.10.3 does not crash my kernel.

[StRigaud]

Great, I will work on fixing this in the coming days

[StRigaud]

The source of the problem was related to the introduction of the Optionnal annotation in the function definitions. I still fail to understand how it was not triggered before and how it is linked to having a napari viewer active ...

Hopefully #220 should fix this bug. I will deploy these in the next release of the package which is planned soon.

Again, thanks for pointing this !

[StRigaud]

@TimMonko updating to the 0.12.1 should fix the issues now.

Do no hesitate to reopen if needed!