mriconvert: ordering of diffusion / non-diffusion volumes

Wed Aug 7 14:15:45 PDT 2013

Since I do not know the present ordering scheme I can not argue for or against it. I am saying that placing special meaning into acquisition time is not as useful as one expects. After all, DTI can also be acquired in packages, unlikely in practice though. Whatever the choice, users should be able to convert back, from volume number to image labels (diff direction, b-value, echo number, etc) to be able to get other attributes from DICOM.

Roman

________________________________________
From: Jolinda Smith [jolinda at uoregon.edu]
Sent: Wednesday, August 07, 2013 4:53 PM
To: MRIConvert user's list; Andreas Bartsch; Roman Fleysher
Subject: Re: mriconvert: ordering of diffusion / non-diffusion volumes

This is all true, but I'm only talking about changing how magnitude DTI data is ordered. That data should be ordered by acquisition time, and isn't currently.

Jolinda

On Wed, 07 Aug 2013 13:47:56 -0700, Roman Fleysher <roman.fleysher at einstein.yu.edu> wrote:

> Time is natural indeed! But when we have complex data, time is not enough to specify order. Example, one slice produces two images from the same acquisition: magnitude and phase. Both have the same time, and thus "acquisition time" is not sufficient to define order. Since mcverter needs (does it?, I say yes!) to be generic, it uses many image labels to define internal "time" -- the order in which the images are output. To get actual time, one needs to read DICOM field, which will be identical for the magnitude and phase and presumably the software that is processing the data knows what to do with it.
>
> Sometimes, to minimize motion artefacts, one slice is acquired in a time series before moving to the next slice. When NIFTI volumes are formed by mcverter, volume number will be the repetition number of the time series, but actual times of all slices will be different. Only software that analyzes this data and knows specifics of the project can deal with it properly.
>
> Let's say mcverter (I am not sure this is true!) uses this ordering scheme:
>
> 1. First it orders images according to image type (magnitude, phase)
> 2. Within each type, it orders by repetition number
> 3. Within type and repetition group, it orders by cardiac phase
> 4. within type-rep-phase it orders by echo number
> 5. within type--rep-phase-echo   --- by ASL label (tag, no tag)
>
> That is ASL label changes most rapidly and image type -- least. Knowing this algorithm, external sorter can convert volume order in the NIFTI file into the image labels:
>
> 0  -> asl=noTag, echo=0, cardio=0, rep=0, type=mag
> 1 -> asl=tag, echo=0, cardio=0, rep=0, type=mag
> 2 -> asl=noTag, echo=1, cardio=0, rep=0, type=mag
> 3 -> asl=tag, echo=1, cardio=0, rep=0, type=mag
> 4 -> asl=noTag, echo=0, cardio=1, rep=0, type=mag
> ......
>
>  and then search DICOM fields to get actual time of the slice and other attributes corresponding to the image labels. This algorithm is the basis how external sorters can do what is needed. (This is what I do, actually.) This algorithm is what I call "mcverter time", --- Greenwich time for us.
>
> Roman
> ________________________________________
> From: Roman Fleysher
> Sent: Wednesday, August 07, 2013 2:47 PM
> To: Jolinda Smith; MRIConvert user's list; Andreas Bartsch
> Subject: RE: mriconvert: ordering of diffusion / non-diffusion volumes
>
> Exactly! Time must be obtained from DICOM because we violate NIFTI standard by pressing non-fMRI data into an fMRI data container.
>
> The converter has to work for multi-package schemes as well. By this I mean where half of slices are acquired first with short TR, and then second half of slices. When all slices are packaged into volumes by the mcverter, what is the time of acquisition of the volume?
>
> To solve these questions. mcverter uses logical, rather than chronological tags, as I understand. These are: slice number, volume number, echo number, diffusion encoding index, image type (magnitude, phase), ASL (label/control), etc. All these combined together define mcverter "time" -- volume order which fits into NIFTI. This definition should be as stable as possible, like Greenwich time. Each external sorter will use it to get the actual time or order, as defined by the needs of the project. For DTI, images can be ordered according to b-values, for ASL -- according to control/lable, for cardiac --- cardiac phase, echo number for fitting T2, something that makes sense for the project.
>
> mcverter should know as little as possible about the forthcoming analysis project to remain universal. It simply should do its job: convert to NIFTI, and do it well, as I think it does.
>
> Thank you, Jolinda, I sure will!
>
> Roman
>
> ________________________________________
> From: Jolinda Smith [jolinda at uoregon.edu]
> Sent: Wednesday, August 07, 2013 2:18 PM
> To: MRIConvert user's list; Andreas Bartsch; Roman Fleysher
> Subject: Re: mriconvert: ordering of diffusion / non-diffusion volumes
>
> The problem with this is that the volume number * TR may not correspond to the acquisition time, depending on how the files get sorted out. Having the volumes be ordered by acquisition time seems to be a reasonable default ordering to me.
>
> Roman, if you're ever in Eugene stop by!
>
> Jolinda
>
> On Wed, 07 Aug 2013 11:12:28 -0700, Roman Fleysher <roman.fleysher at einstein.yu.edu> wrote:
>
>>
>> As of now, b-value=0 is not always first, and I use my external sorter (and bval file) to make it first because the rest of my processing needs that.
>>
>> NIFTI actually has "time" information in it. NIFTI was designed for fMRI (magnitude only) and thus one image set corresponded to a given TR cycle. Thus. NIFTI has TR in the header and time is given by:
>>
>> time = TR* volume number.
>>
>> In reality, we use NIFTI files for more than fMRI. Magnitude and phase (real and imaginary) can come from the same TR cycle. In that sense, when we convert acquisitions other than magnitude-only fMRI to NIFTI we go outside the NIFTI design. But this is OK as long as we are consistent.
>>
>> mcverter, internally, introduces a replacement for time, it is the sorting algorithm that uses DICOM tags to order the images. This is the mcverter's definition of time. I propose to define mcverter time ones and stick to it.
>>
>> The rest of the parameters, like time of acquisition of slice (important in fMRI, ASL,..) have to be obtained from DICOM and use the same mcverter time to map to volume (if needed). This task should be outside of mcverter (although mcverter group can provide such tools as separate utilities). The only thing mcverter should provide is the mapping mechanism (definition of time, that is). I do not know an easy way of doing it because I know little about DICOM format. I am willing to contribute to the solution. I wish I could meet Jolinda... and shake her hand (sorry for disclosing my feelings publicly).
>>
>>
>>
>> Roman
>>
>>
>>
>>
>> ________________________________________
>> From: Jolinda Smith [jolinda at uoregon.edu]
>> Sent: Wednesday, August 07, 2013 1:44 PM
>> To: MRIConvert user's list; Andreas Bartsch; Roman Fleysher
>> Subject: Re: mriconvert: ordering of diffusion / non-diffusion volumes
>>
>> The order would still be defined by DICOM tags, it's just a matter which tags are used to sort. Since the time information is not not (I think!) included in the NIFTI file, this is actually a good argument for changing it away from B0 first -- you can always resort it to put them first after the fact, using the bval file. Or am I wrong, and it's simple to sort by time afterwards too?
>>
>> Jolinda
>>
>> On Wed, 07 Aug 2013 10:31:56 -0700, Roman Fleysher <roman.fleysher at einstein.yu.edu> wrote:
>>
>>> Dear Jolinda,
>>> Dear All,
>>>
>>> I thought mcverter outputs images in order determined by some DICOM flags. This is important because I could use the same mechanism to extract other dicom parameters and match with the output of the mcverter. This is how I get time of volume acquisition in fMRI scan, for example.
>>>
>>> I always urge people to split the functionality of software for clarity. In this case, bval file is output by mcverter and can be used for sorting of any kind, moving b-value=0 images to front of the file or back. This image sorter is a separate routine with its own options. This is in fact what I have and do.
>>>
>>> In other words, keep the sorting mechanism as it was (defined by DICOM tags) and external sorters with their options can do the sorting job. Different projects may prefer different order: sometimes you want magnitude images first, imaginary phases second, ordered by time within each; sometimes, order by time first, then magnitude/phase. If external sorter needs additional info  it should either use text files provided by the mcverter or reach out to the original DICOM and use the same DICOM-tag mechanism as in mcverter to match the volumes.
>>>
>>> Thank you,
>>>
>>> Roman
>>>
>>> ________________________________________
>>> From: mriconvert-bounces at lists.uoregon.edu [mriconvert-bounces at lists.uoregon.edu] on behalf of Jolinda Smith [jolinda at uoregon.edu]
>>> Sent: Wednesday, August 07, 2013 12:57 PM
>>> To: mriconvert at lists.uoregon.edu; Andreas Bartsch
>>> Subject: Re: mriconvert: ordering of diffusion / non-diffusion volumes
>>>
>>> Very good point Andreas. It should be simple enough to order by time instead. Is there any benefit to having an option to put them at the front? I don't want to have unnecessary options, but I don't want to fix it for some and break it for others.
>>>
>>> Jolinda
>>>
>>> On Wed, 07 Aug 2013 07:39:06 -0700, Andreas Bartsch <bartsch at radvisory.net> wrote:
>>>
>>>> Hi,
>>>>
>>>> for diffusion EPIs, MRIConvert seems to put all the B0 images at the
>>>> beginning of the 4D nifti file.
>>>> While I can see the rationale behind it, recent preprocessing tools may be
>>>> better / easier off if you >don't< re-shuffle the ordering in time (see the
>>>> FSL thread below).
>>>> So you might consider not to put all the B0 volumes at the start in future
>>>> versions.
>>>> Cheers,
>>>> Andreas
>>>>
>>>>
>>>> Von:  Jesper Andersson <jesper.andersson at NDCN.OX.AC.UK>
>>>> Antworten an:  FSL - FMRIB's Software Library <FSL at JISCMAIL.AC.UK>
>>>> Datum:  Mittwoch, 7. August 2013 15:14
>>>> An:  <FSL at JISCMAIL.AC.UK>
>>>> Betreff:  Re: [FSL] eddy question
>>>>
>>>> Hi Andreas,
>>>>
>>>>> in our diffusion sequence multiple B0 (nodif) acquisitions are interspersed
>>>>> into the diffusion weightings.
>>>>> MRIConvert puts all the B0 images at the beginning of the 4D nifti file.
>>>>> Does this adversely affect the output of eddy, given that the *_movpar.txt
>>>>> from topup then suggests that all the motion has happened at the beginning of
>>>>> the acquisition?
>>>>
>>>> See the answer to the next question, which I hope will clarify things.
>>>>
>>>>
>>>>>
>>>>> As a related note, does the acp file used for topup have to be the same like
>>>>> the one used in eddy? If I have, lets say, 10 B0 images for blip-up and down,
>>>>> my --datain for topup needs 20 entries. For eddy, I could just use a file with
>>>>> 2 enries for --acqp if my --index is ok.
>>>>> So I assume that this won't make any difference (i.e. if --datain of topup and
>>>>> --acqp of eddy differ) but I want to make sure that it's ok.
>>>>
>>>> Eddy will anyway need to estimate movement parameters for every diffusion
>>>> weighted image. BUT given the correct information it can use the parameters
>>>> estimated from topup as starting guesses.
>>>>
>>>> To make this concrete: Imagine we have 9 scans where scan 0, 3 and 6 are b=0
>>>> and that topup found mb=0.1 between the first and second b=0 and mb=0.3
>>>> between the first and third b=0. Eddy would then start out by guessing the
>>>> following mb parameters for the six diffusion weighted images
>>>>
>>>> 0 0 0.1 0.1 0.3 0.3
>>>>
>>>> and as eddy executes it will update these such this it might end with for
>>>> example
>>>>
>>>> 0 0.05 0.11 0.27 0.33 0.45
>>>> You can use a 20 entry --datain file along with the --index file to make
>>>> sure that eddy gets the correct information. In our example case above
>>>> (where we have 3 b=0 and hence a three-line --acqp file) we would use the
>>>> --acqp file that we used for topup and then the following --index file
>>>>
>>>> 1 2 3 1 1 2 2 3 3
>>>>
>>>> Is that clear?
>>>>
>>>> Puss J
>>>>
>>>>>
>>>>> Cheers,
>>>>> Andreas
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Jolinda Smith, Ph.D.
>>> MR Physicist
>>> Interim Director of Operations
>>> Lewis Center for Neuroimaging
>>> University of Oregon
>>> Eugene, OR USA
>>> _______________________________________________
>>> mriconvert mailing list
>>> mriconvert at lists.uoregon.edu
>>> https://lists-prod.uoregon.edu/mailman/listinfo/mriconvert
>>>
>>>
>>>
>>> _______________________________________________
>>> mriconvert mailing list
>>> mriconvert at lists.uoregon.edu
>>> https://lists-prod.uoregon.edu/mailman/listinfo/mriconvert
>>>
>>
>>
>> --
>> Jolinda Smith, Ph.D.
>> MR Physicist
>> Interim Director of Operations
>> Lewis Center for Neuroimaging
>> University of Oregon
>> Eugene, OR USA
>>
>>
>>
>>
>
>
> --
> Jolinda Smith, Ph.D.
> MR Physicist
> Interim Director of Operations
> Lewis Center for Neuroimaging
> University of Oregon
> Eugene, OR USA
>
>
>
>

--
Jolinda Smith, Ph.D.
MR Physicist
Interim Director of Operations
Lewis Center for Neuroimaging
University of Oregon
Eugene, OR USA