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

Is <source_entities> sufficient or should be extended to include _mod- when necessary? #625

Open
yarikoptic opened this issue Sep 28, 2020 · 2 comments

Comments

@yarikoptic
Copy link
Collaborator

ATM (v1.4.0-373-g2f0f61b) BIDS says

-   Each Derivatives filename MUST be of the form:
    `<source_entities>[_keyword-<value>]_<suffix>.<ext>`
    (where `<value>` could either be an `<index>` or a `<label>` depending on
    the keyword; see [Definitions][definitions])

-   When the derivatives chain involves outputs derived from a single raw input,
    `source_entities` MUST be the entire source filename, with the omission of
    the source suffix and extension.

so the suffix (and extension) are stripped. It is possible (even if not too common) to have files with multiple suffixes (e.g. _T1w and _PD). That creates a collision while establishing any derivative data on such sets of files (ref: #518, #519; also I think mentioned as possible problem within BEP014 to store transformations). I wonder how we could/should resolve it?

There is an odd _mod- entity used ATM only for _mod-<priorsuffix>_defacemask. Shouldn't <source_entities> description in above to at least allow (if not to RECOMMEND to remove possible ambiguity and to make it more explicit) to add _mod- entity with the original suffix?

@effigies
Copy link
Collaborator

I have no objection to extending mod- in this way.

@yarikoptic
Copy link
Collaborator Author

Flipping the table: what to do if it was a _mod-T1w_defacemask and I created a derivative file from it, what should <source_entities> become?

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

2 participants