Affine transformation

[nilgoyette]

We would like to contribute "affine" code to nifti-rs. A part of the code is in our private compagnie codebase and the rest is here.

I think it belongs in nifti-rs because:

• it doesn't belong in trk-io, nor in our private codebase :)
• it totally depends on NiftiHeader struct.
• some people might need it and this is where they will search first.

In fact, I consider nifti-rs to be the Rust version of NiBabel, so of course it should be in nifti-rs. What's your opinion on this?

Disclaimer: Most of the code has been ported from NiBabel. I don't know much about licensing and I don't like to care about it.

[Enet4]

That sounds quite interesting, and could narrow the gap towards other features of this library. :+1:

I consider nifti-rs to be the Rust version of NiBabel, so of course it should be in nifti-rs. What's your opinion on this?

To my understanding, NiBabel can handle a plethora of other neural imaging formats, whereas I wish to focus this library on NIfTI. We can add that logic anyway, and perhaps consider making it an opt-in or separate component if it becomes large enough to stand on its own.

Disclaimer: Most of the code has been ported from NiBabel. I don't know much about licensing and I don't like to care about it.

NiBabel is covered by the MIT license, so we can use it as long as we include their copyright + permission notices in the ported module .rs file.

[fmorency]

To my understanding, NiBabel can handle a plethora of other neural imaging formats, whereas I wish to focus this library on NIfTI. We can add that logic anyway, and perhaps consider making it an opt-in or separate component if it becomes large enough to stand on its own.

That's okay and it makes sense. Atm, we're only using NIFTI and we wrote our own library to handle TRK files 1 which are supported by the NiBabel streamline API. We don't plan to add/support other file formats in nifti-rs and will write new libraries/crates if required.

[Enet4]

Indeed, that is fair and nice. :) Feel free to send in the PRs and I'll do the usual reviewing when possible.

[nilgoyette]

I started working on this and I might have some architecture and dependency questions.

I believe that the "natural" types for transformations and affines are from nalgebra, types like Vector3, Matrix3, Matrix4 and Quaternion

• nifti-rs doesn't use nalgebra
• it uses ndarray though, but it's not a good replacement in this context. ndarray is excellent for dynamic arrays, nalgebra is perfect for static arrays.
• creating our own type is a bad idea!

So, do we take nalgebra anyway and lock all the affine stuff behind a feature?

[Enet4]

Yes, placing this behind an affine Cargo feature sounds like a reasonable approach for now. We can decide whether to make this the default later. The two array crates aren't necessarily a redundancy if they play different roles and allow us to gain access to the ecosystem's existing solutions.