Re: [caret-users] info in the deformation maps

[Timothy Coalson]

A small addendum: spherical surface registration is not the only use for
measuring surface distortion.  If you use it on resampled anatomical
surfaces from different longitudinal timepoints, or from different species,
or just different subjects, you can get a measure of the difference in
anatomical size of various features of the cortex.

Since you were talking about "deformation from native space to fs_LR", I
didn't think about these other possibilities.

Tim


On Fri, Oct 20, 2017 at 5:59 PM, Timothy Coalson  wrote:

> Deformation maps are inherently designed for the purpose of going from one
> topology (number of triangles and their layout) to a different one, so they
> are a tricky thing to try to compare vertexwise.  They also don't really
> encode warpfield deformations (and even using them to reconstruct as much
> as possible gives you only half the story).  This is actually another
> reason why we chose not to use them in workbench.
>
> If you want to see the amount of deformation that happened to the sphere
> during registration, what you need are the original and registered spheres
> - these will always be on the same mesh, so they can be compared directly
> via things like wb_command -surface-distortion.
>
> However, I am curious about your interest in surface distortion, so some
> explanation is in order, and here is where things get mind-bending (or more
> properly, where they don't, as I will explain).  Surface registration and
> resampling does not cause any change in the shape of an individual's
> brain.  It is not an anatomical registration, unlike volume-based
> registration: it does not align anatomical coordinates.  What it actually
> does, is take the original coordinates of the subject's cortex, and
> represent them with a different set of triangles - the places where the new
> surface intersects the subject's voxels are unchanged, it just has
> different triangle and vertex numbers in each location than it used to (and
> generally a different total count of vertices/triangles).
>
> To come at it from a different angle, surface registration is about
> finding corresponding locations on brains with different shapes - it
> doesn't change the shapes in the process, it just finds where, for
> instance, foveal V1 is in each subject, and stores that information for
> later.  When surfaces and data are then resampled, foveal V1 is now vertex
> #2856 in every subject (whereas previously it was on a different vertex
> number per subject) - but, in every subject, the coordinates of that vertex
> is different, corresponding to where the original surface said foveal V1
> was located.
>
> So, what does surface registration distortion actually represent?  It is,
> in fact, the change in sampling density of that patch of the surface:  If
> part of the subject's sphere gets expanded during registration, then that
> patch will have a lot of small triangles within it in the resampled
> surface.  If it gets elongated on the sphere, then on the resampled surface
> it will have skinny (obtuse) triangles on the resampled surface.  This is
> one of the main reasons that we try to control distortion in registration
> (another is that it is also a good proxy for overfitting).
>
> If what you are after is distortion of anatomical coordinates, then you
> should only be looking at the volume registration.  While you could look at
> the changes that happen to the coordinates when you average different
> subject's surfaces together, but we don't recommend using group average
> surfaces for much more than visualization (when doing surface-based
> processing on them, such as gradients, we generally supply a secondary file
> in order to do some correction for the effects of averaging the
> coordinates).
>
> Of course, if you aren't trying to look at anatomical changes from
> registration, then surface distortion could be exactly what you want.
>
> Tim
>
>
> On Fri, Oct 20, 2017 at 4:24 PM, tony han  wrote:
>
>> Hi John and David,
>>
>>
>> Thanks a lot for your reply! Yes I'm thinking to move from Caret to
>> Workbench since most of the time we use wb_command a lot and it makes sense
>> to keep our tools up-to-date and consistent.
>>
>>
>> Just want to clarify: the weights (last 3 columns) of the vertices
>> (indexed by the first 3 columns) are decided by the distance from the 3
>> vertices of SOURCE to the vertex of TARGET? If so, maybe that's the reason
>> why why the sum of weights is not one for each vertex of TARGET?
>>
>>
>> So the reason why I'm looking at deformation maps is that I'm trying to
>> figure out a way to quantify the deformation from native

Re: [caret-users] info in the deformation maps

[Timothy Coalson]

Deformation maps are inherently designed for the purpose of going from one
topology (number of triangles and their layout) to a different one, so they
are a tricky thing to try to compare vertexwise.  They also don't really
encode warpfield deformations (and even using them to reconstruct as much
as possible gives you only half the story).  This is actually another
reason why we chose not to use them in workbench.

If you want to see the amount of deformation that happened to the sphere
during registration, what you need are the original and registered spheres
- these will always be on the same mesh, so they can be compared directly
via things like wb_command -surface-distortion.

However, I am curious about your interest in surface distortion, so some
explanation is in order, and here is where things get mind-bending (or more
properly, where they don't, as I will explain).  Surface registration and
resampling does not cause any change in the shape of an individual's
brain.  It is not an anatomical registration, unlike volume-based
registration: it does not align anatomical coordinates.  What it actually
does, is take the original coordinates of the subject's cortex, and
represent them with a different set of triangles - the places where the new
surface intersects the subject's voxels are unchanged, it just has
different triangle and vertex numbers in each location than it used to (and
generally a different total count of vertices/triangles).

To come at it from a different angle, surface registration is about finding
corresponding locations on brains with different shapes - it doesn't change
the shapes in the process, it just finds where, for instance, foveal V1 is
in each subject, and stores that information for later.  When surfaces and
data are then resampled, foveal V1 is now vertex #2856 in every subject
(whereas previously it was on a different vertex number per subject) - but,
in every subject, the coordinates of that vertex is different,
corresponding to where the original surface said foveal V1 was located.

So, what does surface registration distortion actually represent?  It is,
in fact, the change in sampling density of that patch of the surface:  If
part of the subject's sphere gets expanded during registration, then that
patch will have a lot of small triangles within it in the resampled
surface.  If it gets elongated on the sphere, then on the resampled surface
it will have skinny (obtuse) triangles on the resampled surface.  This is
one of the main reasons that we try to control distortion in registration
(another is that it is also a good proxy for overfitting).

If what you are after is distortion of anatomical coordinates, then you
should only be looking at the volume registration.  While you could look at
the changes that happen to the coordinates when you average different
subject's surfaces together, but we don't recommend using group average
surfaces for much more than visualization (when doing surface-based
processing on them, such as gradients, we generally supply a secondary file
in order to do some correction for the effects of averaging the
coordinates).

Of course, if you aren't trying to look at anatomical changes from
registration, then surface distortion could be exactly what you want.

Tim


On Fri, Oct 20, 2017 at 4:24 PM, tony han  wrote:

> Hi John and David,
>
>
> Thanks a lot for your reply! Yes I'm thinking to move from Caret to
> Workbench since most of the time we use wb_command a lot and it makes sense
> to keep our tools up-to-date and consistent.
>
>
> Just want to clarify: the weights (last 3 columns) of the vertices
> (indexed by the first 3 columns) are decided by the distance from the 3
> vertices of SOURCE to the vertex of TARGET? If so, maybe that's the reason
> why why the sum of weights is not one for each vertex of TARGET?
>
>
> So the reason why I'm looking at deformation maps is that I'm trying to
> figure out a way to quantify the deformation from native space to fs_LR at
> each vertex on the surface (32k fs_LR atlas surface). Could you give me any
> suggestion?
> --
> *From:* David Van Essen 
> *Sent:* Friday, October 20, 2017 3:41:11 PM
> *To:* Caret, SureFit, and SuMS software users; tony han
> *Subject:* Re: [caret-users] info in the deformation maps
>
> Hi Tony et al.
>
> John’s explanation regarding deformation map files is correct.  Here, I’m
> drawing to your attention the fact that Connectome Workbench (and
> wb_command) provides improved methods for mapping from one surface mesh
> that has been registered to another (see below).  Depending on your use
> case scenario, you (and others) may decide to stick with Caret and its
> deformation maps (even though Caret is no longer under active development).
> Or you may find it advantageous to switch to wb_command for future
> analyses, as it has become more  powerful and flexible, and is still under
> active development (https://www.humanconnectome.org/software/connecto

Re: [caret-users] strange patches on grey surface?

[Timothy Coalson]

That looks like a problem with the coordinates or possibly with the
topology of what you loaded as the left surfaces.  I'm not really sure how
that would happen.  You can open the
"Human.PALS_B12.LR.MULTI-FIDUCIAL_FLIRT_fMRI-MAPPER.B1-12.LEFT.73730.spec"
file itself (part of the caret-data package, I expect) and just display the
surfaces, and see if that has the same issue.

Lengthy side note: Caret5 is older software, no longer maintained.
Connectome Workbench is its successor, and can do many of the same things,
with more intuitive controls:

http://www.humanconnectome.org/software/connectome-workbench

However, it does not have options in the GUI for the same kind of
processing, as we have shifted almost entirely to the command line and
scripts for that purpose (much easier to tweak a pipeline script then
recompile the software).  The basic command needed for this type of
operation is "wb_command -volume-to-surface-mapping", which will map one
nifti volume file to one surface, which we use to map single-individual
data to the surfaces of that same individual, which gives us significant
gains by bypassing the volume registration problem entirely.  It can be
used, with a moderate amount of scripting and some additional commands, to
do what the caret5 function you want to use does (map a group volume file
to many subjects' surfaces, then average).

Now for the bad news: The average errors of nonlinear volume registration
in cortex are rather high due to folding variability, larger than the fMRI
resolutions we now use (2mm for 3T using multiband), and will be much worse
for linear volume registration such as FLIRT.  The fMRI mapping method you
are using is largely intended as a workaround for simply viewing legacy
group volume data, where the individual data is not available for
reprocessing with better methods.  We recommend against using volume-based
group analysis of cortex in new studies.  See here for an example of the
specificity and reproducibility we can get with surface-based group
analysis (2 independent groups of subjects, click on the image to enlarge):

https://balsa.wustl.edu/WDpX

Tim



On Tue, Aug 29, 2017 at 7:05 AM, Alle Meije Wink  wrote:

> Mapping a functional volume onto the caret surfaces made with FLIRT, I get
> some strange black/white coloured patches in only the left hemisphere.
>
> My computer has Debian 9 (Stretch) and I have installed caret and
> caret-data from the NeuroDebian repository.
> I follow the instructions of http://brainvis.wustl.edu/wiki
> /index.php/Caret:Operations/MapVolumeToSurface:
>
> From main window:
>  -- menu -> attributes -> map volume(s) to surface(s)
>  -- data mapping type -> metric (functional) or surface shape data
>  -- volume selection -> add volumes from disk -> * resolution 4x4x4 mm^3> (thresholded to only show negative clusters)*
>  -- spec file and surface selection -> map to spec file ->
> Human.PALS_B12.LR.MULTI-FIDUCIAL_FLIRT_fMRI-MAPPER.B1-12.LEFT.73730.spec
> spec file
> -> topology file -> Human.sphere_6.LEFT.HEM.73730.topo *(no others
> possible)*
> fiducual
> coordinate files -> select all coord files (12x)
>  map to spec file ->
> Human.PALS_B12.LR.MULTI-FIDUCIAL_FLIRT_fMRI-MAPPER.B1-12.RIGHT.73730.spec
> spec file
> -> topology file -> Human.sphere_6.RIGHT.HEM.73730.topo *(no others
> possible)*
> fiducual
> coordinate files -> select all coord files (12x)
>  -- data file naming -> surface family -> Human.PALS_B12.LR.MULTI-FIDUCI
> AL_FLIRT_fMRI-MAPPER.B1-12.LEFT.73730.spec (12 coord files)
>  data file ->
> *map_data_2_29_Aug_2017_12_33_32.metric*
> surface family ->
> Human.PALS_B12.LR.MULTI-FIDUCIAL_FLIRT_fMRI-MAPPER.B1-12.RIGHT.73730.spec
> (12 coord files)
>  data file ->
> *map_data_3_29_Aug_2017_12_35_25.metric*
>  -- mapping algorithm -> metric_enclosing_voxel
>
> Back to main window:
>  -- menu -> file -> open spec file
>  -- specification file: Human.PALS_B12.LR.MULTI-FIDUCI
> AL_FLIRT_fMRI-MAPPER.B1-12.LEFT.73730.spec
>  coordination files -> select all
>  -- metric file: *map_data_0_29_Aug_2017_12_33_32.metric*
>  -> window captured as caret_left.png
>
> Back to main window:
>  -- menu -> file -> open spec file
>  -- specification file: Human.PALS_B12.LR.MULTI-FIDUCI
> AL_FLIRT_fMRI-MAPPER.B1-12.RIGHT.73730.spec
>  coordination files -> select all
>  -- metric file: *map_data_1_29_Aug_2017_12_35_25.metric*
>  -> window captured as caret_right.png
>
> Now the right hemisphere looks brilliant (both with and without the
> functional values mapped in) but th

Re: [caret-users] loading .paint/ .coord file in matlab

[Timothy Coalson]

For coord files, I would use them and a topo file with caret_command
-file-convert -sc and make a gifti surface file.  For a paint file, I would
see about converting it to a gifti label file ".label.gii".  Gifti file
types can be loaded with the gifti matlab toolbox:

https://www.artefact.tk/software/matlab/gifti/

Tim


On Wed, Mar 29, 2017 at 9:35 AM, Bakker-10, C.A. <
c.a.bakker...@umcutrecht.nl> wrote:

> Hi all,
>
>
>
> I’m trying to load a .paint file or a .coord in matlab using the
> caret_load function from the toolbox of David van Essen.
>
> Unfortunately matlab won’t load the file and crashes every time…
>
> Does anybody know how to load a .paint file and a .coord file in matlab?
>
>
>
> Thank you in advance!
>
> Best regards,
>
> Carlijn Bakker
>
>
> --
>
> * De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
> uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
> ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender
> direct te informeren door het bericht te retourneren. Het Universitair
> Medisch Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin
> van de W.H.W. (Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat
> geregistreerd bij de Kamer van Koophandel voor Midden-Nederland onder nr.
> 30244197. *
>
> * Denk s.v.p aan het milieu voor u deze e-mail afdrukt. *
> --
>
> * This message may contain confidential information and is intended
> exclusively for the addressee. If you receive this message unintentionally,
> please do not use the contents but notify the sender immediately by return
> e-mail. University Medical Center Utrecht is a legal person by public law
> and is registered at the Chamber of Commerce for Midden-Nederland under no.
> 30244197. *
>
> * Please consider the environment before printing this e-mail. *
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] Caret Manual and Tutorials

[Timothy Coalson]

We no longer actively develop Caret, so you may also want to look at
Connectome Workbench, which is Caret's successor:

http://www.humanconnectome.org/software/get-connectome-workbench.html

Tutorials are under the software download section.

Tim


On Tue, Dec 15, 2015 at 1:25 PM, Rosalia Dacosta Aguayo  wrote:

> Dear Caret team,
>
> I have just downloaded Caret and I am highly interested in reading a
> Manual and do some of the tutorials...what I have been not able to find
> themany suggestion about where I can find it? and about which of your
> data would be more suitable for doing tutorials?
>
> Yours sincerely,
>
> Rosalia.
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] Color palette for metric data

[Timothy Coalson]

For discrete integer values, I would recommend a paint (label) file rather
than using a metric file, which is acontinuous-valued file type.  Paint
files let you set the color for each integer independently.  Unfortunately,
I haven't dealt with paint files much, but this other post may help if it
is the result of mapping volume to surface:

http://brainvis.wustl.edu/pipermail/caret-users/2015-June/006290.html

In connectome workbench (which is effectively caret 7), there is a command
to make a label file from a metric file, but I'm not sure if there is a way
to do this in caret5.

Tim


On Mon, Aug 24, 2015 at 3:09 PM, Roman M  wrote:

> Hi,
>
>  I'm having some trouble with the color palette to render metric data - I
> was hoping I could get some support.
>  It's a fairly simple situation: I have metric data with only 3 values: 2,
> 4 and 6 (i.e., task 1, task 2, overlap), which I'd like to color,
> respectively, blue, green, and yellow.
>
> Now, following a previous post, I've created a new palette with:
> 0.33 --> blue
> 0.66 --> green,
> 1 --> yellow
>  set the user scale to positive only min: 2 and max 6 (I've pasted the
> relevant section of the post instructions below). Yet I cannot seem to
> display 3 colors. I can only get them 2 at a time, and in fact, to get
> anything close to the scheme I'm looking for I have to do the opposite of
> what was suggested in the post (i.e., 0.33 yellow, 0.66 green, 1 blue).
>
> I feel this should be really simple, so sorry if it's too much of a naive
> question, but can't seem to get it to work after having tried a number of
> permutations..
>
>  Cheers
>
>  Martin
>
>
>
>
>
> http://brainvis.wustl.edu/pipermail/caret-users/2008-May/004310.html
>
> *If your data truly ranges from ranges
> *>* from zero to 300, you could stick with auto scale.  If not, change the
> *>* "Color Mapping" to "User Scale" and set the "Pos Min/Max" values to
> *>* 0.0 and 300.0.  If you palette has red at 0.33, orange at 0.66, and
> *>* yellow at 1.0, metric values of 0 to 100 are assigned red, metric
> *>* values of 100 to 200 are assigned orange, and metric values of 200 to
> *>* 300 are assigned yellow.*
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] Problem"out of memory", please help me, thank you !

[Timothy Coalson]

I think caret5 has trouble with non-english locales, if you are using a
different OS language, could you try setting the OS language to english and
trying it again?

Tim


On Fri, Jan 9, 2015 at 1:18 AM, 陈晨  wrote:

> ChenChen
>
> chenchen_...@163.com
>
> caret5
>
> v5.65 AND Jan 27 2012
>
> Windows 7 Ultimate
>
> I get an "out of memory,Caret terminating" error message when loading
> PALS_B12.RIGHT.DEMO.73730.spec.
>
> PALS_B12.RIGHT.DEMO.73730.zip
>
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] average fs_LR32k mesh

[Timothy Coalson]

The script quoted in the post you linked specifically resamples the
surface, so if that is what you did, the output from it is the midthickness
in fs_LR32k.  Other surface types can be resampled the same way.  Caret5
will load .surf.gii files just fine, you don't need to convert back to
topo/coord (but you can, with caret_command -file-convert -sc ...).

Tim


On Wed, Oct 1, 2014 at 11:22 AM, Alexander Schäfer 
wrote:

> Dear List,
>
> A previous post
> (http://brainvis.wustl.edu/pipermail/caret-users/2014-August/006194.html)
> on this list helped me to successfully downsample my fs_LR164k
> (func.gii) data to fs_LR32k. Now, I have the problem that I only have
> the provided 32k sphere file to overlay the data onto. Is there some
> average fs_LR32k mesh (.coord, .topo for inflated, midthickness, etc)
> that could be shared by someone?
>
> Thank you,
> Alex Schaefer
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] projecting functional MRI to gii surfaces

[Timothy Coalson]

 a label name in the front of the label
> file, e.g.:
> >>
> >>>> Alpha="0">
> >>>> Alpha="1">
> >>>> Alpha="1">
> >>>> Alpha="1">
> >>>> Alpha="1">
> >>>> Alpha="1">
> >>>> Alpha="1">
> >>>> Alpha="1">
> >>>> Alpha="1">
> >>>> Alpha="1">
> >>>> Alpha="1">
> >>
> >> You can also export the label table as ASCII text.  But each vertex is
> associated with one of these keys in the label.gii file.
> >>
> >> Donna
> >>
> >>
> >> On Aug 28, 2014, at 2:27 PM, "Tang, Yan"  wrote:
> >>
> >>> I still have problem. How can I know which brain region is every
> vertex belonged to?
> >>> 
> >>> From: Tang, Yan
> >>> Sent: Friday, August 15, 2014 12:27 PM
> >>> To: Caret, SureFit, and SuMS software users
> >>> Subject: RE: [caret-users] projecting functional MRI to gii surfaces
> >>>
> >>> Thank all of you. Thank you very much.
> >>> 
> >>> From: caret-users-boun...@brainvis.wustl.edu [
> caret-users-boun...@brainvis.wustl.edu] on behalf of Donna Dierker [
> do...@brainvis.wustl.edu]
> >>> Sent: Wednesday, August 13, 2014 2:27 PM
> >>> To: Caret, SureFit, and SuMS software users
> >>> Subject: Re: [caret-users] projecting functional MRI to gii surfaces
> >>>
> >>> Hi Yan,
> >>>
> >>> I'm not sure about wb_import, but I know it won't downsample for you.
> This will, I hope:
> >>>
> >>>
> http://brainmap.wustl.edu/pub/donna/ATLASES/HUMAN/FSLR/downsample164_to_32k.zip
> >>> login pub
> >>> password download
> >>>
> >>> There is a script in there you will need to tweak to put in your
> pathnames and subject list.  I tried it on some freesurfer_to_fs_LR output
> I had lying around, and it worked.  The zip file also contains the spheres
> you need:
> >>>
> >>> ExtractDir=/home/donna/downsample164_to_32k
> >>> SubjectDir=/mnt/myelin/donna/SUBJ/fs_LR_output_directory
> >>> ResamplingMethod=BARYCENTRIC
> >>>
> >>> for Subject in $SubjList
> >>> do
> >>> for Hemisphere in L R
> >>> do
> >>>
> CoordInput=$SubjectDir/$Subject/"$Subject".$Hemisphere.midthickness_orig.164k_fs_LR.coord.gii
> >>>
> TopoInput=$SubjectDir/$Subject/"$Subject".$Hemisphere.164k_fs_LR.topo.gii
> >>>
> SurfaceInput=$SubjectDir/$Subject/"$Subject".$Hemisphere.midthickness_orig.164k_fs_LR.surf.gii
> >>> caret_command -file-convert -sc -is CARET $CoordInput $TopoInput -os
> >>> GS $SurfaceInput
> >>>
> CurrentSphere=$ExtractDir/spheres/standard.$Hemisphere.sphere.164k_fs_LR.surf.gii
> >>>
> NewSphere=$ExtractDir/spheres/standard.$Hemisphere.sphere.32k_fs_LR.surf.gii
> >>>
> SurfaceOutput=$SubjectDir/$Subject/"$Subject".$Hemisphere.midthickness_orig.32k_fs_LR.surf.gii
> >>> wb_command -surface-resample \
> >>> $SurfaceInput \
> >>> $CurrentSphere \
> >>> $NewSphere \
> >>> $ResamplingMethod \
> >>> $SurfaceOutput
> >>> done
> >>> done
> >>>
> >>> Donna
> >>>
> >>>
> >>> On Aug 13, 2014, at 10:42 AM, "Tang, Yan"  wrote:
> >>>
> >>>> You means I can finish this work by using the Connectome Workbench.
> So, the first thing I need to do is to convert all files to Workbench
> format by using wb_import. Is it true?
> >>>> From: caret-users-boun...@brainvis.wustl.edu [
> caret-users-boun...@brainvis.wustl.edu] on behalf of Timothy Coalson [
> tsc...@mst.edu]
> >>>> Sent: Tuesday, August 12, 2014 7:16 PM
> >>>> To: Caret, SureFit, and SuMS software users; Donna Dierker
> >>>> Subject: Re: [caret-users] projecting functional MRI to gii surfaces
> >>>>
> >>>> -spec-file-change-resolution will not get you to the fs_LR 32k atlas
> from fs_LR 164k (but it may get you deceptively close, making it even more
> treacherous).  Those messages aren't errors, and the reasons behind them
> are better left alone, as this isn't th

Re: [caret-users] projecting functional MRI to gii surfaces

[Timothy Coalson]

wb_import should convert many of the file types, though I'm not as sure
about surface files - if not, caret_command -file-convert -sc ... will take
care of surface files, which I think you have done before to get the
surfaces into matlab.  If you already have nifti volumes, those don't need
conversion.

Since your earlier posts indicate your end goal may be putting volume data
onto an fs_LR 32k surface, and this is something we put some thought into
in the HCP pipelines, you might want to look at the methods we use
(citation below).  The short version is that we use wb_command's ribbon
method of volume to surface mapping, which allows you to include just
voxels between the white and pial surfaces (caret5 methods mainly make
point estimates at the vertex locations).  We do the volume to surface
mapping using high resolution surfaces, and then downsample that data,
rather than doing volume to surface mapping with a downsampled surface,
because a resampled surface file loses some precision (gyral crowns can
move slightly inwards, etc).  We do this data downsampling with the new
ADAP_BARY_AREA method of wb_command -metric-resample, which prevents SNR
loss without needing smoothing before resampling.

The most recent paper covering the methods we use is this one:
http://www.ncbi.nlm.nih.gov/pubmed/23668970 (search in the text for "HCP
pipelines: fMRISurface").  I believe we are working on getting our
pipelines ready for release, which might make this process easier for you.

Tim



On Wed, Aug 13, 2014 at 2:27 PM, Donna Dierker 
wrote:

> Hi Yan,
>
> I'm not sure about wb_import, but I know it won't downsample for you.
>  This will, I hope:
>
>
> http://brainmap.wustl.edu/pub/donna/ATLASES/HUMAN/FSLR/downsample164_to_32k.zip
> login pub
> password download
>
> There is a script in there you will need to tweak to put in your pathnames
> and subject list.  I tried it on some freesurfer_to_fs_LR output I had
> lying around, and it worked.  The zip file also contains the spheres you
> need:
>
> ExtractDir=/home/donna/downsample164_to_32k
> SubjectDir=/mnt/myelin/donna/SUBJ/fs_LR_output_directory
> ResamplingMethod=BARYCENTRIC
>
> for Subject in $SubjList
> do
>  for Hemisphere in L R
>  do
>
>  
> CoordInput=$SubjectDir/$Subject/"$Subject".$Hemisphere.midthickness_orig.164k_fs_LR.coord.gii
>
>  TopoInput=$SubjectDir/$Subject/"$Subject".$Hemisphere.164k_fs_LR.topo.gii
>
>  
> SurfaceInput=$SubjectDir/$Subject/"$Subject".$Hemisphere.midthickness_orig.164k_fs_LR.surf.gii
>caret_command -file-convert -sc -is CARET $CoordInput $TopoInput -os
> GS $SurfaceInput
>
>  
> CurrentSphere=$ExtractDir/spheres/standard.$Hemisphere.sphere.164k_fs_LR.surf.gii
>
>  NewSphere=$ExtractDir/spheres/standard.$Hemisphere.sphere.32k_fs_LR.surf.gii
>
>  
> SurfaceOutput=$SubjectDir/$Subject/"$Subject".$Hemisphere.midthickness_orig.32k_fs_LR.surf.gii
>wb_command -surface-resample \
> $SurfaceInput \
> $CurrentSphere \
> $NewSphere \
> $ResamplingMethod \
> $SurfaceOutput
>  done
> done
>
> Donna
>
>
> On Aug 13, 2014, at 10:42 AM, "Tang, Yan"  wrote:
>
> > You means I can finish this work by using the Connectome Workbench. So,
> the first thing I need to do is to convert all files to Workbench format by
> using wb_import. Is it true?
> > From: caret-users-boun...@brainvis.wustl.edu [
> caret-users-boun...@brainvis.wustl.edu] on behalf of Timothy Coalson [
> tsc...@mst.edu]
> > Sent: Tuesday, August 12, 2014 7:16 PM
> > To: Caret, SureFit, and SuMS software users; Donna Dierker
> > Subject: Re: [caret-users] projecting functional MRI to gii surfaces
> >
> > -spec-file-change-resolution will not get you to the fs_LR 32k atlas
> from fs_LR 164k (but it may get you deceptively close, making it even more
> treacherous).  Those messages aren't errors, and the reasons behind them
> are better left alone, as this isn't the command you want.
> >
> > What you need to do is to use the fs_LR atlas files for resampling the
> surface.  In caret5, this requires deformation map files, which we have
> probably already made for going between fs_LR 32k and 164k (Donna, do you
> know if these are available?), with the -deformation-map-apply command.
>  However, we now do this in Connectome Workbench using atlas spheres
> directly with the -surface-resample command (the fs_LR 32k and 164k spheres
> are aligned by definition, but going to or from other atlases will need a
> cross-atlas registered sphere).
> >
> > Tim
> >
> >
> >
> > On Tue, Aug 12, 2014 at 4:33 PM, Tang, Yan  wrote:
> > Sorry, I meet another problem.  I 

Re: [caret-users] projecting functional MRI to gii surfaces

[Timothy Coalson]

-spec-file-change-resolution will not get you to the fs_LR 32k atlas from
fs_LR 164k (but it may get you deceptively close, making it even more
treacherous).  Those messages aren't errors, and the reasons behind them
are better left alone, as this isn't the command you want.

What you need to do is to use the fs_LR atlas files for resampling the
surface.  In caret5, this requires deformation map files, which we have
probably already made for going between fs_LR 32k and 164k (Donna, do you
know if these are available?), with the -deformation-map-apply command.
 However, we now do this in Connectome Workbench using atlas spheres
directly with the -surface-resample command (the fs_LR 32k and 164k spheres
are aligned by definition, but going to or from other atlases will need a
cross-atlas registered sphere).

Tim



On Tue, Aug 12, 2014 at 4:33 PM, Tang, Yan  wrote:

>  Sorry, I meet another problem.  I used  the Freesurfer_to_fs_LR Pipeline
> to get  164k fs_LR surface. I think the vertex too much. So I want to  
> down-sampled
> to a 32,492 vertex surface. I used the caret_command
> -spec-file-change-resolution.
> But, the error was  followed:
> "Nonstandard resolution specified...
> Using closest divided icosahedron, with 32492 nodes."
> Can you explain it?
> if I change the number, I find only  a few files be created such as
> def_sphere.coord, def_sphere.deform_map,study1.R.2k_fs_LR.topo.gii and
> study1.R.mini+orig.2k_fs_LR.spc. Many files such as curvature.shape.gii,
> inflated.coord.gii, midthickness.coord.gii, pial.coord.gii,
> thickness.shape.gii and white.coord.gii all aren't changed. So, I do some
> wrong steps. How should I do it?
>  --
> *From:* caret-users-boun...@brainvis.wustl.edu [
> caret-users-boun...@brainvis.wustl.edu] on behalf of Timothy Coalson [
> tsc...@mst.edu]
> *Sent:* Monday, August 11, 2014 3:54 PM
>
> *To:* Caret, SureFit, and SuMS software users
> *Subject:* Re: [caret-users] projecting functional MRI to gii surfaces
>
>
> On Mon, Aug 11, 2014 at 2:14 PM, Tang, Yan  wrote:
>
>> Yes，I have a lot of volumes which need be projected to surface. I only
>> know how to use the 'map volume to surface '. I don't know how to use the
>> command. Could you give me an example?
>> Can the file of *.coord.gii be thought as the 
>> file? But I only found .coord file can be used in the menu of "caret
>> command executor" . How about "topo"?
>>
>
>  .coord.gii should work, if it doesn't rename or copy the file to end in
> just .coord .  The topo is the same file you need to load to be able to
> view the surface.
>
>
>> another thing is how to set the ?
>>
>
>  From the pasted help:
>
>  "If the input metric or paint file name is not an empty string (""), the
> newly create metric or paint columns will be appended to the file and then
> written with the output file name."
>
>  In other words, if you don't want to append the columns to an existing
> metric file, use "" (a pair of double quotes) for the argument.
>
>  Since you asked something related on the hcp_users list (wb_command
> volume to surface mapping), I will recommend that you try using wb_command
> for this, as caret5 is no longer under active development.  The main hurdle
> in moving to Workbench is converting the separate coord/topo files into the
> combined .surf.gii format (with caret_command -file-convert with the -sc
> option).
>
>
>> 
>> From: caret-users-boun...@brainvis.wustl.edu [
>> caret-users-boun...@brainvis.wustl.edu] on behalf of Donna Dierker [
>> do...@brainvis.wustl.edu]
>>  Sent: Tuesday, August 05, 2014 9:14 AM
>>  To: Caret, SureFit, and SuMS software users
>> Cc: Tang, Yiyuan
>> Subject: Re: [caret-users] projecting functional MRI to gii surfaces
>>
>> I'm not clear on what you mean by "I want get fMRI time course for
>> surface vertices of every subject."
>>
>> If you just mean how do you scale up -- map that many volumes to all your
>> subjects -- then I recommend scripting it and using caret_command.  (Note
>> that Workbench, the software that is superseding Caret 5.*, has more robust
>> mapping features than caret_command, but I am going to provide the
>> caret_command usage, since this is the caret-users list.  There is also a
>> hcp-users list that covers workbench.)
>>
>> Here is the usage for the command that maps volumes onto surfaces:
>>
>>   caret_command -volume-map-to-surface
>>  
>>  
>>  
>>  
>>  
>>   

Re: [caret-users] projecting functional MRI to gii surfaces

[Timothy Coalson]

On Mon, Aug 11, 2014 at 2:14 PM, Tang, Yan  wrote:

> Yes，I have a lot of volumes which need be projected to surface. I only
> know how to use the 'map volume to surface '. I don't know how to use the
> command. Could you give me an example?
> Can the file of *.coord.gii be thought as the  file?
> But I only found .coord file can be used in the menu of "caret command
> executor" . How about "topo"?
>

.coord.gii should work, if it doesn't rename or copy the file to end in
just .coord .  The topo is the same file you need to load to be able to
view the surface.


> another thing is how to set the ?
>

>From the pasted help:

"If the input metric or paint file name is not an empty string (""), the
newly create metric or paint columns will be appended to the file and then
written with the output file name."

In other words, if you don't want to append the columns to an existing
metric file, use "" (a pair of double quotes) for the argument.

Since you asked something related on the hcp_users list (wb_command volume
to surface mapping), I will recommend that you try using wb_command for
this, as caret5 is no longer under active development.  The main hurdle in
moving to Workbench is converting the separate coord/topo files into the
combined .surf.gii format (with caret_command -file-convert with the -sc
option).


> 
> From: caret-users-boun...@brainvis.wustl.edu [
> caret-users-boun...@brainvis.wustl.edu] on behalf of Donna Dierker [
> do...@brainvis.wustl.edu]
> Sent: Tuesday, August 05, 2014 9:14 AM
> To: Caret, SureFit, and SuMS software users
> Cc: Tang, Yiyuan
> Subject: Re: [caret-users] projecting functional MRI to gii surfaces
>
> I'm not clear on what you mean by "I want get fMRI time course for surface
> vertices of every subject."
>
> If you just mean how do you scale up -- map that many volumes to all your
> subjects -- then I recommend scripting it and using caret_command.  (Note
> that Workbench, the software that is superseding Caret 5.*, has more robust
> mapping features than caret_command, but I am going to provide the
> caret_command usage, since this is the caret-users list.  There is also a
> hcp-users list that covers workbench.)
>
> Here is the usage for the command that maps volumes onto surfaces:
>
>   caret_command -volume-map-to-surface
>  
>  
>  
>  
>  
>  
>  [-av  average-voxel-neighbor-cube-size (mm)]
>  [-bf  brain-fish-max-distance
>brain-fish-splat factor]
>  [-g   gaussian-neighbor-cube-size (mm)
>sigma-norm
>sigma-tang
>norm below cutoff (mm)
>norm above cutoff (mm)
>tang-cutoff (mm)]
>  [-mv  maximum-voxel-neighbor-cube-size (mm)]
>  [-sv  strongest-voxel-neighbor-cube-size (mm)]
>
>  Map volume(s) to a surface metric or paint file.
>
>  For successful mapping, both the surface and the volume
>  must be in the same stereotaxic space.
>
>  "algorithm" is one of:
> METRIC_AVERAGE_NODES
> METRIC_AVERAGE_VOXEL
> METRIC_ENCLOSING_VOXEL
> METRIC_GAUSSIAN
> METRIC_INTERPOLATED_VOXEL
> METRIC_MAXIMUM_VOXEL
> METRIC_MCW_BRAIN_FISH
> METRIC_STRONGEST_VOXEL
> PAINT_ENCLOSING_VOXEL
>
>  If the input metric or paint file name is not an empty string
>   (""), the newly create metric or paint columns will be
>  appended to the file and then written with the output file
>  name.
>
>
>
> On Aug 4, 2014, at 3:49 PM, "Tang, Yan"  wrote:
>
> > Thank you for your help.  Now, I meet another problem. I project all
> functional MRI to 164k fs_LR surface. Every subject have 135 volumes. I
> want get fMRI time course for surface vertices of every subject. How should
> I do?
> > 
> > From: caret-users-boun...@brainvis.wustl.edu [
> caret-users-boun...@brainvis.wustl.edu] on behalf of Donna Dierker [
> donna.dier...@sbcglobal.net]
> > Sent: Friday, August 01, 2014 5:34 PM
> > To: Caret, SureFit, and SuMS software users
> > Cc: Tang, Yiyuan
> > Subject: Re: [caret-users] projecting functional MRI to gii surfaces
> >
> > Push Toolbar: D/C and make sure the primary overlay is Metric.
> >
> > Make sure the right column is selected.
> >
> > If that check out okay, then I would do:
> >
> > File: Open Data File: Volume Functional File
> > Load the volume you just mapped
> > Switch to volume view and select view All (as opposed to H (horizontal
> or axial).
> > Select D/C and on the page selection drop-down menu, scroll all the way
> to the bottom
> >something like volume surface outline
> > Toggle on the fiducial surface used for the mapping, so that you can see
> how the surface aligns with the volume.
> >
> > Sometimes there are header issues, and the origin is no

Re: [caret-users] projecting functional MRI to gii surfaces

[Timothy Coalson]

Yes, the vertices array appears to be the vertex coordinates.  You may need
to do the -file-convert -format-convert XML_BASE64_GZIP (not ASCII) on the
metric file (and maybe even rename it to end in .func.gii) to load it in
matlab as a gifti file.

The metric file does not contain voxel values, it contains a value at each
surface vertex.  The correspondence between voxels and surface vertices is
purely spatial, and unless you used enclosing voxel mapping (which is not
good for continuous data values like functional activation), each vertex
contains an interpolated value derived from several voxels.

Tim



On Wed, Aug 6, 2014 at 4:40 PM, Tang, Yan  wrote:

>  Thank you for your help. I use the command  "caret_command -file-conver
> -sc -is CARET" to get surf.gii file. And I use the GIFTI to open this
> surf.gii file and get two important variables "vertices" and "faces".
> vertices=
>  -6.8856  -52.5189   23.7218
>   -22.1394  -41.5367   68.0599
>   -49.4149   -0.5296   47.7317
>-3.4733   22.7785   64.3392
>   -25.9901 -104.46824.0191
>   -47.4914  -56.3775   48.6392
>   -26.3158   45.2893   14.0113
>-0.94799.10271.0427
>   -23.8312  -56.4579   -7.5924
>   -51.4654  -34.09551.4522
> 
>  I think the "vertices" include the coordinates. Is it right?
> But I still can't open the metric file in GIFTI. This metric file was
> obtain by mapping functional volumes to surfaces in volume selection page.
> When I used the  caret_command -file-convert -format-convert ASCII
> my_fmri.metric, I found some information in the metric
>  0 -3.944756
> 1 0.00
> 2 0.00
> 3 0.00
> 4 -0.291482
> 5 0.995688
> 6 6.848554
> 7 3.783060
> 8 0.804804
> 9 -4.805716
> 10 -6.419259
> 11 -0.036545
> 12 -5.132483
> 13 -6.023278
> 14 -6.115900
> 15 -6.208522
> 16 -6.301144
> 17 -6.347455
> 18 -5.193967
> 19 -3.463736
> 20 -2.005528
> 
> These information maybe display the every voxel's value. But I still can't
> use the use the vertices in surf.gii as seed to analysis the resting state
> functional connectivity. Because I don't know the correspondence between
> the vertices in surf.gii and the voxel in fMRI. Please help me.
>
>  Thank you.
>
>  --
> *From:* caret-users-boun...@brainvis.wustl.edu [
> caret-users-boun...@brainvis.wustl.edu] on behalf of Timothy Coalson [
> tsc...@mst.edu]
> *Sent:* Wednesday, August 06, 2014 1:27 PM
>
> *To:* Caret, SureFit, and SuMS software users
> *Cc:* Tang, Yiyuan
> *Subject:* Re: [caret-users] projecting functional MRI to gii surfaces
>
> Correction, there is a matlab GIFTI toolbox, not CIFTI.  Metric files
> are usually already GIFTI files, but caret5 coord/topo files need to be
> converted:
>
>  to convert non-GIFTI metric file to GIFTI:
>  caret_command -file-convert -format-convert XML_BASE64_GZIP 
>
>  to convert topo/coord to GIFTI surface:
>  caret_command -file-conver -sc -is CARET   -os GS
> 
>
>  I believe the matlab GIFTI toolbox will read surface files, but you'll
> need to separate the two data arrays in it as to which describes the
> triangles, and which is the vertex coordinates.
>
>  Tim
>
>
>
> On Wed, Aug 6, 2014 at 8:32 AM, Donna Dierker 
> wrote:
>
>> First, I want to point out that there is a CIFTI matlab toolkit, I think,
>> but I know very little about it (or matlab in general).  What I do know:
>>
>> * The freesurfer_to_fs_LR pipeline probably doesn't generate CIFTI
>> output.  But the forthcoming Human Connectome Project (HCP) pipeline does.
>> * Questions about the CIFTI matlab toolkit might better be posed to the
>> CIFTI forum on nitrc.org (http://www.nitrc.org/forum/?group_id=454).
>>
>> Using the caret5/caret_command tools, it is possible to convert the
>> metric/func.gii files to ASCII, e.g.:
>>
>> caret_command -file-convert -format-convert ASCII my_fmri.metric
>>
>> … or:
>>
>> caret_command -file-convert -format-convert ASCII my_fmri.func.gii
>>
>> As for the coordinates, since you have the individual midthickness
>> surfaces on 164k mesh, you can those for the unprojection command.  If you
>> really want a grid, then it is a border file you will get out of caret:
>>
>>
>> http://brainvis.wustl.edu/CaretHelpAccount/caret5_help/file_formats/file_formats.html#borderFile
>>
>> Here is the Alex Cohen paper:
>>
>> http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2705206/
>>
>> This is not a trivial task. ;-)
>>
>>
>> On Aug 5, 2014, at 3:13 PM, "Tang, Yan"  wrote:
>>
>

Re: [caret-users] projecting functional MRI to gii surfaces

[Timothy Coalson]

Correction, there is a matlab GIFTI toolbox, not CIFTI.  Metric files are
usually already GIFTI files, but caret5 coord/topo files need to be
converted:

to convert non-GIFTI metric file to GIFTI:
caret_command -file-convert -format-convert XML_BASE64_GZIP 

to convert topo/coord to GIFTI surface:
caret_command -file-conver -sc -is CARET   -os GS


I believe the matlab GIFTI toolbox will read surface files, but you'll need
to separate the two data arrays in it as to which describes the triangles,
and which is the vertex coordinates.

Tim



On Wed, Aug 6, 2014 at 8:32 AM, Donna Dierker 
wrote:

> First, I want to point out that there is a CIFTI matlab toolkit, I think,
> but I know very little about it (or matlab in general).  What I do know:
>
> * The freesurfer_to_fs_LR pipeline probably doesn't generate CIFTI output.
>  But the forthcoming Human Connectome Project (HCP) pipeline does.
> * Questions about the CIFTI matlab toolkit might better be posed to the
> CIFTI forum on nitrc.org (http://www.nitrc.org/forum/?group_id=454).
>
> Using the caret5/caret_command tools, it is possible to convert the
> metric/func.gii files to ASCII, e.g.:
>
> caret_command -file-convert -format-convert ASCII my_fmri.metric
>
> … or:
>
> caret_command -file-convert -format-convert ASCII my_fmri.func.gii
>
> As for the coordinates, since you have the individual midthickness
> surfaces on 164k mesh, you can those for the unprojection command.  If you
> really want a grid, then it is a border file you will get out of caret:
>
>
> http://brainvis.wustl.edu/CaretHelpAccount/caret5_help/file_formats/file_formats.html#borderFile
>
> Here is the Alex Cohen paper:
>
> http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2705206/
>
> This is not a trivial task. ;-)
>
>
> On Aug 5, 2014, at 3:13 PM, "Tang, Yan"  wrote:
>
> > Maybe I do some wrong things.  I used  the Freesurfer_to_fs_LR Pipeline
> to get  164k fs_LR surface. Then, I want to get the points in 164k fs_LR
> surface and use these points as seed to analysis the resting state
> functional connectivity. So I do project functional MRI to surface. But
> after that, I don't know how to do it in next step. I get metric file, but
> these files cannot be read in Matlab. And I also don't get the coordinates
> of the points in 164k fs_LR surface.
> >
> > Just you mention the method of Alex Cohen. I am  beginner of Caret.
> Could you tell me the method in detail?
> >
> > thank you
> > 
> > From: caret-users-boun...@brainvis.wustl.edu [
> caret-users-boun...@brainvis.wustl.edu] on behalf of Donna Dierker [
> do...@brainvis.wustl.edu]
> > Sent: Tuesday, August 05, 2014 10:26 AM
> > To: Caret, SureFit, and SuMS software users
> > Cc: Tang, Yiyuan
> > Subject: Re: [caret-users] projecting functional MRI to gii surfaces
> >
> > You can do that, but I am not used to seeing this done with the mean
> midthickness surface.  Alex Cohen did something like this when he was using
> resting state functional connectivity to find gradients in a subject's
> cortical networks.  He used the PALS flat or spherical map to get a common
> grid onto a standard mesh.  Once there, he projected that grid onto the
> individual's midthickness surface on the standard mesh.  (Like the grid is
> getting folded back up into the individual's anatomical pattern.)  Then he
> unprojected the points to use as seeds for his analysis.
> >
> > Do you mind if I ask how the mean midthickness surface comes into play?
> >
> > Caret's Layers: Borders has options for making grids on the flat map.
>  People make grids on the sphere in matlab.
> >
> > There are caret_command tools for unprojecting borders.
> >
> >  caret_command -surface-border-unprojection
> >
> > Border files differ from border projection files in that they are points
> not tied to a particular mesh.  The advantage is that you can open the same
> border point on, say, a native and 164k mesh, and it will align with both,
> if it aligns with one (and they are identical except for mesh).  The
> advantage of borderproj files is that they open on multiple configurations
> - flat, midthickness, inflated, etc. - but the price is that you're tied to
> a mesh.
> >
> >
> > On Aug 5, 2014, at 10:06 AM, "Tang, Yan"  wrote:
> >
> >> Thank you for your help. Another problem is how to use the Caret
> software to generate  regularly spaced Cartesian grids  on the flattened
> PALS-B12 average surface of the left and right hemispheres.  Can I use this
> 3-dimensional (3D) stereotactic coordinates from the PALS-B12 average
> fiducial (midthickness) surface for each grid location to obtain the voxel
> coordinates (3 × 3 × 3 mm resolution) containing that point in fMRI?
> >>
> >> 
> >> From: caret-users-boun...@brainvis.wustl.edu [
> caret-users-boun...@brainvis.wustl.edu] on behalf of Donna Dierker [
> donna.dier...@sbcglobal.net]
> >> Sent: Friday, August 01, 2014 5:34 PM
> >> To: Caret, SureFit, and SuMS s

Re: [caret-users] Myelin Mapping

[Timothy Coalson]

That file has multiple problems, the first being that it isn't plumb, the
sform/qform have some rotation in them.  Caret5 won't read those kinds of
volumes correctly, and it is nontrivial to try to reverse-generate the
equivalent in the volume space you need it in.  The easiest way to get
something that works may be to first remove obliques from your original T1
volume, and then rerun freesurfer, so that this file is no longer oblique.

However, I'm not clear on why the third volume dimension has a different
number of voxels - you might need to pad your original input volume or
something.  I haven't had to deal with these things in freesurfer, so
someone else should probably give you some guidance.

Tim



On Thu, Jul 31, 2014 at 3:11 PM, SHAHIN NASR 
wrote:

> Hi Timothy,
> That may be the problem. When the output is like this:
>
> ribbon.nii.gz
>
> sizeof_hdr 348
> data_type  INT16
> dim0   3
> dim1   256
> dim2   256
> dim3   176
> dim4   1
> dim5   1
> dim6   1
> dim7   1
> vox_units  mm
> time_units s
> datatype   4
> nbyper 2
> bitpix 16
> pixdim00.00
> pixdim11.00
> pixdim21.00
> pixdim31.00
> pixdim42.529714
> pixdim51.00
> pixdim61.00
> pixdim71.00
> vox_offset 352
> cal_max0.
> cal_min0.
> scl_slope  0.00
> scl_inter  0.00
> phase_dim  0
> freq_dim   0
> slice_dim  0
> slice_name Unknown
> slice_code 0
> slice_start0
> slice_end  0
> slice_duration 0.00
> time_offset0.00
> intent Unknown
> intent_code0
> intent_name
> intent_p1  0.00
> intent_p2  0.00
> intent_p3  0.00
> qform_name Scanner Anat
> qform_code 1
> qto_xyz:1  0.009315  -0.034602  -0.999358  87.028618
> qto_xyz:2  -0.998443  0.054645  -0.011198  162.972198
> qto_xyz:3  -0.054997  -0.997906  0.034039  140.719284
> qto_xyz:4  0.00  0.00  0.00  1.00
> qform_xorient  Anterior-to-Posterior
> qform_yorient  Superior-to-Inferior
> qform_zorient  Right-to-Left
> sform_name Scanner Anat
> sform_code 1
> sto_xyz:1  0.009315  -0.034602  -0.999358  87.028618
> sto_xyz:2  -0.998443  0.054645  -0.011199  162.972198
> sto_xyz:3  -0.054997  -0.997906  0.034039  140.719284
> sto_xyz:4  0.00  0.00  0.00  1.00
> sform_xorient  Anterior-to-Posterior
> sform_yorient  Superior-to-Inferior
> sform_zorient  Right-to-Left
> file_type  NIFTI-1+
> file_code  1
> descripFreeSurfer May 14 2013
> aux_file
>
>
> As you see, dim3 is different than the T1 and T2.  But I used the command
> the command that was mentioned in the instruction to generate ribbon (i.e. 
> mri_convert
> -rl mri/rawavg.mgz mri/ribbon.mgz ribbon.nii.gz).
>
> Any suggestion how to correct this problem?
>
>
>
>
> On Thu, Jul 31, 2014 at 3:08 PM, Timothy Coalson  wrote:
>
>> A quick look at the source shows that the same error text is used when
>> the mask volume doesn't have the same dimensions as the cortical ribbon
>> volume, please check that file also.
>>
>> Tim
>>
>>
>>
>> On Thu, Jul 31, 2014 at 1:31 PM,  wrote:
>>
>>> Matt,
>>>The output of fslhd when i apply it to my T1 and T2 files are as
>>> below:
>>>
>>> For T2:
>>>
>>> filename   T2w.nii.gz
>>>
>>>
>>> sizeof_hdr 348
>>> data_type  INT16
>>> dim0   3
>>> dim1   256
>>> dim2   256
>>> dim3   256
>>> dim4   1
>>> dim5   1
>>> dim6   1
>>> dim7   1
>>> vox_units  mm
>>> time_units s
>>> datatype   4
>>> nbyper 2
>>> bitpix 16
>>> pixdim00.00
>>> pixdim11.00
>>> pixdim21.00
>>> pixdim31.00
>>> pixdim43.200477
>>> pixdim50.00
>>> pixdim60.00
>>> pixdim70.00
>>> vox_offset 352
>>> cal_max0.
>>> cal_min0.
>>> scl_slope  1.00
>>> scl_inter  0.00
>>> phase_dim  0
>>> freq_dim   0
>>> slice_dim  0
>>> slice_name Unknown
>

Re: [caret-users] Myelin Mapping

[Timothy Coalson]

A quick look at the source shows that the same error text is used when the
mask volume doesn't have the same dimensions as the cortical ribbon volume,
please check that file also.

Tim



On Thu, Jul 31, 2014 at 1:31 PM,  wrote:

> Matt,
>The output of fslhd when i apply it to my T1 and T2 files are as below:
>
> For T2:
>
> filename   T2w.nii.gz
>
>
> sizeof_hdr 348
> data_type  INT16
> dim0   3
> dim1   256
> dim2   256
> dim3   256
> dim4   1
> dim5   1
> dim6   1
> dim7   1
> vox_units  mm
> time_units s
> datatype   4
> nbyper 2
> bitpix 16
> pixdim00.00
> pixdim11.00
> pixdim21.00
> pixdim31.00
> pixdim43.200477
> pixdim50.00
> pixdim60.00
> pixdim70.00
> vox_offset 352
> cal_max0.
> cal_min0.
> scl_slope  1.00
> scl_inter  0.00
> phase_dim  0
> freq_dim   0
> slice_dim  0
> slice_name Unknown
> slice_code 0
> slice_start0
> slice_end  0
> slice_duration 0.00
> time_offset0.00
> intent Unknown
> intent_code0
> intent_name
> intent_p1  0.00
> intent_p2  0.00
> intent_p3  0.00
> qform_name Scanner Anat
> qform_code 1
> qto_xyz:1  -1.00  -0.00  -0.00  123.848427
> qto_xyz:2  -0.00  -0.00  1.00  -86.819458
> qto_xyz:3  0.00  -1.00  0.00  136.943146
> qto_xyz:4  0.00  0.00  0.00  1.00
> qform_xorient  Right-to-Left
> qform_yorient  Superior-to-Inferior
> qform_zorient  Posterior-to-Anterior
> sform_name Scanner Anat
> sform_code 1
> sto_xyz:1  -1.00  -0.00  0.00  123.848427
> sto_xyz:2  0.00  -0.00  1.00  -86.819458
> sto_xyz:3  -0.00  -1.00  0.00  136.943146
> sto_xyz:4  0.00  0.00  0.00  1.00
> sform_xorient  Right-to-Left
> sform_yorient  Superior-to-Inferior
> sform_zorient  Posterior-to-Anterior
> file_type  NIFTI-1+
> file_code  1
> descripFSL5.0
> aux_file
>
>
> For T1:
>
> filename   OrigT1.nii.gz
>
> sizeof_hdr 348
> data_type  UINT8
> dim0   3
> dim1   256
> dim2   256
> dim3   256
> dim4   1
> dim5   1
> dim6   1
> dim7   1
> vox_units  mm
> time_units s
> datatype   2
> nbyper 1
> bitpix 8
> pixdim00.00
> pixdim11.00
> pixdim21.00
> pixdim31.00
> pixdim42.529714
> pixdim51.00
> pixdim61.00
> pixdim71.00
> vox_offset 352
> cal_max0.
> cal_min0.
> scl_slope  0.00
> scl_inter  0.00
> phase_dim  0
> freq_dim   0
> slice_dim  0
> slice_name Unknown
> slice_code 0
> slice_start0
> slice_end  0
> slice_duration 0.00
> time_offset0.00
> intent Unknown
> intent_code0
> intent_name
> intent_p1  0.00
> intent_p2  0.00
> intent_p3  0.00
> qform_name Scanner Anat
> qform_code 1
> qto_xyz:1  -1.00  -0.00  -0.00  123.848427
> qto_xyz:2  -0.00  -0.00  1.00  -86.819458
> qto_xyz:3  0.00  -1.00  0.00  136.943146
> qto_xyz:4  0.00  0.00  0.00  1.00
> qform_xorient  Right-to-Left
> qform_yorient  Superior-to-Inferior
> qform_zorient  Posterior-to-Anterior
> sform_name Scanner Anat
> sform_code 1
> sto_xyz:1  -1.00  -0.00  0.00  123.848427
> sto_xyz:2  0.00  -0.00  1.00  -86.819458
> sto_xyz:3  -0.00  -1.00  0.00  136.943146
> sto_xyz:4  0.00  0.00  0.00  1.00
> sform_xorient  Right-to-Left
> sform_yorient  Superior-to-Inferior
> sform_zorient  Posterior-to-Anterior
> file_type  NIFTI-1+
> file_code  1
> descripFreeSurfer May 14 2013
> aux_file
>
>
> > Please paste the output of fslhd on both files.
> >
> > Peace,
> >
> > Matt.
> >
> > From:  SHAHIN NASR 
> > Reply-To:  "Caret, SureFit, and SuMS software users"
> > 
> > Date:  Thursday, July 31, 2014 at 11:18 AM
> > To:  "Caret, SureFit, and SuMS software users"
> > 
> > Subject:  [caret-users] Myelin Mapping
> >
> > Hi,
> >I am trying to do myelin mapping.  I am following your instructions on
> > this website:
> >
> > http://brainvis.wustl.edu/wiki/index.php/Caret:Operations/MyelinMapping
> >
> >and I don't get any error till the last command which says:
> >
> > MYELIN MAPPING ERROR: t1 Dimensions do not match t2 dimensions
> >
> >But when I check the my T1 and T2 files (using mri_info), I do not see
> > any difference:
> >
> > For T1:
> >   type: nii
> > dimensions: 256 x 256 x 256
> >voxel sizes: 1., 1., 1.000

Re: [caret-users] Issue with displaying voxel intensities

[Timothy Coalson]

It is doing that because the FOV is so large compared to the brain - the
total number of positive voxels is only 2.1% of the total number of voxels.
 Thus, the default display of clipping the top and bottom 2% of values
results in a very low "max" for palette scaling.  Changing the Draw Type in
Volume Settings in display control to Min to Max shows the variation in the
data, though a bit darker than what 2% to 98% does on more
approriately-sized volumes.

It should also be noted that ~50% of your voxels are NaN, which are
generally quite unfriendly to computation such as smoothing.

Tim



On Thu, Jun 19, 2014 at 2:41 PM, HINDRIKS, RIKKERT  wrote:

> Hi Donna,
>
> I'm sorry but I am unable to upload the file...
>
> Kind regards,
> Rikkert
>
>
>
> On Thu, Jun 19, 2014 at 5:27 PM, Donna Dierker 
> wrote:
>
>> Hi Rikkert,
>>
>> Please try again.  There was a problem with permissions when I tried just
>> now, but I fixed it.
>>
>> Donnba
>>
>>
>> On Jun 19, 2014, at 1:12 AM, "HINDRIKS, RIKKERT" <
>> rikkert.hindr...@upf.edu> wrote:
>>
>> > Hi Donna,
>> >
>> > I tried to upload the file but am not sure if it worked though.
>> > Please let me know...
>> >
>> > Kind regards,
>> > Rikkert
>> >
>> >
>> > On Wed, Jun 18, 2014 at 8:30 PM, Donna Dierker <
>> do...@brainvis.wustl.edu> wrote:
>> > Hi Rickert,
>> >
>> > Assuming you used File: Open Data File: type = Volume Anatomy File, you
>> should see a normal T1w image.
>> >
>> > If you see solid white, then please upload the volume here, so we can
>> try to replicate the problem:
>> >
>> > http://pulvinar.wustl.edu/cgi-bin/upload.cgi
>> >
>> > Donna
>> >
>> >
>> > On Jun 18, 2014, at 12:32 PM, "HINDRIKS, RIKKERT" <
>> rikkert.hindr...@upf.edu> wrote:
>> >
>> > >
>> > > Dear all,
>> > >
>> > > When I load a T1-weighted scan into Caret, the image looks like a
>> mask, that is, all white voxels covering the brain. The voxel intensities
>> themselves are, however, nicely distributed and the grey and white matter
>> peaks are clearly visible. Also, the intensities are normalized between 0
>> and 255. This problem does not occur when I view the scan with MRIcron or
>> SPM. Does anyone know what is going on here?
>> > >
>> > > Thanks alot,
>> > > Rikkert
>> > > ___
>> > > caret-users mailing list
>> > > caret-users@brainvis.wustl.edu
>> > > http://brainvis.wustl.edu/mailman/listinfo/caret-users
>> >
>> >
>> > ___
>> > caret-users mailing list
>> > caret-users@brainvis.wustl.edu
>> > http://brainvis.wustl.edu/mailman/listinfo/caret-users
>> >
>> > ___
>> > caret-users mailing list
>> > caret-users@brainvis.wustl.edu
>> > http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>
>>
>> ___
>> caret-users mailing list
>> caret-users@brainvis.wustl.edu
>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] mapping fMRI data to surface

[Timothy Coalson]

wb_command -metric-smoothing does have better smoothing methods,
particularly GEO_GAUSS_AREA, which takes into account variation in vertex
area.

You will also need to rename the converted file to .func.gii if
you want to view it in workbench rather than caret.

I would also suspect that your volume was smooth to begin with for your
metric to be that smooth after mapping, but I haven't used MFM, so I don't
know what smoothness to expect from that, if that is what you did.

Tim



On Mon, Mar 31, 2014 at 11:17 AM, Donna Dierker wrote:

> I definitely would NOT write to the caret/data_files directory.  You can
> copy from it, but messing with those files is not a good idea, even if the
> permissions allow you to do so.  Caret uses files in that directory to do
> its job, so if you modify them, things will break.
>
> Under Attributes: Metric there are many smoothing options, but
> caret_command has this feature:
>
>   caret_command -metric-smoothing
>  
>  
>  
>  
>  
>  
>  
>
>  [-geo-gauss sigma]
>
>  [-fwhm  desired-full-width-half-maximum]
>
>  [-gauss   spherical-coordinate-file-name
>sigma-norm
>sigma-tang
>norm below cutoff (mm)
>norm above cutoff (mm)
>tang-cutoff (mm)]
>
>  [-parallel]
>
>  Smooth metric data.
>
>  "smoothing-algorithm" is one of:
> AN  Average Neighbors
> DILATE  Dilation
> FWHMFull-Width Half-Maximum
> GAUSS   Gaussian, requires -gauss
> GEOGAUSS   Geodesic Gaussian, uses -geo-gauss, default 2.0
> WAN Weighted Average Neighbors
>
> NOTE: Geodesic Gaussian IGNORES the strength parameter,
>amount of smoothing is controlled solely by sigma and
>iterations.  The intent is to do one iteration of
>smoothing, with the sigma specifying how much smoother
>the metric is desired to be.
>
> I suspect wb_command has even better smoothing (seem to recall Tim C
> saying something along those lines, but I can't recall the details).  This
> command line utility is part of Caret Workbench and needs a different
> format -- GIFTI or CIFTI.  You can convert caret5 metric to GIFTI by doing:
>
> caret_command -file-convert -format-convert XML_BASE64_GZIP my_file.metric
>
> At least I think that is what Tim C. told me. ;-)
>
>
> On Mar 31, 2014, at 10:38 AM, "Cheng, Hu"  wrote:
>
> > Hi Donna,
> >
> > I loaded the atlas first, then I was able to see the mapping using "Map
> to Caret". In the software it shows the metric file is added to the spec
> file if using "Map to Spec File With Atlas", maybe it's forbidden to add
> file to caret/data_files/standard_mesh_atlases/Human.PALS.LEFT?
> > Now I have the metric file, could you tell me how to smooth it or is
> there any way to convert it back to freesurfer which I know how to do
> smoothing?
> > Many thanks!
> >
> > Regards,
> >
> > Hu
> >
> >
> > -Original Message-
> > From: caret-users-boun...@brainvis.wustl.edu [mailto:
> caret-users-boun...@brainvis.wustl.edu] On Behalf Of Donna Dierker
> > Sent: Monday, March 31, 2014 11:07 AM
> > To: Caret, SureFit, and SuMS software users
> > Subject: Re: [caret-users] mapping fMRI data to surface
> >
> > Hi Hu,
> >
> > No, there's no log file, but if you check Debug Enabled (File:
> Preferences), all sorts of stuff will scroll to the terminal window from
> which Caret was launched.
> >
> > I assume you have made sure your working directory is writable by the
> user running Caret.  File: Set Working Directory can show you what Caret
> thinks the working directory is.
> >
> > Donna
> >
> >
> > On Mar 31, 2014, at 9:54 AM, "Cheng, Hu"  wrote:
> >
> >> Hi Donna,
> >>
> >> Thank you! There is no non-English character set on the mac. I just
> wonder if there is a log file so that I can see what's wrong.
> >>
> >> Regards,
> >>
> >> Hu
> >>
> >>
> >> -Original Message-
> >> From: caret-users-boun...@brainvis.wustl.edu [mailto:
> caret-users-boun...@brainvis.wustl.edu] On Behalf Of Donna Dierker
> >> Sent: Friday, March 28, 2014 5:07 PM
> >> To: Caret, SureFit, and SuMS software users
> >> Subject: Re: [caret-users] mapping fMRI data to surface
> >>
> >> Do you have a non-English character set installed on this computer?  We
> have had issues with writing metric files when a non-English character set
> was installed, but the error I recall was worded slightly different.
> >>
> >>
> >> On Mar 28, 2014, at 1:22 PM, Cheng, Hu wrote:
> >>
> >>> Dear Caret users,
> >>>
> >>> I'm trying to map fMRI data to surface template and do surface based
> smoothing. The fMRI data I used were already normalized in spm8. I ran
> attribute "Map Volumes(s) to Surface(s)" accordingly to
> http://brainvis.wustl.edu/wiki/index.php/Caret:Operations/MapVolumeToSurface,
>

Re: [caret-users] caret-users Digest, Vol 124, Issue 15

[Timothy Coalson]

Completely removing sform and qform will result in a volume with
coordinates (0, 0, 0) at a corner of the FOV, this is almost certainly not
what you want.  What you probably want is the sform and qform to both be
valid, and to match, and the matrix to have zeros except on the diagonal
and last column (and last row is always 0 0 0 1), something like this:

...
qto_xyz:1  -1.00  0.00  0.00  84.904289
qto_xyz:2  0.00  1.00  0.00  -55.609478
qto_xyz:3  0.00  0.00  1.00  -135.906647
qto_xyz:4  0.00  0.00  0.00  1.00
...
and the same exact values for the sform matrix

I don't think the exact values of the last column matter much at this
point, since I don't think you've done volume registration yet.

Tim



On Fri, Mar 28, 2014 at 3:09 PM, Matt Glasser  wrote:

> All that matters is that they are not oblique.  If they are oblique
> FreeSurfer, FSL, and Caret will not work well together.  I don¹t know that
> setting the code is sufficient.
>
> Peace,
>
> Matt.
>
> On 3/28/14, 2:44 PM, "Righart, Ruthger" 
> wrote:
>
> >Dear Matt
> >I removed the sform from the t1.nii, before mri_convert makes it
> >001.mgz, so at the start of Freesurfer (sform_code='0').
> >But do I understand correctly from your mail that both sform and qform
> >should be removed? (i.e., sform_code='0' and qform_code='0' in the
> >header). If so then that might be the reason.
> >Best,
> >Ruthger
> >
> >Le 2014-03-28 18:00, caret-users-requ...@brainvis.wustl.edu a écrit :
> >> Send caret-users mailing list submissions to
> >>  caret-users@brainvis.wustl.edu
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >>  http://brainvis.wustl.edu/mailman/listinfo/caret-users
> >> or, via email, send a message with subject or body 'help' to
> >>  caret-users-requ...@brainvis.wustl.edu
> >>
> >> You can reach the person managing the list at
> >>  caret-users-ow...@brainvis.wustl.edu
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of caret-users digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >>1. Re: Surface-Volume registration (Matt Glasser)
> >>
> >>
> >>
> >> --
> >>
> >> Message: 1
> >> Date: Fri, 28 Mar 2014 09:58:32 -0500
> >> From: Matt Glasser 
> >> To: "Caret, SureFit, and SuMS software users"
> >>  
> >> Subject: Re: [caret-users] Surface-Volume registration
> >> Message-ID: 
> >> Content-Type: text/plain;charset="US-ASCII"
> >>
> >> Did you remove the sform and qform at the beginning of the process
> >> (i.e.
> >> before FreeSurfer)?
> >>
> >> Peace,
> >>
> >> Matt.
> >>
> >> On 3/28/14, 9:04 AM, "Righart, Ruthger" 
> >> wrote:
> >>
> >>>Dear Caret experts,
> >>>
> >>>I am working on myelin mapping but encounter errors in surface-volume
> >>>registration, as previously reported in this list.
> >>>
> >>>I have removed oblique sforms from the t1.nii and t2.nii files
> >>>(sform_code='0' and qform='1', the new headers have equal matrices
> >>> for s
> >>>and q).
> >>>I have the impression that the first error occurs after the command:
> >>>
> >>>applywarp --interp=spline -i OrigT2w.nii.gz -r T1w.nii.gz
> >>>--premat=T2w2T1wbb.mat -o T2w2T1w_translated.nii.gz
> >>>
> >>>Please find attached an fslview for the translated and non-translated
> >>>images. The translated image is not centered and from the
> >>> non-translated
> >>>images a piece of the left hemisphere is cut-off (I wondered if this
> >>> has
> >>>anything to do with the coordinate space, Scanner Anat(1) or Aligned
> >>>Anat(2) in the headers?). I would welcome your suggestions to solve
> >>> this
> >>>problem. I am working with Caret v5.65 on a Linux machine. Thank you
> >>>very much in advance!
> >>>
> >>>Ruthger___
> >>>caret-users mailing list
> >>>caret-users@brainvis.wustl.edu
> >>>http://brainvis.wustl.edu/mailman/listinfo/caret-users
> >>
> >>
> >>
> >>
> >> --
> >>
> >> ___
> >> caret-users mailing list
> >> caret-users@brainvis.wustl.edu
> >> http://brainvis.wustl.edu/mailman/listinfo/caret-users
> >>
> >>
> >> End of caret-users Digest, Vol 124, Issue 15
> >> 
> >___
> >caret-users mailing list
> >caret-users@brainvis.wustl.edu
> >http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

[caret-users] Fwd: libstdc++ version and caret5

[Timothy Coalson]

Putting this conversation back on the list to let others know.

Short version: the download page now has an additional link to a version
compiled on redhat.

Tim

-- Forwarded message --
From: Caspar M. Schwiedrzik 
Date: Tue, Feb 4, 2014 at 12:33 PM
Subject: Re: [caret-users] libstdc++ version and caret5
To: John Harwell 
Cc: Donna Dierker , David Van Essen <
vanes...@wustl.edu>, Timothy Coalson 


Hi John,
thank you very much!
To a first approximation, the Redhat version you provide now runs on our
system.
Caspar



2014-02-04 John Harwell :

Caspar,
>
> The last compilation of the Linux distributions may have been on an Ubuntu
> system and not RedHat.
>
> An additional link has been added to the download page (
> http://brainvis.wustl.edu/wiki/index.php/Caret:Download) for a version
> that is compiled on a RedHat system with an Intel compiler.  You can try it.
>
> There is a link to the source code.  But beware, building Caret5 requires
> both Qt and VTK libraries.
>
> John
>
> On Feb 3, 2014, at 5:52 PM, Timothy Coalson wrote:
>
> It seems like the LinuxIntel64 distribution of caret is built on redhat,
> while the ones we link on the download page may be built on ubuntu (has
> similar version information to the non-redhat builds of workbench).  Is
> there some problem with making the intel build available (legal issues,
> or...)?
>
> Tim
>
>
> -- Forwarded message --
> From: Caspar M. Schwiedrzik 
> Date: Fri, Jan 31, 2014 at 2:52 PM
> Subject: [caret-users] libstdc++ version and caret5
> To: caret-users@brainvis.wustl.edu, Pablo Polosecki <
> ppolose...@mail.rockefeller.edu>
>
>
> Hi!
> We are having trouble getting Caret to start on our Linux system.
> It complains about the version number of libstdc++. Explicitly adding the
> path to bashrc did not improve things. Our IT support claims that we have a
> newer version installed and would like to know if you have compiled a
> supported RHEL5 version or provide the source so we can do it. Please see
> details in the attached email below.
> We are running Red Hat Enterprise Linux Server release 5.9 (Tikanga).
> Thanks!
> Caspar
>
>
>
>
>
> -- Forwarded message --
>
>
> Hi
>
> I don't think this is an age issue.
>
> compat-libstdc++-33-3.2.3-61.x86_64 is THE 3.x version libstdc++ for
> redhat 5.
>
> compare your binary
>
> ./caret5: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
> GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped
>
> to as an example ssh
>
> /usr/bin/ssh: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV),
> for GNU/Linux 2.6.9, stripped
>
> Notice the native file has a higher number.
>
> Here is redhat's document on C version numbers.
>
> https://access.redhat.com/site/documentation/en-US/Red_
> Hat_Enterprise_Linux/6/html/Developer_Guide/libraries.html
>
> libstdc++ 3.4.x is standard on the decommissioned unsupported RHEL 4.
>
> So it wants a version of Linux that is older than supported.  Of course
> there is a compatibility lib for redhat, libstdc++.  It's ported directly
> from RHEL 4, but the version of C that caret5 wants was never supported
> there.
>
> This is as far as RHEL 4 ever went.
>
> libstdc++-devel-3.4.6-11.el4_8.1
>
> I don't think this binary program was ever supported on Redhat. Perhaps
> compiled on Debian? Those versions were not even available on RHEL 4.  You
> should contact the developer and ask him if he can compile a supported
> RHEL5 version or provide the source so you can do it.  Usually binary
> programs need to be compiled for a specific distro RHEL5, RHEL6, etc.
>
> I checked the support file (from the README)
>
> No information about distros or versions.
> http://brainvis.wustl.edu/CaretHelpAccount/caret5_help/
> installation/caret5_installation.html
>
> Sorry I don't think we can help without knowing what it was compiled for.
>  Even then it may require a whole separate installation of Linux to run it.
>
> Matt
>
> REF:188754
>
> --
> Matthew Newhall
> mnewh...@rockefeller.edu
> (212)327-8758
>
> In the spirit of expediency please send any requests for new work not
> already associated with a ticket to helpd...@rockefeller.edu.  Thank
> you for your cooperation.
>
>
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] not able to down Myelin_Mapping_Documentation_v2.doc

[Timothy Coalson]

You don't use your email as the user, you use the login name from the
registration email (right above the password).

Tim



On Wed, Jan 29, 2014 at 4:14 PM, Ping-Hong Yeh wrote:

> Hi Caret Users,
>
> I was not able to login to access the Myelin_Mapping_Documentation_v2.doc
> poseted on The http://brainvis.wustl.edu/wiki/index.php/Caret:MyelinMaps.
> I had tried my email address and my name for the usr and the assigned pwd,
> but none was successful.
>
> Thank you,
>
> Ping
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] Using caret_stats for TFCE

[Timothy Coalson]

>From what I remember of the issue, some JREs were holding onto memory that
should have been deallocated, which eventually fills the memory pool and
crashes, while the good JREs kept their memory usage fairly constant.  The
issue was solved in Sun's java before the default java debian/ubuntu
install, but I think it got solved in that one also in more recent
versions.  If all else fails, you could try updating to the latest
available JRE.

Note that you may have multiple versions of java installed, and may need to
configure which one is used by default, for instance
http://java.dzone.com/articles/choosing-java-version-ubuntu .

Tim



On Thu, Jan 23, 2014 at 9:04 AM, Donna Dierker wrote:

> This sounds very much like a problem I had before switching JRE's.  This
> version has been known to work with Ubuntu 10.10, Ubuntu 10.10, Linux it
> 2.6.35-32-generic #67-Ubuntu SMP Mon Mar 5 19:39:49 UTC 2012 x86_64
> GNU/Linux:
>
> java version "1.6.0_21"
> Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
> Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)
>
> Tim Coalson believed the problem was somehow related to a cache size.
>  Once it reached that cache size, then java performance plummeted, as you
> saw.  Switching JRE's fixed the problem, and I don't have a non-java TFCE
> version I can send you.
>
>
> On Jan 22, 2014, at 4:27 PM, Eshita Shah  wrote:
>
> > Yes, it works fine at 1000 iterations. I am trying to run 5000. It seems
> to get really slow after 1000, but continues on to about 2600 until it
> crashes.
> >
> >
> > On Wed, Jan 22, 2014 at 2:13 PM, Donna Dierker 
> wrote:
> > How many iterations did you specify?  Have you tried it with 1000
> iterations?
> >
> >
> > On Jan 22, 2014, at 3:09 PM, Eshita Shah  wrote:
> >
> > > Hi Donna,
> > >
> > > I have been trying to allocate more memory to caret_stats so it can
> run java properly without crashing. However, this has not worked. I just
> downloaded the JRE you provided, and it is actually the same one that I am
> using.
> > >
> > > Do you think there is another source of this problem?
> > >
> > > Thank you,
> > > Eshita
> > >
> > >
> > > On Wed, Jan 15, 2014 at 7:23 PM, Donna Dierker <
> donna.dier...@sbcglobal.net> wrote:
> > > At the end of the TFCE processing, you should get a text file named
> something like *report.txt, along with a *ignif*metric.  If you don't, then
> it's not finishing normally.
> > >
> > > How many iterations are you using?  If it doesn't finish overnight
> with 5k iterations, then it might be your java runtime engine.  Before I
> started using this one, my java runtime engine just hung or grinded to a
> near halt after a few thousand iterations:
> > >
> > > http://brainmap.wustl.edu/pub/donna/US/WVU/linux_java.zip
> > > login pub
> > > password download
> > >
> > > You can use others; just be aware that the JRE can be an obstacle.
> > >
> > >
> > > On Jan 15, 2014, at 3:32 PM, Eshita Shah  wrote:
> > >
> > > > Hi Donna,
> > > >
> > > > I am running a script you sent me a while ago, which uses
> caret_stats to run ANOVA and then TFCE for significant cluster analysis. I
> am noticing that the output files generated after running the script do not
> match up to the expected outputs. I am seeing files such as
> ".metric.data1", ".metric.data2", etc. I'm not sure where they are coming
> from - my hunch is that the script is being aborted at some point (because
> I am not getting any of the TFCE outputs), but I'm not exactly sure why
> these files would be generated or what they are.
> > > >
> > > > Please let me know if you have any ideas.
> > > >
> > > > Thank you,
> > > > Eshita
> > > >
> > > > --
> > > > Eshita Shah
> > > > University of California, Los Angeles | 2014
> > > > B.S. Neuroscience
> > > > eshs...@ucla.edu
> > > >
> > > >
> > > > ___
> > > > caret-users mailing list
> > > > caret-users@brainvis.wustl.edu
> > > > http://brainvis.wustl.edu/mailman/listinfo/caret-users
> > >
> > >
> > > ___
> > > caret-users mailing list
> > > caret-users@brainvis.wustl.edu
> > > http://brainvis.wustl.edu/mailman/listinfo/caret-users
> > > ___
> > > caret-users mailing list
> > > caret-users@brainvis.wustl.edu
> > > http://brainvis.wustl.edu/mailman/listinfo/caret-users
> >
> >
> > ___
> > caret-users mailing list
> > caret-users@brainvis.wustl.edu
> > http://brainvis.wustl.edu/mailman/listinfo/caret-users
> >
> >
> >
> > --
> > Eshita Shah
> > University of California, Los Angeles | 2014
> > B.S. Neuroscience
> > eshs...@ucla.edu
> >
> >
> > ___
> > caret-users mailing list
> > caret-users@brainvis.wustl.edu
> > http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/

Re: [caret-users] ribbon generation

[Timothy Coalson]

I think we may have intended workbench-related things to go on hcp-users,
but I'm not sure.

At any rate, -create-signed-distance-volume and -volume-math will allow you
to do something like what you want.  The first creates the signed distance
function in whatever voxel grid you tell it to, as it takes a template
volume to get the voxel grid.  Make this for both white and pial surfaces,
and then use -volume-math to threshold and "and" the results (via
multiplication, like "(x > 0) * (y < 0)").

If you want voxels to be included/excluded by their centers, use a
threshold of 0, or you can use something like half the voxel diagonal to
exclude any voxel that could possibly have even a corner outside the ribbon
(though that could exclude some voxels that are entirely inside the ribbon,
as it doesn't actually do voxel/surface intersection, it just calculates
signed distance at voxel centers).  I think Matt has done this, but I don't
recall what threshold he used.

Tim



On Wed, Oct 23, 2013 at 3:50 PM, Colin Reveley  wrote:

> I think this one is for the caret list really.
>
> I wonder, is there a way using wb_command to generate a ribbon volume
> suitable for myelin mapping, from a pair of surfaces?
>
> Unfortunately, caret "make segmentation from surface" seems to lack the
> required precision. It seems I've been operating with that issue for a long
> time without fully realising it.
>
> fressurfer mris_fill works very well. Unfortunately, the nature of the
> data is such that generating conformed output and reslicing is not possible
> without downsampling all the volumes to be mapped. And that basically won't
> do it turns out.
>
> one can generate surface fills that are the exact minimum voxel dimensions
> of the ribbon with mris_fill though. and they look great. Perfect.
>
> But I simply just cannot figure out how to resize that output and give it
> the appropriate header so that it's the same size, shape, alignment as the
> data volume to be mapped with caret and/or workbench myelin mapping.
>
> It strikes me that the 700um HCP structural pipeline or related primate
> pipelines that deal with non-1mm data might in some way have addressed this
> matter.
>
> It seems like the ribbon voxels are key here. I've traced my problems to
> having an accurate ribbon.
>
> I can get one, but I can't figure out how to size and align it when I
> can't use mris_fill -c
>
> best,
>
> Colin Reveley
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] cifti math mem

[Timothy Coalson]

It should compute it one row at a time, so as long as you have enough rows
that it divides the total cifti file into a managable row size, you should
be fine.  You can always try it on your local machine, and see if it starts
allocating swap (cifti-math, along with the other math commands, aren't
parallel anyway, it should usually be IO bound since the amount of
processing to do is exactly proportional to the size of the data files, so
unless you are running multiple commands in parallel, it probably doesn't
need to be on a cluster).  In general, I try to write cifti commands so
that they compute/write cifti files one row at a time during computation,
so they don't use as much memory.  Correlation is a notable exception,
since the output is symmetric, retaining some/all of the results in memory
allows it to finish faster.

Note, however, that metric/volume inputs/outputs always use the memory of
the uncompressed data (we don't do on-disk reading/writing for them), and
most cifti commands that do spatial things like smoothing or gradient
separate the cifti into in-memory metric/volume files one at a time, which
may take a fair amount of memory.

I hadn't thought of making a "count nonzero" reduce operation, but it is
rather easy to add more reduce operations.

Tim



On Sat, Oct 5, 2013 at 11:07 AM, Colin Reveley  wrote:

> Hi -
>
> I'm wondering (before I try and damage remote equipment)
>
> when running wb_command -cifti-math
>
> is it necessary that the cifti(s) fit into RAM memory?
>
> what I want to do is take a very large dconn.nii file, and binarize it
> such that all non-zero entries are 1 and all 0 entries stay 0.
>
> this is, obviously, an intermediate step to something else (tracking stats
> from vertex seeds).
>
> In an ideal world I'd also like to divide the value in each cell by
> another cifti of the same dimensions.
>
> if -cifti-math is able to avoid RAM (like cifti-reduce) then great. If not
> I need another way or I risk disrupting the university cluster.
>
> the basic task is to replace all non-zero entries with 1 without requiring
> more than say 1/10 of the file size in RAM.
>
> if that is not possible then, if we call the binarised cifti above "A"
> then the output of -cifti-reduce A.dconn.nii SUM
>
> obtained by any means would be great and a big help
>
> obviously there is more detail to the problem/questions that might help.
> But I'm trying not to explicitly be "unsupported" at this point in case the
> question can be answered in a "supported" way.
>
> best,
>
> Colin
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] transforming surf.gii

[Timothy Coalson]

Warping the vertices should not need to change the faces, so that shouldn't
be a problem.  That scrambling makes me wonder if something is getting the
endianness wrong, are the values extremely large?

If you can put your warpfield into a 3-brick nifti volume, with format of
relative x, y, and z offset (relative shifts), you should be able to get
wb_command to apply the warp with -surface-apply-warpfield (as the command
help says, make sure it is the inverse of the warpfield used to resample a
volume), assuming it uses the nifti sform/qform for alignment to the
surface.

Tim



On Thu, Aug 22, 2013 at 4:33 PM, Colin Reveley  wrote:

> I should say: it loads in workbench. it just doest work.
>
> images (gifti in matlab, same in workbench) attached. also the header I'm
> trying to load. You'll see the header has quite a lot of detritus.
>
> best
>
> Colin
>
>
> On 22 August 2013 22:24, Colin Reveley  wrote:
>
>> hi.
>>
>> we have a system (a bespoke system) for non-linear registration of
>> volumes.
>>
>> we wondered if we could take the output transform and use that data to
>> shift the vertices of a surf.gii so that it's transformed.
>>
>> much like wb_command and fnirt.
>>
>> we tried it. in matlab (using gifti lib) it works.
>>
>> unfortunately the resulting surface renders in matlab, but when saved not
>> in caret or workbench.
>>
>> there are a million reasons why that could be. And I'm happy to mess with
>> the headers till it works.
>>
>> but before i do I wondered if there might be an in-principle problem:
>>
>> we move the vertices. but the face definitions remain the same, as in
>>
>> gii =
>>
>> vertices: [211995x3 single]
>>  mat: [4x4 double]
>>faces: [423986x3 int32]
>>
>> is that the basic problem, or is it just a question of messing with the
>> xml till caret or workbench accepts it?
>>
>> I accept it's complicated. But our code does appear to work in terms of
>> moving vertices and aligning to a nifti within matlab, so unless the face
>> definitions are the fundamental issue for loading in caret5/7 (mainly
>> caret5 for the moment) I can just twiddle with headers till it loads
>> hopefully.
>>
>> but if it's the faces I have a bigger problem.
>>
>> best wishes
>>
>> Colin
>>
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] wb functionality

[Timothy Coalson]

Inline replies.

Tim


On Sun, Jul 14, 2013 at 12:23 PM, Colin Reveley  wrote:

> Hi - I have a few questions about WB functionality and plans for
> functionality
>
> a) what is the position on flatmaps? can these be displayed (e.g. made in
> CARET5, saved as "surf.gii", will they work? what if the flat coord file
> has fewer nodes than the original mesh, which is fine in caret5)
>

You can always load any valid gifti surface.  I believe we added something
that disables rotation when a surface marked as a flatmap is loaded, making
it more convenient to view it.  I think we are going to try to avoid cut
surfaces of any variety in our future studies, but it has been requested by
others.


> b) there's a nice facility to specify a distance from the white or pial
> surface and make an average "laminar approximate" surface at that distance.
>
> but laminae vary in thickness. If one specified multiple distances from
> the WM at different points on the mesh (with ROIs and e.g. a spline) it
> could be possible to more accurately follow actual laminar lines in high
> resolution MRI. I guess that is more of a thought than a question. It would
> be really useful.
>

If you mean -surface-cortex-layer, it doesn't take a distance, it
calculates the placement based on a specified fraction of volume
above/below the placement of the new surface (based on the same idea as
https://www.sciencedirect.com/science/article/pii/S1053811913003480, but
implemented differently).  There is also -surface-average you can trick
into providing a simple weighted average of a fixed fraction by repeating
surfaces.  We haven't done much with surface modification/creation commands
yet, there isn't one that takes an arbitrary placement metric.

c) most importantly: given an FSL BEDPOSTX model, one can "estimate fiber
> binghams" and also  "Takes precomputed bingham parameters from volume files
> and converts them
>   to the format workbench uses for display."
>
> in either case: how does one actually do that? what does the display look
> like?
>

It currently uses a temporary file format, so we aren't encouraging people
to do this yet.


> there is -cifti-create-label and -cifti-convert
>

-cifti-convert just exports the data matrix of a cifti file as something
else so that other software that can't read cifti can still use its data.


> if one has a GM/WM segmentation, made by e.g. FAST, how can one generate a
> suitable cifti from it to pass to "-estimate-fiber-binghams?
>
> and does it actually matter to -estimate-fiber-binghams what the labels
> (WM or GM) are? does it treat GM labelled regions somehow differently?
>
> I probably don't want to do that (treat them differently in any way).
>

No, it doesn't care which actual structures are used, it is just to specify
the cifti volume space - it matches this space with the trajectory file to
ensure that it doesn't try to render trajectories in the wrong fiber file.
Again though, these use temporary formats at present, so I probably
shouldn't say how to do it with current commands on the list.


> It would certainly be nice to display mean fibre orientations as little
> vetors like caret_command -map-fsl etc
>

The current display has options for displaying the bingham as squashed
cones, or the set of all samples as lines (though that gets rather slow).
The more interesting display option is using the tractography data to
select which orientations to show.


> But it seems like there more to this. I can't quite get a grasp on it. I'd
> like to have a look.
>
> The latest stuff is great. Thanks. especially applying flirt transforms to
> surfs that's really wonderful.
>

Glad to see some interest.  You can also convert the flirt transforms to a
more intuitive format (that you can use directly via matrix multiplication
with coordinates) with -convert-affine.  You can also use fnirt warpfields
on surfaces, though you will need to use their tools to invert them first.
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] wb FSL fibre volume display

[Timothy Coalson]

Actually, it is probably more my area to answer this.  Inline replies.

Tim

On Fri, Jun 14, 2013 at 1:40 PM, Colin Reveley  wrote:

> Hi - I guess this is a question specificially for matt.
>
> I have some FSL processed diffusion data. I want to display the mean fibre
> orientations in "little colored lines on top of a volume" format.
>
> fslview does this. it's very common. the problem is that the data is very
> high resolution. So you really can't see the little lines if you print the
> image from FSLview.
>
> One way around this is caret_command -volume-fsl-to-vector
>
> I accept this is unsupported. but it does provide a better display for my
> needs in that the way the vectors appear on the screen is more configurable
> and generally makes a better figure.
>
> only:
>
> that command works and thinks in terms of axial slices and the display is
> interms of distances above and below the axial plane.
>
> this means that in coronal view it can end up looking a bit off.
>
> I was wondering:
>
> surely workbench now has a neat-o way of displaying fibers?
>
> it looks like it does.
>
> but how to get the data in there?
>
> there is
>
> wb_command -estimate-fiber-binghams
> and
> wb_command -convert-fiber-orientations
>

-estimate-fiber-binghams is probably what you want,
-convert-fiber-orientations is for when diffusion processing estimates
binghams directly, which I'm not sure is released yet.


>
> since bedpostx does not output ka or kb (or std_dev normally, maybe it
> does in some circumstances) I presume the former command serves as input to
> the latter in some way
>

No, they have the same kind of output, but different input.


> how exactly would that work, to create a nice volume display of fibers in
> workbench? in particualar, the input to -est-fib-bing requires a label
> volume. is this a volume of integers? where is the specification of what
> the CIFTI idenifiers (eg CORTEX RIGHT) actually map to as numbers?
>

There are no fixed numbers, it uses the strings, you just have to generate
a workbench style label volume with those strings as the label names.
 However, there are fixed numbers for the freesurfer parcellations of the
corresponding structures, and matt may be able to help you there.
 Alternatively, you can just take a white matter segmentation volume and
assign something appropriate to the "true" value (usually 1).


> generally, is it possible to make a fiber file for display in WB given
> suitable data, and e.g. a FAST segmantation relabelled to the CIFTI
> itentifier values?
>

Strings, not values, and yes, it doesn't care where it comes from, it just
has to match the volume space of the fiber data.


> Given my goals as described above, do I even want to be trying this?
>

I don't see why not.  There are a few options in fiber display in
workbench, and the fibers are in free space, rather than realigned to voxel
centers, which sounds like a problem you were having.
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] label volume mapping

[Timothy Coalson]

There is the nifti c library:

http://niftilib.sourceforge.net/

I haven't really looked at it, so I don't know how easy it makes it, but
even just the nifti1 header has enough documentation (and the format is
simple enough) that you could write your own, if you are so inclined.

Tim



On Wed, May 29, 2013 at 9:50 PM, Colin Reveley  wrote:

> Is there any code anywhere to just open a nifti header with caret
> extensions and just mess with those extensions in a programming language?
> (C is a programming language. C would be fine. Optimal possibly)
>
> since when one loads a paint volume you can generate a header with names
> "region_1 region_2 etc" and those integers correspond to the voxel values
> caret has read then: then one could just substitute those names for the
> names that are actually required.
>
> I just don't know how to access the header (the caret label volume
> specific bit).
>
> Come what may, it might behove us to have a robust, controlled (by us)
> distributable method of doing this in software that we can be confident
> of distributing to users in a way that is automated.
>
> Good Software Engineering Practice. Or something.
>
> best,
>
> Colin
>
>
>
>
>
> On 30 May 2013 02:52, Colin Reveley  wrote:
>
>> Hi  -
>>
>> re: wb_command -volume-label-import
>>
>> what it appears to do is just vaporize the header.
>>
>> However, much could have gone wrong. The input volume is wholly
>> constructed in software (mainly imageJ and inhouse C) and is probably weird
>> (although it's been saved in CARET before trying to run this. I tried both
>> ways. header below has been through caret). and maybe I've got the format
>> of the label list wrong.
>>
>> I note that the output of the command is a float volume. I was pretty
>> sure paint volumes had to be unsigned char. I tried both float and uchar as
>> inputs anyway.
>>
>> my input header looks something like this. and my label file looks like
>> what follows under the header
>>
>> thanks for advice
>>
>> I appreciate it may not work. That is ok. It was a bit too good to be
>> true anyway. it doesn't dump core, or give an error (or any info at all).
>> it just thinks for a bit, removes most info from the header and outputs a
>> float volume
>>
>> actually there's probably a debug swtich. I'll look at that now.
>>
>> thanks,
>>
>> Colin
>>
>> sizeof_hdr: 348
>>  data_type:
>>db_name:
>>extents: 0
>>  session_error: 0
>>regular: r
>>   dim_info: 0
>>dim: 3 137 347 245 1 1 0 0
>>  intent_p1: 0.000
>>  intent_p2: 0.000
>>  intent_p3: 0.000
>>intent_code: 1002
>>   datatype: 2
>> bitpix: 0
>>slice_start: 0
>> pixdim: 1.000 0.250 0.250 0.250 0.000 0.000 0.000 0.000
>> vox_offset: 41760.000
>>  scl_slope: 1.000
>>  scl_inter: 0.000
>>  slice_end: 0
>> slice_code: 0
>> xyzt_units: 0
>>cal_max: 0.000
>>cal_min: 0.000
>> slice_duration: 0.000
>>toffset: 0.000
>>  glmax: 0
>>  glmin: 0
>>description:
>>
>>   aux_file:
>> qform_code: 3
>> sform_code: 3
>>  quatern_b: 0.000
>>  quatern_c: 0.000
>>  quatern_d: 0.000
>>  qoffset_x: -2.750
>>  qoffset_y: -48.750
>>  qoffset_z: -26.500
>> srow_x: 0.250 0.000 0.000 -2.750
>> srow_y: 0.000 0.250 0.000 -48.750
>> srow_z: 0.000 0.000 0.250 -26.500
>>intent_name:
>>  magic: n+1
>>
>> Intent Name:  NIFTI_INTENT_LABEL
>> Intent Parameters:Label index
>>
>>First Voxel XYZ (method 1): 0.000, 0.000, 0.000
>>Spacing: 0.250, 0.250, 0.250
>>
>> QFORM: NIFTI_XFORM_TALAIRACH
>>   1.000   0.000   0.000   0.000
>>   0.000   1.000   0.000   0.000
>>   0.000   0.000   1.000   0.000
>>   0.000   0.000   0.000   1.000
>>Orientation: Left to Right, Posterior to Anterior, Inferior to Superior
>>First Voxel XYZ (Method 2): -2.750, -48.750, -26.500
>>Spacing: 0.250, 0.250, 0.250
>>
>> SFORM: NIFTI_XFORM_TALAIRACH
>>   0.250   0.000   0.000  -2.750
>>   0.000   0.250   0.000 -48.750
>>   0.000   0.000   0.250 -26.500
>>   0.000   0.000   0.000   1.000
>>Orientation: Left to Right, Posterior to Anterior, Inferior to Superior
>>First Voxel XYZ (Method 3): -2.750, -48.750, -26.500
>>Spacing: 0.250, 0.250, 0.250
>>
>> Data Type: NIFTI_TYPE_UINT8
>>
>> Space Units: NIFTI_UNITS_UNKNOWN
>> Time Units: NIFTI_UNITS_UNKNOWN
>>
>> Extension 1 before byte swap
>>Size: 22816
>>Code: 4
>> Extension 1 after byte swap
>>Size: 22816
>>Code: 4
>> AFNI extension:
>> Extension 2 before byte swap
>>Size: 18592
>>Code: 30
>> Extension 2 after byte swap
>>Size: 18592
>>Code: 30
>>
>>
>> ---
>>
>> F3
>> 107 50 5 240 255
>> 8Bm
>> 77 50 10 5 255
>> ABmc
>> 31 50 10 155 255
>> Ig
>> 51 50 30 115 255
>> G
>> 161 50 30 140

Re: [caret-users] label volume mapping

[Timothy Coalson]

You can check that it added the label table to the nifti file by looking at
it in a text viewer (less).  I don't know much about label volumes in
caret5, there appears to be some code that should try to read the label
table from that extension, but I'm not sure what to do to make it happy.
 Workbench should display it just fine, though that might not help you.

Tim



On Wed, May 29, 2013 at 8:52 PM, Colin Reveley  wrote:

> Hi  -
>
> re: wb_command -volume-label-import
>
> what it appears to do is just vaporize the header.
>
> However, much could have gone wrong. The input volume is wholly
> constructed in software (mainly imageJ and inhouse C) and is probably weird
> (although it's been saved in CARET before trying to run this. I tried both
> ways. header below has been through caret). and maybe I've got the format
> of the label list wrong.
>
> I note that the output of the command is a float volume. I was pretty sure
> paint volumes had to be unsigned char. I tried both float and uchar as
> inputs anyway.
>
> my input header looks something like this. and my label file looks like
> what follows under the header
>
> thanks for advice
>
> I appreciate it may not work. That is ok. It was a bit too good to be true
> anyway. it doesn't dump core, or give an error (or any info at all). it
> just thinks for a bit, removes most info from the header and outputs a
> float volume
>
> actually there's probably a debug swtich. I'll look at that now.
>
> thanks,
>
> Colin
>
> sizeof_hdr: 348
>  data_type:
>db_name:
>extents: 0
>  session_error: 0
>regular: r
>   dim_info: 0
>dim: 3 137 347 245 1 1 0 0
>  intent_p1: 0.000
>  intent_p2: 0.000
>  intent_p3: 0.000
>intent_code: 1002
>   datatype: 2
> bitpix: 0
>slice_start: 0
> pixdim: 1.000 0.250 0.250 0.250 0.000 0.000 0.000 0.000
> vox_offset: 41760.000
>  scl_slope: 1.000
>  scl_inter: 0.000
>  slice_end: 0
> slice_code: 0
> xyzt_units: 0
>cal_max: 0.000
>cal_min: 0.000
> slice_duration: 0.000
>toffset: 0.000
>  glmax: 0
>  glmin: 0
>description:
>
>   aux_file:
> qform_code: 3
> sform_code: 3
>  quatern_b: 0.000
>  quatern_c: 0.000
>  quatern_d: 0.000
>  qoffset_x: -2.750
>  qoffset_y: -48.750
>  qoffset_z: -26.500
> srow_x: 0.250 0.000 0.000 -2.750
> srow_y: 0.000 0.250 0.000 -48.750
> srow_z: 0.000 0.000 0.250 -26.500
>intent_name:
>  magic: n+1
>
> Intent Name:  NIFTI_INTENT_LABEL
> Intent Parameters:Label index
>
>First Voxel XYZ (method 1): 0.000, 0.000, 0.000
>Spacing: 0.250, 0.250, 0.250
>
> QFORM: NIFTI_XFORM_TALAIRACH
>   1.000   0.000   0.000   0.000
>   0.000   1.000   0.000   0.000
>   0.000   0.000   1.000   0.000
>   0.000   0.000   0.000   1.000
>Orientation: Left to Right, Posterior to Anterior, Inferior to Superior
>First Voxel XYZ (Method 2): -2.750, -48.750, -26.500
>Spacing: 0.250, 0.250, 0.250
>
> SFORM: NIFTI_XFORM_TALAIRACH
>   0.250   0.000   0.000  -2.750
>   0.000   0.250   0.000 -48.750
>   0.000   0.000   0.250 -26.500
>   0.000   0.000   0.000   1.000
>Orientation: Left to Right, Posterior to Anterior, Inferior to Superior
>First Voxel XYZ (Method 3): -2.750, -48.750, -26.500
>Spacing: 0.250, 0.250, 0.250
>
> Data Type: NIFTI_TYPE_UINT8
>
> Space Units: NIFTI_UNITS_UNKNOWN
> Time Units: NIFTI_UNITS_UNKNOWN
>
> Extension 1 before byte swap
>Size: 22816
>Code: 4
> Extension 1 after byte swap
>Size: 22816
>Code: 4
> AFNI extension:
> Extension 2 before byte swap
>Size: 18592
>Code: 30
> Extension 2 after byte swap
>Size: 18592
>Code: 30
>
>
> ---
>
> F3
> 107 50 5 240 255
> 8Bm
> 77 50 10 5 255
> ABmc
> 31 50 10 155 255
> Ig
> 51 50 30 115 255
> G
> 161 50 30 140 255
> Ld
> 119 50 40 45 255
> LIPv
> 20 50 40 120 255
> Ia
> 87 50 55 15 255
>
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

[caret-users] test message - do not accept

[Timothy Coalson]

testing list moderation settings

Tim
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] Sequences for myelin mapping

[Timothy Coalson]

pulvinar is just a legacy alias for brainvis, the upload link should really
be http://brainvis.wustl.edu/cgi-bin/upload.cgi

I was hoping that one of the tools I mentioned was easily available, so
Irene could check the header directly.

As for getting plumb data through freesurfer, it may be best to fake the
sform, compute the affine between them, run freesurfer on the faked sform
version, then (if needed) reapply the real sform and transform the surface
with the computed affine after freesurfer finishes.

Tim



On Wed, May 8, 2013 at 3:31 PM, Matt Glasser  wrote:

> I don't think we have figured out how to make FreeSurfer data run with
> oblique sforms line up with volume data in Caret.  I have avoided this
> issue by always removing the oblique sforms before running FreeSurfer.  In
> theory, it must be possible to fix, however the different software handle
> the oblique sforms differently.  I'll have to defer to others in the lab
> (Tim) on if this is solvable however.  The issue is that the offset
> between the surfaces and volume (FreeSurfer's c_ras) no longer causes the
> surfaces and volumes to align in Caret if you gave FreeSurfer data with
> oblique sforms.
>
> I think the upload site is: http://pulvinar.wustl.edu/cgi-bin/upload.cgi
>
> Peace,
>
> Matt.
>
> On 5/7/13 9:48 AM, "Irene Altarelli"  wrote:
>
> >Dear Caret experts,
> >
> >I'd like to use the myelin mapping processing stream. I have processed
> >my T1 scans with Freesurfer 5.0 some time ago, finely correcting the
> >segmentation for a number of subjects (these are children).
> >
> >From what I have read from the documentation it appears that oblique
> >s/qforms might be creating some problems. I am afraid that I have them
> >in my already processed T1s, given the output of mri_info.
> >
> >I also got two versions of the T2 sequence from the scanner, one
> >apparently being somewhat filtered.
> >
> >May I ask you to have a look at these images and their headers and give
> >me some advice on how to proceed? I can upload them wherever you think
> >is easy to access.
> >
> >Thank you very much in advance.
> >Best,
> >Irene
> >
> >--
> >Irene Altarelli - PhD student
> >Laboratoire de Sciences Cognitives et Psycholinguistique
> >Ecole Normale Supérieure
> >29, rue d'Ulm
> >75230 Paris Cedex 5
> >tel. 01 44 32 29 92
> >
>
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] Interpolate surfaces

[Timothy Coalson]

You may be able to trick the -surface-average command into doing this, if
the intermediate you want is a rational number, by providing the same
coordinate file multiple times to increase its weight (so if you wanted 3/8
versus 5/8, specify one file 3 times and the other 5 times).  What do you
want these surfaces for?

The implementation is simple, but the surfaces must be in register for it
to work: at each vertex, do a weighted average of the coordinates of the
two surfaces it is transitioning between.

Tim



On Tue, Mar 26, 2013 at 1:38 AM, Tristan Chaplin
wrote:

> Hi,
>
> I have a question about the Interpolate surfaces feature: is it possible
> to get the coord files of the intermediate surfaces?  And also, is there
> any information available on how the algorithm works?
>
> Thanks,
> Tristan
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] PALS atlas fiducial surface area

[Timothy Coalson]

The reduction of tile areas should be nonuniform, because areas of cortex
that are more anatomically variable will not line up, and the features will
smooth each other out due to not being matched.  I don't think surface area
is particularly meaningful on an average surface.

Tim



On Wed, Feb 20, 2013 at 10:35 PM, Tristan Chaplin  wrote:

> Thanks Time.
>
> If I wanted to measure areas on this human cortex model, do you think it's
> ok to first scale the surface model up to this 965cm2 area? Or is the
> reduction in surface area too variable over the surface (ie not uniform)?
>
> Cheers,
> Tristan
>
>
> On Thu, Feb 21, 2013 at 8:56 AM, Timothy Coalson  wrote:
>
>> The surface generated as the average of all subjects in the atlas is
>> significantly smoother than any individual's surface, which reduces
>> the surface area.  This may account for the discrepancy, as what
>> appears to be reported by the paper you saw is the mean of the surface
>> areas of the individuals, rather than the surface area of the average
>> surface.
>>
>> Tim
>>
>> On Tue, Feb 19, 2013 at 8:08 PM, Tristan Chaplin
>>  wrote:
>> > Sorry that should be 565 cm2.
>> >
>> >
>> > On Wed, Feb 20, 2013 at 12:25 PM, Tristan Chaplin
>> >  wrote:
>> >>
>> >> Hi,
>> >>
>> >> I have been looking at the surface area of the PALS atlas and am a bit
>> >> confused as it seems smaller than I expected.  The spec file
>> >>
>> >> PALS_B12.RIGHT.STANDARD-SCENES.73730.spec
>> >>
>> >> downloaded from
>> >>
>> >>
>> >>
>> http://sumsdb.wustl.edu:8081/sums/archivelist.do?archive_id=6570866&archive_name=PALS_B12.RIGHT.STANDARD-SCENES.73730.spec
>> )
>> >>
>> >> seems to have a fiducial surface area of 565 mm2 (including
>> non-cortical
>> >> medial wall) but the Van Essen 2005 Neuroimage paper says the average
>> >> surface area of the individuals is 965 cm2.
>> >>
>> >> Am I doing something wrong, or is there is something about atlas
>> building
>> >> that causes this?
>> >>
>> >> Thanks,
>> >> Tristan
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> > ___
>> > caret-users mailing list
>> > caret-users@brainvis.wustl.edu
>> > http://brainvis.wustl.edu/mailman/listinfo/caret-users
>> >
>> ___
>> caret-users mailing list
>> caret-users@brainvis.wustl.edu
>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] Vertex resolution (32k) in HCP workbench tutorial dataset?

[Timothy Coalson]

There is downsampling, yes, but not by mesh decimation.  We have an atlas
with surfaces at 164k and 32k that uses spheres generated specifically for
regular topology and even spacing, registered individuals to the atlas, and
resampled the surfaces to that mesh using that registration.

I don't know that much about the data itself.

Tim



On Thu, Apr 25, 2013 at 8:29 AM, Matthias Ekman wrote:

> Dear all,
>
> my apologies in case this is not the right list to ask my question.
>
> I recently attended a presentation given by David, talking about
> functional connectivity analysis performed on the surface. To me that made
> a lot of sense and caught my interest. I downloaded the
> connectome-workbench application and the HCP tutorial dataset [1]. Thanks
> for making this freely available, the application looks very promising.
>
> The HCP tutorial dataset contains a functional gifti file
> "rfMRI_REST1_LR_s2.atlasroi.L.32k_fs_LR.func.gii" with 32492 vertices and
> 1200 time-points.
>
> This is the point where I was wondering, how you guys managed to reduce
> the number of vertices to such a low number (32k per hemisphere). In my
> pipeline, using freesurfer [2], I end up with about 127k vertices, which
> makes the analysis computationally much more demanding.
>
> I assume, that the analysis scripts are not freely available yet, but it
> would help me already to get an idea whether the processing contains any
> downsampling steps of the data (e.g. in freesurfer it is possible to
> decimate the mesh in order to reduce the number of vertices).
>
> Any pointer into that direction would be of great help and much
> appreciated.
>
> Related to that, I noticed that the provided time-series data contains in
> the 2nd half (>Volume 600) some very "ugly" looking spikes [3]. But I
> assume you guys are already aware of that.
>
> regards,
>  Matthias
>
>
> [1] http://humanconnectome.org/connectome/get-connectome-workbench.html
> [2] this basically involves surface reconstruction of the T1 (recon-all)
> followed by a projection of the functional data onto the white matter mesh
> (mri_surf2surf)
> [3] https://dl.dropboxusercontent.com/u/38470419/spikes.png
>
>
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] Sequences for myelin mapping

[Timothy Coalson]

To dump the header info, there is fslhd from fsl, or wb_command
-nifti-information (part of connectome workbench), or 3dinfo (from afni).
 caret5 is allergic to obliques, and may not have a utility to tell you
about them.

wb_command can handle oblique volumes, so if you have a suitable volume
space to resample them into (or create one with caret_command
-volume-create), you can resample the T1 and T2, and then use those.
 Alternatively, you could fake the header sforms to be plumb (fsledithd?),
apply an equivalent transform to the surfaces, and use those.  Or, you
could do the equivalent of the myelin mapping method using wb_command
operations, since it doesn't object to oblique volumes.

Tim



On Tue, Apr 30, 2013 at 10:16 AM, Irene Altarelli wrote:

> Dear Caret experts,
>
> I'd like to use the myelin mapping processing stream. I have processed
> my T1 scans with Freesurfer 5.0 some time ago, finely correcting the
> segmentation for a number of subjects (these are children).
>
> From what I have read from the documentation it appears that oblique
> s/qforms might be creating some problems. I am afraid that I have them
> in my already processed T1s, given the output of mri_info.
>
> I also got two versions of the T2 sequence from the scanner, one
> apparently being somewhat filtered.
>
> May I ask you to have a look at these images and their headers and give
> me some advice on how to proceed? I can upload them wherever you think
> is easy to access.
>
> Thank you very much in advance.
> Best,
> Irene
>
>
>
>
> --
>
> Irene Altarelli, PhD student
> Laboratoire de Sciences Cognitives et Psycholinguistique
> Ecole Normale Supérieure
> 29, rue d'Ulm
> 75230 Paris Cedex 05
> tel. 01 44 32 29 92
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] PALS atlas fiducial surface area

[Timothy Coalson]

The surface generated as the average of all subjects in the atlas is
significantly smoother than any individual's surface, which reduces
the surface area.  This may account for the discrepancy, as what
appears to be reported by the paper you saw is the mean of the surface
areas of the individuals, rather than the surface area of the average
surface.

Tim

On Tue, Feb 19, 2013 at 8:08 PM, Tristan Chaplin
 wrote:
> Sorry that should be 565 cm2.
>
>
> On Wed, Feb 20, 2013 at 12:25 PM, Tristan Chaplin
>  wrote:
>>
>> Hi,
>>
>> I have been looking at the surface area of the PALS atlas and am a bit
>> confused as it seems smaller than I expected.  The spec file
>>
>> PALS_B12.RIGHT.STANDARD-SCENES.73730.spec
>>
>> downloaded from
>>
>>
>> http://sumsdb.wustl.edu:8081/sums/archivelist.do?archive_id=6570866&archive_name=PALS_B12.RIGHT.STANDARD-SCENES.73730.spec)
>>
>> seems to have a fiducial surface area of 565 mm2 (including non-cortical
>> medial wall) but the Van Essen 2005 Neuroimage paper says the average
>> surface area of the individuals is 965 cm2.
>>
>> Am I doing something wrong, or is there is something about atlas building
>> that causes this?
>>
>> Thanks,
>> Tristan
>>
>>
>>
>>
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] transforms

[Timothy Coalson]

flirt does not use the nifti origin, I think this may be the cause of your
problems.  I wrote a utility to convert between simple coordinate to
coordinate matrices and the matrices flirt expects (and another convention
or two specific to 4dfp).  You probably won't have it unless you have a
very recent version of the 4dfp suite (look for the source
folder/executable "aff_conv" if you do).

To be precise, flirt uses the pixdim field of nifti for the spacing, with
an origin at voxel (0, 0, 0), that is, corner of the volume.  However, it
also checks for the sform having positive determinant, and if so, does an
x-flip of the coordinate system (that is, negates the x spacing, and puts
the origin at voxel (X, 0, 0) where X is the largest possible value of the
first index).

In short, yes it should be simple, but it isn't.  I actually don't know of
a volume transform/resampling utility that works correctly with an
unadulterated coordinate to coordinate transform.

Tim

On Wed, Dec 26, 2012 at 12:16 PM, Colin Reveley  wrote:

> thanks donna - I know that.
>
> I'm talking about volumes and surfaces that are already aigned, and
> humming nicely.
>
> I want to apply an arbitrary linear operation to the volume (actuslly just
> two rotations, but it shoould generalise presumably) and the surface, and
> have them stay linked.
>
> so, turn it upside down. double it's size.
>
> one matrix. two things (MRI data, and surface representations of exactly
> that data)  that are equivalent in space under any transform I care to
> apply.
>
>
>
> On 26 December 2012 18:00,  wrote:
>
>> Send caret-users mailing list submissions to
>> caret-users@brainvis.wustl.edu
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>> or, via email, send a message with subject or body 'help' to
>> caret-users-requ...@brainvis.wustl.edu
>>
>> You can reach the person managing the list at
>> caret-users-ow...@brainvis.wustl.edu
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of caret-users digest..."
>>
>> Today's Topics:
>>
>>1. Re: transform surf and vol (Donna Dierker)
>>
>>
>> -- Forwarded message --
>> From: Donna Dierker 
>> To: "Caret, SureFit, and SuMS software users" <
>> caret-users@brainvis.wustl.edu>
>> Cc:
>> Date: Tue, 25 Dec 2012 15:31:48 -0600
>> Subject: Re: [caret-users] transform surf and vol
>> If you import a Freesurfer surface into Caret, it won't align with the
>> volume in mri/orig.mgz until you apply an offset transformation defined by
>> something like mri_info -cras (I forget the exact command).  Depending on
>> which surface you apply that transformation -- before or after cras offset
>> -- you could get the behavior you describe.
>>
>>
>> On Dec 24, 2012, at 7:51 PM, Colin Reveley wrote:
>>
>> > Hey, merry christmas.
>> >
>> > I have a surface. and a volume. they are in register in caret. the
>> volume has an origin reported in the nifti header.
>> >
>> > If I apply a rigid body transform to both, they are both rotated the
>> way I want (the way I want is so that the surface, and MR data in the slice
>> plane as some microscope slides of the sample) but the surface is no longer
>> in register with the volume.
>> >
>> > the rotations are right. but the translations aren't (there aren't any
>> translations intended actually)
>> >
>> > I can
>> >
>> > a) manually translate the surface around in caret till it roughly fits
>> (which I did, it's fine for now)
>> > b) adjust the origin of the nifti (the origin isn't changed by applying
>> the transform with flirt)
>> >
>> > or I guess c) adjust something in the surface header. couldn't see what.
>> >
>> > It occurred to me to treat the original volume origin as a vector and
>> apply the transform to it, then set the origin of the rotated volume to
>> those values.
>> >
>> > Probably that would work. But it's a bit too much linear algebra for me.
>> >
>> > Moving on from the obvious fact that I'm not that bright, surely doing
>> exactly this kind of thing ought to be pretty easy?
>> >
>> >
>> > ___
>> > caret-users mailing list
>> > caret-users@brainvis.wustl.edu
>> > http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>
>>
>>
>>
>> ___
>> caret-users mailing list
>> caret-users@brainvis.wustl.edu
>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>
>>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] flipping

[Timothy Coalson]

One more thing to keep in mind, when you flip a surface's coordinates, the
normals will point inward rather than outward, so you may want to also
reorient the topology to have the normals outward
(-surface-topology-fix-orientation looks like the right command).

Tim

On Thu, Dec 6, 2012 at 11:38 AM, Colin Reveley  wrote:

> Jet lagged though i am it is clear that any image is trivially flippable.
> so that's solved short term, sorry.
>
> in the long term, it is definitely best to change all my caret data to the
> correct hemispheric designation and orientation. but I think it's not hard:
>
> flip surfaces in y with a transform. flip and project and resample
> borders. just fslswapdim volumes (ACPC is unchanged). rename the structure
> in surface headers. leave metric, paint etc alone. they are just vectors.
> rename all the files. update/create spec. done. I think.
>
> unless the surfaces or anything else need further header changes. they
> don't look like they do.
>
> other things probably easiest to just backup and do again as needed.
> registration related stuff, whatever else.
>
> but that should flip the surfaces and volumes, preserve the important data
> (metrics, to a lesser extent borders, paints, rois), and everything should
> work smoothly and be in the right place.
>
> I do actually need to do this. At least for some of them. it turns out
> that while the caret data is correct, the actual brain is the wrong way
> round and it's not something called "rigorous" to flip histological data.
> whatever. talk to the hand.
>
> I hope it's that easy as above. I think it hopefully is.
>
> best,
>
>
> Colin
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] caret-users Digest, Vol 108, Issue 1

[Timothy Coalson]

Did you paste the command into the script from somewhere?  I'm thinking
maybe the whitespace in those places isn't a simple space, and it is
confusing the shell, but if you typed it in manually, that shouldn't
happen...perhaps you could upload the script itself to the place donna
suggested?

Tim

On Fri, Sep 14, 2012 at 6:37 PM, Andrew Bock  wrote:

> Thanks for the advice Tim, but I did paste these commands exactly as I
> have them in my script (i.e. I don't use quotes).  The quotes are only
> present in the command line error.
>
> Oddly the other caret_command operation works (caret_command
> -file-convert), it is only caret_command
> --surface-apply-transformation-matrix that results in an error.  Any other
> suggestions?
>
> Andrew
>
> On Fri, Sep 14, 2012 at 10:00 AM, 
> wrote:
>
>> Send caret-users mailing list submissions to
>> caret-users@brainvis.wustl.edu
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>> or, via email, send a message with subject or body 'help' to
>> caret-users-requ...@brainvis.wustl.edu
>>
>> You can reach the person managing the list at
>> caret-users-ow...@brainvis.wustl.edu
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of caret-users digest..."
>>
>>
>> Today's Topics:
>>
>>1. caret_command -surface-apply-transformation-matrix (Andrew Bock)
>>2. Re: caret_command -surface-apply-transformation-matrix
>>   (Timothy Coalson)
>>
>>
>> --
>>
>> Message: 1
>> Date: Thu, 13 Sep 2012 15:49:11 -0700
>> From: Andrew Bock 
>> Subject: [caret-users] caret_command
>> -surface-apply-transformation-matrix
>> To: caret-users@brainvis.wustl.edu
>> Message-ID:
>> > xxzekj10ul4k-v8v...@mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hello,
>>
>> I am attempting to follow the myelin maps pipeline outlined here:
>> http://brainvis.wustl.edu/wiki/index.php/Caret:MyelinMaps
>>
>>
>> >From my subjects directory I run the following commands:
>>
>> mri_convert -rl mri/rawavg.mgz mri/ribbon.mgz ribbon.nii.gz
>>
>> caret_command -file-convert -sc -is FSS surf/lh.white -os CARET
>> lh.white.coord.gii lh.white.topo.gii FIDUCIAL CLOSED -struct left
>> caret_command -file-convert -sc -is FSS surf/rh.white -os CARET
>> rh.white.coord.gii rh.white.topo.gii FIDUCIAL CLOSED -struct right
>>
>> caret_command -file-convert -sc -is FSS surf/lh.pial -os CARET
>> lh.pial.coord.gii lh.pial.topo.gii FIDUCIAL CLOSED -struct left
>> caret_command -file-convert -sc -is FSS surf/rh.pial -os CARET
>> rh.pial.coord.gii rh.pial.topo.gii FIDUCIAL CLOSED -struct right
>>
>> MatrixX=`mri_info mri/brain.finalsurfs.mgz | grep "c_r" | cut -d "=" -f 5
>> |
>> sed s/" "/""/g`
>> MatrixY=`mri_info mri/brain.finalsurfs.mgz | grep "c_a" | cut -d "=" -f 5
>> |
>> sed s/" "/""/g`
>> MatrixZ=`mri_info mri/brain.finalsurfs.mgz | grep "c_s" | cut -d "=" -f 5
>> |
>> sed s/" "/""/g`
>> Matrix1=`echo "1 0 0 ""$MatrixX"`
>> Matrix2=`echo "0 1 0 ""$MatrixY"`
>> Matrix3=`echo "0 0 1 ""$MatrixZ"`
>> Matrix4=`echo "0 0 0 1"`
>> Matrix=`echo "$Matrix1"" ""$Matrix2"" ""$Matrix3"" ""$Matrix4"`
>>
>> caret_command
>> -surface-apply-transformation-matrix lh.white.coord.gii lh.white.topo.gii
>> lh.white.coord.gii -matrix $Matrix
>> caret_command
>> -surface-apply-transformation-matrix rh.white.coord.gii rh.white.topo.gii
>> rh.white.coord.gii -matrix $Matrix
>>
>> caret_command
>> -surface-apply-transformation-matrix lh.pial.coord.gii lh.pial.topo.gii
>> lh.pial.coord.gii -matrix $Matrix
>> caret_command
>> -surface-apply-transformation-matrix rh.pial.coord.gii rh.pial.topo.gii
>> rh.pial.coord.gii -matrix $Matrix
>>
>>
>> Unfortunately I receive the following errors for the last 4 commands:
>>
>> ERROR: operation
>> "-surface-apply-transformation-matrix lh.white.coord.gii
>> lh.white.topo.gii"
>> not found.
>> ERROR: operation
>> "-surface-apply-transforma

Re: [caret-users] caret_command -surface-apply-transformation-matrix

[Timothy Coalson]

Looks like a quoting problem to me.  Your shell is interpreting
"-surface-apply-transformation-matrix lh.white.coord.gii lh.white.topo.gii"
as one argument, when it needs to be three.  If these commands are run in a
script, quote each argument separately, rather than all together.  If you
are pasting the commands exactly as you wrote them in the email, they
should work, unless your shell got messed up somehow (but since it didn't
include "-matrix" in the error message, I'm fairly sure it is quoting).

Tim

On Thu, Sep 13, 2012 at 5:49 PM, Andrew Bock  wrote:

> Hello,
>
> I am attempting to follow the myelin maps pipeline outlined here:
> http://brainvis.wustl.edu/wiki/index.php/Caret:MyelinMaps
>
>
> From my subjects directory I run the following commands:
>
> mri_convert -rl mri/rawavg.mgz mri/ribbon.mgz ribbon.nii.gz
>
> caret_command -file-convert -sc -is FSS surf/lh.white -os CARET
> lh.white.coord.gii lh.white.topo.gii FIDUCIAL CLOSED -struct left
> caret_command -file-convert -sc -is FSS surf/rh.white -os CARET
> rh.white.coord.gii rh.white.topo.gii FIDUCIAL CLOSED -struct right
>
> caret_command -file-convert -sc -is FSS surf/lh.pial -os CARET
> lh.pial.coord.gii lh.pial.topo.gii FIDUCIAL CLOSED -struct left
> caret_command -file-convert -sc -is FSS surf/rh.pial -os CARET
> rh.pial.coord.gii rh.pial.topo.gii FIDUCIAL CLOSED -struct right
>
> MatrixX=`mri_info mri/brain.finalsurfs.mgz | grep "c_r" | cut -d "=" -f 5
> | sed s/" "/""/g`
> MatrixY=`mri_info mri/brain.finalsurfs.mgz | grep "c_a" | cut -d "=" -f 5
> | sed s/" "/""/g`
> MatrixZ=`mri_info mri/brain.finalsurfs.mgz | grep "c_s" | cut -d "=" -f 5
> | sed s/" "/""/g`
> Matrix1=`echo "1 0 0 ""$MatrixX"`
> Matrix2=`echo "0 1 0 ""$MatrixY"`
> Matrix3=`echo "0 0 1 ""$MatrixZ"`
> Matrix4=`echo "0 0 0 1"`
> Matrix=`echo "$Matrix1"" ""$Matrix2"" ""$Matrix3"" ""$Matrix4"`
>
> caret_command
> -surface-apply-transformation-matrix lh.white.coord.gii lh.white.topo.gii
> lh.white.coord.gii -matrix $Matrix
> caret_command
> -surface-apply-transformation-matrix rh.white.coord.gii rh.white.topo.gii
> rh.white.coord.gii -matrix $Matrix
>
> caret_command
> -surface-apply-transformation-matrix lh.pial.coord.gii lh.pial.topo.gii
> lh.pial.coord.gii -matrix $Matrix
> caret_command
> -surface-apply-transformation-matrix rh.pial.coord.gii rh.pial.topo.gii
> rh.pial.coord.gii -matrix $Matrix
>
>
> Unfortunately I receive the following errors for the last 4 commands:
>
> ERROR: operation
> "-surface-apply-transformation-matrix lh.white.coord.gii lh.white.topo.gii"
> not found.
> ERROR: operation
> "-surface-apply-transformation-matrix rh.white.coord.gii rh.white.topo.gii"
> not found.
> ERROR: operation
> "-surface-apply-transformation-matrix lh.pial.coord.gii lh.pial.topo.gii"
> not found.
> ERROR: operation
> "-surface-apply-transformation-matrix rh.pial.coord.gii rh.pial.topo.gii"
> not found.
>
>
> Any help would be greatly appreciated.  I am running Caret 5.65 on Linux64
> (Ubuntu).
>
> Andrew
>
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] inner white matter

[Timothy Coalson]

Okay, taking a shot in the dark here, but if what you want is the WM
surface, except thinner between sides, rescaling the surface is
unlikely to give you what you want, since it will also bring
everything towards some point in the volume, so with that hook shape
in the image, the inside edge will move into GM while the outside
moves into the WM, and even if that picture is deceptive as to the 3D
structure, it will cut off a larger portion of WM on a gyrus than in a
sulcus.

However, I have a possibility you can try.  Get workbench installed if
you haven't yet, and try "wb_command -create-signed-distance-volume"
with the WM surface (after converting it to .surf.gii).  Note that its
default distance is sized for a human brain, so you will probably want
to use the -exact-limit and -approx-limit options.  Then, threshold
the new volume into a segmentation at a negative number equal to how
many mm you want to trim from the WM, and generate a surface from it
in caret5.  It may not be a particularly smooth surface, but it should
end up about where you want it, in theory (if you have something that
can take a real-valued volume and generate a surface at a particular
level set, it may give you a smoother surface, but I don't know of
such a utility).

Tim

On Mon, Aug 27, 2012 at 10:04 AM, Donna Dierker
 wrote:
> Pretty pictures, but I still don't get why you want to scale down the 
> surface, then scale it back up.
>
> I could see lying to a volume header, or resampling the anatomical, to get 
> SureFit to behave better.  And if you do that, you would need to rescale the 
> surface to get rid of the deliberately mis-stated resolution in the volume 
> header.
>
>
> On Aug 26, 2012, at 6:43 PM, Colin Reveley wrote:
>
>>
>> I don't think it makes sense at in human, or rhesus.
>>
>> however in marmoset the caudal white matter (which is really most of the 
>> white matter) is arranged in a sort of nested shell type deal. the inner 
>> white matter is the most myelinated, mainly its seems mostly the optic 
>> radation. but not only that.
>>
>> the principle diffusoion direction of the outer shell seems orthogonal to 
>> the inner. and there is a very clear boundary.
>>
>> so one might want to map DTI maps, FA and etc etc between these shells to 
>> characterise the WM.
>>
>> here are a couple of picture at 100um showing what I mean.
>>
>> it can only possibly work when the anatomy is like this, and also no folding
>>
>> probably not even then
>>
>> but if it did work I can map ev's, vol ratio, myelin, lattice index, loads 
>> of measures. and hence learn more about marmoset anatomy.
>>
>> which is a new thing for me. there's nearly nothing on its WM structure in 
>> the literature. I'm trying to figure it out.
>>
>> It's an idea. no more.
>>
>> On 25 August 2012 18:00,  wrote:
>> Send caret-users mailing list submissions to
>> caret-users@brainvis.wustl.edu
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>> or, via email, send a message with subject or body 'help' to
>> caret-users-requ...@brainvis.wustl.edu
>>
>> You can reach the person managing the list at
>> caret-users-ow...@brainvis.wustl.edu
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of caret-users digest..."
>>
>> Today's Topics:
>>
>>1. Re: Inner white matter (Donna Dierker)
>>
>>
>> -- Forwarded message --
>> From: Donna Dierker 
>> To: "Caret, SureFit, and SuMS software users" 
>> 
>> Cc:
>> Date: Fri, 24 Aug 2012 13:17:17 -0500
>> Subject: Re: [caret-users] Inner white matter
>> Go here:
>>
>> http://www.nitrc.org/frs/download.php/2871/GIFTI_Surface_Format.pdf
>>
>> On page 36, it says:  The application of a CoordinateSystemTransformMatrix, 
>> places the coordinates into the system shown in the table below. All 
>> coordinates are in millimeters.
>>
>> So sorry:  You don't get to change units.
>>
>> But I know I'm not the only one scratching my head wondering why you want to 
>> do this.  Oh, I know the occasional temptation to lie in a volume header, to 
>> elicit certain software behavior.
>>
>> But I've never been tempted to do it on a surface.  I've scaled surfaces for 
>> real (e.g., if I had to lie in a header when segmenting a smaller mammal, to 
>> get SureFit to do the right thing).  But not to get surfaces to behave 
>> properly.  So I guess I'm curious.
>>
>> Because what you describe below seems to me to be the equivalent of taking 
>> x,y,z axes; lining out the indices and writing numbers 1/4 the size of the 
>> original marks; and then lining those through and writing the original marks 
>> down.  Which means I'm almost certainly not getting what you asked.
>>
>>
>> On Aug 24, 2012, at 1:47 AM, Colin Reveley wrote:
>>
>> > Would it be possible to shrink a surface with a scaling matrix, and then 
>> > define the mesh as being in the same space as the original.
>> >
>> >

Re: [caret-users] regarding to smoothing t-map

[Timothy Coalson]

I generally regard the "average neighbors" smoothing as a legacy
method, to be used only if you need to compare to a previous study
that also used it.  The geodesic gaussian smoothing method in caret5
uses a gaussian kernel based on geodesic distance directly, so you
don't need to futz with the parameters in order to get the same
spatial smoothing on a different density mesh.  Furthermore, workbench
improves upon that slightly, for surfaces that have highly irregular
node areas (like freesurfer native meshes), with the geodesic gaussian
area method, which additionally takes node areas into account when
calculating the weights.  If you want a specific FWHM or gaussian
kernel, I recommend these two methods.  Due to its shoehorning into
caret5's existing metric smoothing command, geodesic gaussian
smoothing ignores the "strength" parameter, and I recommend using a
single iteration, specifying the desired sigma of the gaussian kernel
with  the "-geo-gauss" option.  Beware, the "GAUSS" method is
something else entirely, and the "-gauss" option is similarly
unrelated.

Unfortunately, the average neighbors method's effective FWHM or
gaussian kernel can't be estimated only by the iterations and
strength, it also depends on the mesh density (basically, on how long
each edge is, on average).  I don't know of a robust formula to
estimate the effective kernel, it would need an estimate of the
effective gaussian kernel for one iteration, which varies by the
strength parameter.  There should be a gaussian kernel that generates
very similar smoothing as long as you do more than 1 or 2 iterations
with average neighbors, since repeated convolution of any smoothing
kernel approximates a gaussian kernel.  It really boils down to: if
you want to know the effective gaussian kernel, as far as I know, you
need to test empirically against geodesic gaussian and compare, or use
a metric with a single nonzero value and use the result to measure the
size of the kernel.

As for translating an existing average neighbors setting to a
different density mesh, multiplying the iterations by the ratio of
nodes should, in theory, work out to a similar sized effective
gaussian kernel.  This is because the node spacing varies with
approximately the square root of the number of surface nodes (given
the same total surface area), and the effective gaussian kernel varies
with the average node spacing times the square root of the number of
iterations.

Smoothing immediately before TFCE is done largely because TFCE is very
sensitive to smoothness (since it uses contiguous above-threshold
areas as part of the calculation, and noise has a very big impact on
contiguity).  It may be equivalent to smooth the data before
generating the t-map, but the only place that the smoothness really
matters, as far as I know, is in TFCE.

Tim

On Fri, Jul 20, 2012 at 2:02 PM, Donna Dierker  wrote:
> Joern Diedrichsen played around with this years ago and found four average
> neighbors iterations to work well with caret-style surfaces:
>
> www.icn.ucl.ac.uk/motorcontrol/download/Caret_surface_statistics.pdf
>
> But he probably smoothed the mapped fMRI before doing any sort of t- or
> f-test.  We typically are working with depth, which is already pretty
> smooth, but decided to do this small amount of smoothing on the resulting
> t-/f-maps (real and randomized).
>
> We recently started doing this stuff on the 164k mesh, and we use 9
> iterations for that purpose (4*164k/74k).  (Tim Coalson said some
> nonlinearities more or less cancel each other out, so it's mostly
> proportional with the number of vertices.)
>
> Read what Smith & Nichols say about smoothing in the TFCE paper and form
> your own conclusions, based on your data.  The most important thing is to
> be consistent (smooth all subjects/sessions the same amount/way).
>
>
>> Hi Donna,
>>
>> I have used the TFCE method to generate some statistical meaningful
> results on cortical asymmetries. Thanks a lot for your help.
>> Currently, I have a question regarding to step of smoothing t-map with 4
> iterations at 0.5 strength using average neighbors method. I found that
> this step indeed improved the statistical results. What''s
>> difference between smoothing t-map and original surface attributes such
> as sulcal depth or surface area? Why we need smooth t-map instead of
> surface attributes? And also, how the with 4 iterations at 0.5 strength
> using average neighbors method relate to the Gaussian kernel size or
> FWHM on my surface mesh with 160K vertices? Thanks.
>>
>> Regards,
>>
>> Gang
>> ___
>> caret-users mailing list
>> caret-users@brainvis.wustl.edu
>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>
>
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
___
caret-users mailing list
caret-use

Re: [caret-users] myelin mapping

[Timothy Coalson]

Since what the myelin mapping maps is basically T1/T2, you may be able to
adjust your data to be in a plausible range for these values, and then fake
the T2 by taking an image that looks like a T1 and dividing it by this
adjusted data.  As long as your data is not discontinuous at the edge of
the ribbon, it should work because myelin mapping ignores voxels outside
the ribbon.  If you don't have a volume that looks like a T1, you can
probably use nearly anything as long as its grey matter is fairly
consistent and far from zero.

Alternatively, if you have the workbench alpha, its volume to surface
mapping now has a ribbon mapping option which uses data from all voxels
inside the ribbon, rather than just ones close enough to matter for
interpolation, though you will need surfaces that approximate the white and
pial surfaces:

tim@timsdev:~$ wb_command -volume-to-surface-mapping
MAP VOLUME TO SURFACE
   wb_command -volume-to-surface-mapping
  
  
  
  [-trilinear]
  [-enclosing]
  [-ribbon-constrained]
 
 
 [-volume-roi]

 [-voxel-subdiv]

  [-subvol-select]
 
...

This doesn't have the artifact correction code from myelin mapping in it,
though that code in myelin mapping is partly based on the kinds of
artifacts that show up in T1/T2, and may not apply to your data.

Tim

On Sun, Apr 22, 2012 at 12:06 PM, Colin Reveley  wrote:

> hello -
>
> I'm interested in using your myelin mapping algorithm, however:
>
> I don't have a t1w imgage
> I don't have a t2w image
> I don't have any freesurfer data.
>
> what do I have?
>
> I have, instead, a magnetization transfer ratio image from an ex-vivo
> sample. and, it's very high resolution (250um).
>
> I have a pretty good ribbon made in FAST.
>
> I have a caret surface made from a downasmpled 500um of the MTR.
>
> while the MTR is maybe not a perfect correlate of GM myelin content, it's
> pretty good and and it's what I have.
>
> I don't have time to go through the freesurfer process for this data.
>
> since the resolution is good, in principle it's possible to take the caret
> surefit surface and expand and shrink it so that I can map the MTR and get
> some vague gesture at laminar differences in myelin. so far the results of
> this seems to make some sense, although it's hardly exact.
>
> I'd like to apply your algorithm, and it does seem to me that the
> essential data is there (especially as you've previously given me
> insturction on how to get a ribbon that's suitable using only FAST).
>
> so, in effect, I have a midthickness, the equiv of a T1/T2 (I understand
> it's not the same, but we don't have time to get T1w and t2w from the
> sample, which won't behave the same in fixed tissue anyway - the MTR is ok.
> Someone else other than me has made that determination, so let's accept his
> view) and pretty much a cortical ribbon.
>
> however, the inputs to appropriate caret-command aren't right. even though
> the data is surely ok as input to the algorithm.
>
> and I still want to make use of your smart algorithm to process the data
> using ribbon, instead of just volume->surface metric making. It may
> validate, or not, claims of more fine tuned (laminar *related*) info.
>
> the laminar possibility is nice, but it's of course all over the place in
> practical terms of surface mapping, even as the data is there.
>
> attach screen (crude, top ctx layers shaved off).
>
> clearly it can work. if I knew how to fool caret_command by giving it the
> right data or "fake" data just so I can take advantage of your work with
> the ribbon, and the things the you wrote about recently.
>
> and that would be a help, and progress.
>
> best,
>
> Colin
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] GLIBCXX_3.4.9' not found

[Timothy Coalson]

It looks like you are probably running centOS 5.7 or 5.8.  Unfortunately,
the enterprise support model keeps old package versions around longer,
making it harder to build things to be compatible with them from other
distributions.  We have moved to compiling on ubuntu, though we use an
older version of it to try to keep the dependencies from being too recent.
 If you are running 5.8, the gcc44 package may install a libstdc++ that
contains the needed symbols.  If not, or that doesn't work, you might
consider upgrading to 5.8 or 6.2, or manually installing a newer gcc (4.5.x
is the oldest maintained gcc series, and I think the oldest maintained
kernel series is 2.6.27.x).

Tim

On Tue, Apr 10, 2012 at 12:51 PM, Long, Gary  wrote:

>  Hello,
> We just recently installed the latest version of caret. We are getting the
> following errors:
>
> [root@server bin_linux64]# ./caret5
> ./caret5: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found
> (required by ./caret5)
>
>
> [root@server bin_linux64]# ./caret_command
> ./caret_command: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not
> found (required by ./caret_command)
>
> caret_glxgears works as expected. We are running Centos 64 bit machines:
>
> [root@server bin_linux64]# uname -a
> Linux  2.6.18-274.17.1.el5 #1 SMP Tue Jan 10 17:25:58 EST 2012 x86_64
> x86_64 x86_64 GNU/Linux
>
> [root@server bin_linux64]# rpm -qa | grep libstdc++
> libstdc++-4.1.2-52.el5
> libstdc++-devel-4.1.2-52.el5
> compat-libstdc++-33-3.2.3-61
> libstdc++-4.1.2-52.el5
> compat-libstdc++-33-3.2.3-61
> compat-libstdc++-296-2.96-138
>
> [root@server bin_linux64]# rpm -qa | grep gcc
> gcc-c++-4.1.2-52.el5
> libgcc-4.1.2-52.el5
> gcc-java-4.1.2-52.el5
> compat-gcc-34-3.4.6-4.1
> gcc-gfortran-4.1.2-52.el5
> compat-gcc-34-c++-3.4.6-4.1
> compat-libgcc-296-2.96-138
> libgcc-4.1.2-52.el5
> compat-gcc-34-g77-3.4.6-4.1
> gcc-4.1.2-52.el5
>
>
> Do you have any ideas on what we need to check or install? Should we go
> back a version of caret?
>
> Thanks
> Gary
>
> Gary Long, RHCE, GCUX, GCIH
> Information Systems Manager
> Biomedical Research Imaging Center
> and NeuroImage Lab Dept. of Psychiatry
> University of North Carolina at Chapel Hill
> RM#3122 Bioinformatics Bldg.
> CB#7515
> Chapel Hill,NC 27599
> Phone: 919.843.7998
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

[caret-users] Fwd: ima images

[Timothy Coalson]

The list isn't liking donna's home email for some reason, forwarding her
message at her request.

Tim

Begin forwarded message:

*From: *caret-users-ow...@brainvis.wustl.edu
*Subject: **Re: [caret-users] ima images*
*Date: *March 12, 2012 6:14:03 PM CDT
*To: *donna.dier...@gmail.com

You are not allowed to post to this mailing list, and your message has
been automatically rejected.  If you think that your messages are
being rejected in error, contact the mailing list owner at
caret-users-ow...@brainvis.wustl.edu.


*From: *Donna Dierker 
*Subject: **Re: [caret-users] ima images*
*Date: *March 12, 2012 6:08:37 PM CDT
*To: *"Caret, SureFit, and SuMS software users" <
caret-users@brainvis.wustl.edu>


And I think once perhaps I computed xdim*ydim*bytes-per-pixel and used the
Linux tail command to strip the header off the ima files.  Then I used cat
to put them together to form a raw file.  Or I dreamed it.

What can be nightmarish about this is when the slice order differs from the
Linux shell file sort order.  Then you must come to grips with the fact
that you need a software utility to import these for you.

Freesurfer's mri_convert probably fits the bill, too.


On Mar 12, 2012, at 3:59 PM, Timothy Coalson wrote:

FSL is another software package for viewing and manipulating MRI images,
etc, which is entirely separate from Caret:

http://www.fmrib.ox.ac.uk/fsl/

to3d's help suggests that it should understand .ima, but it doesn't seem to
give much detail on how to use it:
"* Siemens .ima image files can now be read.  The program will detect if
  byte-swapping is needed on these images, and can also set voxel grid
  sizes and orientations (correctly, I hope)."

Did you try dinifti or dcm2nii?  I know at least one of them understood
.ima, but I can't remember which.

http://cbi.nyu.edu/software/dinifti.php

http://www.cabiatl.com/mricro/mricron/dcm2nii.html

If all that fails, you may be able to run it through dcm_to_4dfp and
nifti_4dfp from the 4dfp suite, but that will probably involve building it
from source unless you already have it installed.

Tim

On Mon, Mar 12, 2012 at 2:01 PM, Maestri, Matthew <
mmaes...@georgiahealth.edu> wrote:

> Hi Tim,
>
> I was unable to use AFNI's to3d. Is there any way I can convert them in
> Caret or compile them somehow? What is a FSL in Caret?
>
> Thank you,
> Matthew
> 
> From: caret-users-boun...@brainvis.wustl.edu [
> caret-users-boun...@brainvis.wustl.edu] on behalf of Donna Dierker [
> do...@brainvis.wustl.edu]
> Sent: Friday, March 09, 2012 12:10 PM
> To: Caret, SureFit, and SuMS software users
> Subject: Re: [caret-users] ima images
>
> Try something like AFNI's to3d.
>
>
> On Mar 9, 2012, at 11:04 AM, Timothy Coalson wrote:
>
> > I believe .ima is an extension used for dicom data, try a dicom to nifti
> converter such as dinifti or dcm2nii (part of mricron).
> >
> > Tim
> >
> > On Fri, Mar 9, 2012 at 9:09 AM, Maestri, Matthew <
> mmaes...@georgiahealth.edu> wrote:
> > Hi Donna,
> >
> > Is it possible for me to open ima images in Caret? If not, is it
> possible for me to convert the ima images into a Caret friendly image? If
> so, how would I got about doing this?
> >
> > Thanks,
> > Matthew
> >
> > ___
> > caret-users mailing list
> > caret-users@brainvis.wustl.edu
> > http://brainvis.wustl.edu/mailman/listinfo/caret-users
> >
> >
> > ___
> > caret-users mailing list
> > caret-users@brainvis.wustl.edu
> > http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>

___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] ima images

[Timothy Coalson]

FSL is another software package for viewing and manipulating MRI images,
etc, which is entirely separate from Caret:

http://www.fmrib.ox.ac.uk/fsl/

to3d's help suggests that it should understand .ima, but it doesn't seem to
give much detail on how to use it:
"* Siemens .ima image files can now be read.  The program will detect if
  byte-swapping is needed on these images, and can also set voxel grid
  sizes and orientations (correctly, I hope)."

Did you try dinifti or dcm2nii?  I know at least one of them understood
.ima, but I can't remember which.

http://cbi.nyu.edu/software/dinifti.php

http://www.cabiatl.com/mricro/mricron/dcm2nii.html

If all that fails, you may be able to run it through dcm_to_4dfp and
nifti_4dfp from the 4dfp suite, but that will probably involve building it
from source unless you already have it installed.

Tim

On Mon, Mar 12, 2012 at 2:01 PM, Maestri, Matthew <
mmaes...@georgiahealth.edu> wrote:

> Hi Tim,
>
> I was unable to use AFNI's to3d. Is there any way I can convert them in
> Caret or compile them somehow? What is a FSL in Caret?
>
> Thank you,
> Matthew
> 
> From: caret-users-boun...@brainvis.wustl.edu [
> caret-users-boun...@brainvis.wustl.edu] on behalf of Donna Dierker [
> do...@brainvis.wustl.edu]
> Sent: Friday, March 09, 2012 12:10 PM
> To: Caret, SureFit, and SuMS software users
> Subject: Re: [caret-users] ima images
>
> Try something like AFNI's to3d.
>
>
> On Mar 9, 2012, at 11:04 AM, Timothy Coalson wrote:
>
> > I believe .ima is an extension used for dicom data, try a dicom to nifti
> converter such as dinifti or dcm2nii (part of mricron).
> >
> > Tim
> >
> > On Fri, Mar 9, 2012 at 9:09 AM, Maestri, Matthew <
> mmaes...@georgiahealth.edu> wrote:
> > Hi Donna,
> >
> > Is it possible for me to open ima images in Caret? If not, is it
> possible for me to convert the ima images into a Caret friendly image? If
> so, how would I got about doing this?
> >
> > Thanks,
> > Matthew
> >
> > ___
> > caret-users mailing list
> > caret-users@brainvis.wustl.edu
> > http://brainvis.wustl.edu/mailman/listinfo/caret-users
> >
> >
> > ___
> > caret-users mailing list
> > caret-users@brainvis.wustl.edu
> > http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] ima images

[Timothy Coalson]

I believe .ima is an extension used for dicom data, try a dicom to nifti
converter such as dinifti or dcm2nii (part of mricron).

Tim

On Fri, Mar 9, 2012 at 9:09 AM, Maestri, Matthew  wrote:

>  Hi Donna,
>
>  Is it possible for me to open ima images in Caret? If not, is it
> possible for me to convert the ima images into a Caret friendly image? If
> so, how would I got about doing this?
>
>  Thanks,
> Matthew
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] Interspecies comparisons - creating a new atlas for a different primate species

[Timothy Coalson]

The way I understand it, if you already have an atlas sphere, you can (and
probably should) register the native mesh to the spherical atlas directly,
and the result is that (among other things) you get a new surface that
aligns with your native surface, but has topology and node spacing similar
to the atlas sphere.

However, if you do not yet have an atlas sphere, the way I understand it,
we made our atlas sphere without any dependence on the native mesh, by
taking the borders on the subject sphere and unprojecting them to not rely
on a mesh (then averaging them across subjects, but since you have only one
subject, this doesn't apply), and then projecting them onto the sphere we
wanted to use, giving us our atlas sphere with landmarks.  Again though, I
haven't done this, it is just my understanding of how it was described to
me.

If what you want is a surface with more regular spacing than what you have
in the subject native surface, you can do that and then register to the new
atlas sphere, or maybe just use the subject sphere and a new sphere to
generate a deformation map, and deform the subject native surfaces to the
new mesh (this is approximately what spec file change resolution does).

Tim

On Mon, Feb 20, 2012 at 6:55 PM, Tristan Chaplin
wrote:

> Sorry I should have specified this before, for our "atlas" we have only a
> single indvidual with cytoarchitecture.  We have a native mesh for this and
> the associated morphed spherical and flat meshes, as well as
> the cytoarchitecture as a paint file.
>
> I thought that to register this atlas to another individual, or for
> interespecies registration (which is want we really want to do) it
> was necessary to make standard fiducial mesh which has evenly spaced nodes,
> rather than the "native" mesh created after reconstruction from contours.
>
> I think I understand how to make a standard spherical mesh but do I need
> to make a standard fiducial mesh to allow intra and interspecies
> registration?
>
> Cheers,
> Tristan
>
>
> On Sat, Feb 18, 2012 at 05:31, Timothy Coalson  wrote:
>
>> The new atlases we are making (I think they may be included in the 5.65
>> release, but I am not sure, the fs_LR atlases are the ones I mean) use this
>> new kind of sphere.  If you want to take a look at node spacing regularity,
>> there is an option in caret to generate the node areas of a surface under
>> Surface->Region Of Interest Operations...
>>
>> Select all the nodes (clicking select with the default settings should do
>> this), click next, select "Assign metric with node areas", click the
>> "Assign Metric Node Areas" button, and there you have it.  Of course, the
>> node regularity on the sphere doesn't translate directly to node regularity
>> on subject surfaces, there is distortion inherent to registering on a
>> sphere, since the brain isn't a sphere, but it should help.
>>
>> The new sphere code is only used in a few commands, so I would have to
>> know more about what commands generate the surfaces in your current methods
>> to hazard a guess at whether you would need to do something different to
>> get a new sphere.
>>
>> Tim
>>
>>
>> On Fri, Feb 17, 2012 at 11:02 AM, Colin Reveley wrote:
>>
>>> Tim - what you say is interesting.
>>>
>>> I have actually wondered about node spacing in fiducial surfaces
>>> registered to F99 via macaque.sphere6.
>>>
>>> It's not always 100% super straight forward to register (without lots of
>>> crossovers and issues). I'm fairly pleased with what I have. the matches
>>> are quite good.
>>>
>>> however, for my purposes, a node spacing that is a regular as possible
>>> in the context just of registering my surface to F99 has real advantages,
>>> because I use nodes as tractography seeds and I'd like their spacing to be
>>> roughly even.
>>>
>>> Might I benefit from trying your new approach? How hard would it be? f99
>>> is still 73730, as are all the atlas files. DVE's most recent free surfer
>>> macaque to F99 tutorial still very much uses 73730.
>>>
>>> My surfaces are from FS and look pretty evenly spaced. So maybe register
>>> F99 on to my mesh, and make a deform_map for the F99 data? essentially
>>> following the menu driven landmark pinned reg.
>>>
>>> Other than fiducials (WM,GM, mean) the topos and other surfaces are made
>>> with caret operations. I'm guessing if I repeat those operations with
>>> caret5.65, it will follow the new scheme of things in terms of how node
>>> spacing is decided?
>&g

Re: [caret-users] node numbers

[Timothy Coalson]

I am not familiar with that command, but I think LVD stands for landmark
vector difference, it is a method of doing surface based registration.  I
suspect that what you need is to replace the atlas spec file with a spec
file containing an atlas on your desired sphere.  I also suspect that the
deformation map file is being used for a different purpose than
deformation, for instance to get parameters and what kind of method to use
to generate the registration.  I am guessing the individual spec file isn't
on a standard mesh yet?  If it is not on a standard mesh, I don't see how
it could be applying a deformation before it registers it or at least
resamples it onto a standard mesh (and I would not expect it to apply a
deformation other than that obtained by the registration afterwards).

I can only make a wild guess as to what the comment about "fixed for new
spheres" is about, but I suspect the behavior it refers to has not been
changed, partly because my wild guess is that it was based on misuse of a
command, and partly because caret5 hasn't been modified much recently.

Tim

On Fri, Feb 17, 2012 at 3:48 PM, Colin Reveley  wrote:

>
> I'm very sorry I see it's basically trivial to register in both
> directions. My registrations can be tricky though.
>
> if caret command has been fixed for new spheres, I'd be most grateful to
> learn how I might leverage that. It also simplifies the scripts in places.
>
> I need a replacement for *.LVD.deform_map presumably?
>
> many thanks.
>
> On 17 February 2012 19:15,  wrote:
>
>> Send caret-users mailing list submissions to
>>caret-users@brainvis.wustl.edu
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>http://brainvis.wustl.edu/mailman/listinfo/caret-users
>> or, via email, send a message with subject or body 'help' to
>>caret-users-requ...@brainvis.wustl.edu
>>
>> You can reach the person managing the list at
>>caret-users-ow...@brainvis.wustl.edu
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of caret-users digest..."
>>
>> Today's Topics:
>>
>>   1. Re: Interspecies comparisons - creating a new atlas for a
>>  different primate species (Timothy Coalson)
>>
>>
>> -- Forwarded message --
>> From: Timothy Coalson 
>> To: "Caret, SureFit, and SuMS software users" <
>> caret-users@brainvis.wustl.edu>
>> Cc:
>> Date: Fri, 17 Feb 2012 12:31:56 -0600
>> Subject: Re: [caret-users] Interspecies comparisons - creating a new
>> atlas for a different primate species
>> The new atlases we are making (I think they may be included in the 5.65
>> release, but I am not sure, the fs_LR atlases are the ones I mean) use this
>> new kind of sphere.  If you want to take a look at node spacing regularity,
>> there is an option in caret to generate the node areas of a surface under
>> Surface->Region Of Interest Operations...
>>
>> Select all the nodes (clicking select with the default settings should do
>> this), click next, select "Assign metric with node areas", click the
>> "Assign Metric Node Areas" button, and there you have it.  Of course, the
>> node regularity on the sphere doesn't translate directly to node regularity
>> on subject surfaces, there is distortion inherent to registering on a
>> sphere, since the brain isn't a sphere, but it should help.
>>
>> The new sphere code is only used in a few commands, so I would have to
>> know more about what commands generate the surfaces in your current methods
>> to hazard a guess at whether you would need to do something different to
>> get a new sphere.
>>
>> Tim
>>
>> On Fri, Feb 17, 2012 at 11:02 AM, Colin Reveley wrote:
>>
>>> Tim - what you say is interesting.
>>>
>>> I have actually wondered about node spacing in fiducial surfaces
>>> registered to F99 via macaque.sphere6.
>>>
>>> It's not always 100% super straight forward to register (without lots of
>>> crossovers and issues). I'm fairly pleased with what I have. the matches
>>> are quite good.
>>>
>>> however, for my purposes, a node spacing that is a regular as possible
>>> in the context just of registering my surface to F99 has real advantages,
>>> because I use nodes as tractography seeds and I'd like their spacing to be
>>> roughly even.
>>>
>>> Might I benefit from trying your new approach? How hard would it be? f99
>>> is still 73730, as are a

Re: [caret-users] Interspecies comparisons - creating a new atlas for a different primate species

[Timothy Coalson]

The new atlases we are making (I think they may be included in the 5.65
release, but I am not sure, the fs_LR atlases are the ones I mean) use this
new kind of sphere.  If you want to take a look at node spacing regularity,
there is an option in caret to generate the node areas of a surface under
Surface->Region Of Interest Operations...

Select all the nodes (clicking select with the default settings should do
this), click next, select "Assign metric with node areas", click the
"Assign Metric Node Areas" button, and there you have it.  Of course, the
node regularity on the sphere doesn't translate directly to node regularity
on subject surfaces, there is distortion inherent to registering on a
sphere, since the brain isn't a sphere, but it should help.

The new sphere code is only used in a few commands, so I would have to know
more about what commands generate the surfaces in your current methods to
hazard a guess at whether you would need to do something different to get a
new sphere.

Tim

On Fri, Feb 17, 2012 at 11:02 AM, Colin Reveley  wrote:

> Tim - what you say is interesting.
>
> I have actually wondered about node spacing in fiducial surfaces
> registered to F99 via macaque.sphere6.
>
> It's not always 100% super straight forward to register (without lots of
> crossovers and issues). I'm fairly pleased with what I have. the matches
> are quite good.
>
> however, for my purposes, a node spacing that is a regular as possible in
> the context just of registering my surface to F99 has real advantages,
> because I use nodes as tractography seeds and I'd like their spacing to be
> roughly even.
>
> Might I benefit from trying your new approach? How hard would it be? f99
> is still 73730, as are all the atlas files. DVE's most recent free surfer
> macaque to F99 tutorial still very much uses 73730.
>
> My surfaces are from FS and look pretty evenly spaced. So maybe register
> F99 on to my mesh, and make a deform_map for the F99 data? essentially
> following the menu driven landmark pinned reg.
>
> Other than fiducials (WM,GM, mean) the topos and other surfaces are made
> with caret operations. I'm guessing if I repeat those operations with
> caret5.65, it will follow the new scheme of things in terms of how node
> spacing is decided?
>
> Colin Reveley, sussex.
>
> On 17 February 2012 05:17,  wrote:
>
>> Send caret-users mailing list submissions to
>>caret-users@brainvis.wustl.edu
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>http://brainvis.wustl.edu/mailman/listinfo/caret-users
>> or, via email, send a message with subject or body 'help' to
>>caret-users-requ...@brainvis.wustl.edu
>>
>> You can reach the person managing the list at
>>caret-users-ow...@brainvis.wustl.edu
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of caret-users digest..."
>>
>> Today's Topics:
>>
>>   1. Re: caret-users Digest, Vol 101, Issue 2 (Colin Reveley)
>>   2. Interspecies comparisons - creating a new atlas for a
>>  different primate species (Tristan Chaplin)
>>   3. Re: Interspecies comparisons - creating a new atlas for a
>>  different primate species (Timothy Coalson)
>>
>>
>> -- Forwarded message --
>> From: Colin Reveley 
>> To: 
>> Cc:
>> Date: Thu, 16 Feb 2012 18:52:56 +
>> Subject: Re: [caret-users] caret-users Digest, Vol 101, Issue 2
>> One would expect the caret GUI to become unresponsive, and also expect
>> the process to be listed as "not responding" in the task manager even if
>> things were going well.
>>
>> but it crashes.
>>
>> might I suggest the neurodebian virtual machine? there is a 32bit windows
>> version. Loads of great stuff on there including caret.
>>
>> http://neuro.debian.net/vm.html#installation
>>
>> even if things are slow due to hardware limitations you may have, you
>> could segment in the virtual machine, and then use caret in plain windows
>> to work with the results.
>>
>> hope helps,
>>
>> Colin
>>
>> On 16 February 2012 18:00, wrote:
>>
>>> Send caret-users mailing list submissions to
>>>caret-users@brainvis.wustl.edu
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>> or, via email, send a message with subject or body 'help' to
>>>caret-users-requ...@brainvis.wustl.edu
>>>
>>> You can reach 

Re: [caret-users] Interspecies comparisons - creating a new atlas for a different primate species

[Timothy Coalson]

Creating the sphere may not be the first step, but the key thing about an
atlas is that all of the subjects used to generate the atlas need to be on
the same mesh, with subject landmarks occupying the same or nearby node
numbers.  Native meshes from freesurfer do not have this property, nor to
surfaces generated from segmentation volumes.  Those kinds of surfaces have
the additional caveat that their node spacing and number of neighbors per
node can be highly variable.

My understanding of how we make atlases (I haven't been involved in it, but
it has been described to me) is that you draw landmarks on all of the
subjects that make the atlas, unproject them to be borders that aren't tied
to any surface, then resample and average the subject borders together
(flipping left to be right if you want an atlas that has correspondence
between right and left), and finally project those borders to the sphere
that is the mesh you will use (again, flip the borders and project to the
left sphere to get your left atlas target).  Then, you can register your
atlas subjects to this sphere, giving their surfaces node corrrespondence,
and average their coordinate files to get the atlas average fiducial.

Take this with a large grain of salt, as I said, I haven't actually done
this.

Tim

On Fri, Feb 17, 2012 at 12:09 AM, Tristan Chaplin  wrote:

> Thanks for information, but I must confess I don't understand why you
> create the sphere first.  I thought the procedure for atlases was to make a
> surface, then resample it as a standard mesh, then do spherical morphing
> etc.  Is the idea instead to create the fiducial surface, do spherical
> morphing, then align the sphere to one of these standard spheres?
>
> FYI we've already made a fiducial surface with cytoarchitecure as paint.
>
>
> On Fri, Feb 17, 2012 at 16:08, Timothy Coalson  wrote:
>
>> We have moved away from the 73730 mesh, we are now using a new method to
>> generate meshes which results in much more regular node spacing.  Making a
>> sphere is actually relatively easy, especially with the new release of
>> caret.  The hard part is making it into an atlas, which I defer to someone
>> else.  The command:
>>
>> caret_command -surface-create-spheres
>>
>> Will generate a pair of matched left/right spheres (mirror node
>> correspondence, topologies with normals oriented out).  I think that
>> command made it into the 5.65 release, if not you can use spec file change
>> resolution, and grab just the new sphere, and ditch the rest.  The odd bit
>> about spec file change resolution, though, is if you give it an old node
>> count, like 73730, it will give you the old sphere (this is in case someone
>> is relying on its old behavior).  However, ask it for 73731 nodes, and you
>> will get a new highly regular sphere instead (though it won't have 73730
>> nodes, because the 73730 node mesh wasn't a regularly divided geodesic
>> sphere, but it will give you something close).  If all else fails, there
>> are a few spheres in the caret data directory.
>>
>> Tim
>>
>>
>> On Thu, Feb 16, 2012 at 6:56 PM, Tristan Chaplin <
>> tristan.chap...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> A while back I asked about creating standard mesh of 73,730 nodes,
>>> similar to what is used for PALS atlas.  I never got a chance to follow it
>>> up then but I'd like to give it a go now.  It seemed at the time that the
>>> knowledge for creating such meshes was limited to a select few so if anyone
>>> has any experience with this or has the contact details of someone I would
>>> greatly appreciate hearing from them.
>>>
>>> The reason for creating this mesh is for making atlas for the marmoset
>>> monkey.  We are very interested registering this atlas to the macaque
>>> monkey and doing analyses similar to Hill et al. (2010).
>>>
>>> Thanks,
>>> Tristan Chaplin
>>>
>>> On Mon, Feb 7, 2011 at 16:04, Tristan Chaplin >> > wrote:
>>>
>>>> Ok thanks for the information.
>>>>
>>>>
>>>> On Fri, Feb 4, 2011 at 03:25, Donna Dierker 
>>>> wrote:
>>>>
>>>>> On 02/01/2011 07:31 PM, Tristan Chaplin wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I've been reading about the creation of your atlases, and I see that
>>>>> > PALS and the macaque atlases have standard size mesh of 73,730 nodes.
>>>>> >  I was wondering, is this the same across species to allow
>>>>> > interspecies registration?  i.e. is it still possible to do
>>

Re: [caret-users] Interspecies comparisons - creating a new atlas for a different primate species

[Timothy Coalson]

We have moved away from the 73730 mesh, we are now using a new method to
generate meshes which results in much more regular node spacing.  Making a
sphere is actually relatively easy, especially with the new release of
caret.  The hard part is making it into an atlas, which I defer to someone
else.  The command:

caret_command -surface-create-spheres

Will generate a pair of matched left/right spheres (mirror node
correspondence, topologies with normals oriented out).  I think that
command made it into the 5.65 release, if not you can use spec file change
resolution, and grab just the new sphere, and ditch the rest.  The odd bit
about spec file change resolution, though, is if you give it an old node
count, like 73730, it will give you the old sphere (this is in case someone
is relying on its old behavior).  However, ask it for 73731 nodes, and you
will get a new highly regular sphere instead (though it won't have 73730
nodes, because the 73730 node mesh wasn't a regularly divided geodesic
sphere, but it will give you something close).  If all else fails, there
are a few spheres in the caret data directory.

Tim

On Thu, Feb 16, 2012 at 6:56 PM, Tristan Chaplin
wrote:

> Hi,
>
> A while back I asked about creating standard mesh of 73,730 nodes, similar
> to what is used for PALS atlas.  I never got a chance to follow it up then
> but I'd like to give it a go now.  It seemed at the time that the knowledge
> for creating such meshes was limited to a select few so if anyone has any
> experience with this or has the contact details of someone I would greatly
> appreciate hearing from them.
>
> The reason for creating this mesh is for making atlas for the marmoset
> monkey.  We are very interested registering this atlas to the macaque
> monkey and doing analyses similar to Hill et al. (2010).
>
> Thanks,
> Tristan Chaplin
>
> On Mon, Feb 7, 2011 at 16:04, Tristan Chaplin 
> wrote:
>
>> Ok thanks for the information.
>>
>>
>> On Fri, Feb 4, 2011 at 03:25, Donna Dierker wrote:
>>
>>> On 02/01/2011 07:31 PM, Tristan Chaplin wrote:
>>> > Hi,
>>> >
>>> > I've been reading about the creation of your atlases, and I see that
>>> > PALS and the macaque atlases have standard size mesh of 73,730 nodes.
>>> >  I was wondering, is this the same across species to allow
>>> > interspecies registration?  i.e. is it still possible to do
>>> > interspecies comparisons of other species with different size meshes?
>>> Possible, but more difficult.  Not to say that achieving vertex
>>> correspondence across species is trivial.  Interspecies comparisons are
>>> really hard.  I think David Van Essen is the only one in our lab that is
>>> doing them, although Matt Glasser might also be doing some.
>>> >
>>> > I was also wondering how the standard mesh was was actually made.  The
>>> > PALS paper refers to the Saad 2004 paper, which I think uses SUMA.
>>> >  SUMA has a program called MapIcosahedron to create standard meshes.
>>> >  Is this still how you would recommend making a standard mesh?
>>> Tim Coalson (a student who works summers here) also developed a utility
>>> that creates meshes of specified resolution.
>>>
>>> Making a standard mesh is not something I ever do.  You do it with a
>>> specific motivation -- typically some other important data is already
>>> available on that mesh.  And the way you usually get your data on that
>>> mesh is to register it to an atlas target already on that mesh.
>>>
>>> If you are talking about creating, say, a sparser mesh for mice/rats,
>>> then you're out of my orbit.
>>> >
>>> > Thanks,
>>> > Tristan
>>> >
>>> 
>>> >
>>> > ___
>>> > caret-users mailing list
>>> > caret-users@brainvis.wustl.edu
>>> > http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>> >
>>>
>>> ___
>>> caret-users mailing list
>>> caret-users@brainvis.wustl.edu
>>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>>
>>
>>
>
> ___
> caret-users mailing list
> caret-users@brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
>
___
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Re: [caret-users] caret-users Digest, Vol 100, Issue 4

[Timothy Coalson]

Yes, it would indeed rely on being able to mask out the overflow.  The
reason I thought that such intersection wouldn't be an issue is that I
would hope that the mapping method takes appropriate measures to resolve
such conflicts, probably by using the label from the closest surface node.
 This seems like it would be a better conflict resolution than "max" or
"first wins", which is basically what you are left using if you try to map
it in multiple from-surface steps.  You should be able to generate
appropriate masking volumes with caret5's surface to segmentation volume
option, so you shouldn't need the FS ribbon specifically.

Unfortunately, I hear that freesurfer's command to generate ribbon volume
is slower than it should be, but it is just barely possible that it would
only need the 4 surfaces (left/right pial/white) to give the ribbon (note
that the ribbon volume is a label volume, labels 3 and 42 give the right
and left gray matter, if i recall).

Tim

On Thu, Jan 5, 2012 at 12:22 PM, Colin Reveley  wrote:

>
> you'd go above and also below into the wm as well, if I follow you. That
>> seems certainly one way to try, although the thing might be that paint
>> regions intersect in places doing it like that.
>>
>> thanks very much for comments I never computed the ribbon actually in FS.
>> and anything to avoid more FS. I'm sure it's great for human but it's
>> pretty hands on and tricky with macaque. It took ages. doubtless a ribbon
>> volume is just a one line command at this stage though.
>>
>>
>
>
>> On 5 January 2012 18:00,  wrote:
>>
>>> Send caret-users mailing list submissions to
>>>caret-users@brainvis.wustl.edu
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>> or, via email, send a message with subject or body 'help' to
>>>caret-users-requ...@brainvis.wustl.edu
>>>
>>> You can reach the person managing the list at
>>>caret-users-ow...@brainvis.wustl.edu
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of caret-users digest..."
>>>
>>> Today's Topics:
>>>
>>>   1. Re: caret-users Digest, Vol 100, Issue 2 (Timothy Coalson)
>>>
>>>
>>> -- Forwarded message --
>>> From: Timothy Coalson 
>>> To: "Caret, SureFit, and SuMS software users" <
>>> caret-users@brainvis.wustl.edu>
>>> Cc:
>>> Date: Wed, 4 Jan 2012 14:28:27 -0600
>>> Subject: Re: [caret-users] caret-users Digest, Vol 100, Issue 2
>>> Maybe I'm missing something, but would mapping to volume from the
>>> midthickness surface, with a thickness value greater than the maximum
>>> cortical thickness value, and then masking with the ribbon volume give you
>>> what you want?
>>>
>>> Tim
>>>
>>> On Wed, Jan 4, 2012 at 9:13 AM, Donna Dierker 
>>> wrote:
>>>
>>>> I think it's Volume: Segmentation: Fill Cavities.
>>>>
>>>> You can't just leave it at fill cavities, because projecting from
>>>> surface to each of the pial and white surfaces will result in voxels
>>>> outside the ribbon, even if you do optimize thickness for each.  You need
>>>> to mask the result using the ribbon.  (David sent you an alternate way of
>>>> computing the ribbon, but Matt said that route's ribbon was not more
>>>> accurate than Freesurfer's, which presumably you already have, if you have
>>>> white and pial surfaces.)
>>>>
>>>> Mask is a better verb than subtract.
>>>>
>>>> You still have a problem with how you combine the white and pial
>>>> projections; you can use the "Max" function using Caret's volume math ops
>>>> or fslmaths.  But you consider working with one paint/label at a time, in
>>>> case one region projects to the white, but an adjacent region projects to
>>>> the pial.  The higher paint index wins, and this is probably not what you
>>>> want.  If you can script this in such a way that processing one region at a
>>>> time is not onerous, then you will have yourself a not-easy way of doing
>>>> this.
>>>>
>>>>
>>>> On Jan 3, 2012, at 12:55 PM, Colin Reveley wrote:
>>>>
>>>> > the freesurfer ribbon volume is just a GM segmentation right?
>>>&

Re: [caret-users] caret-users Digest, Vol 100, Issue 2

[Timothy Coalson]

Maybe I'm missing something, but would mapping to volume from the
midthickness surface, with a thickness value greater than the maximum
cortical thickness value, and then masking with the ribbon volume give you
what you want?

Tim

On Wed, Jan 4, 2012 at 9:13 AM, Donna Dierker wrote:

> I think it's Volume: Segmentation: Fill Cavities.
>
> You can't just leave it at fill cavities, because projecting from surface
> to each of the pial and white surfaces will result in voxels outside the
> ribbon, even if you do optimize thickness for each.  You need to mask the
> result using the ribbon.  (David sent you an alternate way of computing the
> ribbon, but Matt said that route's ribbon was not more accurate than
> Freesurfer's, which presumably you already have, if you have white and pial
> surfaces.)
>
> Mask is a better verb than subtract.
>
> You still have a problem with how you combine the white and pial
> projections; you can use the "Max" function using Caret's volume math ops
> or fslmaths.  But you consider working with one paint/label at a time, in
> case one region projects to the white, but an adjacent region projects to
> the pial.  The higher paint index wins, and this is probably not what you
> want.  If you can script this in such a way that processing one region at a
> time is not onerous, then you will have yourself a not-easy way of doing
> this.
>
>
> On Jan 3, 2012, at 12:55 PM, Colin Reveley wrote:
>
> > the freesurfer ribbon volume is just a GM segmentation right?
> >
> > why not leave at just "fill cavaties" (I didn't know that existed, that
> seems the key thing)?
> >
> > On 3 January 2012 18:00,  wrote:
> > Send caret-users mailing list submissions to
> >caret-users@brainvis.wustl.edu
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >http://brainvis.wustl.edu/mailman/listinfo/caret-users
> > or, via email, send a message with subject or body 'help' to
> >caret-users-requ...@brainvis.wustl.edu
> >
> > You can reach the person managing the list at
> >caret-users-ow...@brainvis.wustl.edu
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of caret-users digest..."
> >
> > Today's Topics:
> >
> >   1. Re: painting the entire GM thickness accurately from  surface
> >  data (Donna Dierker)
> >   2. Fwd:  error in overlay (Donna Dierker)
> >
> >
> > -- Forwarded message --
> > From: Donna Dierker 
> > To: "Caret, SureFit, and SuMS software users" <
> caret-users@brainvis.wustl.edu>
> > Cc:
> > Date: Tue, 3 Jan 2012 09:43:46 -0600
> > Subject: Re: [caret-users] painting the entire GM thickness accurately
> from surface data
> > I just don't think there is an easy way to do this in Caret right now,
> but I know that won't stop you. ;-)
> >
> > You might try something like this:
> >
> > map surf paint to vol using white, specifying outer thickness >0
> > map surf paint to vol using pial, specifying inner thickness >0
> > union these volumes and fill cavities
> > subtract the result from the Freesurfer ribbon volume
> > min the resulting difference at 0
> >
> >
> > On Dec 31, 2011, at 11:43 AM, Colin Reveley wrote:
> >
> > > Hi - (happy new year)
> > >
> > > Caret has a nice feature that lets you drop paints from a surface into
> a volume.
> > >
> > > but one thing is that all it really allows is for one to specifiy a
> distance above and below the suface. So, it does not allow one to fill the
> gray matter of a volume with paint accurately.
> > >
> > > But, I can fill the gray or white matter accurately by having a pial
> or white surface (from freesurfer), turning them into segmentations and
> subtracting one from the other.
> > >
> > > Or, wisely avoiding freesurfer, I could make a segmentation of the
> entire volume (threshold to segmentation), shrink a midthickness surface
> made with surefit so it pretty much fits the WM and subtract a segmentation
> of that from the volume segmentation.
> > >
> > > So, is there a way, could there be a way, might there one day be a way
> of moving paint data from surface to volume using a segmentation (derived
> from wherever) as a template, so that the entire cortical thickness is
> labelled by the paint volume, and accounting for thickness variation?
> > >
> > > this would be pretty handy. I could see it helping lots of things (for
> example the scabalebrainatlas).
> > >
> > > since I have a mask/segmentation of gray matter maybe there's a trick
> that I could use to accomplish this right now?
> > >
> > > All I can think of is to use the white, mid and pial surfaces I have
> (and maybe 2 more surfaces, the average of white and mid and of pial and
> mid), make paint volumes and OR them all togther.
> > >
> > > best for 2012.
> > > ___
> > > caret-users mailing list
> > > caret-users@brainvis.wustl.edu
> > > http://brainvis.wustl.edu/mailman/listinfo/caret-users
> >
> >
> >
> >
> >
> > -