If this is surface data, then there is nothing that we can do
right now. One possibility is to read the data into matlab with
the FS MRIread.m, then write it out in nifti2 using some other
tool
Hi,
Thanks for your reply, and I get these dims by using nibabel, simply like this:
import nibabel as nibprint(nib.load(*.nii.gz).get_header())
then it would return header info about *.nii.gz, and dim info is included in it. I tried load and get header both from fmcpr.up.sm0.self.lh.nii.gz and fmcpr.up.sm0.fsaverage.lh.nii.gz, and only self data has this negative dim issue and cannot be read by nib.get_data(), fsaverage data has normal dim and can be read.
Besides, I tried your advice and email to nibabel mailing list, they replied to me just as what Christopher said, that is to encourage FreeSurfer to move toward writing NIfTI-2.
Best,
Bai Haohao
On Fri, Jul 28, 2017 at 1:11 AM, Douglas N Greve <greve@nmr.mgh.harvard.edu> wrote:
where are you getting those dims?
On 07/27/2017 09:24 AM, Bai Haohao wrote:
> Hi,
>
> Thanks for your reply. I tried mri_surf2surf --reshape or many other
> methods but none of them could help.
>
> Then based on your explanation, I tried *mri_convert *.nii.gz *.mgz*,
> and I could get data from mgz file, it really helps me, thank you!
>
> Besides, I am interested in the difference of dimension between
> "-surface self"*(dim: -1 1 1)* and "-surface fsaverage"*(dim: 27307 1
> 6)*, why does the dimension of "-surface fsaverage" be set like this
> but "-surface self" do not? Is it possible to set the dimension of
> "-surface self" during preprocessing to make sure every number is less
> than 32k?
>
> Best,
>
> Bai Haohao
>
>
>
> On Thu, Jul 6, 2017 at 7:07 AM, Douglas Greve
>> <mailto:Freesurfer@nmr.mgh.> <greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu >> wrote:
>
> When the nifti standard was adopted, they used a short int to
> represent the dimensions. Unfortunately, this only allows for a
> maximum dimension of 32k, which is not big enough for surfaces. So
> I hacked the FS nifti format to put a -1 as the first dim at which
> point the FS code will go to another place in the header to get
> the spatial dimensions. It is possible to reshape the spatial
> dimensions as long as the largest prime factor is less than 32k
> (see mri_surf2surf with --reshape option). Other than that, you
> might ask the nibabel people to program the same hack.
>
>
> On 6/25/17 6:48 AM, Bai Haohao wrote:
>> Hello Freesurfer experts,
>>
>> I am running my data with preproc-sess to project my func data to
>> individual anatomy file, and the command shows as below:
>>
>> preproc-sess -sf ${Sesslist} -fsd "bold" -surface self lhrh
>> -fwhm 0 -per-run -force
>>
>>
>> And the subjectname point to the subject dir that created after
>> recon-all.
>>
>> After the running completed, I try to load data from
>> fmcpr.sm0.self.lh.nii.gz with nibabel, and I get this error info:
>>
>> >>> f.get_data()
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> File
>> "/usr/lib/pymodules/python2.7/nibabel/spatialimages.py", line
>> 341, in get_data
>> return np.asanyarray(self._data)
>> File
>> "/usr/lib/python2.7/dist-packages/numpy/core/numeric. py",
>> line 512, in asanyarray
>> return array(a, dtype, copy=False, order=order, subok=True)
>> File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py",
>> line 55, in __array__
>> self._data = self._read_data()
>> File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py",
>> line 60, in _read_data
>> data = self.header.data_from_fileobj(fileobj)
>> File "/usr/lib/pymodules/python2.7/nibabel/analyze.py",
>> line 486, in data_from_fileobj
>> data = self.raw_data_from_fileobj(fileobj)
>> File "/usr/lib/pymodules/python2.7/nibabel/analyze.py",
>> line 458, in raw_data_from_fileobj
>> return array_from_file(shape, dtype, fileobj, offset)
>> File "/usr/lib/pymodules/python2.7/nibabel/volumeutils.py",
>> line 493, in array_from_file
>> raise IOError(msg)
>> IOError: Expected -1804 bytes, got 264809160 bytes from file
>> "fmcpr.vol2surf.lh.nii.gz"
>> - could the file be damaged?
>>
>>
>> Then I check the file header by nibabel, and I get this:
>>
>>
>> >>> print(f.get_header())
>> <class 'nibabel.nifti1.Nifti1Header'> object, endian='<'
>> sizeof_hdr : 348
>> data_type :
>> db_name :
>> extents : 0
>> session_error : 0
>> regular :
>> dim_info : 0
>> dim : [ 4 -1 1 1 451 1 1 1]
>> intent_p1 : 0.0
>> intent_p2 : 0.0
>> intent_p3 : 0.0
>> intent_code : none
>> datatype : float32
>> bitpix : 32
>> slice_start : 0
>> pixdim : [-1. 1. 1. 1.
>> 2.00000072 1. 1.
>> 1. ]
>> vox_offset : 352.0
>> scl_slope : 0.0
>> scl_inter : 0.0
>> slice_end : 0
>> slice_code : unknown
>> xyzt_units : 10
>> cal_max : 0.0
>> cal_min : 0.0
>> slice_duration : 0.0
>> toffset : 0.0
>> glmax : 0
>> glmin : 146790
>> descrip : FreeSurfer May 13 2013
>> aux_file :
>> qform_code : scanner
>> sform_code : scanner
>> quatern_b : -0.0115927606821
>> quatern_c : -0.996071338654
>> quatern_d : -0.0864994972944
>> qoffset_x : 73344.5546875
>> qoffset_y : -1492.14978027
>> qoffset_z : -2311.28955078
>> srow_x : [ -9.99280393e-01 2.56918129e-02 2.79041883e-02
>> 7.33445547e+04]
>> srow_y : [ 2.04970520e-02 9.84766901e-01 -1.72667429e-01
>> -1.49214978e+03]
>> srow_z : [ 3.19152586e-02 1.71971247e-01 9.84584868e-01
>> -2.31128955e+03]
>> intent_name :
>> magic : n+1
>>
>>
>>
>>
>> Note that the dim has value -1, but when I use -surface
>> fsaverage, the dim is correct(show as below):
>>
>> dim : [ 4 27307 1 6 451 1 1
>> 1]
>>
>>
>> And I read the source code, the difference between self and
>> fsaverage is appeared when running rawfunc2surf-sess, and log
>> files are attached.
>>
>> I have tried many commands to load data from
>> fmcpr.sm0.self.lh.nii.gz, such as fslview, freeview, mri_convert,
>> mri_surf2surf, ...
>>
>> and only tksurfer could read this file by -timecourse
>> fmcpr.sm0.self.lh.nii.gz.
>>
>> I want to figure out how could I fix it, and any suggestion would
>> be helpful.
>>
>> Thanks in advance,
>>
>> Bai Haohao
>>
>>
>> Version info:
>> System: ubuntu-16.04.1-server-amd64
>> Freesurfer: freesurfer-Linux-centos4_x86_64-stable-pub-v5.3.0-HCP
>> nibabel: python-nibabel 1.2.2-1
>>
>>
>>
>> _______________________________________________
>> Freesurfer mailing list
>> Freesurfer@nmr.mgh.harvard.edu
harvard.edu >
>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/ freesurfer
>> <https://mail.nmr.mgh.harvard.edu/mailman/listinfo/ >freesurfer
>
>
> _______________________________________________ > Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.
> Freesurfer mailing list
harvard.edu >
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/ freesurfer
> <https://mail.nmr.mgh.harvard.edu/mailman/listinfo/ >freesurfer
>
>
> The information in this e-mail is intended only for the person to
> whom it is
> addressed. If you believe this e-mail was sent to you in error and
> the e-mail
> contains patient information, please contact the Partners
> Compliance HelpLine at
> http://www.partners.org/complianceline
> <http://www.partners.org/complianceline > . If the e-mail was sent
> to you in error
> but does not contain patient information, please contact the
> sender and properly
> dispose of the e-mail.
>
>
>
>
> _______________________________________________ --
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/ freesurfer
Douglas N. Greve, Ph.D.
MGH-NMR Center
greve@nmr.mgh.harvard.edu
Phone Number: 617-724-2358
Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/ greve/
_______________________________________________
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