WIP: refactoring parrec2nii while adding tests

Refactoring parrec2nii to make it easier to save in canonical array
orientation.  First add tests for minmax and scaling options to make
sure I don't break anything.
That makes sense. At the very least it seems like there should be some
simple / easy Python methods that could be used to accomplish the same
thing as whatever parrec2nii does. Having to resort to command line
utilities to get synod access to desired functionality is a bit unpythonic.

How about a function to convert any loaded image (parrec or not) to FSL
compatible representation when working with DTI data? This would make it
all applicable to all data formats, which would be great. Or maybe a method
of the class, which for now would only be implemented for parrec image
flavors.

Eric

On Nov 29, 2014 9:34 PM, "Matthew Brett" <notifications@github.com> wrote:
>
> In bin/parrec2nii:
>
> > +    else:
> > +        # Multi scalefactor case
> > +        slope = np.array([1.])
> > +        intercept = np.array([0.])
> > +        in_data = np.array(pr_img.dataobj)
> > +        out_dtype = np.float64
> > +    # Reorient data block to LAS+ if necessary
> > +    ornt = io_orientation(np.diag([-1, 1, 1, 1]).dot(affine))
> > +    if np.all(ornt == [[0, 1],
> > +                       [1, 1],
> > +                       [2, 1]]): # already in LAS+
> > +        t_aff = np.eye(4)
> > +    else: # Not in LAS+
> > +        t_aff = inv_ornt_aff(ornt, pr_img.shape)
> > +        affine = np.dot(affine, t_aff)
> > +        in_data = apply_orientation(in_data, ornt)
>
> Hmm. There are some problems with making
nib.load('test.par').save('test.nii') the same as the output for parrec2nii.
>
> I tend to think of the individual load routines as loading the data in
the way that is most obvious for the image format. In this case, that would
be in the orientation the voxels are stored. It's tough to explain why the
format should load in LAS orientation rather than the orientation the image
is saved in, where the answer is "FSL DTI routines seem to prefer data and
bvecs in this orientation'. Would we have to do this for every image type
for which we can generate bvecs?
> If we do reorient the image, the header information and affine no longer
corresponds to the voxel orientation in the image. That could be confusing.
>
> —
> Reply to this email directly or view it on GitHub.