NF: add support for V4 of PARREC format

[matthew-brett]

V4 appears to differ only in having fewer general and image information fields.

[larsoner]

Looks reasonable to me. I assume you derived the fake example from a V4 format file you have on hand?

BTW @mrjeffs plans to hopefully obtain some sample images that we could share as test cases for nibabel. If we can get them, it probably won't be for at least a couple of weeks, so it's not worth delaying release for.

[matthew-brett]

Yes, the fake example is from looking at some of the Rosetta bit project data. I think it's representative, but I didn't want to include the Rosetta bit data because of the license.

[larsoner]

Any way we could contact them to ask if we can re-license one of the files under MIT/BSD? I'm not familiar with the project, how big or flexible it is, etc.

[matthew-brett]

Discussion here - https://www.nitrc.org/forum/forum.php?thread_id=4975&forum_id=4571

One option is to use a sample of their data in a separate test images repository, so their license would only apply to the test data, not to the nibabel source repo.

[larsoner]

Didn't you set up some form of test data repo? That would presumably allow us to specify the license of subsets of the data.

[matthew-brett]

Yeah - that was the idea - experimenting with https://bitbucket.org/nipy/rosetta-samples as submodule.

[matthew-brett]

Branch here: https://github.com/matthew-brett/nibabel/tree/rosetta-tests

We differ a lot on the affines, I think we'll need your viewer to check who is right.

[larsoner]

Hmm... I guess this is a blocker for release, then, since it tests the parrec functionality? It isn't too hard to pull in my viewer changes (temporarily) to test it. Then again, if my viewer has a bug, it might make things worse :) Maybe for now running through parrec2nii followed by a fsl or freeview call would be the safest way to go.

[matthew-brett]

It looks like the affines are OK but the converted images differ so it is difficult to test in an automated way. I suggest we release with this PR, and work on validating on these images later.

[matthew-brett]

To check the affines I merged:

• https://github.com/Eric89GXL/nibabel/tree/pauls-viewer-tweaks
• MRG: add resampling and smoothing functions #255

and then used this script: https://gist.github.com/matthew-brett/667dd9e7516aaa7109cf to view the Rosetta nifti files and our converted files in real space.

[grlee77]

I don't have a V4 .PAR file on hand to test this, but I think the last 3 entries of _hdr_key_dict were added only in 'V4.2'. At least that seems to be the case looking through some old matlab-based conversion scripts I have. These entries are:

'Max. number of diffusion values': ('max_diffusion_values', int),
'Max. number of gradient orients': ('max_gradient_orient', int),
'Number of label types   <0=no ASL>': ('nr_label_types', int),

edit: actually the first two of those were added in V4.1, and the last in V4.2

[grlee77]

V4.1 added the additional diffusion gradient info over V4, while V4.2 added the ASL-related label type field.
V4.1 can also be easily supported as well. The only difference relative to V4.2 are:

1.) in _hdr_key_dict remove the following:
'Number of label types <0=no ASL>': ('nr_label_types', int),

2.) in image_def_dtd, remove the following:
('label type', int,), # (imagekey!)

The changes to support all the way back to V3 are a bit more substantial and I don't have any files that old to test with.

[matthew-brett]

Actually, we don't need to modify _hdr_key_dict because the routine using it will finish processing when it runs out of lines from the general info section in the file, but I will put in a comment. I did delete the missing general info lines in the fake v4 header though.

[matthew-brett]

Gregory - would you mind checking my fake V4.1 PAR file is what you expected?

Does this look right to you?

[coveralls]

Coverage remained the same when pulling eb9f499 on matthew-brett:parrec-v4-support into a5b67b4 on nipy:master.

[grlee77]

looks good to me