Resampling of the Image Volume about nifti-rs

[nilgoyette]

Hi @liob. IMO, this function doesn't fit in nifti-rs at all because any image can be resampled, not just nifti images. It's a better fit in ndarray but I know that they will refuse. I created my own crate called ndarray-ndimage which I think is a good fit.

[Enet4]

Thank you for reaching out. I feel that that post-processing a volume in such a fashion is out of the scope of the crate, and it is better handled by other crates based on the ndarray library. While nibabel might have this out of the bat, the Rust ecosystem often favours having more packages with a certain focus over a monolithic design.

I was also about to ask @nilgoyette whether he knew what crates could be used here, but I see that we have an answer already! (Thanks!) In any case, feel free to let us know in a comment how you managed to put everything together.

[liob]

Hi @Enet4 and @nilgoyette. I have been using the python ecosystem for a long time and have ingrained the batteries-included mindset. I appreciate your insights and understand that the rust crew is rolling differently.

I have begun work on a library to add nibabel-like resampling capabilities: NIFTI-Processing-rs. @Enet4 I hope you are okay with the name similarity.

@nilgoyette: Creating general-purpose resampling capabilities to ndarray is a great idea! However, as this is my first attempt at creating a rust library (or a contribution to an existing one), I feel this is too complicated. Additionally, I think the narrow use case of strict 3D resampling and the mixing of multiple array libraries (ndarray and nalgebra) warrant a specialized implementation. I would love to discuss implementing a pure ndarray implementation for resampling n-dimensional arrays when NIFTI-Processing-rs has stabilized.

[nilgoyette]

Hi @liob I don't think the Rust crew is rolling differently :) We love to have all kinds of libraries as much as any Python programmer!

I was simply telling you that NIFTI is a "container", in the same way that jpg, bmp, png, etc. contain an image; once you load them, you got the actual pixel data which you can work with. IMO, nifti-processing is a weird name because it tells the user that you can only process a nifti image, nothing else.

This being said, of course you can contribute in any way you like. Everything I wrote are only suggestions.

[liob]

@nilgoyette I think I have miscommunicated. I am sorry for that.

By rolling differently, I meant that Python favors a more monolithic approach, while the Rust ecosystem seems to favor smaller independent crates.

Regarding the processing package: I thought using ndarray exclusively for a general-purpose resampling crate would be desirable. Mixing in nalgebra for indexing seemed weird, as the same functionality could be achieved with ndarray. However, being very new to the ecosystem, I do not know how this is typically done. Is this a common use case? Then it would make perfect sense to choose a more generic name. However, if this is quite specific for nifti-rs then it would make sense to tie the name to nifti-rs, although the functionality would not be exclusive to this library.

[nilgoyette]

Oh, ok, I see what you meant.

As for your last paragraph... I didn't understand the first time why you were talking about nalgebra and I still don't understand. I agree that we/you don't need nalgebra to write an image resampling crate based on ndarray. It would be "weird" (as you say) or maybe simply wasteful.

My crate ndarray-ndimage doesn't use nalgebra yet (and probably never) because everything can be done with ndarray, much like SciPy does everything with NumPy.