mriconvert: basic usage, dti reordering and fsl nifit question

Sat Aug 27 09:39:32 PDT 2016

It’s always been there, and is described in the “file formats” section under
the help menu. By “top/bottom” I mean “top” and “bottom” of the slice, so
anterior-posterior for an axial slice (sorry for the confusion!). This flip
is correctly reflected in the nifti header, so it is only an issue if your
processing software is NOT fully nifti compliant (FSL’s non-compliance  is
why it was implemented in the first place, but FSL is better now). It will
not affect slice timing correction at all because it’s performed on the
slice, not the volume, and neither will applying “fslreorient2std”. You do
need to know the actual acquisition order to correctly perform slice timing
correction and it’s not always obvious – for example, mosaic images from a
Siemens system are always reordered anatomically and don’t reflect the
temporal acquisition order, and interleaved acquisitions have different
orderings depending on the number of slices. That’s why in FSL the slice
timing correction is defined independently of the data order, and for
Siemens interleaved EPI with an even number of slices you must use a custom
slice order file rather than choosing “interleaved”.

Trivia time: the whole “flip” started because computer graphics programs
typically start drawing from the upper left corner, but FSL and other
software wanted to put “zero” on the lower left corner like on a scientific
plot. At one point you could open the same analyze image in two different
programs and see it displayed two different ways. In order to put “anterior”
at the top of the screen, that meant FSL wanted “posterior” to be “zero”,
but DICOM has things the other way around. Before NIFTI, this was dealt with
by reordering the data (often into a LEFT HANDED COORDINATE SYSTEM! The
horror!) I’m sure this predates FSL, but if whoever developed the ANALYZE
format had put “zero” in the upper left when plotting images it would have
saved a lot of trouble! 

From: mriconvert-bounces at lists.uoregon.edu
[mailto:mriconvert-bounces at lists.uoregon.edu] On Behalf Of Roman Fleysher
Sent: Thursday, August 25, 2016 8:21 PM
To: MRIConvert user's list <mriconvert at lists.uoregon.edu>
Subject: Re: mriconvert: basic usage, dti reordering and fsl nifit question

Dear Jolinda, 

3.b, the top/bottom flipping, worries me a lot! Was it always there? I do
not remember reading this in earlier versions. The importance is crucial!
Some data processing needs data exactly (!) as came from scanner because it
is tightly coupled to sequence. This particularly applies to slices which
must be preserved for fMRI slice timing correction. If slices are not "FSL
standard" flipping to standard orientation will break this timing
correction. Could it happen with "-f fsl" option?

Roman

  _____  

From: mriconvert-bounces at lists.uoregon.edu
<mailto:mriconvert-bounces at lists.uoregon.edu>
[mriconvert-bounces at lists.uoregon.edu] on behalf of Jolinda Smith
[jolinda at uoregon.edu]
Sent: Tuesday, August 23, 2016 4:34 PM
To: 'MRIConvert user's list'
Subject: Re: mriconvert: basic usage, dti reordering and fsl nifit question

2. Volume reordering – volumes in MRIConvert are sorted according to a “key”
that determines which file belongs to which volume. This does not always
correspond to the temporal order of acquisition (we don’t typically use
acquisition time, because it isn’t always a meaningful part of the “key” –
think about a double echo sequence for example). This means volumes are not
always in the same order they were acquired, which I know can be a little
annoying, but the bvals/bvecs that are output will be in the same order as
the output volumes, which is the most important thing. 

3. I *think* all FSL tools now fully support 16 bit unsigned files, which
means “nifti” output type should work fine. Most FSL operations convert the
files to floating point right off the bat anyway. Reminder, the difference
between “nifti” and “fsl/nifti” are a) “fsl/nifti” will convert files to
either 16 bit signed or floating point (for images using more than 12 bits),
while “nifti” leaves the image data in its original format, and b)
“fsl/nifti” applies a top/bottom slice-wise flip to the data, in an attempt
to get the images into what fsl considers “standard orientation”. Both are
valid nifti files, and I usually run “fslreorient2std” first anyway which
seems to prevent a lot of orientation problems.

Jolinda

From: mriconvert-bounces at lists.uoregon.edu
<mailto:mriconvert-bounces at lists.uoregon.edu>
[mailto:mriconvert-bounces at lists.uoregon.edu] On Behalf Of Scheel, Michael
Sent: Tuesday, August 23, 2016 1:14 PM
To: mriconvert at lists.uoregon.edu <mailto:mriconvert at lists.uoregon.edu> 
Subject: Re: mriconvert: basic usage, dti reordering and fsl nifit question

Dear Christina, 

thanks so much for you reply. That works! 

Do you or someone else has an idea about:

2) DTI conversion - volumes reordered

3) FSL Nifti - 16bit unsigned issue

Thanks, Michael

On 23.08.2016, at 10:30, Chr. Rossmanith <cr at NEURO.MA.UNI-HEIDELBERG.DE
<mailto:cr at NEURO.MA.UNI-HEIDELBERG.DE> > wrote:

Hi Michael,

maybe an example for file name creation is helpful: 

mcverter --fnformat="My_%PN_%SN" -f fsl -n ...

creates files with names like My_Foo_001_0001.nii, My_Foo_001_0002.nii, ...
, My_Foo_002_0001.nii

i.e. format elements are a combination of some fixed strings ("My") and
variables taken from the image header prepended with '%' (%PN or %SN).

Christina Rossmanith
--
Dept. of Neurology
University Medicine Mannheim
University of Heidelberg
Germany

On 23.08.2016 09:51, Scheel, Michael wrote:

Dear all,

i am a new user of mriconvert (dcm2nii previously) and i am very happy about
the functionality (e.g. about the output of the info.txt file)

and also all the background information that I found in the programm itself
and on this mailing list  (e.g. to File formats especially the details to
fsl nifti)

I have some very basic questions that I hope the mriconvert experts can help
me with

1) Usage of --fnformat=<str>

I am unsure on how to provide format strings for custom naming of output
files

Usage: mcverter [-h] -o <str> -f <str> [-v] [-q] [-V] [-j] [-x] [-d] [-a]
[-n] [-b] [-r] [-u] [-s <str>] [-m <str>] [-F <str>] Input directory or
file(s)...
  -h, --help            Show this help message

..

 -F, --fnformat=<str>

Use this format for name of output file: 
format = {format element} ;
some text = {filesystem-legal characters} ;
format element = {some text} , {"%" "PN" | "PI" | "SD" | "ST" | "SI" | "TD"
| "SN" | "SQ" | "PR" | "RD"} , {some text} ;
or 
format = {"+" | "-" , "PatientName" | "PatientId" | "SeriesDate" |
"SeriesTime" | "StudyId" | "StudyDescription" | "SeriesNumber" |
"SequenceName" | "ProtocolName" | "SeriesDescription"

I would like to have a custom output filename but I am unsure on how I
should provide the format elements.

Could you give me some examples for actual commands

I tried the following but this will rename the file into
{"PatientName”}.hdr/img

mcverter -o conversion_fsl_3 -v --fnformat={"PatientName"} dicom

2) DTI conversion - volumes reordered

I have a DTI dataset with 1b0 volume and 12 directions with 8 repetitions.

It was originally acquired 

b0_rep1 dir1_rep1 dir2_rep1 dir3_rep1 dir4_rep1 dir5_rep1 dir6_rep1
dir7_rep1 dir8_rep1 dir9_rep1 dir10_rep1 dir11_rep1 dir12_rep1 b0_rep2
dir1_rep2  
. dir12_rep8

after conversion the volumes and also the respective bvals and bvecs entries
in my case get resorted

b0_rep1 b0_rep2 b0_rep3 b0_rep4 b0_rep5 b0_rep6 b0_rep7 b0_rep8 dir1_rep1
dir1_rep2 dir1_rep3 dir1_rep4 dir1_rep5 dir1_rep6 dir1_rep7 dir1_rep8
dir2_rep1 dir2_rep2 
.

Is this intended and if so why?

3) FSL Nifti - 16bit unsigned

I have seen that there has been a discussion on FSL supporting 16bit
unsigned. As this led to any results?

Best wishes, Michael

Michael Scheel, MD
Neurodiagnostics Laboratory
and Clinical Neuroimmunology Group
NeuroCure Clinical Research Center
Charité - Universitätsmedizin Berlin
Charitéplatz 1
10117 Berlin, Germany

_______________________________________________
mriconvert mailing list
mriconvert at lists.uoregon.edu <mailto:mriconvert at lists.uoregon.edu> 
https://lists-prod.uoregon.edu/mailman/listinfo/mriconvert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists-prod.uoregon.edu/pipermail/mriconvert/attachments/20160827/8d5a39a7/attachment-0001.html>