-
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
Wrong dimension #15
Comments
That is intriguing, but I'm not quite sure that we should change the current behaviour. The specification in the nifti C header file defines With that said, the current state of the plain volume API is a bit unfortunate in the sense that it's quite limited. Multidimensional array libraries usually contain a wide assortment of access and manipulation methods which we do not provide here. The push of let mut volume = nifti_object.into_volume();
let volume = volume.get_slice(3, 0); A note of warning though, I recall that |
I agree that we shouldn't change the current behavior. Maybe some images are This being said, would a standard by-element constructor make sense? You already "use" one in your |
Well, that should still work. If it doesn't, we ought to look into it. Perhaps a few tests on obtaining an ndarray out of a slice view are due. I agree that there should be a public means to construct volumes (it will be required to write NIfTI volumes from scratch). On the other hand, it might be best for the time being to keep mutating operations away from our An extended slicing API would make sense, though. We could make additional methods for delimiting certain portions of the volume (yielding non-copying views) and optimize those for efficient conversion to an ndarray. |
So, if I read you correctly, you suggest
I would go with 1) for now, because it solves my problem by adding a simple function. Is this ok with you? We can still add 2) and an "extended slicing API" later if we ever need them. |
Yes, that's a nice summary. 👍 We can already do 50% of (2), the second half is likely to depend on the construction API. Feel free to propose new constructors for |
I think the main concern here has been addressed. Feel free to create new issues to pinpoint other matters mentioned here. |
Some images that we receive are strangely defined. For example, we have an image
where
nifti-rs
thinks that it's a 4D image with dimensions[133, 133, 16, 1]
Maybe it's totally domain-related, but here at my job we consider this a 3D image! I tried fixing it myselfbut, as you know, everything in
InMemNiftiVolume
is private (as it should). We do use these 3 objects:InMemNiftiVolume
->ArrayD
->Array<D, T>
in all kinds of context, so I must fixInMemNiftiVolume
, not the others.What do you think? Should all "false" 4D images considered 3D images? If not, should
nifti-rs
offers a constructor to fix this? Or something else?The text was updated successfully, but these errors were encountered: