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
