Mark,
fslorient reports all of our base images RADIOLOGICAL and not mixed.
Also, all the *_struc_GM.* images report RADIOLOGICAL and not mixed.
I will definitely post what happens after the upgrade. Hope this helps.
If you need me to do this for any other of the intermediate images, let
me know.
- Bob
Mark Jenkinson wrote:
> Hi Bob,
>
> I wasn't suggesting that you should have run fslorient before.
> I was asking if you could now just run fslorient for debugging
> purposes (just to report what orientation the image is, not to
> change the image in any way). Viewing it in fslview or html
> doesn't tell you which way around the storage is - only where
> the labels are. To get at the storage orientation you need to
> use fslorient (with just the filename only - which reports the
> storage "orientation"). I'd still be grateful if you could send us
> this information as well as the outcome of the upgrade.
>
> All the best,
> Mark
>
>
> On 15 Dec 2010, at 14:45, Robert Devins wrote:
>
>
>> Mark,
>>
>> I'm using 4.1.4 built from sources to run on our Linux cluster. Sounds like an upgrade is in order - even though I've got a solution to my problem. I have pretty much been using the protocol outlined in the FSLVBM online documentation and using the associated scripts. So I'm not specifically using fslorient in any way unless that is present in the scripts. All my images are of consistent orientation at the input and output of BET and FAST, according to the html and by fslview'ing the intermediate images. Perhaps this problem will also go away with a software upgrade, I'll do that and post the results.
>>
>> - Bob
>>
>> Mark Jenkinson wrote:
>>
>>> Hi,
>>>
>>> There is certainly no random or unset internal variable with FLIRT.
>>> I have never seen this behaviour and am puzzled by it.
>>> Are you using the most recent version of FSL (4.1.6)?
>>> And if you run fslorient on the images that go into creating
>>> the template, are they all of a consistent orientation, or are
>>> they mixed?
>>>
>>> I'm glad that -usesqform works though.
>>>
>>> All the best,
>>> Mark
>>>
>>>
>>> On 14 Dec 2010, at 20:06, Robert Devins wrote:
>>>
>>>
>>>
>>>> I found out that by adding -usesqform to the FLIRT steps this problem goes away. One thing I wonder: the randomness of the flipping (when -usesqform is not used). Is it possible there is an un-initialized variable inside of FLIRT so that it picks one orientation vs another, at random, depending on the initial state of memory? Just wondering.
>>>>
>>>> In any case, this seems to be solved - thanks for the suggestion.
>>>>
>>>> Stephen Smith wrote:
>>>>
>>>>
>>>>> Hi - the first thing to tie down is whether the problem is in the FLIRT registration, or a header problem.
>>>>> Cheers.
>>>>>
>>>>>
>>>>> On 10 Dec 2010, at 19:59, Robert Devins wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I've been trying to run fslvbm, and find that some if the images in the 4D template (after the fslvbm_2_template) step are exactly flipped about the X-axis. The brain images going into that step are not flipped, and look good. Which ones are flipped seem to be kind of random, and often not repeatable. I've tried adding the -noshape option to the flirt steps, but that doesn't fix the flipping issue and makes the warping even worse (again randomly on some images). Does anybody have any thoughts or have seen this?
>>>>>>
>>>>>> Thanks - Bob Devins
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------------
>>>>> 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] <mailto:[log in to unmask]> http://www.fmrib.ox.ac.uk/~steve <http://www.fmrib.ox.ac.uk/%7Esteve>
>>>>> ---------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Bob Devins
>>>> Vermont Advanced Computing Center
>>>> Clinical Neuroscience Research Unit
>>>> University of Vermont, Burlington VT
>>>> (802)656-0141
>>>>
>>>>
>>>>
>> --
>> Bob Devins
>> Vermont Advanced Computing Center
>> Clinical Neuroscience Research Unit
>> University of Vermont, Burlington VT
>> (802)656-0141
>>
>>
--
Bob Devins
Vermont Advanced Computing Center
Clinical Neuroscience Research Unit
University of Vermont, Burlington VT
(802)656-0141
|