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
>
|