Closed psobolewskiPhD closed 2 years ago
Cześć, Dr. Sobolewski. You are right, there is an issue, and I am not sure what is going on. I will investigate now. Thank you for reporting this.
ok. I think I found part of the problem. The PSF associated with CElegans data has the same size (shape) as the data itself. The Redlionfish can handle large data by blocking data but not the PSF. This is some limitation that I couldn't overcome with PyOpenCL. The error occurs when is trying to divide the data into blocks, using the shape of the PSF as reference, but that code is giving negative shape dimensions for the block. I will fix this error.
Please note also that, using such large PSF it will not be possible to use the GPU, because of the PyOpenCL limitation. It will revert to CPU calculation only.
I strongly advise to crop the psf to a much smaller size. In fact, just looking at it in napari, it is mostly empty volume except the centre 'dot'.
Thanks for the sanity check. I hadn't realized the shape being the same. Makes sense to use the psf shape for block shape. Perhaps it would be possible to trigger a warning regarding the PSF size and suggesting the user crop?
BTW I'm looking forward to trying your library programmatically, as I've played around with some OpenCL decon in python. No idea when I'll get time though! 😭
Bug fixed in LMAP branch. Will run a few more tests and then merge to main().
Using the napari plugin and the C. elegans test images from @bnorthan here: https://www.dropbox.com/sh/owh83l3isipv3xy/AABx_qZ69uLU5jnbNw1gVkx-a?dl=0 I get a divide by zero error:
For the record, the bars example data at the same link works fine and uses 100% GPU on my MacBookPro Apple M1 on macOS 12 Monterey. Interestingly, for this toy data using CPU is faster, but I don't see high CPU load ~70%.