Skip to content
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

[RTM] ENH: Subject-level summary report #647

Merged
merged 6 commits into from
Aug 8, 2017

Conversation

effigies
Copy link
Member

@effigies effigies commented Aug 5, 2017

This one's taking a bit more work than I expected. The reportlet is in place, but I'm not sure what the best way to integrate it into reports would be, since it will end up at the same level as "Anatomical" and "Functional", when all of the other reportlets are going under subheadings.

I've started fiddling with the template, but figured I'd put up what I've got at the moment.

Closes #639.

@effigies
Copy link
Member Author

effigies commented Aug 5, 2017

(Also, wanted to push it before rebasing/merging master, after Oscar's recent PRs.)

@effigies effigies changed the title WIP: Subject-level summary report [RTM] ENH: Subject-level summary report Aug 7, 2017
Copy link
Member Author

@effigies effigies left a comment

Choose a reason for hiding this comment

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

This ended up not requiring template tweaking after all, but see these comments on some design choices:

@@ -2,14 +2,20 @@
"sub_reports":
[
{
"name": "Anatomical",
"name": "Summary",
"elements":
[
{
"name": "anat/summary",
"file_pattern": "anat/.*_summary",
Copy link
Member Author

Choose a reason for hiding this comment

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

DerivativesDataSink makes some naming assumptions that don't make it automatic to add a new top-level namespace. I'm not sure that it's worth it, for a single-element entry.

Copy link
Member

Choose a reason for hiding this comment

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

I think we can live with this :).

Additionally, we want #639 to be closed as soon as possible, and modifying DerivativesDataSink (which is currently working) may break it.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah. This comment turned into #649. No plans to change it in this PR.

(bidssrc, bids_info, [(('t1w', fix_multi_T1w_source_name), 'in_file')]),
(bidssrc, summary, [('t1w', 't1w'),
('t2w', 't2w'),
('bold', 'bold')]),
Copy link
Member Author

Choose a reason for hiding this comment

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

This currently provides the name of all BOLD series, rather than just the ones in the current run.

This makes this node more stable when running different task IDs in different processes, but it does mean that if someone doesn't choose to run FMRIPREP on all of their data, then the summary may not match the rest of the outputs.

To make it show just the images in the current execution, we'd just set summary.inputs.bold = subject_data['bold']

# Date not included - update timestamp only if version or command changes


class AboutSummary(SummaryInterface):
Copy link
Member Author

Choose a reason for hiding this comment

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

This interface captures the most recent version/command line used. The timestamp is only updated if either changes. Seem reasonable @chrisfilo?

Copy link
Contributor

Choose a reason for hiding this comment

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

yup

@effigies
Copy link
Member Author

effigies commented Aug 7, 2017

@oesteban @chrisfilo Any final comments?

subjects_dir = Directory(desc='FreeSurfer subjects directory')
subject_id = traits.Str(desc='FreeSurfer subject ID')
subject_id = traits.Str(desc='Subject ID')
Copy link
Member

Choose a reason for hiding this comment

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

Use Str from nipype.interfaces.base better than traits.Str? I think we try to shadow traits.Str but it is safer to use the earlier (and it is already imported in this file...)

Copy link
Member

@oesteban oesteban left a comment

Choose a reason for hiding this comment

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

I think we are just this PR away from officially start testing...

Left one tiny comment about nipype/traits/Str. Otherwise I see this well finished up!

@effigies
Copy link
Member Author

effigies commented Aug 7, 2017

Fixed. I'll merge on passing tests.

@effigies effigies merged commit 7e9804c into nipreps:master Aug 8, 2017
@effigies effigies deleted the report/summary branch August 8, 2017 00:05
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.

None yet

3 participants