[HCP-Users] How to safely unmount /s3/hcp

[Michelle Chiu]

Hello all,

Following the steps on
https://wiki.humanconnectome.org/display/PublicData/How+to+Create+an+EC2+instance+for+HCP+Pipeline+Processing

allows me to mount HCP_900 onto /s3/hcp in my EC2 spot instance.

I've changed my /etc/fstab from "HCP_900" to "HCP_1200" for the 1200
release data, however spot instances cannot be restarted (unlike On-demand).

When I try to unmount on NITRC-CE under "Settings", I get a "Failure to
unmount" message.
When I try to unmount from /s3/hcp using command line, I can't because the
device is busy. Is there a way to safely unmount without using "umount -l"
or *lazy* unmount?

Thank you!

___
HCP-Users mailing list
HCP-Users@humanconnectome.org
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

Re: [HCP-Users] gradient nonlinearity correction question

[Kim, Joo-won]

Hi Kristian,

Have you moved table? If you moved the table, you should manually subtract it 
from qform, sform, and/or affine matrix in the nifty header.

Best,
Joo-won

---
Joo-won Kim, Ph.D.
Postdoctoral Fellow
Translational and Molecular Imaging Institute
Icahn School of Medicine at Mount Sinai


From:  on behalf of Keith Jamison 

Date: Monday, April 9, 2018 at 10:36 AM
To: Kristian Loewe 
Cc: HCP Users 
Subject: Re: [HCP-Users] gradient nonlinearity correction question

First make sure you're using the right coefficient file, copied directly from 
the scanner.  The Prisma should have a file called coeff_AS82.grad, so the one 
you used in your *second* command above should be correct.
Second is to be absolutely sure your input is the uncorrected volume (*_ND).
If you include some matched screenshots of the uncorrected, offline-corrected, 
and scanner-corrected volumes, we can maybe help evaluate the difference.


On Mon, Apr 9, 2018 at 4:09 AM, Kristian Loewe 
> wrote:
Thanks Keith,

Cropping is turned off by default in the version of dcm2niix that I'm using but 
I re-ran the conversion with "-x n" anyway. I also used fslreorient2std as per 
your suggestion. Unfortunately, the result is still the same. Do you have any 
other ideas?


Cheers,

Kristian


Quoting Keith Jamison >:
Some problems can arrise if the NIFTI files are unexpectedly manipulated
prior gradient_unwarp. Two things to check:

1. dcm2nii and dcm2niix has options to perform additional processing like
reorienting or cropping, some of which may be enabled by default. Make sure
those are all DISABLED. (for dcm2niix add "-x n" and for dcm2nii you can
add "-x N -r N"
2. We also usually use "fslreorient2std  _new and then
gradient_unwarp.py
 on _new

-Keith


On Fri, Apr 6, 2018 at 12:05 PM, Kristian Loewe 
>
wrote:
Hi,

I would like to use gradunwarp for offline gradient nonlinearity
correction of some data acquired on our local Siemens scanners. I used
dcm2niix to convert the dicom data to nifti format. After applying
gradunwarp to a T1 image in nifti format (the one that originally has
the _ND suffix), I proceeded to compare the result with the
Siemens-corrected T1 image. I expected that they would look very
similar but in fact they look quite different. I am wondering if this
is to be expected to some degree because of differences in the
correction algorithms or what else might be the reason for this. Could
it be the case, for example, that the wrong center is being used for
some reason?

I have tried this for a T1 image acquired on a Verio and another one
from a Prisma using

   
gradient_unwarp.py
 T1.nii.gz T1_gdc.nii.gz siemens -g coeff_AS097.grad
-n

and

   
gradient_unwarp.py
 T1.nii.gz T1_gdc.nii.gz siemens -g coeff_AS82.grad -n

respectively.

I would really appreciate any help or advice you can provide.

Cheers,

Kristian


Quoting Keith Jamison >:

> FYI, when available, you can enable it on the scanner in the
> "Resolution->Filter" tab with the "Distortion Correction" checkbox.  It's
> often used for structural scans like MPRAGE, where you will see two DICOM
> folders in the output:  and _ND.  ND means "No
> Distortion [Correction]".. .A very confusing choice of acronym.  You can
> then compare the online corrected (not _ND) and offline using gradunwarp.
>
> -Keith
>
>
> On Wed, Oct 19, 2016 at 4:44 PM, Glasser, Matthew 
> >
> wrote:
>
>> Some do for some sequences, but because it is not uniformly applied and
>> because they are likely not to use optimal interpolation algorithms, we
>> prefer to do offline correction.
>>
>> Peace,
>>
>> Matt.
>>
>> From: 
>> >
>>  on behalf of Antonin
Skoch <
>> a...@ikem.cz>
>> Date: Wednesday, October 19, 2016 at 4:27 PM
>> To: "hcp-users@humanconnectome.org" 
>> 

Re: [HCP-Users] gradient nonlinearity correction question

[Keith Jamison]

First make sure you're using the right coefficient file, copied directly
from the scanner.  The Prisma should have a file called coeff_AS82.grad, so
the one you used in your *second* command above should be correct.

Second is to be absolutely sure your input is the uncorrected volume (*_ND).

If you include some matched screenshots of the uncorrected,
offline-corrected, and scanner-corrected volumes, we can maybe help
evaluate the difference.


On Mon, Apr 9, 2018 at 4:09 AM, Kristian Loewe  wrote:

> Thanks Keith,
>
> Cropping is turned off by default in the version of dcm2niix that I'm
> using but I re-ran the conversion with "-x n" anyway. I also used
> fslreorient2std as per your suggestion. Unfortunately, the result is still
> the same. Do you have any other ideas?
>
>
> Cheers,
>
> Kristian
>
>
> Quoting Keith Jamison :
>
> Some problems can arrise if the NIFTI files are unexpectedly manipulated
>> prior gradient_unwarp. Two things to check:
>>
>> 1. dcm2nii and dcm2niix has options to perform additional processing like
>> reorienting or cropping, some of which may be enabled by default. Make
>> sure
>> those are all DISABLED. (for dcm2niix add "-x n" and for dcm2nii you can
>> add "-x N -r N"
>> 2. We also usually use "fslreorient2std  _new and then
>> gradient_unwarp.py on _new
>>
>> -Keith
>>
>>
>> On Fri, Apr 6, 2018 at 12:05 PM, Kristian Loewe 
>> wrote:
>>
>> Hi,
>>>
>>> I would like to use gradunwarp for offline gradient nonlinearity
>>> correction of some data acquired on our local Siemens scanners. I used
>>> dcm2niix to convert the dicom data to nifti format. After applying
>>> gradunwarp to a T1 image in nifti format (the one that originally has
>>> the _ND suffix), I proceeded to compare the result with the
>>> Siemens-corrected T1 image. I expected that they would look very
>>> similar but in fact they look quite different. I am wondering if this
>>> is to be expected to some degree because of differences in the
>>> correction algorithms or what else might be the reason for this. Could
>>> it be the case, for example, that the wrong center is being used for
>>> some reason?
>>>
>>> I have tried this for a T1 image acquired on a Verio and another one
>>> from a Prisma using
>>>
>>>gradient_unwarp.py T1.nii.gz T1_gdc.nii.gz siemens -g coeff_AS097.grad
>>> -n
>>>
>>> and
>>>
>>>gradient_unwarp.py T1.nii.gz T1_gdc.nii.gz siemens -g coeff_AS82.grad
>>> -n
>>>
>>> respectively.
>>>
>>> I would really appreciate any help or advice you can provide.
>>>
>>> Cheers,
>>>
>>> Kristian
>>>
>>>
>>> Quoting Keith Jamison :
>>>
>>> > FYI, when available, you can enable it on the scanner in the
>>> > "Resolution->Filter" tab with the "Distortion Correction" checkbox.
>>> It's
>>> > often used for structural scans like MPRAGE, where you will see two
>>> DICOM
>>> > folders in the output:  and _ND.  ND means "No
>>> > Distortion [Correction]".. .A very confusing choice of acronym.  You
>>> can
>>> > then compare the online corrected (not _ND) and offline using
>>> gradunwarp.
>>> >
>>> > -Keith
>>> >
>>> >
>>> > On Wed, Oct 19, 2016 at 4:44 PM, Glasser, Matthew 
>>> > wrote:
>>> >
>>> >> Some do for some sequences, but because it is not uniformly applied
>>> and
>>> >> because they are likely not to use optimal interpolation algorithms,
>>> we
>>> >> prefer to do offline correction.
>>> >>
>>> >> Peace,
>>> >>
>>> >> Matt.
>>> >>
>>> >> From:  on behalf of Antonin
>>> Skoch <
>>> >> a...@ikem.cz>
>>> >> Date: Wednesday, October 19, 2016 at 4:27 PM
>>> >> To: "hcp-users@humanconnectome.org" 
>>> >> Subject: [HCP-Users] gradient nonlinearity correction question
>>> >>
>>> >> Dear experts,
>>> >>
>>> >> during the set-up of gradunwarp scripts, it came to my mind, why
>>> scanner
>>> >> vendors standardly do not perform gradient nonlinearity correction
>>> directly
>>> >> on the scanner as part of on-line image reconstruction system (i.e.
>>> ICE
>>> in
>>> >> Siemens)?
>>> >>
>>> >> Regards,
>>> >>
>>> >> Antonin Skoch
>>> >>
>>> >>
>>> >> ___
>>> >> HCP-Users mailing list
>>> >> HCP-Users@humanconnectome.org
>>> >> 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.
>>> >>
>>> >> ___

Re: [HCP-Users] gradient nonlinearity correction question

[Kristian Loewe]

Thanks Keith,

Cropping is turned off by default in the version of dcm2niix that I'm  
using but I re-ran the conversion with "-x n" anyway. I also used  
fslreorient2std as per your suggestion. Unfortunately, the result is  
still the same. Do you have any other ideas?

Cheers,

Kristian


Quoting Keith Jamison :

> Some problems can arrise if the NIFTI files are unexpectedly manipulated
> prior gradient_unwarp. Two things to check:
>
> 1. dcm2nii and dcm2niix has options to perform additional processing like
> reorienting or cropping, some of which may be enabled by default. Make sure
> those are all DISABLED. (for dcm2niix add "-x n" and for dcm2nii you can
> add "-x N -r N"
> 2. We also usually use "fslreorient2std  _new and then
> gradient_unwarp.py on _new
>
> -Keith
>
>
> On Fri, Apr 6, 2018 at 12:05 PM, Kristian Loewe 
> wrote:
>
>> Hi,
>>
>> I would like to use gradunwarp for offline gradient nonlinearity
>> correction of some data acquired on our local Siemens scanners. I used
>> dcm2niix to convert the dicom data to nifti format. After applying
>> gradunwarp to a T1 image in nifti format (the one that originally has
>> the _ND suffix), I proceeded to compare the result with the
>> Siemens-corrected T1 image. I expected that they would look very
>> similar but in fact they look quite different. I am wondering if this
>> is to be expected to some degree because of differences in the
>> correction algorithms or what else might be the reason for this. Could
>> it be the case, for example, that the wrong center is being used for
>> some reason?
>>
>> I have tried this for a T1 image acquired on a Verio and another one
>> from a Prisma using
>>
>>gradient_unwarp.py T1.nii.gz T1_gdc.nii.gz siemens -g coeff_AS097.grad
>> -n
>>
>> and
>>
>>gradient_unwarp.py T1.nii.gz T1_gdc.nii.gz siemens -g coeff_AS82.grad -n
>>
>> respectively.
>>
>> I would really appreciate any help or advice you can provide.
>>
>> Cheers,
>>
>> Kristian
>>
>>
>> Quoting Keith Jamison :
>>
>> > FYI, when available, you can enable it on the scanner in the
>> > "Resolution->Filter" tab with the "Distortion Correction" checkbox.  It's
>> > often used for structural scans like MPRAGE, where you will see two DICOM
>> > folders in the output:  and _ND.  ND means "No
>> > Distortion [Correction]".. .A very confusing choice of acronym.  You can
>> > then compare the online corrected (not _ND) and offline using gradunwarp.
>> >
>> > -Keith
>> >
>> >
>> > On Wed, Oct 19, 2016 at 4:44 PM, Glasser, Matthew 
>> > wrote:
>> >
>> >> Some do for some sequences, but because it is not uniformly applied and
>> >> because they are likely not to use optimal interpolation algorithms, we
>> >> prefer to do offline correction.
>> >>
>> >> Peace,
>> >>
>> >> Matt.
>> >>
>> >> From:  on behalf of Antonin
>> Skoch <
>> >> a...@ikem.cz>
>> >> Date: Wednesday, October 19, 2016 at 4:27 PM
>> >> To: "hcp-users@humanconnectome.org" 
>> >> Subject: [HCP-Users] gradient nonlinearity correction question
>> >>
>> >> Dear experts,
>> >>
>> >> during the set-up of gradunwarp scripts, it came to my mind, why scanner
>> >> vendors standardly do not perform gradient nonlinearity correction
>> directly
>> >> on the scanner as part of on-line image reconstruction system (i.e. ICE
>> in
>> >> Siemens)?
>> >>
>> >> Regards,
>> >>
>> >> Antonin Skoch
>> >>
>> >>
>> >> ___
>> >> HCP-Users mailing list
>> >> HCP-Users@humanconnectome.org
>> >> 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
>> >> 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
>>
>>
>>
>> ___
>> 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

Re: [HCP-Users] questions about using HCP surface ROIs in prob-tracking

[Xinyang Liu]

Dear Tim,


Great to know. Thank you so much for your kind patience and help! :)


Best regards,
Xinyang



At 2018-04-09 02:52:06, "Timothy Coalson"  wrote:

Yes, vertex-based data is not tied to any volume space, whether it is stored in 
cifti or gifti.


Tim




On Sun, Apr 8, 2018 at 5:27 AM, Xinyang Liu  wrote:

Dear Tim,


Hi. Thanks a lot to your very detailed explanation, I am more clear now about 
the underpinning relationships. :)


Just to make sure one more thing, when you mentioned "if ignoring the 
subcortical part, then everything will work with T1w surfaces", does this 
"everything" also include the GIFTI files (.func.gii) which were converted from 
the tfMRI CIFTI (.dtseries.nii) files, apart from the original CIFTI files 
themselves? Thanks!


Best regards,
Xinyang


在 2018-04-06 12:36:26，"Timothy Coalson"  写道：

On Thu, Apr 5, 2018 at 11:18 PM, Xinyang Liu  wrote:

Dear Tim,


Hi. Lots of thanks to your very detailed answer! :)


Yes, I agree with you that it would be better to do tractography in the subject 
native volume space. And it is good to know that the MMP1.0 can be also used in 
"T1w"-space surfaces. However, there is one existed problem that I cannot 
figure out. The tfMRI outputs (e.g. tstat1.dtseries.nii) of the 
"$Subject_3T_tfMRI_$TASK_analysis_s2.zip" are in the CIFTI grayordinates 
standard space, with the directory of "MNINonlinear".


CIFTI files contain both surface data and voxel-based data.  We generally only 
release cifti files that use MNI space for the subcortical voxels.  This is why 
they are in MNINonLinear, not because of the surface data.
 
There is no T1w folder for the native cortical surface in the tfMRI s2 file.


The surface files (.surf.gii) are in the structural packages, not in fMRI 
packages.  The fMRI CIFTI files will only have versions in the MNINonLinear 
directory, but as explained, the surface data values are not tied to any volume 
space, only the subcortical values are.  You can use T1w surfaces with the fMRI 
CIFTI files, despite them being in MNINonLinear, as long as you understand that 
the subcortical voxels will not line up properly with respect to the surfaces.  
If you only care about the cortical data, you can ignore the subcortical stuff 
entirely, and everything will work with surfaces in the T1w folder.
 
To do tractography in native volume space, I suppose the surface ROIs should 
also go back to the native surface. But with the only standardly registered 
tfMRI grayordinate output, how should I change back?


No, you don't need to do anything about native mesh, just use the MSMAll 
32k_fs_LR surface data with the T1w folder MSMAll 32k_fs_LR anatomical 
surfaces, and things will work.


I think you have encountered an unfortunate terminology choice on our part - 
the "native mesh" does not refer to anything related to the "native volume 
space", they are orthogonal concepts.  "Native mesh" just means the 
subject-specific, haphazard mesh that comes out of freesurfer (approximately 
140k vertices per hemisphere, as I recall).  This doesn't prevent the 
application of volume registration to their coordinates - indeed, there are 
"native mesh" surfaces in the MNINonLinear folder, where this is exactly what 
we did.  However, you don't need to use them, or the native mesh surfaces in 
T1w space either.
 
Best regards,
Xinyang




At 2018-04-05 04:54:04, "Timothy Coalson"  wrote:

Inline replies to some comments.


Tim


On Wed, Apr 4, 2018 at 7:38 AM, Xinyang Liu  wrote:

Dear Matthew,


Thank you very much for your detailed explanation!


1. The current situation of our study is that, we used the HCP MMP1.0 atlas to 
sample the tfMRI data in order to localize specific functional areas. Since the 
HCP MMP1.0 is in the MNI space,


No, it isn't, because version 1.0 is a surface-only parcellation.  
Surface-based labels or scalar data are not in any volume space, it is only the 
geometry files (*.surf.gii) that have any coordinates in them at all.  It is 
also correct to use the MMP1.0 with "T1w"-space surfaces (MSMAll is 
recommended).
 
we used 
"$SUBJECT/MNINonLinear/fsaverage_LR32k/$SUBJECT.L.midthickness._MSMAll.32k_fs_LR.surf.gii"
 to do the multiplication. Then I suppose the surface ROI to be acquired in the 
MNI standard space, and therefore need to use the --xfm and --invxfm in 
probtrackx2. Is my understanding correct?


As I understand it, tracking in subject native (T1w) volume space is strongly 
recommended, because the nonlinear MNI warp could change the paths that 
tractography takes to be something unrealistic.  The T1w space is an 
undistorted, rigid aligned version of the scanner space of the anatomical 
images (and the T1w space diffusion data has had its vectors rotated to match 
this rigid alignment), and thus the white matter is the same shape as it is in 
the subject's head.
 
2. In this way, do