Sorry, one more...we do have a command to put the coordinates of a surface file into a metric file, so you can compute center of gravity in a surface-based way. Use -surface-coordinates-to-metric, then either -cifti-create-dense-from-template to put the coordinates into cifti, followed by -cifti-parcellate to generate all the centers of gravity, or use -gifti-label-to-roi and -metric-stats to take the center of gravity of a single parcel.
Tim On Wed, Feb 13, 2019 at 1:34 PM Timothy Coalson <tsc...@mst.edu> wrote: > Correction to the volume center of gravity part: if you convert to ROIs > before mapping to volume, you will have soft-edge "ROIs" in the volume, as > it accounts for partial voluming. You can use these as the weights in > -volume-weighted-stats (and you wouldn't need the -roi option) to take this > into account, if you want. If you have binary ROIs in the volume, > -volume-stats with -roi is sufficient. However, the choice of soft-edge > ROIs would matter more to an approach that actually used the shape of the > areas, rather than to a method that only uses center of gravity. > > Tim > > > On Wed, Feb 13, 2019 at 1:26 PM Timothy Coalson <tsc...@mst.edu> wrote: > >> The command you are looking for is -metric-to-volume-mapping for an ROI, >> or -label-to-volume-mapping for the entire label file. Note that these >> take gifti inputs, so you will need -cifti-separate and possibly >> -gifti-label-to-roi first (alternatively, -volume-label-to-roi >> afterwards). We don't have a command to give the center of gravity of an >> ROI, though - if you make a volume file containing the coordinates of every >> voxel (in matlab or octave), then you can use -volume-weighted-stats on it >> with -roi and -mean and that will give you center of gravity. >> >> The problem we keep mentioning with MNI volume space is when it is used >> for averaging voxel data across subjects, because current volume >> registrations don't achieve the cross-subject functional correspondence >> that even folding-based surface registration does. It is valid to use >> surfaces and volumes of a single individual in MNI space (we actually do >> this with functional data, mostly for computational and storage reasons), >> and these are provided in the MNINonLinear folder. >> >> However, be aware that our MNI space is nonlinear registered, and as such >> it has local deformations of features compared to what the subject anatomy >> really is. Our "T1w" space is actually rigidly (rotation and translation >> only) registered to an MNI template, so you can treat it mostly like a >> linear MNI registration (however, note that the MNI templates and the >> related 12-DOF registrations have different expansion ratios on different >> axes compared to average human brain size). >> >> So, our "T1w" space is an anatomically accurate space for the subject, >> but has been mostly aligned to the MNI coordinate system. You will have to >> work out whether the slightly-larger MNI coordinates are compensated for in >> your software, and thus you would need to either "add in" the typical MNI >> scaling to our "T1w" coordinates, or do your own affine registration to >> MNI. Alternatively, if you can back out the computed solution into a >> subject-specific space before actually positioning the coils, then it may >> not matter that what you put into the software isn't "really" MNI space. >> Volume space issues are always a bunch of fun... >> >> Tim >> >> >> On Wed, Feb 13, 2019 at 12:36 PM Stevens, Michael < >> michael.stev...@hhchealth.org> wrote: >> >>> It also occurs to me that if someone has already worked out even roughly >>> approximate locations for parcels (e.g., centers?) that correspond to >>> volume space coordinates in MNI-land, this would be “good enough” for me to >>> finalize the grant proposal in the next day or so. Admittedly, I’d rather >>> learn which files/commands I can use to do the transformations directly so >>> I can explore a bit with real data. But I’d be really happy just to be >>> able to have something that allows us to generate the typical tDCS field >>> intensity mappings and electrode configuration for this grant proposal’s >>> methods section. >>> >>> >>> >>> Thanks! >>> >>> Mike >>> >>> >>> >>> >>> >>> *From:* Glasser, Matthew [mailto:glass...@wustl.edu] >>> *Sent:* Tuesday, February 12, 2019 10:58 PM >>> *To:* Stevens, Michael; hcp-users@humanconnectome.org >>> *Subject:* Re: [HCP-Users] Individualized HCP parcel to MNI coord >>> >>> >>> >>> EXTERNAL email from Outside HHC! Do NOT open attachments or click links >>> from unknown senders. >>> >>> If we leave out the “MNI coordinates” part of this question and think in >>> terms of the volume space coordinates of the individual being studied, it >>> is perfectly valid to bring results from the group surface back to an >>> individual’s physical volume space. Is a single coordinate what you need or >>> would an ROI be better? >>> >>> >>> >>> Matt. >>> >>> >>> >>> *From: *<hcp-users-boun...@humanconnectome.org> on behalf of "Stevens, >>> Michael" <michael.stev...@hhchealth.org> >>> *Date: *Tuesday, February 12, 2019 at 9:47 PM >>> *To: *"hcp-users@humanconnectome.org" <hcp-users@humanconnectome.org> >>> *Subject: *[HCP-Users] Individualized HCP parcel to MNI coord >>> >>> >>> >>> Hi everyone, >>> >>> >>> >>> I know by now this is a tired subject that’s come up in several ways on >>> the HCP listserv over the past few years. But can y’all remind me the most >>> straightforward way to go backwards from a given HCP parcel (e.g., IFSa) >>> and find a reasonably close approximation in MNI space? >>> >>> >>> >>> The problems in working from “group level” surface data and the >>> differences from subject to subject have been discussed here before. But >>> I’m pretty sure I’m not risking those pitfalls with what I’m planning >>> here. I’m finalizing a study design and I need a “starting point” to >>> select precise brain stimulation coordinates for individuals. This study >>> formulation is based on several years’ worth of my fMRI data in HCP space >>> that I’ve done some things with ICA and DCM to put together some >>> interesting systems-level circuit maps. Now, based on findings within HCP >>> localized space, I want to use specific parcels to plan how best to >>> modulate those circuits experimentally with tDCS. The catch… of course… is >>> that the neurotargeting software works in voxelwise space. In practice, I >>> suspect this won’t be too significant a hurdle. I envision taking each >>> subject’s individual surface, backtracking a given HCP parcel to their own >>> volume space, then use neurotargeting software to figure out how to >>> optimize focality/field intensity to that region in volume space… purely on >>> a subject-by-subject basis. Even the individual parcel-to-volume mapping >>> would be nothing more than a starting point for individualized >>> optimization. You can only do so much to maximize tDCS focality… even with >>> impressive recent advances in multifocal current flow modeling. So there’s >>> always going to be some slop. The trick simply is to minimize that slop as >>> much as possible, including making sure I don’t inadvertently divert >>> current through OTHER key regions of the neural circuit. >>> >>> >>> >>> So what I lack is a set of wb_command’s that can do that individualized >>> back-tracking. If possible, I want to actually do this on my own data >>> prior to finalizing the grant proposal I’m working up right now, just to be >>> sure I’ve got all this right. I’ve already got some code (thank to y’all a >>> few months back) that uses the –volume-to-surface-mapping command to go the >>> OTHER way. Sure, I could make a string of guesses of which MNI coordinates >>> might map best to my target parcels, and test iteratively over a 100 or so >>> subject datasets until I find a convincing match. But it just seems >>> “cleaner” if I could simply do the reverse of this… That is, truly go from >>> a given parcel (e.g., IFSa) to MNI coordinate in each subject. I might’ve >>> missed it, but I just don’t see an obvious command candidate for going in >>> the other direction. If there’s not, is there a way to string together a >>> bunch of other wb_command’s to achieve this result? >>> >>> >>> >>> Any guidance would be welcome. Thanks in advance! >>> >>> >>> >>> Mike >>> >>> >>> >>> >>> >>> Michael C. Stevens, Ph.D. >>> >>> Director, CNDLAB, Olin Neuropsychiatry Research Center >>> >>> Director, Child & Adolescent Research, The Institute of Living >>> >>> Adjunct Professor of Psychiatry, Yale University School of Medicine >>> >>> >>> >>> >>> >>> >>> *This e-mail message, including any attachments, is for the sole use of >>> the intended recipient(s) and may contain confidential and privileged >>> information. Any unauthorized review, use, disclosure, or distribution is >>> prohibited. If you are not the intended recipient, or an employee or agent >>> responsible for delivering the message to the intended recipient, please >>> contact the sender by reply e-mail and destroy all copies of the original >>> message, including any attachments. * >>> >>> _______________________________________________ >>> HCP-Users mailing list >>> HCP-Users@humanconnectome.org >>> http://lists.humanconnectome.org/mailman/listinfo/hcp-users >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.humanconnectome.org_mailman_listinfo_hcp-2Dusers&d=DwMF-g&c=e_HtEeZEQXP5NUOb33qoTj0AVvRFBS9_rhBTQcfkWoA&r=golSXqwzwyESse15ixCMA3FkCV08C4TvBJ1P6uKO0nE&m=4SjVi-8cpylbSXxrt8aSRiZs-OTJtz-JSyfzOqMrTOE&s=LfQq03Plq22cs0a2MRLwH6OlU0zrui4h-fn6b7o84Ro&e=> >>> >>> >>> ------------------------------ >>> >>> 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. >>> >>> >>> >>> *Reminder: This e-mail and any attachments are subject to the current >>> HHC email retention policies. Please save or store appropriately in >>> accordance with policy. * >>> >>> _______________________________________________ >>> HCP-Users mailing list >>> HCP-Users@humanconnectome.org >>> http://lists.humanconnectome.org/mailman/listinfo/hcp-users >>> >> _______________________________________________ HCP-Users mailing list HCP-Users@humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users
