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
Mon Aug 13 08:24:37 EDT 2012Hi 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