[caret-users] v5.5 VS v5.51 alignment/center of voxel issues?

Wed Aug 1 09:56:15 CDT 2007

Hi Joseph,

See inline replies below.

Donna

On 07/31/2007 06:18 PM, Vu, An wrote:
> Hi All,
>
> I was wondering what software people have used in their labs for mapping fMRI data onto surfaces and getting the alignment done. If Caret can do it, I'm still unclear on how to turn .img/.hdr or .mat files into .paint files view on them.
>   
Paint files are more for categorical data (e.g., partitioning schemes / 
ROI labels); for fMRI data, metric is the more appropriate format (i.e., 
node scalar pair).  The Van Essen Lab naturally uses Caret to map 
functional data either of these ways:

1. Caret GUI: Select Attributes: Map volumes to surface.
2. Command line:  caret_map_fmri (see attached sample script -- not 
tested, but in the ballpark)

There are other software packages that have similar features (e.g., 
AFNI/SUMA's 3dVol2Surf), but I use Caret.

Occasionally, people have trouble aligning their surfaces with their 
volumes.  This can happen if the anatomical volume to which the 
functional data is aligned differs in origin, orientation, or worse -- 
rotation -- from the anatomical volume used to reconstruct the surface.  
I can usually help pinpoint the problem by comparing your fiducial 
surface (coord and topo), functional volume, and anatomical volume.  If 
you'd like me to have a look, upload a zip file here:

http://pulvinar.wustl.edu/cgi-bin/upload.cgi
>
> The following are a few technical questions about v5.5 vs v5.51 definitions of voxel center:
>
>
> I see that after switching from Caret v5.5 to v5.51 that the default way Caret sets the origin has changed from being at the corner of the voxel to the center (at least as far as I can tell with the cursor and XYZ, IJK coordinates). So if I transfer my volumes with v5.5 origins (XYZ = 0,0,0) to v5.51, the origin shifts to XYZ= 0.5,0.5,0.5. 
>
>
> Does this mean that v5.5 and v5.51 define the center of voxels differently? When adjusting the origin by .5mm increments, the cursor in either version does not reflect the change, so the definition of voxel center is left somewhat ambiguous.
>   
To my surprise, the list of changes 
(http://brainmap.wustl.edu/caret/caret5.51_help/misc/change_log.html) 
does include this entry:

    * (30 April 2007) Improved consistency of volumes so that crosshairs 
are at the center of a voxel.

Honestly, I had not noticed.
>
> Now the real problem is here: if I reposition the origin with v5.51 standards (center of the voxel), will this create an .5mm offset with all my v5.5 segmentation and v5.51 surfaces? 
>   
This just affects the crosshairs display -- not how the volume 
intersects the surface.  To my knowledge, caret_map_fmri's behavior 
hasn't changed (or it's GUI counterpart's).
>
> Might this affect the alignment between the volume and created surfaces in v5.5 vs v5.51?
>   
If I read the change log correctly, it's just a display difference.
> Are the surface coordinates relative to the volumes kept consistent when the surfaces are exported to .vtk files? This is fairly important in terms of retinotopic mapping. 
>   
Yes -- unless you explicitly translated the surface using Window : 
Transformation matrix editor or AFNI/SUMA's Vecwarp.
>
> On a related note, is it possible to do an analogous operation like "Resize Underlay Volume" and "set origin" on segmentations? 
In searching the change log for the offset issue, I also found this 
handy feature:

    * (12 Mar 2007) Add "-volume-resize" to caret_command.

And this one also was good news for me:

    * (17 May 2007) Add "-volume-histogram" to caret_command which 
prints a histogram of the input volume to the terminal window.

I don't know when this was added, but it seems to address your need:

caret_command -volume-set-origin

AFNI's 3drefit also does this, if your data is in AFNI or NIfTI format.

> This seems to be necessary when performing the "Mathmatical Operations" (OR, AND, etc...) of segmentations of same scale but different matrix sizes for the same brains. It may also be usful for solving these offset problems described above. 
>   
If you're going to be combining/comparing segmentations, then it's best 
to use a fixed bounding box (i.e., crop all volumes the same).  But 
these issues should not in any way affect your functional alignment.  
You can map segmentations and/or functional volumes of different 
bounding boxes to the same surface, and then do math ops on the 
resulting metric files, which should have the same mesh (i.e., number of 
nodes), assuming you're using the same surface substrate.

Functional mapping should not depend on how your crop, except that 
you'll only have as much coverage as your cropping dictates.
>
> Thanks so much!
> Joseph
>
>
> _______________________________________________
> caret-users mailing list
> caret-users at brainvis.wustl.edu
> http://pulvinar.wustl.edu/mailman/listinfo/caret-users
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: map_func.sh
Type: text/x-sh
Size: 1095 bytes
Desc: not available
Url : http://brainvis.wustl.edu/pipermail/caret-users/attachments/20070801/c15a2f10/attachment.bin 