mriconvert: basic usage, dti reordering and fsl nifit question

Fri Sep 2 12:49:31 PDT 2016

Thank you, Jolinda. Then all is fine.

Roman

________________________________
From: mriconvert-bounces at lists.uoregon.edu [mriconvert-bounces at lists.uoregon.edu] on behalf of Jolinda Smith [jolinda at uoregon.edu]
Sent: Saturday, August 27, 2016 12:39 PM
To: 'MRIConvert user's list'
Subject: Re: mriconvert: basic usage, dti reordering and fsl nifit question

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/20160902/21e3564d/attachment-0001.html>