Open jyeatman opened 8 years ago
Hi @jyeatman,
I recently added an option for a more general sorting that should work correctly for your case. If you build from the current master branch, parrec.load
has a new option called strict_sort
which you should set as True
to get the expected behavior.
Similarly, if you are using the parrec2nii
command line utility, pass the option --strict-sort
(you may also need --overwrite
to make sure any previously created .nii files will be overwritten).
Perhaps it is worth making the new sorting the default in a future release, but for now I did not enable it by default to preserve backward compatibility.
Please let me know if for some reason this option does not work for your case and we will work to fix it!
also, I forgot to mention if you have more than 4 dimensions in the data, you will still get a 4D .nii volume, but there is another new option to parrec2nii
called --volume-info
that will write out a .csv
detailing what labels the volumes along the 4th dimension correspond to (e.g. image type, echo, dynamic, cardiac phase, etc...)
Thanks! I will test this out with a few data sets and I will let you know if there is any unexpected behavior.
On Saturday, April 30, 2016, Gregory R. Lee notifications@github.com wrote:
also, I forgot to mention if you have more than 4 dimensions in the data, you will still get a 4D .nii volume, but there is another new option to parrec2nii called --volume-info that will write out a .csv detailing what labels the volumes along the 4th dimension correspond to (e.g. image type, echo, dynamic, cardiac phase, etc...)
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/nipy/nibabel/issues/449#issuecomment-215987009
Jason D. Yeatman, PhD Assistant Professor, Institute for Learning & Brain Sciences (I-LABS) Department of Speech & Hearing Sciences University of Washington http://depts.washington.edu/bdelab/
@jyeatman, has the solution I described above worked out for you? If so we can close this issue. Some additional documentation to make these new features more visible was added in #451.
Yes, this worked great. Thanks Gregory
Jason D. Yeatman, PhD Assistant Professor, Institute for Learning & Brain Sciences (I-LABS) Department of Speech & Hearing Sciences University of Washington http://depts.washington.edu/bdelab/
On Wed, May 25, 2016 at 3:46 PM, Gregory R. Lee notifications@github.com wrote:
@jyeatman https://github.com/jyeatman, has the solution I described above worked out for you? If so we can close this issue. Some additional documentation to make these new features more visible was added in #451 https://github.com/nipy/nibabel/pull/451.
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/nipy/nibabel/issues/449#issuecomment-221730326
@jyeatman - does the current master branch work for you?
@libbyhuber - can you test if the master branch is working?
@Eric89GXL For par/rec files the volumes can be written in an arbitrary order, but the volume number is noted in the par file. From what I can tell nibabel is not reading the image_type_mr column to correctly organize the volumes. This means in a series of images where volume 1 is intended to be the magnitude data and volume 2 the real data, the order will be randomly switched during the nifti conversion.