Hi Mark
Thanks for the heads up on the artefact issue! Since we collected some fMRI data in the same session, will this impact on that data as well (although I can't see any similar feature visually)?
Regards,
Louis.
On Fri, 11 Oct 2013 21:21:16 +0000, Mark Jenkinson <[log in to unmask]> wrote:
>Hi,
>
>I'm afraid I have bad news for you.
>The phase images that you sent me contain an artefact which is common when generating phase images incorrectly from multi-coil data. The artefact looks like an edge (bright on one side and dark on the other) that just stops abruptly. This can never be correctly unwrapped as it represents a non-physical phase (the "wrapped" phase image is not generated by wrapping an actual smooth phase image, but is a stitched together image from different coils, and the end of the edge is a place where the stitching changes). Unfortunately, I am unaware of a way of fixing this at the analysis stage. It really needs to be fixed at the acquisition or reconstruction stage. You need to use a different method of combining the coil data together to create a valid phase image in the reconstruction. There should be other options available on the scanner and you should experiment to find the one that produces good reconstructions. Unless you saved the non-reconstructed data from all the coils, this means that your only solution is to collect new data.
>
>All the best,
> Mark
>
>
>On 7 Oct 2013, at 11:30, Louis Shue <[log in to unmask]> wrote:
>
>> Hi Mark
>>
>> Thanks for the heads up on using BET. The unwrapped image looks more reasonable now.
>>
>> https://db.tt/J2bMVh5Y
>>
>> However the range of values [-14.8, 19.5] in the unwrapped image seems too small?? Is there an additional scaling necessary here?
>>
>> Regards,
>> Louis.
>>
>> On Sat, 5 Oct 2013 08:05:45 +0000, Mark Jenkinson <[log in to unmask]> wrote:
>>
>>> Hi,
>>>
>>> These images are not correct as the phase unwrapping has failed.
>>> The reason is that they are not brain extracted, and the non-brain material makes all the unwrapping massively more complicated. So if you brain extract your images to start with (apply BET to the magnitude and then use this mask with fslmaths on the phase images). then I think it should work OK. The rest of the steps seem fine.
>>>
>>> The order of the subtraction will change the sign of the unwarping direction (e.g. from +y to -y or vice versa) but you'll need to try both signs in order to determine which is correct anyway (because there are many other steps in the reconstruction and analysis pipeline that could change this sign too, so it is safer to work it out empirically based on the final results, which is what we recommend).
>>>
>>> Also note that the process here, with the unwrapping and division by the echo time difference is performing the same job as fsl_prepare_fieldmap, so you do not need to run fsl_prepare_fieldmap at all. Once you get the unwrapped phase, take the difference and divide by the echo time difference, then you have an image in radians per second that you can supply directly to the FEAT GUI or to epi_reg.
>>>
>>> All the best,
>>> Mark
>>>
>>>
>>> On 4 Oct 2013, at 10:14, Louis Shue <[log in to unmask]> wrote:
>>>
>>>> Hi Mark,
>>>>
>>>> I have carried out the steps as you suggested to unwrap the phase volumes. However the outcome does not seem correct?? Was there something wrong in the order I carried out the operations?
>>>>
>>>> magimage = 2 magnitude volumes https://db.tt/F71xTceQ
>>>> phaseimage = 2 phase volumes https://db.tt/C4ilVBfO
>>>> unwrapped = outcome from prelude https://db.tt/J2bMVh5Y
>>>>
>>>> fslmaths phaseimage -div 4096 -mul 3.14159 phaseimage_scaled
>>>> prelude -p phaseimage_scaled -a magimage -o unwrapped
>>>>
>>>> fslsplit unwrapped pindv -t (to extract the 2 separate phase volumes)
>>>> fslmaths pu0000 -sub pu0001 -div 0.00246 phasediff
>>>>
>>>> Questions:
>>>> Does it make a difference regarding the ordering of the terms in this subtraction? Also, it turns out that phasediff (and also unwrapped) is outside of [-pi, pi] after this operation, so there was an error when I next used fsl_prepare_fieldmap
>>>>
>>>> Regards,
>>>> Louis.
>>>>
>>>> On Thu, 3 Oct 2013 05:37:40 +0000, Mark Jenkinson <[log in to unmask]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>> I forgot to mention that I do actually have a separate file which contains the magnitude volumes.
>>>>>
>>>>> Ah, well that's good to know now.
>>>>>
>>>>>> For the phase images (in the file I posted), I understand now that I will need to scale them (after fslsplit into 2 separate volumes) to [-pi, pi] but can you please elaborate on what you meant by "run unwrapping"?
>>>>>
>>>>> Use prelude (this performs phase unwrapping).
>>>>>
>>>>>> By the way, in the example from FSL course (http://fsl.fmrib.ox.ac.uk/fslcourse/lectures/practicals/reg/) the phase map was rescaled to [0, 2 *pi]. Do I need to do the same here too?
>>>>>
>>>>> No, it doesn't matter if the range is -pi to +pi, or 0 to 2*pi.
>>>>>
>>>>>> Finally, when looking at the report from FEAT GUI I noticed that the steps for fieldmap-based unwarping are somewhat different from the steps used in the script epi_reg (although I do realise that epi_reg can handle only one 3D volume at a time). Is there a "preferred" approach (the fieldmap-based unwarping in FEAT vs epi_reg) since I am also trying to come up with customised scripts for our data set? Or am I missing something here?
>>>>>
>>>>> There is a little bit of extra clean-up of the fieldmap in the FEAT GUI. This tries to get rid of noisy voxel values which typically occur near the edge of the brain. It does make things a little more robust to apply this, so I would go with those steps as a general recommendation. The application of the fieldmap in the registration is then done with epi_reg after these cleaning steps.
>>>>>
>>>>> All the best,
>>>>> Mark
>>>>>
>>>>>
>>>>>
>>>>>> Thanks again for your advice.
>>>>>>
>>>>>> Regards,
>>>>>> Louis.
>>>>>>
>>>>>> On Wed, 2 Oct 2013 16:08:15 +0000, Mark Jenkinson <[log in to unmask]> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> From the images you uploaded it seems that you do have two phase images and no magnitude image.
>>>>>>> This is a problem in that you really do need a magnitude image. If you do not have one then a potential solution is to take a structural image from the same sequence (assuming there was no major movement in between) and resample this with (using your own filenames):
>>>>>>> flirt -in structural -ref fieldmap_phase -applyxfm -usesqform -out fmap_mag
>>>>>>> Check that the output (fmap_mag) looks well registered with the fieldmap_phase image (you'll have to do this by eye).
>>>>>>>
>>>>>>> For the phase images, you do have phase wraps in them, so you will need to scale each image to a range of -pi to +pi radians (divide by 4096 and multiply by 3.14159), then run unwrapping, then take the difference between the images. After this, just divide by the echo time difference of the fieldmap sequence (using units of seconds) and then you'll have a radians per second fieldmap image.
>>>>>>>
>>>>>>> Use this, in conjunction with the magnitude image above, and the brain extracted magnitude image, in the FEAT GUI as normal.
>>>>>>>
>>>>>>> All the best,
>>>>>>> Mark
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2 Oct 2013, at 14:21, "Harms, Michael" <[log in to unmask]> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> One of those volumes should be a magnitude image, and the other should be
>>>>>>>> a phase difference image.
>>>>>>>> Other than running BET on the magnitude image to create the necessary
>>>>>>>> Brain Extracted magnitude image input for fsl_prepare_fieldmap, so should
>>>>>>>> not need to do any other conversions. That is what fsl_prepare_fieldmap
>>>>>>>> is for.
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>> -MH
>>>>>>>>
>>>>>>>> --
>>>>>>>> Michael Harms, Ph.D.
>>>>>>>>
>>>>>>>> -----------------------------------------------------------
>>>>>>>> Conte Center for the Neuroscience of Mental Disorders
>>>>>>>> Washington University School of Medicine
>>>>>>>> Department of Psychiatry, Box 8134
>>>>>>>> 660 South Euclid Ave. Tel: 314-747-6173
>>>>>>>> St. Louis, MO 63110 Email: [log in to unmask]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/2/13 5:00 AM, "Louis Shue" <[log in to unmask]> wrote:
>>>>>>>>
>>>>>>>>> Dear FSL experts,
>>>>>>>>>
>>>>>>>>> We have received some new data (from a Siemens scanner) where the
>>>>>>>>> phasemap is of the following form (2 volumes, range is -4096 to +4092):
>>>>>>>>>
>>>>>>>>> https://dl.dropboxusercontent.com/u/8460189/HIN035_20130412_2819_027_fl2d_
>>>>>>>>> fieldmap.nii.gz
>>>>>>>>>
>>>>>>>>> May I know what are the steps needed to convert this to a format that can
>>>>>>>>> be used in fsl_prepare_fieldmap? It looks like I may need to use
>>>>>>>>> prelude??
>>>>>>>>>
>>>>>>>>> Thanks very much!
>>>>>>>>>
>>>>>>>>> Louis.
>>>>>>>>
>>>>>>>>
>>>>>>>> ________________________________
>>>>>>>> The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.
--
Sendmail-Host: epeire2.extra.cea.fr
Relay: cirse.extra.cea.fr [132.166.172.102]
Helo: cirse.extra.cea.fr
Envelope-From: [log in to unmask]
Queue-Id: r9E626hL001199
Date: Mon, 14 Oct 2013 06:02:06 GMT
Envelope-To: [log in to unmask]
Fur_rdns: deneb.ease.lsoft.se
Fur_helo: deneb.ease.lsoft.se
Fur: 212.247.25.55
Direction: Inbound
Mapped-Recipients: [log in to unmask]
Recipient-Group: [log in to unmask]
User-Language: fr
Virus-Id: SOPHOS_SAVI_ERROR_OLD_VIRUS_DATA
Reason: infecte_in
Global-ID: 88221525-4
Msg-Info-Size: 0x00000231
|
