Archive for the ‘Data Acquisition’ Category

Planning for hardware upgrades

May 23rd, 2016

The CNI is planning for a significant equipment upgrade, which we expect to be available in about a year. This message describes our plans, which are rather uncertain. Despite this uncertainty, we thought it best to write this note to give you plenty of time to plan.

About a year ago, Siemens released a new scanner (Prisma) that has particularly strong gradients. Many NIH grants are now being written with the specification of matching the Prisma performance. Bob has worked hard at the CNI to implement the sequences and reach the quality of images that are required for these grants. The CNI team have documented the SNR of the data, and we think it is pretty good and should make us eligible for these NIH awards.

GE is responding to the competition. In particular, they have told us that they expect make available a gradient system upgrade within the next year. The stronger gradients will make our scanner competitive with (GE says better than) the Siemens Prisma.

We are funding this upgrade through a GE non-obsolescence service contract that costs about $100k per year for the next three years. The funds for this service contract are coming from user fees (which have barely gone up over the 5 years of operation). We can afford this because of the heavy usage at the CNI and our efforts to keep other costs in check. An additional $200k was needed to bring our system up to the current GE hardware platform, and this funding was provided by the Dean of Research. This upgrade was implemented last year and involved a faster host computer and reconstruction server. Some of you may have noticed this upgrade in the form of reduced delays between multiband scans. (It did not affect the data acquisition systems, so it has no impact on data quality.)

We will keep you informed as we learn about the likely delivery dates for the scanner upgrade.  We expect the new hardware to be available in about a year, and the system will likely be down for about 2 weeks during the installation process. The new gradients can be run at the current system’s lower performance level to maintain compatibility with data collected pre-upgrade. Diffusion sequences and a few others will benefit significantly from the new gradients (not such much for fMRI).

Feel free to post questions about the upgrade here. We will let you know more as we learn more.

Brian and Bob


High Order Shim Errors (UPDATE)

March 15th, 2016

Gary Glover kindly shared his fix for this issue and we have installed it on the CNI scanner. So you no longer need to worry about the HO Shim checkbox described below. Your shims will be preserved regardless of the checkbox state (although it doesn’t hurt to have it checked).


Hello CNI users,

After you do High Order Shim, and then start to a new scan, you may receive the error that reads:

A change has been made to scan locations.
High Order Shimming results will be lost.

To prevent this error, please do the following:

1. In ALL series/scans that you want to use the HO shim, check the tiny “Retain HOS Currents” box in the lower left corner of the screen.


N.B.  The checkbox is not visible when you are in the Protocol Editor. You can only check this box when you are scanning.

2. When you finish scanning, save the updated protocol.  Then you won’t need to check this box the next time you scan.


SMS, EPI and tSNR (long)

March 15th, 2016

Bob, Hua and the CNI team are working with the community to improve our methods.  The text below - excerpted from a recent exchange with the Wagner lab – illustrates the tools we use to exchange data and computational methods.  This software infrastructure is an important part of the CNI research and development mission.

The story below illustrates how one group uncovered a problem and effectively communicate it to the CNI team.  They collaborated to develop a solution that improves on previous methods, and this will benefit the entire community.

In a subsequent post, we will describe our plan of action when we discover that a method can be improved. Such advances happen (routinely we hope!).  Our general plan is to share advances by taking advantage of the database (NIMS) so that we can identify data that could be improved and alert you to apply the improvements.

Bob, Brian and Michael


An SMS Story

Bob, Kangrong, Matt, Hua, and Adam have been developing simultaneous multislice methods (SMS) for use at the CNI. Variants of this sequence for rapid, whole-brain acquisitions have been developed and distributed on Siemens, but as far as we know, the CNI implementation is the first fully working system on the GE platform.  The SMS technology allows investigators to collect whole brain fMRI measurements with a repetition time of substantially less than 1 sec even with a resolution as low as 2mm isotropic. For diffusion imaging, SMS allows the scan time to be substantially reduced, allowing more diffusion directions and/or b-value shells to be measured in a reasonable scan time.

Our user community has been very actively involved in testing the CNI implementation.  As with the development of any new technology, feedback from the field is very important.  Since the initial roll out of the method, Karen LaRocque and the team in the Wagner lab have provided particularly useful feedback.

In February, Karen sent a message to Bob noting that

I’m analyzing some multiband (3 band) data and am noticing that the variance in the timeseries seems to vary systematically between the odd-even slices. It’s more apparent for some runs than for others, but is present in multiple runs / subjects.

Karen and her colleagues also shared links to data sets and Jupyter notebooks showing her calculations.

Bob responded with some ideas (the CNI team often uses “mux” as a synonym for SMS)

Hi Karen,

One hypothesis that I have is that this is related to the calibration scan. If the subject moves (even a little along z) during the calibration scan, it can create some inhomogeneity in the signal intensity in the calibration images and that will carry over into the mux scans.

Things to check: 

1. look at the quality of the calibration scan (should be the second volume in the nifti) and see if it correlates with the appearance of the artifact

2. is the tSNR variance caused by changes in the signal or the noise? Or both?

If it is a calibration scan issue, then we can try reconstructing some of of the bad scans using calibration data from a different scan. I will also talk to the MR physics group to see if there are any ideas for a fix in the reconstruction (e.g., smoothing the calibration images). Longer-term, we do hope to develop better calibration scan methods. But that will be some time away.

Also, can you tell me how serious you think this artifact is? Are you thinking that it makes data unusable in some cases? 



Hua pitched in, working with Bob to understand the problem.  Karen pointed Hua to their most problematic data set, which could be referenced by a link to the NIMS data base

From: Karen Fossum LaRocque <>
Sent: Wednesday, February 17, 2016 2:10 PM
To: Hua Wu
Cc: Anthony David Wagner; Michael Lawrence Waskom; Valerie Ann Carr; Ian Connors Ballard; Bob Dougherty
Subject: Re: multiband data: odd-even slice variance differences

Hi Hua,

This is my most problematic scan:,exp=95441,sess=96169,epoch=96210


After some analyses and experiments, the CNI team found an improved method.

From: Bob Dougherty <>

Sent: Monday, February 22, 2016 5:30 PM
To: Karen Fossum LaRocque
Cc: Anthony David Wagner; Michael Lawrence Waskom; Valerie Ann Carr; Ian Connors Ballard; Brian A Wandell; Hua Wu
Subject: Re: multiband data: odd-even slice variance differences

Hi Karen,

We’re trying out an alternative recon algorithm (split-slice GRAPPA) and some z-axis smoothing on the calibration images. The ssGRAPPA seems to make the tSNR more uniform across slices, and the smoothing may increase tSNR a bit as well. Here’s the comparison for subject you pointed us to (exam 7840, series 26):


I’ve put both files up on your cni lx-container (cnic9) in /data/7840_26_1_weightedavg.nii.gz and /data/7840_26_1_spslgrappa.nii.gz. You should be able to scp the files with ‘scp klarocqu@cnic9:/data/7840_26_1_* .’ (for more info on the cni containers, see Note that the image orientation is messed up in these niftis because we’re using our bleeding-edge recon code, which isn’t fully debugged yet. But we hope to get that fixed this week. After more testing, we could be ready to start redoing recons in NIMS sometime next week.