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

"stat" entity #61

Open
Lestropie opened this issue Sep 12, 2022 · 10 comments
Open

"stat" entity #61

Lestropie opened this issue Sep 12, 2022 · 10 comments

Comments

@Lestropie
Copy link
Collaborator

Mostly been considering this in the context of common derivatives, but might nevertheless be applicable here.

Consider the case where one wants to compute the mean EPI volume across an fMRI time series. One way to encode this would be to include a dedicated entity _stat-*, which indicates that there has been some scalar summary statistic computed along one axis of the data. One could consider mandating that some metadata field appear that nominates the axis along which that statistic was computed, though theoretically in the future this could be discoverable through provenance.

Where this might be applicable in BEP016 is in the ball-and-sticks model. There are some parameters for which a set of parameters per bootstrap realisation is provided, and others for which the mean across all bootstrap realisations is provided instead / in addition. Currently these two cases are somewhat clumsily disambiguated using the _desc- entity. Explicitly indicating that a mean has been taken along the bootstrap axis might be more accurate.

@oesteban
Copy link
Collaborator

@effigies I'm pretty sure this has been discussed in the functional derivatives front. What's the situation there?

@effigies
Copy link
Contributor

We had a discussion over in poldracklab/fitlins#125. I haven't brought a proposal to the community, as I've been waiting on structural and functional derivatives to get merged first.

@effigies
Copy link
Contributor

Summary: We've used _statmap suffix, and have several labels for a stat-<label> entity: effect, variance, t, F', p, z.

We also use some other ones for model assessment, and you can find them all here: https://gin.g-node.org/markiewicz/fitlins-tests/src/master/outputs/afni_smooth/node-subject/sub-01

@oesteban
Copy link
Collaborator

Any particular reason not to use a more general suffix (e.g., _param) instead of _statmap and then particularize that this map is a statistical map by the fact that the stat-<label> is present?

Rather than suggesting changes, I'm trying to learn of potential issues I haven't anticipated when proposing #68.

BTW. I remember this stat-<label> idea was discussed back in the day when the early BEPs were kicked off. Probably the time has blurred that initial impetus on the idea.

@Lestropie
Copy link
Collaborator Author

I think the content of the proposal here may have been inferred erroneously based only on the key of the proposed entity. My description has nothing to do with statistical inference or linear models. This is purely about computing some aggregate statistic along an axis of an image.

@oesteban
Copy link
Collaborator

Then I guess this proposal should be moved into common derivatives, correct?

@Lestropie
Copy link
Collaborator Author

If there's merit to the idea, then yes. Could do with a basic sanity check though, I'm not across all of the various goings-on in the BIDS ecosystem. Also wanted to think a bit about how to encode in filename entities vs. metadata (need to know both what statistic was computed and along which axis), and how that relates to provenance.

@effigies
Copy link
Contributor

The just-completed workshop did adopt stat-<mean|std> as needed for molecular imaging maps. Thanks @Lestropie for linking this issue in. We'll need to consolidate these use cases, but I suspect we can reasonably give a generic definition for the term that allows for different use cases to use a different collection of values for clarity.

At least for the use cases I can think of the phrase "across volumes" (typically axis 4) is universally true for images and over ROI time series there's only one dimension to collapse across. For N-D images (bids-standard/bids-specification#197) with no this does seem like a potential concern, though I think we will need specific use cases to see if there are practical concerns.

@Remi-Gau
Copy link
Contributor

I may be missing something (and sorry if I missed the discussion in Copenhagen) but does that not introduce some redundancy at least with the mean and std suffixes proposed by the functional bep12.

https://bids-specification--519.org.readthedocs.build/en/519/05-derivatives/05-functional-derivatives.html#functional-derivatives-maps

I am not opposed to have both but we need to make it very clear when to use each.

@effigies
Copy link
Contributor

Yes, BEP12 will probably move those out of the suffix and into an entity. We'll need to think of what the new suffix should be. boldmap or mrmap (magnetic resonance map, to match PET's molecular imaging map mimap) spring to mind, but they may be terrible.

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

No branches or pull requests

4 participants