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

Revert to one directory per scan #37

Open
tsalo opened this issue Aug 3, 2020 · 15 comments
Open

Revert to one directory per scan #37

tsalo opened this issue Aug 3, 2020 · 15 comments
Labels
folder-structure Proposals to reorganize files in the specification. impact: high Estimated high impact change

Comments

@tsalo
Copy link
Member

tsalo commented Aug 3, 2020

The BIDS 1.x directory structure places scans within anat, func, dwi folders. Within each folder one can have multiple different scans. I propose to go back to the one scan per folder structure so as to keep a files for one scan together. This is especially useful for the derivatives folder where having multiple scans of the same type residing in one folder will quickly result in a potential mixing of derivatives. With properly named sequences on your scanner console it will then become trivial to place dicoms and subsequent niftis in new folders by stripping the folder name from the scanname.

BIDS 1.x

  • sub-control01
    • anat
      • sub-control01_T1w.nii.gz
      • sub-control01_T1w.json
      • sub-control01_T2w.nii.gz
      • sub-control01_T2w.json
    • func
      • sub-control01_task-nback_bold.nii.gz
      • sub-control01_task-nback_bold.json
      • sub-control01_task-nback_events.tsv
      • sub-control01_task-nback_physio.tsv.gz
      • sub-control01_task-nback_physio.json
      • sub-control01_task-nback_sbref.nii.gz

Proposal for BIDS 2.x

  • sub-control01
    • T1w
      • sub-control01_T1w.nii.gz
      • sub-control01_T1w.json
    • T2w
      • sub-control01_T2w.nii.gz
      • sub-control01_T2w.json
    • Nback
      • sub-control01_task-nback_bold.nii.gz
      • sub-control01_task-nback_bold.json
      • sub-control01_task-nback_events.tsv
      • sub-control01_task-nback_physio.tsv.gz
      • sub-control01_task-nback_physio.json
      • sub-control01_task-nback_sbref.nii.gz
    • MID
      • sub-control01_task-mid_bold.nii.gz
      • sub-control01_task-mid_bold.json
      • sub-control01_task-mid_events.tsv
      • sub-control01_task-mid_physio.tsv.gz
      • sub-control01_task-mid_physio.json
      • sub-control01_task-mid_sbref.nii.gz

Original authors: Unknown

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

Andrea Goldstein wrote:

This is actually a really critical point for me as well.

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

@chrisgorgo wrote:

This is actually a really critical point for me as well.

Thank you for your feedback. Could you elaborate why is this feature critical for you?

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

Andrea Goldstein wrote:

Thank you for your feedback. Could you elaborate why is this feature critical for you?

Hi Chris, Maybe I should have revised to say important rather than critical. I agree with the comment from the other document that it becomes a bit unwieldly to have all of the files associated with a specific task in the same folder as all other tasks.

As a side note, I also am working with a dataset of over 1000 previously acquired scanning sessions across 5-6 different studies on the same paradigms. I actually utilize the BIDS 2.0 proposed hierarchy already (but with different file names but exact same structure). So I may be a bit biased towards BIDS 2.0

Really appreciating the work you guys have put into this!

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

Fidel A wrote:

I agree this is the way to go. Not only derivatives can be overwritten if different scans are in the same folder bur also having many different modalities in the same directory can be rather confusing.

Plus, what do we do with modalities like DfMRI (If someone manage to make it) or future modalities we have not even heard about?

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

@chrisgorgo wrote:

Not only derivatives can be overwritten if different scans are in the same folder bur also having many different modalities in the same directory can be rather confusing.

What do you mean "derivatives can be overwritten if different scans are in the same folder"? Derivatives should never go into the same folder as the raw data (it really makes things messy!).

BTW if we switch to one folder per scan you potentially end up with even more confusing situation - all scan folders from all modalities will be under the same subject (or session) folder. Extra level of hierarchy ads a little structure.

I do agree that DfMRI would be hard to classify.

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

Fidel A wrote:

"Derivatives should never go into the same folder as the raw data"

Sure, but it would be just logical that the directory structure of the derivatives should reflect the structure of the raw data. I would not expect the structure of the derivatives to be hugely different in the subject level.

"all scan folders from all modalities will be under the same subject (or session) folder. "

I think that the way to go would be one folder per modality, not per scan.

  • All T1ws in the T1w directory.
  • All dMRIs in the dMRI directory.
  • All tfMRI in the tfMRI directory.
  • All SWI in the SWI directory.

Etc.

At the end, we would only end with 8/10 directories at most?

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

@chrisgorgo wrote:

This looks reasonable to me, although it would only help with clutter in anatomical folder (since if I understand your proposal correctly "tfMRI" folder would essentially include all of the files "func" folder includes now).

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

Fidel A wrote:

Well, resting (in my opinion) is a completely different modality from task (There are no events, analysis is different...). That would also be separated in a different directory.

But yes, if there are many different task experiments they would all be under the same directory.

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

@chrisgorgo wrote:

Overall this seems like a reasonable, but quite different proposal we are commenting on. Would you mind fleshing it out in the document? People might miss it if it's just in the comments.

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

Fidel A wrote:

Sure. I'll go for it.

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

Andrea Goldstein wrote:

I should also say I created a workaround to get it into the BIDS 1.0 format from my original structure (which maps on exactly to the proposed BIDS 2 structure) using symlinks.

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

@marcelzwiers wrote:

I should also say I created a workaround to get it into the BIDS 1.0 format from my original structure (which maps on exactly to the proposed BIDS 2 structure) using symlinks.

I also feel that the 'anat','func', etc folders are somewhat artificial and very inflexible (i.e. not future-proof). Taking something like SeriesDescription as the foldername seems like the most logical thing to do. In that way, the foldername is descriptive, the semantics ('func', 'anat') should go into the json-files. And if not, at least the "extra_data" folder should be part of BIDS

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

@edickie wrote:

I also feel that the 'anat','func', etc folders are somewhat artificial and very inflexible (i.e. not future-proof). Taking something like SeriesDescription as the foldername seems like the most logical thing to do. In that way, the foldername is descriptive, the semantics ('func', 'anat') should go into the json-files. And if not, at least the "extra_data" folder should be part of BIDS

I agree with the suggestion to potientially split tasks into separate folders under func, but it might be more useful (and scriptable) to allow certain tags to optionally effect the folder structure of derivatives (like "space")

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

@jcohenadad wrote:

i agree with this, with some exceptions (e.g., mt folder (once accepted by the bids community) should include all the necessary files to compute mt-related metrics)

@tsalo tsalo added folder-structure Proposals to reorganize files in the specification. impact: high Estimated high impact change labels Aug 3, 2020
@jbteves
Copy link

jbteves commented Aug 4, 2020

Is there an existing conversation on why modalities are split to begin with? With proper naming it is straightforward to filter only the modality you're seeking, such as
Bash:

ls *T1w*
ls | grep T1w

Python

files = os.listdir(path)
for f in files:
    if 'T1w' in f:
        print(f)

MATLAB

files = dir('*T1w*');

I would think that in some ways it could be useful to have all modalities together and offer explanations of how to filter, rather than maintain additional folders in the hierarchy which are redundant between subjects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
folder-structure Proposals to reorganize files in the specification. impact: high Estimated high impact change
Projects
None yet
Development

No branches or pull requests

2 participants