I have put a script together that should undo your phase ramp problem.
The script is called fixpiramps.sh and can be downloaded from
The usage is easy, just give it the input and output image names.
Note that it will work with 3D or 4D Analyze files in either complex
form or with just the real phase part.
The phase ramp you have is very close to pi and that is a critical value
which causes my prelude code trouble, as the value of the ramp after
wrapping oscillates between +pi and -pi, making the average near zero.
Hence for this I'll need a special test in prelude which I'll put in before
the next release. Anyway, for now just run the script which will take
your data and get rid of all pi phase ramps in it, which will allow
prelude to work well.
All the best,
P.S. It should use standard FSL components, but let me know if you
have any trouble.
Jack Grinband wrote:
>Thanks so much! I really, really appreciate your help. I will try to get it fixed from this
>On Fri, 5 Dec 2003 18:20:07 +0000, Mark Jenkinson <[log in to unmask]>
>>Your problems are now clear to me.
>>What you've got is a *very* large phase ramp across your image.
>>If you display the phase image you can see this as the underlying
>>checkerboard pattern. Basically each voxel is around pi radians
>>different from its neighbours. In addition you have the normal
>>phase wrapping on a large spatial scale that you can detect by
>>eye on top of the checkerboard pattern.
>>This also explains your excessive run times as basically each
>>voxel gets put in a region all of its own and you get no benefit
>>from the region labelling which is central for prelude.
>>I did have code for removing phase ramps but unfortunately yours
>>are so large that it doesn't estimate them correctly. What I did do
>>was remove them manually in matlab with values of (3.1,3.0,4.0)
>>for the phase change per voxel in (x,y,z). After this preprocessing
>>I unwrapped using normal prelude (in 3D mode) and got a good solution.
>>You can find the resulting unwrapped image at:
>>In general I will try to fix my estimation code to make it work in
>>these extreme cases. If this works then I'll release a prelude update.
>>Otherwise it might require manual matlab fixing or maybe tweaking
>>with your MR sequence to get rid of this effect (your k-space is
>>I'll let you know how I get on.
>>All the best,