Archive for the ‘Data Processing’ Category

Upgrade Plan for DV26

August 28th, 2017

Executive summary

We will be upgrading the GE software and computational infrastructure in late September (from DV25 to DV26). The reasons and implications for your projects are explained below in detail.

To migrate the CNI sequences to this new environment, the CNI development team needs time on the scanner (we estimate about 12 hours).  As most of you know, the schedule is very full. Thus, starting September 1st and continuing for a few weeks, the CNI will have priority for any released time and all protocol development time.

If you have already booked protocol development time, we may contact you to negotiate an alternative slot. We will return to a more open policy after the transition is completed. Thank you for your cooperation.

Background

Like many GE sites, we are now planning for a significant upgrade.  This upgrade, DV26, includes new computational hardware and software (but no new MR gear, such as coils or gradients).  This upgrade includes features that will eventually be valuable for many of you.

At minimum before we make the upgrade, we will be making sure the existing CNI-modified sequences (cni_epi, cni_epi2, muxarcepi, muxarcepi2, sprt, cni_3dgrass, cni_efgre3d,  cni_ir_epi and Probe-MEGA) will all be working at DV26 as they do at DV25, together with offline reconstruction for the mux and spiral sequences using NIMS.  Other existing product sequences are not noticeably changed in this upgrade. As a result, the transition for users should in most cases be seamless.

A beneficial feature of the new system is that GE has incorporated the SMS methods that were implemented by Adam, Kangrong, Bob, Hua  and Matt Middione (GE) at the CNI.  GE refers to their implementation as Hyperband (love the marketing folks; multiband was not enough).  The DV26 product includes only a Hyperband DTI sequence, but GE has agreed to enable us to use a beta version of the Hyperband fMRI sequence.

The user-interface for Hyperband will operate as any normal sequence. Simply prescribe the whole volume you wish to acquire and the online reconstruction will perform the slice and inplane acceleration unaliasing so that undistorted images appear in the mini-viewer and scanner image database. The new computational hardware from GE will perform these reconstructions, eventually reducing the burden on our aging CNI computers.

However, there are some limitations of the new product Hyperband sequences.  GE has not yet implemented our preferred reconstruction algorithm for Hyperband acquisitions (split-slice GRAPPA). Also, there are some support features in the CNI versions of these sequences (e.g. triggering selection) that are not in the product Hyperband sequences.  The CNI team will make modifications to these Hyperband sequences to support the specific CNI features as well as augment the product reconstruction.  Some of these updates, in particular supporting online split-slice-GRAPPA reconstruction, will not be completed until after our migration to DV26.

As a result of these limitations to the Hyperband sequences, and until we have the opportunity to confirm these sequences have the same performance of our existing SMS sequences, we advise users to continue to use the CNI SMS sequences (muxarcepi, muxarcepi2). However we expect that we will be able to recommend users migrate to these Hyperband sequences sometime later this year.  We will keep you posted on our progress.

The CNI Team

Optimizing image quality: Fieldmaps and shimming

April 9th, 2017

Acquiring a high quality fieldmap of the mean magnetic field is crucial to obtaining a good measurement.  Making sure you set the parameters so that this field map is obtained as part of your protocol is something we help you with.  There are cases, including new sequences, where this can require some extra attention.

The problem: The CNI team recently helped diagnose a confusing fieldmap result.  The user was acquiring a fieldmap using a spiral acquisition, but without first performing a high-order shim (HOS) acquisition or setting Autoshim (linear-order shim).  They subsequently acquired EPI data with Autoshim.  This resulted in acceptable imaging quality but also created some problems. The disadvantage was that high-order shim corrections were not used, and the spiral fieldmap data did not incorporate the linear-order shim corrections that were imposed by the Autoshim.  As a result, the data quality were not optimized.

The solution: We recommend that a HOS be acquired as part of your protocol, especially when EPI sequences are used for subsequent data acquisition.  We describe these procedures on our Wiki entries, as well as some troubleshooting steps in a blog entry:

http://cni.stanford.edu/wiki/MR_Protocols#HOS_WB_HRBRAIN
http://cni.stanford.edu/wiki/Troubleshooting#HIGH_ORDER_SHIMS_.28HOS.29
https://cni.stanford.edu/high-order-shim-errors/

If this overhead is too time-consuming, then it is important to ensure an Autoshim is acquired, which performs a linear-order shim correction. Please note: when Autoshim acquisition is set to “Auto”, and an HOS is acquired, the system should use the HOS acquisition rather than acquire a new linear correction.

Some details: A variation in the B0 main field from the desired B0 leads to an image shift in the phase encode direction of EPI acquired images.  When the B0 field is spatially varying, this leads to varying image shifts which can result in signal pileup, voids, and image warping. There are two methods described in our Wiki for correcting these distortions.  First, you can repeat your EPI data acquisition twice, with a reversal of the phase-encoding direction between data sets as we describe in a Wiki entry: CNI Data Processing

Secondly, you can acquire an explicit fieldmap using the spiral fieldmap sequence and then process the subsequently acquired EPI data as described in another Wiki entry: Fieldmaps

Please note that if the explicit fieldmap correction approach is adopted, it is important to ensure that the subsequent EPI acquisition does not modify the shim corrections.  In this case setting Autoshim to “Off” in your protocol would be advisable.

 
Adam and Hua

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? 

thanks,

bob

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 <klarocqu@stanford.edu>
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:  https://cni.stanford.edu/nims/auth/browse#main,exp=95441,sess=96169,epoch=96210

Thanks!
karen

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

From: Bob Dougherty <bobd@stanford.edu>

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):

heegieda

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 http://cni.stanford.edu/wiki/LXC). 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.