Skip to content

ENH: Specify motion parameter source in modelgen #1379

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Mar 30, 2017

Conversation

effigies
Copy link
Member

This change adds an optional parameter_source input to the SpecifyModel classes, with the same options as available in ArtifactDetect, though only FSFAST causes any change from default behavior.

Per #706 and https://groups.google.com/d/msg/nipy-user/QzmvYr7x9B4/F30k7sET5lQJ, FSFAST motion parameters are in columns 1-6 (zero-indexed).

The default behavior is changed to choosing the first 6 columns of a parameter file, since the assumption appears to be rotation and translation parameters. Though it might be preferable to restore the old default, which is to take as many columns as are found.

@chrisgorgo
Copy link
Member

@jbpoline you might be interested in this

@chrisgorgo
Copy link
Member

@satra @effigies I wonder if we should make the new input mandatory or set some defaults

@effigies
Copy link
Member Author

I was a little hesitant to make it mandatory because that would break existing scripts. As for defaults, it would probably make sense to have SpecifySPMModel use parameter_source='SPM', but what would be a sensible default for the generic models?

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.003%) to 72.98% when pulling 5fea204 on effigies:param_source into c46b932 on nipy:master.

@effigies effigies force-pushed the param_source branch 2 times, most recently from 437e5c1 to 1466199 Compare April 7, 2016 00:38
@coveralls
Copy link

Coverage Status

Coverage increased (+0.007%) to 72.544% when pulling 7fe723f on effigies:param_source into 28c9473 on nipy:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.003%) to 72.535% when pulling 7fe723f on effigies:param_source into 28c9473 on nipy:master.

@coveralls
Copy link

coveralls commented Jul 13, 2016

Coverage Status

Coverage decreased (-0.003%) to 72.289% when pulling bbcd176 on effigies:param_source into 6d8efd7 on nipy:master.

@coveralls
Copy link

coveralls commented Aug 8, 2016

Coverage Status

Changes Unknown when pulling a0218e6 on effigies:param_source into * on nipy:master*.

@oesteban
Copy link
Contributor

oesteban commented Aug 8, 2016

Tests are not passing because of #1571. Sorry about that.

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling ffc37b7 on effigies:param_source into * on nipy:master*.

1 similar comment
@coveralls
Copy link

coveralls commented Aug 16, 2016

Coverage Status

Changes Unknown when pulling ffc37b7 on effigies:param_source into * on nipy:master*.

effigies added a commit to effigies/nipype that referenced this pull request Aug 16, 2016
@coveralls
Copy link

coveralls commented Aug 16, 2016

Coverage Status

Changes Unknown when pulling b1b6bd2 on effigies:param_source into * on nipy:master*.

1 similar comment
@coveralls
Copy link

Coverage Status

Changes Unknown when pulling b1b6bd2 on effigies:param_source into * on nipy:master*.

@effigies
Copy link
Member Author

Just going to re-up this, since it's behavior our scripts depend on. It'd be nice to keep it working without making a conversion script for our data or maintaining a lab-specific nipype patch set.

Is this something y'all are interested in including, and if so, what can I do to get it merge-ready? I don't see obvious tests to write, but let me know if you do.

@@ -187,6 +187,9 @@ class SpecifyModelInputSpec(BaseInterfaceInputSpec):
realignment_parameters = InputMultiPath(File(exists=True),
desc="Realignment parameters returned by motion correction algorithm",
copyfile=False)
parameter_source = traits.Enum("SPM", "FSL", "AFNI", "NiPy", "FSFAST",
desc="Source of motion parameters",
mandatory=False)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mandatory=False should be removed.

@satra
Copy link
Member

satra commented Aug 18, 2016

@effigies - we can include this for now (especially as it doesn't make any change to existing workflows), but this will likely be replaced with the new SpecifyEvents formulation that is being worked on in the context of BIDS and a forthcoming new project on naturalistic stimuli.

let's make sure this is merged with current master and all the tests pass.

effigies added a commit to effigies/nipype that referenced this pull request Aug 18, 2016
@coveralls
Copy link

coveralls commented Aug 18, 2016

Coverage Status

Changes Unknown when pulling a664bd4 on effigies:param_source into * on nipy:master*.

1 similar comment
@coveralls
Copy link

Coverage Status

Changes Unknown when pulling a664bd4 on effigies:param_source into * on nipy:master*.

effigies added a commit to effigies/nipype that referenced this pull request Dec 30, 2016
@effigies effigies force-pushed the param_source branch 2 times, most recently from 0e7df59 to 1867b65 Compare February 22, 2017 01:10
@effigies effigies force-pushed the param_source branch 3 times, most recently from 4d28735 to 76e545d Compare February 27, 2017 15:47
@effigies
Copy link
Member Author

Updated this with @chrisfilo's normalize_mc_params function. Also set parameter_source default to SPM, which normalize_mc_params passes through untouched.

Seem reasonable?

@effigies
Copy link
Member Author

Note that I removed Nipy because I couldn't find clear documentation on their parameters, and depending on normalize_mc_params implies that the parameters are presented in SPM-compatible format.

@effigies effigies force-pushed the param_source branch 2 times, most recently from e3cb55b to 96f9c9a Compare March 5, 2017 15:31
@effigies
Copy link
Member Author

effigies commented Mar 6, 2017

@satra This is the PR I mentioned yesterday.

@satra
Copy link
Member

satra commented Mar 8, 2017

@effigies - for this one in particular, i would like to see the Nipy SpaceTimeRealign output handled, since we use it for our analysis.

to do that in an SPM-compatible way, the following would need to happen:

nipype_params -> matrix representation -> extracting euler angles and translation parameters

@chrisgorgo
Copy link
Member

chrisgorgo commented Mar 8, 2017 via email

@effigies
Copy link
Member Author

effigies commented Mar 8, 2017

@satra, @chrisfilo see 57740e1. Does this look reasonable?

I found a number of different suggestions on how to extract Euler angles, and whether there are multiple equivalent formulations or different starting assumptions for each, I was unable to make an intelligent choice among them. Given that aff2euler is in the nipy catalogue, I sincerely hope that it assumes the format resulting from to_matrix44.

The mat2euler function from nibabel returns rotations about z, y, and x, which is, from what I can tell, reverse from the SPM ordering.

I think probably the best way to test this is to remove these lines and make sure RapidArt gives the same results (within some tolerance) for nipy motion parameters.

@chrisgorgo
Copy link
Member

You can also run realigment with 4D and say mcflirt and compare FD. They should be roughly the same.

@satra
Copy link
Member

satra commented Mar 18, 2017

@effigies - the other piece i'm not sure about now is why i wrote this if:

https://github.com/nipy/nipype/blob/master/nipype/algorithms/rapidart.py#L78

@effigies
Copy link
Member Author

effigies commented Mar 19, 2017

@satra

From AFNI's 3dvolreg manual:

       N.B.: The motion parameters are those needed to bring the sub-brick
             back into alignment with the base.  In 3drotate, it is as if
             the following options were applied to each input sub-brick:
              -rotate 'roll'I 'pitch'R 'yaw'A  -ashift 'dS'S 'dL'L 'dP'P

Assuming this applies them left-to-right on the CLI, then you have Rz -> Rx -> Ry -> T, which is what you've got. (But shouldn't the Rz be negative because they label the axis S-I, not I-S?)

Incidentally, at least in FSL, scale precedes skew. If the scaling matrix S is anisotropic, S.dot(Sh) != Sh.dot(S), and so there may be a bug here for FSL parameters.

I'm having trouble finding a detailed description of parameters and order-of-operations in the SPM manual.

matrix = to_matrix44(params)
params = np.zeros(6)
params[:3] = M[:3, 3]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this work? "M" is undefined.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Woops. Fixed.

@effigies
Copy link
Member Author

Are you guys waiting on me for anything here, by the way? I'm just not sure what the status of this one is.

@chrisgorgo
Copy link
Member

chrisgorgo commented Mar 30, 2017 via email

@satra satra merged commit 368e184 into nipy:master Mar 30, 2017
@effigies effigies deleted the param_source branch March 30, 2017 19:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants