Hi,
I agree that it probably helps to run fslreorient2std on your images first.
However, this shouldn't really affect anything that you are running, provided that the individual registrations are working (and you need to check the result of each flirt command to be sure about this). Running on images after reorienting to the standard orientation will just help make things more robust and likely to work.
As for your midtrans usage, the code provided by Sourena is pretty close but the template in the third call to midtrans should be t1 and not t2, but I don't think this would make a lot of difference (unless the FOV of t1 and t2 are massively different).
If you still have problems then email us back but we will need more details in order to help, as "inconsistent orientations was not solved" doesn't really describe what is happening, what you've tested, or what the results look like.
All the best,
Mark
On 14 Jul 2014, at 23:11, Joel Bruss <[log in to unmask]> wrote:
> Not that it should matter (much) but are your input images all oriented the same way? If you run fslhd, do they all have the same q-form/s-form orientation? If not, can you reorient them all to the same (e..g "RPI") orientation with fslswapdim/fslorient? Input orientation seems to be the issue on a lot of the mailing list questions. Just a guess though.
> On 07/14/2014 04:45 PM, Thiago Junqueira Ribeiro de Rezende wrote:
>> Hi Everybody!
>>
>> Thanks for the suggestions.
>> However, once more, the problem with inconsistent orientations was not solved.
>> I think that the problem is about the reference images or some specification in images from Philips' scanners. But, when I make the registration in VBM, the same way and the same images, the resultant images show up registered.
>> What do you think?
>>
>> All the best
|