RGB images writer

[nilgoyette]

There's some code copy, but I don't know how to avoid it. Most types can have a slope so the standard functions respect:

 where
    ...
    A: Div<Output = A>,
    A: FromPrimitive,
    A: ScalarOperand,
    A: Sub<Output = A>
    ...

Of course, [u8; 3] can't respect those traits, so I added write_rgb_nifti, which is almost identical to write_nifti, and I try to re-use utility functions as much as possible.

Moreover, I added 2 tests where I write RGB images, but I can't read them... So, those tests only check that the code compiles I guess. We will need a RGB reader someday to fix this!

[Enet4]

Sorry for the delay, here it is. I do feel that there should be a centralized way to write any kind of volume, but we can tackle that once we also have other missing pieces (namely, reading/writing more kinds of volumes).

[Enet4]

I think this part of the function should be reiterated (either now or in a separate PR), since it does not exactly resemble the current logic employed when reading transformed data. The data::element module provides multiple linear transformation strategies for each valid element data type to prevent precision loss. In this particular code, an scl_slope of 0.5 (haven't even seen real data with this, but it's a valid one nevertheless) would turn all voxel values to 0 if we pass an ndarray of integers. We might need a bit more code than just reusing this module though, since the transformation strategies currently live in immaterial types.

[nilgoyette]

Ouch. True. I'll check if I can copy your design.

[nilgoyette]

TODO, in another PR, if you agree

• Support hdr writing
• Inverse Linear Transform

[Enet4]

Sounds good, thank you! 👍 It might be worth filing an issue for this concern, so we don't forget to fix it.