Thank you Mark that's very useful advice!
Cheers
Reem
On 21/11/2010, at 23:25, "Mark Jenkinson" <[log in to unmask]> wrote:
> Hi Reem,
>
> The -inm argument is rescaling the intensities of each image to be
> at a preset value - that is, 1000 in this case. This number is completely
> arbitrary. So if your original images had a mean intensity less than this
> then you'll see the final intensity is higher (and hence the cal_min and
> cal_max values will scale appropriately - but as we all said, you can
> ignore these values). Doing this mean scaling can be useful if the
> images do have considerably different intensity ranges, which can happen
> in MRI as the intensity range is arbitrary. So I think that including this
> argument is useful and would recommend it.
>
> All the best,
> Mark
>
>
> On 20 Nov 2010, at 21:34, Reem Jan wrote:
>
>> Thanks Andreas and Mark,
>>
>> I guess my question was whether it is recommended to normalize using the -inm argument in this case and where the 1000 value comes from?
>>
>> Cheers
>> Reem
>>
>> On 20/11/2010, at 12:36, "Andreas Bartsch" <[log in to unmask]> wrote:
>>
>>> Hi Reem,
>>>
>>> don't worry about cal min!
>>> And yes, 6 DoFs is good, assuming you are talking about intra-individual follow-up registrations without much pathology / surgery...
>>> Cheers,
>>> Andreas
>>> ________________________________
>>> Von: FSL - FMRIB's Software Library [[log in to unmask]] im Auftrag von Reem Jan [[log in to unmask]]
>>> Gesendet: Freitag, 19. November 2010 22:21
>>> An: [log in to unmask]
>>> Betreff: Re: [FSL] Flirt average query
>>>
>>> Hi Mark
>>>
>>> Thanks alot for your reply, very reassuring indeed.
>>>
>>> Another query regarding this... When using flirt_average, do you recommend normalizing the input images first (as suggested by the post I mentioned). I.e.
>>>
>>> "A thing the flirt_average script is not doing is the normalization of the single scans before averaging. This step might be useful when there is a difference in image intensities. Just change the last line of the script for example to:
>>>
>>> fslmaths $output -inm 1000 -Tmean $output"
>>>
>>> When I tried adding the "-inm 1000" argument to my flirt_average script, the cal_min value became a lot more negative (-125). I'm not sure whether I should perform this step or not?
>>>
>>> Last question is can I double check that 6 DOF is a good value for flirt in this case? I can't see reason for using 12 DOF.
>>>
>>> Thank you in advance :)
>>>
>>> Cheers
>>>
>>> Reem
>>>
>>> On 19/11/2010, at 22:36, "Mark Jenkinson" <[log in to unmask]<mailto:[log in to unmask]>> wrote:
>>>
>>> Hi Reem,
>>>
>>> The cal_min and cal_max values are really unimportant.
>>> They *only* control how the image looks in a viewer (the min and
>>> max *displayed* range). However, they have absolutely no effect
>>> on the stored intensity values. All they do is act as the initial values
>>> in the FSLView display range boxes.
>>>
>>> So therefore it is completely unimportant what they are set to.
>>> However, I would still recommend using flirt_average in general as
>>> it produces slightly sharper images due to the sinc interpolation.
>>> One downside of the sinc interpolation is the fact that it induces
>>> negative values (due to ringing) near the strong edges. This is
>>> almost certainly why the cal_min gets set to a negative value.
>>> It really isn't important what cal_min is, but that is an indication
>>> that there is some ringing in the output data. In general I would
>>> say that this was fine and worth the improved sharpness in the
>>> average, but it really is a judgement call. So have a look yourself
>>> at the output images and go with whichever one you prefer.
>>>
>>> All the best,
>>> Mark
>>>
>>>
>>> On 19 Nov 2010, at 04:27, Reem Jan wrote:
>>>
>>> Dear Mark/Steve or anyone who is happy to answer my FLIRT query J
>>>
>>> I am in the process of averaging 2 xT1-weighted structural scans per subject to use in an FSL-VBM analysis.
>>>
>>> I have searched through the archives and found a very helpful post on flirt_average (https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0803&L=FSL&P=R24790&1=FSL&9=A&J=on&d=No+Match;Match;Matches&z=4) and hence I tried using flirt_average as follows:
>>>
>>> Flirt_average 2 input_1 input_2 output_average –dof 6
>>>
>>> I noticed (using the fslinfo command) that the output_average file had a cal_min -16 and cal_max 876. When I opened the output file in fslview, these values of -16 and 876 where what I saw in the bricon min max tool bar. I compared these values to the input images which had cal_min and cal_max values of zero, however when viewed the input images in fslview I see a min value of 0 on the Bricon toolbar and a maximum value of 423.
>>>
>>> I got slightly concerned about the output (average T1) negative cal_min value (-16), so I decided to try other averaging methods to see if I get the same sort of output. I tried the following:
>>>
>>> 1. Flirt (where the reference is input_1, the input is input_2 and the output is input_2flirted) using 6 DOF
>>> 2. Fslmaths input_1 –add input_2flirted –div 2 output_average
>>>
>>> The output_average from this method had a cal_min of zero and cal_max of 838
>>>
>>> I then tried another method (I think this is what flirt_average script is based on)
>>>
>>> 1. Flirt (where reference is input_1, the input is input_2 and the output is input_2flirted) using 6 DOF
>>> 2. fslmerge –t output_merged input_1 input_2flirted
>>> 3. fslmaths output_merged –Tmean output_average
>>>
>>> The output_average from this method was exactly the same as the method above (cal_min of zero and cal_max of 838). Both these methods have resulted in a cal_min value of zero as opposed to the negative number I get from using the flirt_average command.
>>>
>>> My questions are
>>> 1. what are cal_min and cal_max values?
>>> 2. Should I not be using flirt_average because of the negative value I am getting for cal_min?
>>> 3. Is it ok that the cal_max value is almost double of that of the original input files (although the output file has been averaged)?
>>>
>>> Sorry about the long explanations and I appreciate any advice you can provide.
>>>
>>> Many thanks
>>> Reem
>>>
>>>
>>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5631 (20101118) __________
>>>
>>> The message was checked by ESET NOD32 Antivirus.
>>>
>>> http://www.eset.com
>>
|
