clEsperanto
clImages versus clBuffers
So far we are only working with OCLArrays and I'm not sure what it internally is: clBuffers or clImages.
It might be important to be able to choose. For interpolation-related filters (scaling, affine transform, image warping ...) and filters accessing local pixel neighborhood, we should be able to choose. In clij, an additional buffer-to-image-copy pays off because there is apparently hardware-optimization for accessing neigboring pixels and interpolation.
I could imagine that pyopencl has some internal magic for converting buffers to images transparent for the API user.
cl.array.Arrays use cl.Buffers. I have some logic in napari-ndtiffs that provides a numpy-to-image function and does some nice device inspection to maximize chances of compatibility depending on what the device supports (using cl.get_supported_image_formats). That was after some trial and error getting the code to pass tests on CI. I can port some of that code here if you want to have a cl.Image object to start working with.
actually that whole file has a nicely working affine transform... and tries to match the scipy.ndimage.interpolation API as closely as possible (drop in replacement). I know you have those kernels elsewhere in clij, but feel free to look through it for ideas.
That was after some trial and error getting the code to pass tests on CI.
Awesome! I struggled with the same (actually reviewer #2 struggled with it more than myself). :-) I've implemented a pretty fail-safe alternative as it tests on the GPU and disables image support in case it crashes.
I can port some of that code here if you want to have a
cl.Imageobject to start working with.
If you find time for that, that would be awesome. I would say your solution looks more sophisticated than mine.
actually that whole file has a nicely working affine transform...
Hehe, that looks pretty much like we both were inspired by gputools. I've got a buffer variant using nearest-neighbor and a image counter part with interpolation.
It's so good that we work together on this. Obviously, we spend time on doing the same things in Java and Python =-)