Comments (6)
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 dim[0]
as the number of dimensions. And so, the library assumes it's 4D because dim[0]
is, in fact, 4. If we were to interpret trailing 1's as superfluous and not part of the real dimensions, we might run into situations where the volume was DxHxWx1
by happenstance (worse even, DxHx1x1
or Dx1x1x1
), and volume processing pipelines would then have to adapt to different dimensionalities when they were actually just expecting 4D volumes.
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 ndarray
volumes was a way to facilitate integration while mitigating this issue. Nonetheless, you can still get a slice of that 4D volume over the last dimension to make it 3D:
let mut volume = nifti_object.into_volume();
let volume = volume.get_slice(3, 0);
A note of warning though, I recall that into_ndarray
on a SliceView
is currently not implemented for efficiency.
from nifti-rs.
I agree that we shouldn't change the current behavior. Maybe some images are DxHxWx1
by design for real :) I wasn't aware of get_slice
, thank you, but if I can't call into_ndarray
on it, it's useless.
This being said, would a standard by-element constructor make sense? You already "use" one in your InMemNiftiVolume
tests. (yes, I know you don't need a constructor for the inner tests). Or any method that can mutate the dim
array. I'm just throwing ideas because I don't know what could be useful to other programers. I don't want to modify nifti-rs
just for my own precious use-case!
from nifti-rs.
but if I can't call
into_ndarray
on it, it's useless.
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 NiftiVolume
implementations. Instead, there should hopefully be an incentive to convert the volume to a more flexible type (ndarray
) and back to a volume if needed, rather than hinting towards making all manipulations in InMemNiftiVolume
-land.
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.
from nifti-rs.
So, if I read you correctly, you suggest
- "a public means to construct volumes", keeping it immutable
- volume -> ndarray (modifiable) -> volume
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.
from nifti-rs.
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 InMemNiftiVolume
.
from nifti-rs.
I think the main concern here has been addressed. Feel free to create new issues to pinpoint other matters mentioned here.
from nifti-rs.
Related Issues (20)
- Documentation Examples Do Not Compile HOT 2
- Support reading and writing of complex-valued data HOT 7
- Inverse Linear Transform on writing HOT 5
- into_img_file_gz HOT 2
- Malformed header writing when `descrip` has a different size HOT 4
- Data writing is always done in native byte order regardless of header HOT 2
- Rethink some of the header's default attribute values HOT 3
- Huge gz file HOT 5
- Automatic extension HOT 2
- ndarray 0.13 HOT 2
- Shortcut for the 10 AsPrimitive<T> HOT 8
- Tracker issue towards 1.0 -- API stability HOT 9
- Writing 4D images with a single volume
- Header fix HOT 7
- FSL intent HOT 2
- Unused dimension 0 or 1 HOT 2
- support nifti-2 files HOT 3
- IncompatibleLength HOT 3
- IntoNdArray for slice views could be more efficient
- Resampling of the Image Volume HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nifti-rs.