Dear Freesurfers,
First thanks everyone who helped me out with reading-in .mgh data from within Python (especial thanks to Krish).
Now I wonder what actually I got ;-) and please pardon my ignorance
When I read in thickness file in I get an array of (23406, 7, 58) dimensionality, where 58 makes sense to me since we have 58 subjects.
P.S. I've got the same dimensions whenever I didn't use Krish's python binding but converted to minc and loaded using NetCDF module (in python though again, but python's numpy.ndarray dimensionality is not limited by short)
What I wonder about is that why 23406 and 7? ok - the product is equal to the surface number of vertices:23406*7=163842, so it seems that I can simply collapse those two dimensions (which one goes first?)
but why is that done so?
according to http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/MghFormat and mri.h in particular I don't see any limit on width/hight to be of short (not int) type and int (4 bytes) should be good enough to store full index. Is that due to some historical perspective? or am I just completely missing smth?
Thanks in advance for the hints!
Yaroslav,
You do indeed need to collapse the 23406 x 7 arrays into a single array. I don't remember why it is split into 7 vectors, something to do with being able to read into AFNI I think. Doug will know and will probably answer. But in any case you can collapse 23406 x 7 data into a single array.
Nick
On Tue, 2008-04-29 at 18:12 -0400, Yaroslav Halchenko wrote:
Dear Freesurfers,
First thanks everyone who helped me out with reading-in .mgh data from within Python (especial thanks to Krish).
Now I wonder what actually I got ;-) and please pardon my ignorance
When I read in thickness file in I get an array of (23406, 7, 58) dimensionality, where 58 makes sense to me since we have 58 subjects.
P.S. I've got the same dimensions whenever I didn't use Krish's python binding but converted to minc and loaded using NetCDF module (in python though again, but python's numpy.ndarray dimensionality is not limited by short)
What I wonder about is that why 23406 and 7? ok - the product is equal to the surface number of vertices:23406*7=163842, so it seems that I can simply collapse those two dimensions (which one goes first?)
but why is that done so?
according to http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/MghFormat and mri.h in particular I don't see any limit on width/hight to be of short (not int) type and int (4 bytes) should be good enough to store full index. Is that due to some historical perspective? or am I just completely missing smth?
Thanks in advance for the hints!
I think it's because of nifti. Doug is out of town, but he's the one who will be able to tell you definitively.
cheers, Bruce On Tue, 29 Apr 2008, Nick Schmansky wrote:
Yaroslav,
You do indeed need to collapse the 23406 x 7 arrays into a single array. I don't remember why it is split into 7 vectors, something to do with being able to read into AFNI I think. Doug will know and will probably answer. But in any case you can collapse 23406 x 7 data into a single array.
Nick
On Tue, 2008-04-29 at 18:12 -0400, Yaroslav Halchenko wrote:
Dear Freesurfers,
First thanks everyone who helped me out with reading-in .mgh data from within Python (especial thanks to Krish).
Now I wonder what actually I got ;-) and please pardon my ignorance
When I read in thickness file in I get an array of (23406, 7, 58) dimensionality, where 58 makes sense to me since we have 58 subjects.
P.S. I've got the same dimensions whenever I didn't use Krish's python binding but converted to minc and loaded using NetCDF module (in python though again, but python's numpy.ndarray dimensionality is not limited by short)
What I wonder about is that why 23406 and 7? ok - the product is equal to the surface number of vertices:23406*7=163842, so it seems that I can simply collapse those two dimensions (which one goes first?)
but why is that done so?
according to http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/MghFormat and mri.h in particular I don't see any limit on width/hight to be of short (not int) type and int (4 bytes) should be good enough to store full index. Is that due to some historical perspective? or am I just completely missing smth?
Thanks in advance for the hints!
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
well -- yeah... nifti is indeed has a 'short' limit on the size of a dimension but I leave it open question 'what .mgh format has to do with .nii' ;-)
Thank you guys very much for your rapid replies!
Cheers Yarik
On Tue, 29 Apr 2008, Bruce Fischl wrote:
I think it's because of nifti. Doug is out of town, but he's the one who will be able to tell you definitively.
cheers, Bruce
It has to do with being able to store it in analyze/nifti (which cannot handle more than 32k in any dimension). It is possible to prevent the reshaping.
doug
On Tue, 29 Apr 2008, Bruce Fischl wrote:
I think it's because of nifti. Doug is out of town, but he's the one who will be able to tell you definitively.
cheers, Bruce On Tue, 29 Apr 2008, Nick Schmansky wrote:
Yaroslav,
You do indeed need to collapse the 23406 x 7 arrays into a single array. I don't remember why it is split into 7 vectors, something to do with being able to read into AFNI I think. Doug will know and will probably answer. But in any case you can collapse 23406 x 7 data into a single array.
Nick
On Tue, 2008-04-29 at 18:12 -0400, Yaroslav Halchenko wrote:
Dear Freesurfers,
First thanks everyone who helped me out with reading-in .mgh data from within Python (especial thanks to Krish).
Now I wonder what actually I got ;-) and please pardon my ignorance
When I read in thickness file in I get an array of (23406, 7, 58) dimensionality, where 58 makes sense to me since we have 58 subjects.
P.S. I've got the same dimensions whenever I didn't use Krish's python binding but converted to minc and loaded using NetCDF module (in python though again, but python's numpy.ndarray dimensionality is not limited by short)
What I wonder about is that why 23406 and 7? ok - the product is equal to the surface number of vertices:23406*7=163842, so it seems that I can simply collapse those two dimensions (which one goes first?)
but why is that done so?
according to http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/MghFormat and mri.h in particular I don't see any limit on width/hight to be of short (not int) type and int (4 bytes) should be good enough to store full index. Is that due to some historical perspective? or am I just completely missing smth?
Thanks in advance for the hints!
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
freesurfer@nmr.mgh.harvard.edu
-
Bruce Fischl -
Doug Greve -
Nick Schmansky -
Yaroslav Halchenko