Hi Franz - Looks like it may be a windows vs. unix text file issue.
Looking at dwi_orig.mghdti.bvecs under unix, it seems that it has windows-specific carriage returns (they look like "^M" in unix). Actually, I could only see this on a darwin machine, on a centos machine I can only read the first 3 lines of the file. This was probably courtesy of excel. Can you try using dos2unix on the files or saving them in another program?
a.y
On Wed, 6 Jul 2011, Franz Liem wrote:
Hi Priti and Anastasia.
Thank you very much for your replies.
Prit, I ran you modified_bvecs. This resulted in zeros (see bvecs_out). I also tried the modified_bvecs in a tab-deliniated version. same result.
Anastasia, the original bvecs file is attached as bvecs_orig. I imported this into excel and transposed it. Since (cp $bvecfile $dwidir/dwi_orig.mghdti.bvecs) the dwi_orig.mghdti.bvecs from my first post should be an exact copy of my original input.
I then took the bvecs file provided in the tutorial data (and deleted the lines >33). This again resulted in zeros (see bvecs_tutorial_out).
I then created a file with only ones and zeros (see bvecs_onezero_western):
33 lines of 0 0 0 1 0 0 ....
This resulted in correct bvecs after ecc (see bvecs_onezero_western_out).
- I then appended .000 (see bvecs_onezero3dec_western)
0.000 0.000 0.000 1.000 0.000 0.000 ...
this resulted in the exact same bvecs after ecc (with integers - see bvecs_onezero3dec_western_out).
- I then wrote 1.100 (instead of 1.000; see bvecs_onezero3decpoint1_western). This again led to the same output (see bvecs_bvecs_onezero3decpoint1_western_out).
So in conclusion, it seems as if the flip4fsl cannot read the digits after the decimal point. Can you reproduce this error? Might this be a problem with my german-language-settings computer (mac osx 10.6.4; although, since it is a swiss-german machine the system wide setting for decimal separator is the dot )?
Thank you, Franz