[pymvpa] NiftiDatatset bug?

[Scott Gorlin]

> IMHO, if you load a 3D image the first dimension should not be 1, since
> it is a _3_D volume. Actually, NIfTI supports 7 dimensions and the
> standard requires all unused dimensions to be set to length 1 (in the
> header's `dim` vector). So following your logic the shape of the data
> array should be (1,1,1,1,X,Y,Z). IMHO this is not desirable for the
> corresponding array shape. 
Well, I agree completely.
> However, I might be missing something and as
> I am currently heading towards a new PyNIfTI release it might be useful
> to discuss this.
>
>   
You may regret inviting me to discuss ;)

I agree with you except that the dimension index of an ND array should 
be consistent no matter how many dimensions they have.  In other words, 
shape[0] should have the same meaning for the same type of data 
regardless of how many samples (or u,v,w dims) there are.  It seems self 
evident this should be the case from the pymvpa point of view at least, 
since shape[0] is always treated as the number of samples (which is 1 
for a 3d volume).  With proper mapping handled in the NiftiDataset this 
is less of an issue, but it should also be easy to manipulate this 
manually when not using pymvpa - as I'm sure you intend pynifti for 
general usage.

Either that, or the data should be handled privately (in NiftiImage) in 
an intelligent way that can translate the correct dimensions into the 
actual dimensions in the data array.  Perhaps a function like 
getFullData(t=True, u=False, v=False, w=False) which extracts a 4d 
(T,X,Y,Z) even if there's only one sample?  Otherwise you get bugs like 
this.  For instance, I don't know ahead of time if i'll be loading a 3D, 
4D, or 4D with 1 timepoint volume (which apparently is treated 
differently, as my cludgy hack works that way) and every time i need to 
use the array I have to check for where the dimensions are.

To further question this - what would happen to the Nifti data if the 
UVW dims are not 1?  Presumably this is rare... but would they keep 
adding on to the beginning of the array?  So the number of samples now 
falls in the 2nd, 3rd, or 5th position?  Now perhaps I extract a subset 
of U,V,W 4-D volumes and squeeze away the preceding singleton dims - now 
there's no guarantee to the number of dims I'm left with.  Or are U,V,W 
mapped after Z? And what about single-slice, or other 1d and 2d images 
encoded in an nii?  It seems like wanting to squeeze out dims stands at 
ends with dim compatibility in this case.

While I'm proposing crazy ideas, it would also be simpler if the index 
just happened to be reversed - (Z,Y,X,T,W,V,U).  That way the proper 
volume is always consistent and extra dimensions can be safely dropped.  
I think in Matlab, nii's are typically loaded like this (I usually load 
using Freesurfer tools, not sure about SPM).  It would also be easy to 
concatenate samples or uvw coords without having to permute the array first.

I understand these ideas are probably over the top complicated in the 
face of backwards compatibility - so perhaps they can be my 'modest 
proposal'.  But I hope they illustrate my point - IMHO it's crucial to 
easily extract and concatenate 3D volumes from a NiftiImage without 
having to figure out what dimension 'samples' is stored in  every time 
it's necessary.

In other words - if you are heading to a new release with pynifti, yes, 
i think this issue is worth addressing there :)

sorry if this seems like a rant - just my two drops of oil...