MRG: check for MINC using processing routines

[matthew-brett]

The processing routines assume that image have spatial axes before time etc
axes, but this may well not be true for MINC images.

Barf on MINC images > 3D for now. Later maybe we can investigate the image
axis names to work out which axes are spatial.

[coveralls]

Coverage increased (+0.01%) to 96.224% when pulling ddf6edb on matthew-brett:minc-defense into 82a261c on nipy:master.

[codecov-io]

Current coverage is 94.24% (diff: 98.30%)

Merging #464 into master will increase coverage by 0.02%

@@             master       #464   diff @@
==========================================
  Files           160        161     +1   
  Lines         21185      21243    +58   
  Methods           0          0          
  Messages          0          0          
  Branches       2265       2276    +11   
==========================================
+ Hits          19961      20020    +59   
+ Misses          803        802     -1   
  Partials        421        421          

Powered by Codecov. Last update 82a261c...3294e29

[coveralls]

Coverage increased (+0.01%) to 96.224% when pulling 4e05ae6 on matthew-brett:minc-defense into 82a261c on nipy:master.

[effigies]

So I take it you don't want a spatial_axes_first attribute/property in SpatialImage classes, since this seems to be a temporary solution? It's a little bit of a footgun, if a new format comes along that should fail this test, given that you need to remember to add a special case to the function. But if it's a short term thing, no big deal.

Might update the doc on resample_from_to to require from_img to have shape attribute, and same for smooth_img and img.

[matthew-brett]

Yes, was planning for this to be a short term thing. I take your point about the footguniness - but then I guess the choices are either to add the attribute to all images - I guess with False as the default, to prevent false positives, or list all known image types where spatial axes are first, hoping that people with new image types will know to update that list. What do you think?

[matthew-brett]

I added the documentation on required shape attribute, thanks for pointing that out.

[effigies]

Well, if you're okay with adding to the image class, this would be my first thought:

class SpatialImage:
    ...
    @property
    def spatial_axes_first(self):
        return len(self.shape) < 4

And then let known good formats say:

class Nifti1Image:
    spatial_axes_first = True
    ...

Worth considering whether this should go in the image or the header, but that's the general idea.

BUT, if you're thinking of a more long-term axis-labeling, you might not want to have to keep this API around. In which case the existing solution seems fine.

[coveralls]

Coverage increased (+0.01%) to 96.224% when pulling 214dd3b on matthew-brett:minc-defense into 82a261c on nipy:master.

[matthew-brett]

Yes, right - I was hoping to throw this away fairly soon - and avoid adding to the image API. But of course the definitive fix might not come soon.

[matthew-brett]

I made an opt-in list of image classes known to be OK. It's a bit ugly but I guess it's a little safer.

[coveralls]

Coverage increased (+0.02%) to 96.225% when pulling 3294e29 on matthew-brett:minc-defense into 82a261c on nipy:master.

[effigies]

Just to be sure, this is meant to require exact classes and exclude subclasses?

[matthew-brett]

That was what I intended, on the basis that it is possible to imagine a sub-class that doesn't have the same behavior, but maybe that is a bit obscure.

[effigies]

Nah, that's fine. Just wanted to be sure that was the intended behavior. It makes sense to me to insist on explicit inclusion in the list.

[effigies]

LGTM.

[matthew-brett]

Thanks for the review.