-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Writing NIfTI files #19
Comments
We, at Imeka, already have the code to write a .nii or .nii.gz image and we want to contribute. It has been heavily tested (we wrote several thousands images in the last months). Of course, it's not perfect, we're not sure how to handle the scaling slope and offset, and maybe some other problems that I don't remember at the moment. |
I would be happy to receive and review your contributions! We can do this piece by piece and discuss those concerns as they appear in the code. |
I forgot to tell you, my code is totally tied to
Also, how to you manage temporary files in your tests? I usually use the
|
I am not opposed to including a crate for temporary files in tests, especially because that would be a development dependency. |
Hi, I ran across your project while trying to make my own nifti crate (which is significantly less sophisticated...) I'd like to help out with this, are there any developer docs aside from what's on the repo? |
I don't think there more docs. The project is not too big so it's easy enough to jump in and modify. We will be happy to review and merge your PRs. Is there something that you need and that nifti-rs doesn't handle? |
I'm still fiddling with it, but mostly I'm offering to help with whatever would be useful to help with writing extensions. It'll probably take me a while to make a PR since I'm very new to Rust. |
I just posted a PR that allows writing extensions. |
Feature/nifti extension writer (task 5 of issue #19)
I guess we can now check off task 5 on the list in the original. I have a question about the transpose in the writing of the files. In our use case we are now always pre-transposing our data, to cancel out the transpose in the writing process. What am I missing? I didn't think image data has any explicit notion of FORTRAN/C. |
We had a discussion about this in #9 and #10 (see also comment). According to some savvy folks that were queried on this matter, plus sample data found online, NIfTI-1 volumes are required to be in column-major order on disk. This means that anyone wishing to work with them in row-major order will need to transpose the data as it arrives, then transpose it again when writing. |
But shouldn't the transpose then be conditional on We are presently transposing first before calling write_nifti, so it comes out correct. |
The code may be under an assumption that the ndarray provided is always in C contiguous order. I cannot quite pinpoint how this is managed right now, but if it's a manual process, it should definitely become automatic. Our tests for writing various kinds of multi-dimensional arrays in tests/writer.rs seem to be doing the necessary axis inversions for the writing process to work. With that said, what we could use here is a way to ensure that the data is in F order, which we cannot do with |
We're probably talking about that line
I agree that this is strange. What is even stranger is that we tested it with C and F arrays and that it was always working properly. We're probably missing something important here. because logically it shouldn't work with F array. In fact, I've been using this code for years at my job with both C and F 3D-4D images. We never had any problem. |
In order to write these files, we need methods for:
NiftiHeader
to a file (".hdr") or writer;The text was updated successfully, but these errors were encountered: