Hi - it looks like you named the original files C202_dti_FA (etc)
hence you will also need to name the files in the L1 subdirectory
(etc) C202_dti_FA.
Cheers.
On 31 Oct 2008, at 03:54, India Bohanna wrote:
> Hi,
>
> When I try to run the tbss_non_FA L1 script on L1 data on FSL4.1
> (tbss v1.2) I get this error:
>
> ** ERROR (nifti_image_read): failed to find header file for '../L1/
> C202_dti_FA_F
> A'
> ** ERROR: nifti_image_open(../L1/C202_dti_FA_FA): bad header info
> Error: failed to open file ../L1/C202_dti_FA_FA
> ERROR: Could not open image ../L1/C202_dti_FA_FA
> Image Exception : #22 :: Failed to read volume ../L1/
> C202_dti_FA_FA.nii.gz
> terminate called after throwing an instance of
> 'RBD_COMMON::BaseException'
> /usr/local/fsl/4.1/gnu/bin/tbss_non_FA: line 91: 24388
> Aborted $
> FSLDIR/bin/applywarp -i ../${ALTIM}/$f -o ${f}_to_target_${ALTIM} -r
> $FSLDIR/dat
> a/standard/FMRIB58_FA_1mm -w ${f}_FA_to_${best}_warp $postaffine
>
> I have named the L1 files EXACTLY as the FA images were originally
> named (e.g. C202_dti_FA.nii.gz). I have not run tbss_1_preproc or
> scaled the data since the manual says it’s not required in the new
> version. The script seems to be looking for something called L1/
> C202_dti_FA_FA?
>
> Any help would be appreciated!
>
> Thanks
> India
>
>
> On 29/10/08 10:45 AM, "Anthony Ang" <[log in to unmask]> wrote:
>
>> Hi Mark,
>>
>> invwarp took 12 min with the 2mm voxel ref image - this is indeed
>> much faster and cuts down the processing time tremendously.
>> Thank you very much!
>>
>> For ApplyXFM, I assume the transformation matrix to be Identity
>> Transformation?
>>
>> How do I check the voxel size using fslhd?
>>
>> fslhd x1000024_roi_2mmvoxel gave:
>> sizeof_hdr 348
>> data_type INT16
>> dim0 3
>> dim1 91
>> dim2 93
>> dim3 88
>> dim4 1
>> dim5 1
>> dim6 1
>> dim7 1
>> vox_units mm
>> time_units s
>> datatype 4
>> nbyper 2
>> bitpix 16
>> pixdim0 0.0000000000
>> and so on.
>>
>>
>> Thanks.
>>
>> Best regards
>> Anthony
>>
>>
>>
>>
>>
>>
>> On Tue, Oct 28, 2008 at 8:51 PM, Mark Jenkinson
>> <[log in to unmask]> wrote:
>>> Hi,
>>>
>>> OK, my turn. :)
>>>
>>> If you don't like using invwarp because it is taking a long time,
>>> then
>>> you can massively speed it up by calculating the warp at 2mm
>>> resolution
>>> rather than 1mm. To do this just make a reference image with the
>>> same
>>> (or similar) FOV to your input but with a 2mm voxel size. Then run
>>> invwarp with this as the reference, and later run applywarp as usual
>>> (with your higher resolution image as the reference). On my machine
>>> the invwarp step here took 6 *minutes*! So even at half this
>>> speed it
>>> will be quick. And the results, compared with the full results are
>>> almost identical and certainly will be good enough for warping masks
>>> between the spaces.
>>>
>>> To make the 2mm reference image you can use ApplyXFM and set
>>> the output size to be based on Voxel Dimensions. I made it have
>>> 91x93x88 voxels, each of 2x2x2mm for your data, in order to have
>>> the same FOV.
>>>
>>> All the best,
>>> Mark
>>>
>>>
>>>
>>>
>>>
>>>
>>> Jesper Andersson wrote:
>>>> Hi Antony,
>>>>
>>>>
>>>>> To clarify, I wish to register a MNI image (or more accurately a
>>>>> lobe-based
>>>>> mask e.g. temporal lobe mask) into subject space. My question is
>>>>> whether
>>>>> flirt and fnirt can be carried out with ref=subject image and
>>>>> input=MNI-image (lobe-based mask)?
>>>>>
>>>>
>>>> you can in principle do like that (with --in=MNI152_T1_2mm) and
>>>> then apply
>>>> the warps to your "lobe mask". However, you would need a different
>>>> configuration file. I recently made one for some people here, and
>>>> I am
>>>> waiting to see how well it performs. If they are happy with it
>>>> and it
>>>> works well then I'll release that configuration file as part of
>>>> the next
>>>> release.
>>>>
>>>> Until then I suggest you use invwarp.
>>>>
>>>> Good luck Jesper
>>>>
>>>>
>>>>> On Tue, Oct 28, 2008 at 5:24 PM, Steve Smith
>>>>> <[log in to unmask]> wrote:
>>>>>
>>>>>
>>>>>> Hi - in general if you are just wanting to register a subject
>>>>>> into
>>>>>> standard
>>>>>> space then no you don't need to run invwarp to generate the
>>>>>> inverse
>>>>>> warp.
>>>>>> You only need that if you _also_ want to apply the inverse warp
>>>>>> to bring
>>>>>> a
>>>>>> standard space image back into subject space.
>>>>>>
>>>>>> Cheers.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 27 Oct 2008, at 22:59, Anthony Ang wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> FSL4.1.1 was reinstalled on the computer. fnirt now takes 76
>>>>>>> min and
>>>>>>> invwarp is finally working! It takes 8.05 h.
>>>>>>> The MNI152 image is registered well to the subject image. Also
>>>>>>> fnirt
>>>>>>> -iout
>>>>>>> image is the same as applywarp output (with MNI152 image as
>>>>>>> the ref).
>>>>>>>
>>>>>>> However, I could not view (under fslview) -iout image
>>>>>>> initially. The
>>>>>>> min
>>>>>>> intensity is 3000 and max intensity is 8000. It is only after
>>>>>>> I have
>>>>>>> changed
>>>>>>> the intensity range to 0-100 that I could view the -iout
>>>>>>> image. I
>>>>>>> didn't get
>>>>>>> this output with the previous FSL version. Why is this so?
>>>>>>>
>>>>>>> Hence, the problem is indeed due to the use of Analyze rather
>>>>>>> than
>>>>>>> NIFTI
>>>>>>> output files. Mark and Jesper, thank you very much for your
>>>>>>> help!
>>>>>>>
>>>>>>> Now, I am doing:
>>>>>>> flirt (subject to MNI152 linear transform)
>>>>>>> fnirt (subject to MNI152 nonlinear transform)
>>>>>>> invwarp (MNI152 to subject)
>>>>>>> applwarp (MNI152 to subject)
>>>>>>>
>>>>>>> The question is why is the invwarp step necessary? Why can't I
>>>>>>> do the
>>>>>>> following directly?: -
>>>>>>> flirt (MNI152 to subject linear transform)
>>>>>>> fnirt (MNI152 to subject nonlinear transform) and using the --
>>>>>>> iout file
>>>>>>> directly
>>>>>>>
>>>>>>> I'm trying this out to see what's the result? Mark and Jesper,
>>>>>>> what are
>>>>>>> the reasons for doing the 4 steps instead of the 2 steps
>>>>>>> directly?
>>>>>>>
>>>>>>> Thank you very much.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Anthony
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 24, 2008 at 11:00 AM, Anthony Ang <[log in to unmask]
>>>>>>> >
>>>>>>> wrote:
>>>>>>> Hi Mark,
>>>>>>>
>>>>>>> My IT Manager said that FSL was previously installed in /usr/
>>>>>>> local. But
>>>>>>> the latest version was installed in in /usr/share
>>>>>>> Both local and share appear to point to /usr/lib. He suspect
>>>>>>> when the
>>>>>>> new
>>>>>>> version was installed, some old files may not be overwritten so
>>>>>>> although
>>>>>>> these files read as FSL4.1, they may have been older versions.
>>>>>>>
>>>>>>> He would clear this computer of all previous FSL version and
>>>>>>> reinstall
>>>>>>> FSL4.1
>>>>>>>
>>>>>>> He said that FSL was downloaded as a binary version from the
>>>>>>> German
>>>>>>> mirror
>>>>>>> site and installed as according to the instructions provided.
>>>>>>> Is it better to download the binary version or to compile from
>>>>>>> source?
>>>>>>>
>>>>>>> I have copied him into this email. Thanks.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Anthony
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 24, 2008 at 10:17 AM, Mark Jenkinson <[log in to unmask]
>>>>>>> >
>>>>>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> The use of Analyze does explain the problem on your machine,
>>>>>>> as it is
>>>>>>> incorrectly reading the warp file (being in Analyze format)
>>>>>>> and so has
>>>>>>> to
>>>>>>> do
>>>>>>> a lot more filing of blank area and correcting for problems
>>>>>>> due to
>>>>>>> poorly
>>>>>>> constrained Jacobians.
>>>>>>>
>>>>>>> The puzzling thing is that you can get Analyze output from
>>>>>>> FSL4.1 as
>>>>>>> this
>>>>>>> should not be possible. Setting my FSLOUTPUTTYPE variable to
>>>>>>> ANALYZE
>>>>>>> (which is what yours is set to) gives me an error of the form:
>>>>>>> ERROR:: Unrecognised value (ANALYZE) of environment variable
>>>>>>> FSLOUTPUTTYPE
>>>>>>> Legal values are: NIFTI, NIFTI_PAIR, NIFTI_GZ, NIFTI_PAIR_GZ
>>>>>>>
>>>>>>> If you are not getting this error it makes me think that you
>>>>>>> are not
>>>>>>> using
>>>>>>> FSL4.1. I notice that in your PATH you have both /usr/share/
>>>>>>> fsl/bin
>>>>>>> and
>>>>>>> /usr/lib/fsl.
>>>>>>> I would check what version you are really using. See what you
>>>>>>> get with
>>>>>>> "which invwarp" to see where it is finding the files.
>>>>>>>
>>>>>>> As for your supercomputer - invwarp will not be run in
>>>>>>> parallel, so it
>>>>>>> is
>>>>>>> only using one node of your system, and each node seems to be
>>>>>>> a 1.5GHz
>>>>>>> processor, which may not be so fast. Hence 10 hours, although
>>>>>>> long,
>>>>>>> doesn't
>>>>>>> seem unreasonable. However, your setup problems here (I don't
>>>>>>> know
>>>>>>> what
>>>>>>> your fslinit file is or why it is needed) also makes me wonder
>>>>>>> if you
>>>>>>> have
>>>>>>> the right version of FSL installed and are using that one.
>>>>>>>
>>>>>>> We really, really strongly recommend using NIFTI for your
>>>>>>> output format
>>>>>>> (in FSL4.1 you just cannot have ANALYZE for output) and for
>>>>>>> FNIRT it is
>>>>>>> essential. It is the warp fields - particular the coeff
>>>>>>> fields - which
>>>>>>> must use
>>>>>>> the nifti format and so you cannot use any tools that deal
>>>>>>> with these
>>>>>>> (including
>>>>>>> applywarp and invwarp) with ANALYZE. I would change your
>>>>>>> FSLOUTPUTTYPE
>>>>>>> to NIFTI_GZ, check that you are using FSL4.1 (and install it if
>>>>>>> necessary)
>>>>>>> and
>>>>>>> then try running the sequence of commands again on your
>>>>>>> machine and see
>>>>>>> if that fixes the problem.
>>>>>>>
>>>>>>> All the best,
>>>>>>> Mark
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 24 Oct 2008, at 00:00, Anthony Ang wrote:
>>>>>>>
>>>>>>> Hi Jesper,
>>>>>>>
>>>>>>> Attached is the angs_set.txt file for our lab computer. Yes, I
>>>>>>> notice
>>>>>>> that
>>>>>>> Analyze output files are produced.
>>>>>>> I also notice that the supercomputer that I used produces
>>>>>>> NIFTI files
>>>>>>> and
>>>>>>> when I compared the fnirt --iout file and Applywarp file
>>>>>>> generated by
>>>>>>> the
>>>>>>> supercomputer, they are identical.
>>>>>>>
>>>>>>> My subject images (1000024 and so on) are in Analyze format.
>>>>>>> Do I need
>>>>>>> to
>>>>>>> convert them to NIFTI in order for flirt, fnirt, invertwarp,
>>>>>>> applywarp
>>>>>>> to
>>>>>>> work correctly? Does the use of Analyze files also affect
>>>>>>> other FSL
>>>>>>> tools
>>>>>>> such as bet and fast?
>>>>>>>
>>>>>>> However, the difference in the file format still does not
>>>>>>> explain the
>>>>>>>
>>>>>>>> 10
>>>>>>>>
>>>>>>> hours taken by the supercomputer to complete invwarp.
>>>>>>> I remembered when I was using invwarp on the supercomputer, it
>>>>>>> doesn't
>>>>>>> recognize the invwarp command. A fellow colleague helped and
>>>>>>> found an
>>>>>>> fslinit file somewhere; copied and pasted one of the lines (I
>>>>>>> think it
>>>>>>> is
>>>>>>> module load fsl ....) into the terminal and execute it. Then the
>>>>>>> invwarp is
>>>>>>> working. We have no control over the supercomputer. Could this
>>>>>>> have
>>>>>>> explained the long time taken even for this supercomputer to
>>>>>>> carry out
>>>>>>> invwarp, although it uses NIFTI files?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Anthony
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Oct 23, 2008 at 8:44 PM, Jesper Andersson
>>>>>>> <[log in to unmask]>
>>>>>>> wrote:
>>>>>>> Hi again Antony,
>>>>>>>
>>>>>>> the files you sent us are in analyze format. I am not really
>>>>>>> sure how
>>>>>>> that
>>>>>>> happened. As of FSL 4.0, there shouldn't really be any
>>>>>>> (simple) way of
>>>>>>> producing analyze files as output.
>>>>>>>
>>>>>>> This also explains the problems you are having. When fnirt
>>>>>>> produce
>>>>>>> coefficient files (--cout) it uses a number of fields in the
>>>>>>> nifti
>>>>>>> header to
>>>>>>> encode various bits of information that is needed for the other
>>>>>>> applications
>>>>>>> to later decode them. Not all of those fields are present in the
>>>>>>> analyze
>>>>>>> format, and the files do not get interpreted correctly by either
>>>>>>> applywarp
>>>>>>> (which explains that mismatch) or invwarp.
>>>>>>>
>>>>>>> As a first step, could you please do
>>>>>>>
>>>>>>> set > angs_set.txt
>>>>>>>
>>>>>>> and then email us angs_set.txt?
>>>>>>>
>>>>>>> Best regards Jesper
>>>>>>>
>>>>>>>
>>>>>>> On 23 Oct 2008, at 08:19, Anthony Ang wrote:
>>>>>>>
>>>>>>> Hi Mark,
>>>>>>>
>>>>>>> The ref no is 470181
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Anthony
>>>>>>>
>>>>>>>
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: Jesper Andersson <[log in to unmask]>
>>>>>>> Date: Thu, Oct 23, 2008 at 5:38 PM
>>>>>>> Subject: Re: [FSL] Problem with invwarp
>>>>>>> To: [log in to unmask]
>>>>>>> Cc: Mark Jenkinson <[log in to unmask]>, [log in to unmask]
>>>>>>>
>>>>>>>
>>>>>>> Hi Antony,
>>>>>>>
>>>>>>>
>>>>>>>> fslroi x1000024_resize x1000024_roi 29 182 0 186 41 176
>>>>>>>> fslroi x1000024_n3ed x1000024_roi_n3ed 29 182 0 186 41 176
>>>>>>>>
>>>>>>>> flirt -v -ref MNI152_T1_2mm_brain -in x1000024_roi_n3ed -omat
>>>>>>>> flirted_x1000024_reducedFOV.mat -out
>>>>>>>> flirted_x1000024_reducedFOV.hdr
>>>>>>>>
>>>>>>>> flirt_output
>>>>>>>>
>>>>>>>> fnirt -v --in=x1000024_roi --
>>>>>>>> aff=flirted_x1000024_reducedFOV.mat
>>>>>>>> --cout=fnirted_x1000024_cout --iout=fnirted_x1000024_iout
>>>>>>>> --config=T1_2_MNI152_2mm > fnirt_output
>>>>>>>> *
>>>>>>>> applywarp -v --ref=MNI152_T1_2mm --in=x1000024_roi
>>>>>>>> --warp=fnirted_x1000024_cout --out=warped_x1000024 >
>>>>>>>> applywarp_output
>>>>>>>>
>>>>>>> the fnirted_x1000024_iout and warped_x1000024 files should
>>>>>>> definitely
>>>>>>> be
>>>>>>> identical. Could you please tar fnirted_x1000024_iout,
>>>>>>> warped_x1000024
>>>>>>> and
>>>>>>> nirted_x1000024_cout and then go to
>>>>>>>
>>>>>>> http://www.fmrib.ox.ac.uk/cgi-bin/upload.cgi
>>>>>>>
>>>>>>> and follow the instructions there to upload the file? When you
>>>>>>> have
>>>>>>> done
>>>>>>> that please email me and Mark with the six-digit code that you
>>>>>>> are
>>>>>>> given.
>>>>>>>
>>>>>>> Best regards Jesper
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <angs_set.txt>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------------
>>>>>> Stephen M. Smith, Professor of Biomedical Engineering
>>>>>> Associate Director, Oxford University FMRIB Centre
>>>>>>
>>>>>> FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
>>>>>> +44 (0) 1865 222726 (fax 222717)
>>>>>> [log in to unmask]
>>>>>> http://www.fmrib.ox.ac.uk/~steve <http://www.fmrib.ox.ac.uk/%7Esteve
>>>>>> > <http://www.fmrib.ox.ac.uk/%7Esteve>
>>>>>> ---------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>
>
> India Bohanna
> PhD candidate
> Neuroimaging Group
> Howard Florey Institute
> C/- University of Melbourne
> Victoria, Australia, 3010
>
> Telephone: +613 8344 1915
> Fax: +613 9347 0446
> Email: [log in to unmask]
>
---------------------------------------------------------------------------
Stephen M. Smith, Professor of Biomedical Engineering
Associate Director, Oxford University FMRIB Centre
FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
+44 (0) 1865 222726 (fax 222717)
[log in to unmask] http://www.fmrib.ox.ac.uk/~steve
---------------------------------------------------------------------------
|