for those interested I just wrote a small dirty function:
https://github.com/bpinsard/misc/blob/master/split_labels_hcp.py
which splits the labels using the principal axis, but I changed the
MNE-tools original code to split in regions with somewhat even number of
vertices in each, which must be someway a proxy for the surface of cortex.
It seems not to be the case in the original code, which splits at regular
space along axis (like chopping a carrot), but I cannot assert as I didn't
tested it.

a small example is provided, but I do not save the resulting array as gifti
format is somewhat obscure to me.
use at you own risks
cheers.

basile




On Mon, Mar 17, 2014 at 5:24 PM, Glasser, Matthew
<[email protected]>wrote:

>  My understanding is that is what this command does (or can do).
>
>  Peace,
>
>  Matt.
>
>   From: basile pinsard <[email protected]>
> Date: Monday, March 17, 2014 11:22 AM
> To: Matt Glasser <[email protected]>
> Cc: "Harms, Michael" <[email protected]>, Donna Dierker <
> [email protected]>, "[email protected]" <
> [email protected]>
>
> Subject: Re: [HCP-Users] subdivide parcellation
>
>    ok I think I will adapt the MNE code to do the job as I am interested
> into subdividing the existing parcellation rather than creating a random
> one.
>  many thanks for your replies.
>  cheers
>
>  basile
>
>
> On Mon, Mar 17, 2014 at 4:12 PM, Glasser, Matthew <[email protected]
> > wrote:
>
>>  They would not necessarily be aligned with the other data either, given
>> that they exist in their own 1mm RAS space, not the 0.7mm RPI spaces
>> released by the HCP.
>>
>>  For this particular task, I would use:
>>
>>  brainmappers@brainmappers-desktop1:~$ mris_make_face_parcellation
>> usage: mris_make_face_parcellation [options] <input surface> <ico file>
>> <output annot>
>>
>>  example: mris_make_face_parcellation lh.surf
>> $FREESURFER_HOME/lib/bem/ic3.tri ./lh.ic3.annot
>>   surf should be either:
>>     sphere: units will be approximately equal size within subject but
>>             not in correspondence across subjects
>>     sphere.reg: units will be different sizes within subject but
>>             in correspondence across subjects
>>   Note: do not use inflated as was suggested by previous versions!
>>
>>
>>  This generates a parcellation based on which icosahedral face each
>> vertex maps to.
>> Options:
>>   -ctab colortable.txt
>>
>>  Most FreeSurfer binaries work with GIFTI files now (the .label.gii
>> files are equivalent to annot), but sometimes they have "hidden" inputs
>> that may be hard coded to old formats and directory structures.  If this is
>> the case, they will throw a descriptive error message and you may need to
>> use mris_convert to convert some GIFTI file to be whatever the binary is
>> looking for.
>>
>>  Peace,
>>
>>  Matt.
>>
>>   From: <Harms>, Michael <[email protected]>
>> Date: Monday, March 17, 2014 10:04 AM
>> To: basile pinsard <[email protected]>, Donna Dierker <
>> [email protected]>
>>
>> Cc: "[email protected]" <[email protected]>
>> Subject: Re: [HCP-Users] subdivide parcellation
>>
>>
>>  I don't think we've had any discussions about releasing the Freesurfer
>> outputs in their "native" FS directory structure.
>> Indeed, it would be quite redundant to do so.
>>
>>  cheers,
>> -MH
>>
>>   --
>> Michael Harms, Ph.D.
>>  -----------------------------------------------------------
>> Conte Center for the Neuroscience of Mental Disorders
>> Washington University School of Medicine
>> Department of Psychiatry, Box 8134
>> 660 South Euclid Ave. Tel: 314-747-6173
>> St. Louis, MO  63110 Email: [email protected]
>>
>>   From: basile pinsard <[email protected]>
>> Date: Monday, March 17, 2014 9:51 AM
>> To: Donna Dierker <[email protected]>
>> Cc: "[email protected]" <[email protected]>
>> Subject: Re: [HCP-Users] subdivide parcellation
>>
>>    Hi Donna,
>>
>> so you mean this is the files that will be in the next release?
>>  Because what I get from downloading preprocessed structural does not has
>> this structure, here is a list for one subject:
>>
>> STRU/101915/T1w/101915_3T.csv
>> STRU/101915/T1w/aparc.a2009s+aseg.nii.gz
>> STRU/101915/T1w/aparc+aseg.nii.gz
>> STRU/101915/T1w/BiasField_acpc_dc.nii.gz
>> STRU/101915/T1w/brainmask_fs.nii.gz
>> STRU/101915/T1w/fsaverage_LR32k
>> STRU/101915/T1w/fsaverage_LR32k/101915.32k_fs_LR.wb.spec
>> STRU/101915/T1w/fsaverage_LR32k/101915.L.inflated.32k_fs_LR.surf.gii
>> STRU/101915/T1w/fsaverage_LR32k/101915.L.midthickness.32k_fs_LR.surf.gii
>> STRU/101915/T1w/fsaverage_LR32k/101915.L.pial.32k_fs_LR.surf.gii
>> STRU/101915/T1w/fsaverage_LR32k/101915.L.very_inflated.32k_fs_LR.surf.gii
>> STRU/101915/T1w/fsaverage_LR32k/101915.L.white.32k_fs_LR.surf.gii
>> STRU/101915/T1w/fsaverage_LR32k/101915.R.inflated.32k_fs_LR.surf.gii
>> STRU/101915/T1w/fsaverage_LR32k/101915.R.midthickness.32k_fs_LR.surf.gii
>> STRU/101915/T1w/fsaverage_LR32k/101915.R.pial.32k_fs_LR.surf.gii
>> STRU/101915/T1w/fsaverage_LR32k/101915.R.very_inflated.32k_fs_LR.surf.gii
>> STRU/101915/T1w/fsaverage_LR32k/101915.R.white.32k_fs_LR.surf.gii
>> STRU/101915/T1w/Native
>> STRU/101915/T1w/Native/101915.L.inflated.native.surf.gii
>> STRU/101915/T1w/Native/101915.L.midthickness.native.surf.gii
>> STRU/101915/T1w/Native/101915.L.pial.native.surf.gii
>> STRU/101915/T1w/Native/101915.L.very_inflated.native.surf.gii
>> STRU/101915/T1w/Native/101915.L.white.native.surf.gii
>> STRU/101915/T1w/Native/101915.native.wb.spec
>> STRU/101915/T1w/Native/101915.R.inflated.native.surf.gii
>> STRU/101915/T1w/Native/101915.R.midthickness.native.surf.gii
>> STRU/101915/T1w/Native/101915.R.pial.native.surf.gii
>> STRU/101915/T1w/Native/101915.R.very_inflated.native.surf.gii
>> STRU/101915/T1w/Native/101915.R.white.native.surf.gii
>> STRU/101915/T1w/ribbon.nii.gz
>> STRU/101915/T1w/T1w_acpc_dc.nii.gz
>> STRU/101915/T1w/T1w_acpc_dc_restore_brain.nii.gz
>> STRU/101915/T1w/T1w_acpc_dc_restore.nii.gz
>> STRU/101915/T1w/T1wDividedByT2w.nii.gz
>> STRU/101915/T1w/T1wDividedByT2w_ribbon.nii.gz
>> STRU/101915/T1w/T2w_acpc_dc.nii.gz
>> STRU/101915/T1w/T2w_acpc_dc_restore_brain.nii.gz
>> STRU/101915/T1w/T2w_acpc_dc_restore.nii.gz
>> STRU/101915/T1w/wmparc.nii.gz
>>
>>
>>  Thanks
>>
>>  Basile
>>
>>
>> On Mon, Mar 17, 2014 at 3:35 PM, Donna Dierker 
>> <[email protected]>wrote:
>>
>>> Hi basile,
>>>
>>> Note that I'm looking at the structure for the data that is about to
>>> come out, but I see the Freesurfer original directory structure here:
>>>
>>> T1w/106016
>>> T1w/106016/label
>>> T1w/106016/mri
>>> T1w/106016/mri/orig
>>> T1w/106016/mri/transforms
>>> T1w/106016/scripts
>>> T1w/106016/stats
>>> T1w/106016/surf
>>> T1w/106016/touch
>>>
>>> Donna
>>>
>>>
>>> On Mar 15, 2014, at 5:50 PM, basile pinsard <[email protected]>
>>> wrote:
>>>
>>> > Many thanks for the answers.
>>> >
>>> > @Mark: this seems an interesting option if it enables to overcome the
>>> fact that mris_divide_parcellation won't work on gifti and needs freesurfer
>>> original subject directory structure. I will need to adapt it to search for
>>> the files in hcp structure and handle gifti files though.
>>> >
>>> > @Markus : The only limitation I see for using cmtk Lausanne
>>> parcellation on hcp data is the fact it requires regular freesurfer
>>> outputs/structure to run it relying on freesurfer binaries. I think they
>>> are not contained in the hcp release and this certainly imply converting
>>> gitfti back to freesurfer format? Or rerunning sub-optimally freesurfer
>>> (without .7mm optimization etc).
>>> >
>>> > Best,
>>> > basile
>>> >
>>> >
>>> >
>>> > On Sat, Mar 15, 2014 at 10:33 PM, Markus Gschwind <
>>> [email protected]> wrote:
>>> > Hi!
>>> >
>>> > You might be interested in the parcellation tool form connectomemapper
>>> in nipype
>>> >
>>> http://nipy.org/nipype/0.6/interfaces/generated/nipype.interfaces.cmtk.parcellation.html
>>> >
>>> > or the connectomemapper itself:
>>> > http://www.cmtk.org/mapper/stages.html#parcellation
>>> >
>>> > This is the tool that created the multi-parcellation presented in
>>> >
>>> http://www.plosbiology.org/article/info%3Adoi%2F10.1371%2Fjournal.pbio.0060159
>>> >
>>> > Best,
>>> > Markus
>>> >
>>> >
>>> > 2014-03-14 20:10 GMT+01:00 basile pinsard <[email protected]>:
>>> > Hi HCP experts,
>>> >
>>> > I am trying to subdivide the aparc.a2009s parcellation (for cortex
>>> only, maybe cerebellum too) to get more homogeneous sized parcels
>>> (preserving connectivity) to perform connectivity study at the subject
>>> level from densetimeseries, I can think of many ways to do this but none is
>>> that simple to carry out.
>>> > Is there a command that would be appropriate in wb_command utility?
>>> > What do you think would be the best way to proceed?
>>> > Is it possible to simply map a surface parcellation from fsaverage to
>>> a subject's fsaverage32k space?
>>> >
>>> > Thanks
>>> > Best regards.
>>> >
>>> > basile
>>> > _______________________________________________
>>> >
>>> >
>>> > HCP-Users mailing list
>>> > [email protected]
>>> > http://lists.humanconnectome.org/mailman/listinfo/hcp-users
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > HCP-Users mailing list
>>> > [email protected]
>>> > http://lists.humanconnectome.org/mailman/listinfo/hcp-users
>>> >
>>>
>>>
>>  _______________________________________________
>> HCP-Users mailing list
>> [email protected]
>> http://lists.humanconnectome.org/mailman/listinfo/hcp-users
>>
>>
>>  ------------------------------
>>
>> The materials in this message are private and may contain Protected
>> Healthcare Information or other information of a sensitive nature. If you
>> are not the intended recipient, be advised that any unauthorized use,
>> disclosure, copying or the taking of any action in reliance on the contents
>> of this information is strictly prohibited. If you have received this email
>> in error, please immediately notify the sender via telephone or return mail.
>>
>> _______________________________________________
>> HCP-Users mailing list
>> [email protected]
>> http://lists.humanconnectome.org/mailman/listinfo/hcp-users
>>
>>
>>  ------------------------------
>>
>> The materials in this message are private and may contain Protected
>> Healthcare Information or other information of a sensitive nature. If you
>> are not the intended recipient, be advised that any unauthorized use,
>> disclosure, copying or the taking of any action in reliance on the contents
>> of this information is strictly prohibited. If you have received this email
>> in error, please immediately notify the sender via telephone or return mail.
>>
>
>
>  ------------------------------
>
> The materials in this message are private and may contain Protected
> Healthcare Information or other information of a sensitive nature. If you
> are not the intended recipient, be advised that any unauthorized use,
> disclosure, copying or the taking of any action in reliance on the contents
> of this information is strictly prohibited. If you have received this email
> in error, please immediately notify the sender via telephone or return mail.
>

_______________________________________________
HCP-Users mailing list
[email protected]
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

Reply via email to