Hello everyone,

I've analyzed my polar retinotopy data (2 runs with clockwise and counterclockwise wedge rotations) using FsFast. To better understand the analysis, I'd be very grateful if you could help me with the following questions:

1. I understand that freesurfer assumes that the rotating wedge starts at 12 o'clock, which means that the middle of the wedge has to be exactly aligned with the upper vertical meridian. Is that correct? In my task I used a 45 degree wedge that starts rotating with its left and right borders aligned to to 12 o'clock, respectively. Do I need to account for that somehow in the analysis or in the display of the results, for example by changing the angle offset while displaying the polar map (under: view -> configure -> Phase encoded data display)?

2. When searching through the archive, I came across this thread below about freesurfer assuming that a clockwise rotating wedge starts at 12:00 and a counterclockwise one at 15:00:

*[Freesurfer] polar angle analysis with clockwise- and counterclockwise-rotating wedges* * Thomas Janssens thomasj at nmr.mgh.harvard.edu <freesurfer%40nmr.mgh.harvard.edu?Subject=Re:%20%5BFreesurfer%5D%20polar%20angle%20analysis%20with%20clockwise-%20and%0A%09counterclockwise-rotating%20wedges&In-Reply-To=%3CE0168CFF-41F9-4FE3-944B-29E5F6E2FAAC%40nmr.mgh.harvard.edu%3E> Mon Aug 13 08:24:37 EDT 2012*

*Hi Doug,

It seems that, our stimulus presentation is inconsistent with the way freesurfer processes the retinotopy clockwise and counter clockwise data.

After going through the freesurfer code I found the following. The freesurfer code assumes that the wedge starts horizontally for both clockwise and counterclockwise runs. In the glm analysis, the difference between the two types of runs (specified in the paradigm file by "neg" or "pos") is programmed in the function $FREESURFER_HOME/fsfast/toolbox/flac_desmat.m as follows:

for "pos" runs the real part equals cos(phz) and the imaginary part equals sin(phz)

for "neg" runs the real part stays cos(phz) and the imaginary part equals -sin(phz).

This is correct if the wedge starts in the horizontal positionm, but not if the wedge starts vertically. In that case the code above will lead to a phase shift of half a cycle for the "neg" runs compared to the "pos" runs.

However, this problem is solved by changing the code for the "neg" runs to: the real part equals -cos(phz) and the imaginary part equals sin(phz).

This small change fixed the problems for our data.

Thomas*

Should I also make the same adaptation, i.e. inverse the signs of sin and cos for negative runs in my analysis for my retinotopy analysis, given that in freesurfer v. 5.3, in flac_desmat.m file, the "pos" and "neg" runs are still specified as cos(phz), sin(phz) and cos(phz) and -sin(phz), respectively.

3. When displaying the results using rtview command, I see somewhat blurred retinotopic maps, whereas I do not use any smoothing in the analysis (mkanalysis-sess [...] - fwhm 0). I've noticed that one of the output message in terminal while running tksurfer is the following: tksurfer: polar-views.tcl: read and smooth real Fourier comp, surfer: smooth_val(2)? Is it possible that tksurfer smooths the maps before displaying them? If so, how to display unsmoothed results?

rtview command I use to display polar maps on the left hemisphere: rtview --s subjNr --lh --polar \ --real subjNr/bold/rtopy.self.lh/polar/real.nii.gz --imag subjNr/bold/rtopy.self.lh/polar/imag.nii.gz --fsig subjNr/bold/rtopy.self.lh/polar/fsig.nii.gz

Thank you very much for your help, Kinga Littke