-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Image Functions #704
Comments
Hi, thanks for tracking the discussion in a GitHub issue.
Yes, that would be very convenient. But I think it better to have this in Summary:
Summary:
The function would do the following:
Also, I imagine the code not to be portable with the new Apple Silicon architecture, where one doesn't have an NVIDIA graphic card and has mixed RAM/VRAM memory that is handled by the OS. Summary:
|
Final comment:
|
As discussed with @LucaMarconato @melonora and @josenimo, I think it would be great to extend the functionality and ease of use of spatialdata by adding a few functions. When I first started using spatialdata I ran into a few issues like napari crashing due to image size, difficult image loading and overall very laborious image handling. The functions I suggest to implement are as follows:
Image Loader for universal file formats such as JPG, PNG, TIFF, Ome-TIFF
-> from my testing skimage.imread is able to handle all 4 of these formats, maybe a simple addition to Image2DModel or another simple function that loads any image into a dask array?
Image size/available GPU memory check
-> warn the user if the image size exceeds VRAM since big images may cause napari to stutter/crash
-> @melonora suggested the vispy.gloo.gl package
A Check/hook to verify that the image has been written to zarr before opening in napari
example for cpu check
The text was updated successfully, but these errors were encountered: