Re: [HCP-Users] Converting legacy data to CIFTI format

[Glasser, Matthew]

That doesn’t sound like you solved the alignment problem (it will still be 
misaligned in the volume) and I wouldn’t expect specifying the T2w as the T1w 
will work without some pipeline modifications.

Matt.

From: Kelli Cannon >
Date: Thursday, October 6, 2016 at 1:17 PM
To: Matt Glasser >
Cc: "hcp-users@humanconnectome.org" 
>
Subject: Re: Converting legacy data to CIFTI format

Hi Matt,

Thanks for the information! I was able to successfully run the PreFreeSurfer 
pipeline by specifying the T1w image as the T2w image. The FreeSurfer pipeline 
is running now, and I expect to be able to run the PostFreeSurfer pipeline 
next, since I have the output files from the PreFreeSurfer pipeline to use as 
inputs into the PostFreeSurfer pipeline.

The main reason that I am wanting to convert my legacy data into CIFTI space is 
to map the Glasser et al., 2016 MMP average parcellation scheme to my data. 
Since the lack of field maps makes accurately registering the BOLD scan to the 
T1w image problematic, I will apply the subject-specific NIFTI/CIFTI 
transformation matrix to the parcellated CIFTI file in order to map the parcels 
onto the subject’s volume space and then do my analysis of the BOLD data in 
volume space.

Thanks again for the help!

Best,
Kelli


On Oct 4, 2016, at 5:35 AM, Glasser, Matthew 
> wrote:

The lack of a field map is the larger issue, as it makes accurately registering 
the EPI to the T1w image problematic.  Some folks have made use of an “average 
field map” to attempt to improve upon this situation, but I don’t have this 
code or personal experience with this.

Lacking the T2w image need not necessarily prevent mapping fMRI data to CIFTI 
as one can take the non T2w parts of PreFreeSurfer (basically everything except 
the T2w to T1w registration and the bias correction), do things like specifying 
the T1w image as the T2w image (e.g. for the MNI registration), run FreeSurfer 
on its own, and then specify the T1w image as the T2w image for PostFreeSurfer. 
 A script that does all of this exists, but is not an “official pipeline.”

Peace,

Matt.

From: Kelli Cannon >
Date: Monday, October 3, 2016 at 5:32 PM
To: "hcp-users@humanconnectome.org" 
>
Cc: Matt Glasser >
Subject: Converting legacy data to CIFTI format

Hello,

I would like to convert a legacy dataset into CIFTI format. The legacy dataset 
lacks T2-weighted images or field maps. How does the HCP advise that 
investigators go about converting legacy data into CIFTI format? I assume this 
must be possible, as we can use FreeSurfer to convert to flat maps with such 
data...

For the structural data, the PreFreeSurfer pipeline requires both a T1w and a 
T2w image, so it can not be used on the legacy dataset. One can run the T1w 
images through FreeSurfer’s recon-all to approximate the HCP FreeSurfer 
pipeline for lower-resolution data. However, the PostFreeSurfer pipeline 
requires additional input files (e.g., T1w_acpc_dc_restore.nii.gz) that are not 
included in the FreeSurfer output.

Is there a reasonably straightforward way of converting legacy data without T2w 
images into CIFTI format? If not, does HCP plan to create a pipeline for 
preprocessing legacy data?


Best regards,

Kelli Cannon
Graduate Student
UAB Department of Vision Science
kecan...@uab.edu




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
HCP-Users@humanconnectome.org
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

Re: [HCP-Users] Pulse Ox - PULS.log

[Andrew Bock]

Hi Greg/all,

It turns out the "bad" PULS.log time stamps are off by 24 hours.
Subtracting 24 hours worth of ticks from the time stamps solves the problem
for those runs.

Andrew

On Thu, Oct 6, 2016 at 1:45 PM, Burgess, Gregory  wrote:

> We have not had enough experience with these yet. You may want to check
> the CMRR MB support page, or post an issue
> https://github.com/CMRR-C2P/MB/issues
>
> --Greg
>
> 
> Greg Burgess, Ph.D.
> Staff Scientist, Human Connectome Project
> Washington University School of Medicine
> Department of Psychiatry
> Phone: 314-362-7864
> Email: gburg...@wustl.edu
>
> > On Oct 6, 2016, at 12:42 PM, Andrew Bock  wrote:
> >
> > Hi Greg,
> >
> > Thanks for your reply, I was not aware of the 'readCMRRPhysio.m'
> function or that repo.  That code is similar to mine, and I'm glad to see
> that the ACQ_START_TICS are indeed 2.5 ms / tic.  My first concern was that
> I was misinterpreting the time stamp values.
> >
> > The issue is that the window of time stamps for some PULS.log files do
> not correspond to the window of time stamps for any of our dicom files for
> that session.  To add to the problem, this is not always these case, but
> rather only occurs for some of our scans.  I'm currently looking into
> differences between "good" and "bad" sessions. There are a few other issues
> with these files, e.g. the time found in the file names is the same for all
> PULS.log files within a session, the first ~2000 values are the same for
> all PULS.log files within a session.
> >
> > It would be great to know if other uses are experiencing these issues,
> or if this is specific to our site.
> >
> > Cheers,
> >
> > Andrew
> >
> > On Thu, Oct 6, 2016 at 11:37 AM, Burgess, Gregory 
> wrote:
> > I haven’t had a chance to look at those new files, so I’d be interested
> to hear more about your experience.
> >
> > If you’re not familiar with it, you should check out
> https://github.com/CMRR-C2P/MB/blob/master/readCMRRPhysio.m .
> >
> > One thing to note, at least with the legacy files, the time stamp in the
> DICOM corresponds to the onset of the “dummy scans”: scans used for the
> SBRef plus dropped scans for T1 equilibration. In HCP data, those dummy
> scans corresponded to 13 TRs (MB8 -> 8 TRs for SBRef, plus 5 TRs for
> dropped scans). It would be interesting to see if ACQ_START_TICS
> corresponds to some number of TRs after the time stamp in the image DICOM
> header.
> >
> > In the legacy files, there were timestamps in each modality that
> corresponded to the ms clock time of the PMU. If you’re getting different
> clock times for different modalities, they might correspond to these.
> (Although I thought the point of the ICE logging was to eliminate reliance
> on the PMU times.)
> >
> > --Greg
> >
> > 
> > Greg Burgess, Ph.D.
> > Staff Scientist, Human Connectome Project
> > Washington University School of Medicine
> > Department of Psychiatry
> > Phone: 314-362-7864
> > Email: gburg...@wustl.edu
> >
> > > On Oct 6, 2016, at 10:07 AM, Andrew Bock 
> wrote:
> > >
> > > Hi all,
> > >
> > > Has anyone had issues with the "new" format of the physio files, which
> end in PULS.log?  For some of our scans, I have found that the
> 'ACQ_START_TICS' time stamps do not align with any of the time stamps found
> in our dicom headers.
> > >
> > > Andrew
> > >
> > > --
> > > Andrew Bock, PhD
> > > Postdoctoral Researcher
> > > Department of Neurology
> > > University of Pennsylvania
> > > Philadelphia, PA 19104
> > > bock.and...@gmail.com
> > >
> > > ___
> > > 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.
> >
>
>
> 
> 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

Re: [HCP-Users] MELODIC denoising vs. released ICA-FIX datasets

[Keith Jamison]

Steve,

Have you found an obvious downside to a shorter HPF cutoff of, say, 200
seconds?  Would the HCP FIX training data still apply or would the
classifier need to be retrained?

-Keith


On Thu, Oct 6, 2016 at 12:43 PM, Xu, Junqian  wrote:

>
> > On Oct 4, 2016, at 9:03 PM, Ely, Benjamin  wrote:
> >
> > Thanks Steve, that's good to keep in mind. Our acquisition is a single
> "HCP-like" 15 minute run at MB6, 2.1mm isotropic resolution, TR=1s, AP
> phase encoding, 32-channel head coil on a 3T Skyra; hopefully that gives us
> a similar temporal profile.
>
> It’s not much about the acquisition protocol (though in the multiband era,
> MB is now related to scanner transmitter stability), but rather the scanner
> stability itself.
>
> > Sounds like I should compare our temporal stability against the HCP's -
> is there a measure you recommend?
>
> HCP Connectom Skyra scanner has quite small temporal drift and a very
> linear trend (specific to the gradient and body coil hardware
> characteristics), which a typical Skyra can’t match. To determine what
> detrending cutoff you should use for your site-specific data, you could run
> a 5-10min fBIRN phantom scan with your fMRI protocol and look at the
> scanner stability.
>
> ___
> 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] Pulse Ox - PULS.log

[Burgess, Gregory]

We have not had enough experience with these yet. You may want to check the 
CMRR MB support page, or post an issue
https://github.com/CMRR-C2P/MB/issues

--Greg


Greg Burgess, Ph.D.
Staff Scientist, Human Connectome Project
Washington University School of Medicine
Department of Psychiatry
Phone: 314-362-7864
Email: gburg...@wustl.edu

> On Oct 6, 2016, at 12:42 PM, Andrew Bock  wrote:
>
> Hi Greg,
>
> Thanks for your reply, I was not aware of the 'readCMRRPhysio.m' function or 
> that repo.  That code is similar to mine, and I'm glad to see that the 
> ACQ_START_TICS are indeed 2.5 ms / tic.  My first concern was that I was 
> misinterpreting the time stamp values.
>
> The issue is that the window of time stamps for some PULS.log files do not 
> correspond to the window of time stamps for any of our dicom files for that 
> session.  To add to the problem, this is not always these case, but rather 
> only occurs for some of our scans.  I'm currently looking into differences 
> between "good" and "bad" sessions. There are a few other issues with these 
> files, e.g. the time found in the file names is the same for all PULS.log 
> files within a session, the first ~2000 values are the same for all PULS.log 
> files within a session.
>
> It would be great to know if other uses are experiencing these issues, or if 
> this is specific to our site.
>
> Cheers,
>
> Andrew
>
> On Thu, Oct 6, 2016 at 11:37 AM, Burgess, Gregory  wrote:
> I haven’t had a chance to look at those new files, so I’d be interested to 
> hear more about your experience.
>
> If you’re not familiar with it, you should check out 
> https://github.com/CMRR-C2P/MB/blob/master/readCMRRPhysio.m .
>
> One thing to note, at least with the legacy files, the time stamp in the 
> DICOM corresponds to the onset of the “dummy scans”: scans used for the SBRef 
> plus dropped scans for T1 equilibration. In HCP data, those dummy scans 
> corresponded to 13 TRs (MB8 -> 8 TRs for SBRef, plus 5 TRs for dropped 
> scans). It would be interesting to see if ACQ_START_TICS corresponds to some 
> number of TRs after the time stamp in the image DICOM header.
>
> In the legacy files, there were timestamps in each modality that corresponded 
> to the ms clock time of the PMU. If you’re getting different clock times for 
> different modalities, they might correspond to these. (Although I thought the 
> point of the ICE logging was to eliminate reliance on the PMU times.)
>
> --Greg
>
> 
> Greg Burgess, Ph.D.
> Staff Scientist, Human Connectome Project
> Washington University School of Medicine
> Department of Psychiatry
> Phone: 314-362-7864
> Email: gburg...@wustl.edu
>
> > On Oct 6, 2016, at 10:07 AM, Andrew Bock  wrote:
> >
> > Hi all,
> >
> > Has anyone had issues with the "new" format of the physio files, which end 
> > in PULS.log?  For some of our scans, I have found that the 'ACQ_START_TICS' 
> > time stamps do not align with any of the time stamps found in our dicom 
> > headers.
> >
> > Andrew
> >
> > --
> > Andrew Bock, PhD
> > Postdoctoral Researcher
> > Department of Neurology
> > University of Pennsylvania
> > Philadelphia, PA 19104
> > bock.and...@gmail.com
> >
> > ___
> > 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.
>



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

Re: [HCP-Users] MELODIC denoising vs. released ICA-FIX datasets

[Xu, Junqian]

> On Oct 4, 2016, at 9:03 PM, Ely, Benjamin  wrote:
> 
> Thanks Steve, that's good to keep in mind. Our acquisition is a single 
> "HCP-like" 15 minute run at MB6, 2.1mm isotropic resolution, TR=1s, AP phase 
> encoding, 32-channel head coil on a 3T Skyra; hopefully that gives us a 
> similar temporal profile.

It’s not much about the acquisition protocol (though in the multiband era, MB 
is now related to scanner transmitter stability), but rather the scanner 
stability itself.

> Sounds like I should compare our temporal stability against the HCP's - is 
> there a measure you recommend?

HCP Connectom Skyra scanner has quite small temporal drift and a very linear 
trend (specific to the gradient and body coil hardware characteristics), which 
a typical Skyra can’t match. To determine what detrending cutoff you should use 
for your site-specific data, you could run a 5-10min fBIRN phantom scan with 
your fMRI protocol and look at the scanner stability.

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

Re: [HCP-Users] MELODIC denoising vs. released ICA-FIX datasets

[Xu, Junqian]

> On Oct 4, 2016, at 9:03 PM, Ely, Benjamin  wrote:
> 
> Thanks Steve, that's good to keep in mind. Our acquisition is a single 
> "HCP-like" 15 minute run at MB6, 2.1mm isotropic resolution, TR=1s, AP phase 
> encoding, 32-channel head coil on a 3T Skyra; hopefully that gives us a 
> similar temporal profile.

It’s not much about the acquisition protocol (though in the multiband era, MB 
is now related to scanner transmitter stability), but rather the scanner 
stability itself.

> Sounds like I should compare our temporal stability against the HCP's - is 
> there a measure you recommend?

HCP Connectom Skyra scanner has quite small temporal drift and a very linear 
trend (specific to the gradient and body coil hardware characteristics), which 
a typical Skyra can’t match. To determine what detrending cutoff you should use 
for your site-specific data, you could run a 5-10min fBIRN phantom scan with 
your fMRI protocol and look at the scanner stability.

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

Re: [HCP-Users] Pulse Ox - PULS.log

[Andrew Bock]

Hi Greg,

Thanks for your reply, I was not aware of the 'readCMRRPhysio.m' function
or that repo.  That code is similar to mine, and I'm glad to see that the
ACQ_START_TICS are indeed 2.5 ms / tic.  My first concern was that I was
misinterpreting the time stamp values.

The issue is that the window of time stamps for some PULS.log files do not
correspond to the window of time stamps for any of our dicom files for that
session.  To add to the problem, this is not always these case, but rather
only occurs for some of our scans.  I'm currently looking into differences
between "good" and "bad" sessions. There are a few other issues with these
files, e.g. the time found in the file names is the same for all PULS.log
files within a session, the first ~2000 values are the same for
all PULS.log files within a session.

It would be great to know if other uses are experiencing these issues, or
if this is specific to our site.

Cheers,

Andrew

On Thu, Oct 6, 2016 at 11:37 AM, Burgess, Gregory 
wrote:

> I haven’t had a chance to look at those new files, so I’d be interested to
> hear more about your experience.
>
> If you’re not familiar with it, you should check out
> https://github.com/CMRR-C2P/MB/blob/master/readCMRRPhysio.m .
>
> One thing to note, at least with the legacy files, the time stamp in the
> DICOM corresponds to the onset of the “dummy scans”: scans used for the
> SBRef plus dropped scans for T1 equilibration. In HCP data, those dummy
> scans corresponded to 13 TRs (MB8 -> 8 TRs for SBRef, plus 5 TRs for
> dropped scans). It would be interesting to see if ACQ_START_TICS
> corresponds to some number of TRs after the time stamp in the image DICOM
> header.
>
> In the legacy files, there were timestamps in each modality that
> corresponded to the ms clock time of the PMU. If you’re getting different
> clock times for different modalities, they might correspond to these.
> (Although I thought the point of the ICE logging was to eliminate reliance
> on the PMU times.)
>
> --Greg
>
> 
> Greg Burgess, Ph.D.
> Staff Scientist, Human Connectome Project
> Washington University School of Medicine
> Department of Psychiatry
> Phone: 314-362-7864
> Email: gburg...@wustl.edu
>
> > On Oct 6, 2016, at 10:07 AM, Andrew Bock  wrote:
> >
> > Hi all,
> >
> > Has anyone had issues with the "new" format of the physio files, which
> end in PULS.log?  For some of our scans, I have found that the
> 'ACQ_START_TICS' time stamps do not align with any of the time stamps found
> in our dicom headers.
> >
> > Andrew
> >
> > --
> > Andrew Bock, PhD
> > Postdoctoral Researcher
> > Department of Neurology
> > University of Pennsylvania
> > Philadelphia, PA 19104
> > bock.and...@gmail.com
> >
> > ___
> > 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

Re: [HCP-Users] Pulse Ox - PULS.log

[Burgess, Gregory]

I haven’t had a chance to look at those new files, so I’d be interested to hear 
more about your experience.

If you’re not familiar with it, you should check out 
https://github.com/CMRR-C2P/MB/blob/master/readCMRRPhysio.m .

One thing to note, at least with the legacy files, the time stamp in the DICOM 
corresponds to the onset of the “dummy scans”: scans used for the SBRef plus 
dropped scans for T1 equilibration. In HCP data, those dummy scans corresponded 
to 13 TRs (MB8 -> 8 TRs for SBRef, plus 5 TRs for dropped scans). It would be 
interesting to see if ACQ_START_TICS corresponds to some number of TRs after 
the time stamp in the image DICOM header.

In the legacy files, there were timestamps in each modality that corresponded 
to the ms clock time of the PMU. If you’re getting different clock times for 
different modalities, they might correspond to these. (Although I thought the 
point of the ICE logging was to eliminate reliance on the PMU times.)

--Greg


Greg Burgess, Ph.D.
Staff Scientist, Human Connectome Project
Washington University School of Medicine
Department of Psychiatry
Phone: 314-362-7864
Email: gburg...@wustl.edu

> On Oct 6, 2016, at 10:07 AM, Andrew Bock  wrote:
>
> Hi all,
>
> Has anyone had issues with the "new" format of the physio files, which end in 
> PULS.log?  For some of our scans, I have found that the 'ACQ_START_TICS' time 
> stamps do not align with any of the time stamps found in our dicom headers.
>
> Andrew
>
> --
> Andrew Bock, PhD
> Postdoctoral Researcher
> Department of Neurology
> University of Pennsylvania
> Philadelphia, PA 19104
> bock.and...@gmail.com
>
> ___
> 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