SCI Seg3D Mailing List

Text archives Help

Re: [Seg3D] NIfTI handling

Chronological Thread 
  • From: Petar Petrov <>
  • To:
  • Subject: Re: [Seg3D] NIfTI handling
  • Date: Tue, 12 Jan 2016 14:35:53 +0100

Hi Kabi,

the story of space is fascinating. What one needs to know its all about convention. How IJK (image space) is encoded as well as how it is transformed to XYZ (world space). Regardless of what convention one adopts as long as you have 'complete' definition of space it all ends up in the correct place (you know the saying many roads lead to Rome). Having a complete definition is the key, which implies having all three origin, spacing and orientation available for your image space. At that point you must understand that both the file format as well as the library/app you use to read the files need to adhere to 'complete' space representation only! Example, NRRD till revision 4 is incomplete ( chapter 4), also ITK lib is complete while VTK lib is incomplete, both cases for the incompleteness one can blame it on lacking/ignoring orientation information. So going through an intermediate format when transforming image data can be a source of concern as well as the app/lib you use.

Back to your question: YES , it is a likely source of flipping since neurological space RAS (as nifti1) and radiological space LPS (as DICOM) have flip definition of left-right and front-back. Still, the other options I pointed before are all possible too.

Long story short, always consider the source of the image (scanner manufacturer) any indeterminate format(s) and final package for analysing the data. Also, ALWAYS do analysis in world space instead of image space.  I can give you one compelling real world example from a hospital. One makes a MRI scan of a person having a brain tumour. Radiologists analyse only the images and identify correctly the tumour in contrast with the rest of the anatomical image. No need to worry about messy world space. However, here comes the tricky part. Usually you want to intervene and schedule the patient for brain surgery. The surgeon wants to open the skull and cut the tumour out, but which hemisphere is the affected one? Then the radiologist says it is the left one, but patient left or left to the surgeon :)  Bot having different convention of space, both leading to different hemisphere in the end :)


On Sun, Jan 10, 2016 at 11:54 PM, Kabilar Gunalan <> wrote:
Hi Ayla,

That would be great if this option would be integrated into Seg3D!  FSL is a set of image analysis tools out of Oxford and FSLView is their visualization tool.  I have used FSLView quite a bit and their tool seems robust for reading NIfTI images, so I was using it as my check.  FSL might be using RAS as their basis (  So would this be causing the flipping issue?  Thanks for your help!


On Tue, Jan 5, 2016 at 11:46 PM, Ayla Khan <> wrote:
Hi Kabi,

Seg3D uses ITK's image reader to read NIfTI files, and also uses the same LPS (Left, Posterior, Superior) 3D basis. STL files are exported with the triangle surface oriented using this basis as well. I'm not familiar with FSLView, however I can add NIfTI to the set of file formats that we export through ITK in the next release.


On Dec 30, 2015, at 3:25 PM, Kabilar Gunalan wrote:

Hi Seg3D2 developers,

I am trying to use Seg3D2 to edit volumes that outline a given structure in a MRI and have found this tool to be extremely powerful and easy to use.  However, I need this data saved as a NIfTI file format (*.nii.gz).  I have tried to import the volumes as a NIfTI file format, edit them, and then export them as a NRRD file (*.nrrd).  I then use 3DSlicer to convert them to the NIfTI file format.

When viewed in 3DSlicer the NRRD file is oriented correctly and when viewing the NIfTI file (exported from 3DSlicer) in Seg3D2 it is oriented correctly.  However, when viewed with FSLView this NIfTI file is oriented incorrectly (possibly a x- and y-flip).  I have also found there to be flipping issues with Seg3D2 when exporting meshes (created from an isosurface of a volume imported as a NIfTI file) as a STL file format.  So I'm not sure if this is an issue with the way the NIfTI header is read when importing the file into Seg3D2 or how the files are written by Seg3D2.

I have attached a few files to help convey the issues I have encountered. As explained above, all of these files show up correctly in Seg3D2, 3DSlicer, and FSLView, except for file #3 that doesn't show up correctly in FSLView.
  1. thalamusLeft.nii.gz - Segmentation of left thalamus done in FSLView.
  2. thalamusLeft_exportFromSeg3d2.nrrd - Imported file #1 (thalamusLeft.nii.gz) into Seg3d2 and exported as NRRD format.
  3. thalamusLeft_exportFromSeg3d2_exportFromSlicer.nii.gz - Imported file #2 (thalamusLeft_exportFromSeg3d2.nrrd) into 3DSlicer and exported as NIfTI format.
  4. thalamusLeft_exportFromSlicer.nii.gz - Imported file #1 (thalamusLeft.nii.gz) into 3DSlicer and exported as NIfTI format.

Thanks for your help!!


All the best,
Petar Petrov

Archive powered by MHonArc 2.6.18.

Top of page