Hi Anna & Anne,

I finally had a bit of time to look into this some more. I think that  
you're probably right about the division with the sense factor. The  
unwarping seems a bit heavy with our data too when I don't divide by it.

Cheers,
Kristian


Quoting Anna van 't Veer <[log in to unmask]>:

> Hi Kristian,
>
> Sounds like you’ve really had a thorough look into this.
> Regarding the formula; we also came across an old file from philips  
> in which there was mention of no dividing by the sense factor, so we  
> tested with and without (.3 vs .8 effective echo spacing in our  
> case). The unwarping results did not look OK when we did not divide  
> by the sense factor, the registration looked like the compensation  
> for the distortion was too much (I remember thinking the brain  
> looked ‘squeezed’ in a sagittal view).
>
> We guess that all we can do is recommend people to run comparative  
> tests like this until we know whether the Philips field maps are  
> standardised or not.
>
> Good luck!
>
> Anna & Anne
>
>
> Dr. Anna van 't Veer
> \ Child and Family Studies
> \ Leiden Institute for Brain and Cognition (LIBC)
> \ Social and Behavioural Sciences
> \ Leiden University
>
>
>
> On 04 Aug 2017, at 18:58, Kristian Loewe <[log in to unmask]> wrote:
>
> Hi,
>
> I am also currently analyzing some Philips 3T data for the first time.
>
> The manual by Anna van 't Meer et al. was very useful to me. Thanks, Anna!
>
> I have a few remarks and questions, though (see below).
>
> 1) In my case, I received the data in DICOM format (not PAR/REC)  
> from a collaborator and converted them to NIFTI using dcm2niix (not  
> dcm2nii), which also creates descriptive json-files in addition to  
> the data in NIFTI format.
>
> One can use the json-files corresponding to each image to figure out  
> automatically which of the images is the phase and which is the  
> magnitude image (which could maybe supplement Anna's manual, section  
> 4) using
>
>  $ cat $jsonfile | grep PhilipsRescaleIntercept \
>    | awk '{print substr($2, 1, length($2)-1)}'
>
> The phase image is the one for which the above command yields a  
> non-zero rescale intercept (in my case it's -217).
>
> 2) It seems that the Philips fieldmap comes as a phase difference  
> image in Hz ranging from -0.5/deltaTE to +0.5/deltaTE. Thus, I  
> converted it to radians using
>
> fslmaths phasediff_orig.nii.gz \
>    -mul 2 -mul 3.14159 -mul 0.0023 phasediff_rad.nii.gz
>
> (using deltaTE = 0.0023). The result ranges from -pi to pi. See  
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=fsl;5a9ff5d5.1310.
> In Anna's manual, the multiplication with deltaTE is not applied.
>
> 3) Regarding the effective echo spacing, I'm not sure whether the  
> formula in Anna's manual (page 7) is correct. I got an old Philips  
> manual (from 2010) from the local MR team, which states
>
>  "Since the ETL takes care of the SENSE factor, you don't
>  need to do any further calculation to calculate an
>  effective dwell time"
>
> As a result, it seems to me that you don't have to divide by the  
> SENSE factor. In my case, I computed the effective echo spacing as
>
>  ES = (1000 * 12.499) / (434.2756 * (39 + 1)) = 0.7195
>
> 4) When analyzing Siemens data, I often used fsl_prepare_fieldmap to  
> prepare the fieldmap for subsequent use with epi_reg. I was thus  
> wondering if the FSL team would still be interested in a  
> collaboration to extend the functionality of fsl_prepare_fieldmap to  
> be able to handle Philips data too (as is mentioned on the wiki,  
> https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/FUGUE/Guide#Non-SIEMENS_data).
>
> Looking at the code in fsl_prepare_fieldmap, it seems to me that one  
> could basically use the existing Siemens routine from the "unwarp  
> phasemap" step onward after converting the Philips phase difference  
> image to radians.
>
> I decided to take a closer look at what exactly happens with Siemens  
> data when using fsl_prepare_fieldmap with one of my data sets. After  
> dicom conversion, my Siemens phase difference image ranges from  
> -4096 to 4092. This leads to the image being divided by 2 as part of  
> the sanity check in fsl_prepare_fieldmap. To convert it to radians,  
> the map is then divided by 2048, next 1 is subtracted before it is  
> multiplied by pi.
> The resulting map ranges from -2pi to 0. I wonder if this is the  
> intended range at this point. I suspect that you expect a positive  
> input range and subtract 1 to arrive at an output range of -pi to  
> pi. I don't suppose it makes much of a difference for the final  
> result anyway.
>
> Any additional input on this would be much appreciated!
>
> Cheers,
> Kristian
>
>
> On 04.08.2017 17:18, Ian Malone wrote:
>> Hello Anna,
>> Thank you, I'll give it a read.
>> Regards,
>> Ian
>> On 04/08/17 15:58, Anna wrote:
>>> Dear all,
>>>
>>> Hopefully this manual for B0 unwarping with data from a philips  
>>> scanner can be of use to you: https://osf.io/hks7x/
>>>
>>> It took us quite some time to figure it out, but the results after  
>>> correcting look good (we also ran it by Mark Jenkinson), so I'm  
>>> happy that others can now use this and maybe even improve it.  
>>> Please let me know if you have any questions or suggestions.
>>>
>>> For the specific question of shifting voxels in the wrong  
>>> direction; this may have to do with the scan you acquired, the  
>>> last part of the manual briefly touches on that.
>>>
>>> Cheers,
>>>
>>> Anna van 't Veer
>>>
>>>
>>>
>>> Op 4 aug. 2017 om 16:02 heeft Ian Malone <[log in to unmask]  
>>> <mailto:[log in to unmask]>> het volgende geschreven:
>>>
>>>> Hello,
>>>>
>>>> I re-discovered this old post about a S/I gradient in field maps  
>>>> from Philips scanners, as I'm currently looking at some Philips  
>>>> data which displays exactly the same issue. Did you ever manage  
>>>> to resolve it?
>>>>
>>>> Best wishes,
>>>> Ian
>>>>
>>>> On 09/07/12 16:32, Michael Harms wrote:
>>>>> My apologies for re-posting this one more time, but I'm really stumped.
>>>>> I would REALLY appreciate it (and would be happy to treat you to a
>>>>> beverage of your choice at the next OHBM) if someone that has
>>>>> successfully acquired and applied field map correction from a Philips
>>>>> Achieva could contact me with what they had to do.
>>>>>
>>>>> I'd be happy to then summarize whatever I learn to the broader FSL-list.
>>>>>
>>>>> thanks,
>>>>> -MH
>>>>>
>>>>> On Fri, 2012-06-29 at 11:38 -0500, Michael Harms wrote:
>>>>>> Hello FEAT users with Philips scanners,
>>>>>>
>>>>>> I would be highly appreciative if someone that has successfully applied
>>>>>> fieldmapping correction (B0 unwarping) using Philips scanner data would
>>>>>> contact me off the list so that I could pick your brain.
>>>>>>
>>>>>> We have data from a multi-site study, of which one site was a Philips
>>>>>> scanner.  I *thought* that I knew what needed to be done to apply
>>>>>> fieldmapping correction for the data from this site, but the comparison
>>>>>> in the Prestats report of "undistorted example_func to undistorted
>>>>>> fieldmap" clearly shows that we don't have something right.
>>>>>>
>>>>>> The odd thing is that the "Unwarping shift map" from the Philips site
>>>>>> data shows a spatial pattern that is completely different from what we
>>>>>> observe from 4 different Siemens sites.  Namely, it has a rather strong
>>>>>> S/I gradient, with negative voxel shifts inferiorly, and positive voxel
>>>>>> shifts superiorly.  This makes me wonder if what we collected wasn't a
>>>>>> proper fieldmap (the site collected a FFE with "B0 field map = yes" and
>>>>>> "delta TE = 2.5 ms"), but if that's the case, I'd like to know what the
>>>>>> site needs to do differently at the time of acquisition.
>>>>>>
>>>>>> Thanks in advance!
>>>>>> -MH
>>>>>>
>>>>>>