-
Notifications
You must be signed in to change notification settings - Fork 13
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Dan Levitas
committed
Feb 8, 2024
1 parent
a48d72b
commit d5b2ff2
Showing
2 changed files
with
7 additions
and
91 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -33,55 +33,6 @@ Users do not need to organize their uploaded data in any specific manner, so lon | |
|
|
||
| Should users feel the need to anonymize their data before uploading, we strongly recommend that subjects (and sessions) be organized into subject (and session) folders, with explicit labeling of the subject (and session) IDs (e.g. _/MRI_data/sub-01/ses-01/DICOMS_). Failure to do so for non-anonymized data will result in additional work. | ||
|
|
||
| ### Backend Workflow | ||
|
|
||
| _(optional reading, if interested in the backend API workflow)_ | ||
|
|
||
| 1. Uploading Data | ||
|
|
||
| When a user starts uploading data, ezBIDS will create a new _session_ using `(post)/session` API. A session organize each ezBIDS upload/conversion process. For each session, a new DB/session collection is created with the mongo ID as session ID, and create a unique working directory using the sessionID on the backend server where all uploaded data is stored. When all files are successfully uploaded, client makes `(patch)/session/uploaded/:session_id` API call and set the session state to "uploaded" to let the ezBIDS handler knows that the session is ready to being preprocessing. | ||
|
|
||
| 2. Preprocessing Data | ||
|
|
||
| The backend server polls for uploaded sessions, and when it finds "uploaded" session, it will launch the preprocessing script. It sets the session state to "preprocessing". It basically unzip all zipped files, run dcm2niix and create a `list` file containing all the nifti and sidecar json. analyzer.py uses this to analyze each nifti files and at the end create `ezBIDS_core.json`. When the preprocessing completes, the session state will be set to "analyzed". The preprocessing step then load ezBIDS_core.json json and copy the content to DB/ezBIDS collection (not session collection) under `original` key. | ||
|
|
||
| 3. User interact with the session via web UI. | ||
|
|
||
| Web UI detects the preprocessing completed by polling for session state, and load the content of ezBIDS_core.json via `(get)/download/:session_id/ezBIDS_core.json` API. User then view / correct the content of ezBIDS_core.json. | ||
|
|
||
| 4. (optionally) User request for defacing | ||
|
|
||
| Before user finalizes editing the information, they are given chance to deface anatomical images. When user requests defacing, the UI will make `(post)/session/:sessino_id/deface` API call with a list of images to deface. | ||
| The backend stores this information as `deface.json` in the workdir and set the session state to "deface". The backend defacing handler looks "deface" state session and set it to "defacing" and launch `deface.sh` script. Once defacing is completed, it will set the session state to "defaced". | ||
|
|
||
| `deface.sh` create the following files under the workdir. | ||
|
|
||
| - deface.finished (list the anatomy files defaced successfully) | ||
| - deface.failed (list the anatomy files that failed defacing) | ||
|
|
||
| UI polls these files to determine which files are successfully defaced (or not). When defacing is completed, the status will be set to "defaced". User can then choose if they want to use the defaced version of anatomy file or not (each object will have a field named `defaceSelection` set to either "original" or "defaced" to indicate which image to use). | ||
|
|
||
| 5. Finalize | ||
|
|
||
| When user clicks "finalize" button, UI makes an API call for `(post)/session/:session_id/finalize` API. The UI passes the following content from the memory ($root). | ||
|
|
||
| ``` | ||
| { | ||
| datasetDescription: this.datasetDescription, | ||
| readme: this.readme, | ||
| participantsColumn: this.participantsColumn, | ||
| subjects: this.subjects, //for phenotype | ||
| objects: this.objects, | ||
| entityMappings, | ||
| } | ||
| ``` | ||
|
|
||
| The API then store this information as `finalized.json` in workdir, and copy the content to DB/ezBIDS collection under `updated` key (to contrast with `original` key). The session status will be set to "finalized". This kicks off finalized handler on the server side and the handler reset the status to "bidsing" and run `bids.sh` script to generate the bids structure according to the information stored at the object level. Once it finishes, the session status will be set to "finished". | ||
|
|
||
| 6. User Get BIDS | ||
|
|
||
| Once session status becomes "finished", user will be then allowed to download the final "bids" directory via the download API, or send to other cloud resources | ||
|
|
||
| ### Authors | ||
| - [Daniel Levitas]([email protected])* | ||
| - [Soichi Hayashi]([email protected])* | ||
|
|
@@ -107,48 +58,9 @@ brainlife.io is publicly funded and for the sustainability of the project it is | |
|
|
||
| ### Citations | ||
|
|
||
| We ask that you the following articles when publishing papers that used data, code or other resources created by the brainlife.io community. | ||
|
|
||
| 1. Levitas, Daniel, et al. "ezBIDS: Guided standardization of neuroimaging data interoperable with major data archives and platforms." arXiv preprint arXiv:2311.04912 (2023). | ||
| Please use the following citation when using ezBIDS: | ||
|
|
||
| ### This repo was bootstrapped by | ||
| Levitas, Daniel, et al. "ezBIDS: Guided standardization of neuroimaging data interoperable with major data archives and platforms." [Article](https://www.nature.com/articles/s41597-024-02959-0). | ||
|
|
||
| ``` | ||
| npm init vite@latest ui2 -- --template vue-ts | ||
| ``` | ||
|
|
||
| ### Development Environment | ||
|
|
||
| Users are free to create a local installation of ezBIDS; however, several steps are first needed: | ||
| 1. Have [Docker](https://docs.docker.com/engine/install/) and [docker-compose](https://docs.docker.com/compose/install/) installed on your machine or server. | ||
| 2. Clone this repository to your machine or server (i.e. `git clone https://github.com/brainlife/ezbids`) | ||
| 3. Execute the setup script `./dev.sh -d`. Once everything is built and running, you should be able to reach the installable ezBIDS instance at http://localhost:3000/ezbids | ||
|
|
||
| Copyright © 2022 brainlife.io at University of Texas at Austin | ||
|
|
||
| ### Code Styling/Formatting Guide | ||
|
|
||
| This repo has a few guardrails in it to ensure that only clean, standardized, and uniform code is committed into the ezBIDS repository. It is suggested that VSCode is used when contributing to ezBIDS to make use of the Prettier VSCode extension for convenience. | ||
|
|
||
| There are a few safeguards active: | ||
|
|
||
| 1. We use husky to run a git precommit hook and lint staged files using esLint | ||
| 2. We use husky to run a git precommit hook and run a prettier style check on staged files | ||
| 3. A `.vscode/settings.json` file is attached to this repository, which configures VSCode to allow formatting of files on save and on paste. | ||
|
|
||
| Make sure that you run npm install to install husky if you have not already. | ||
| *You must run npm run prepare-husky* the firs time you touch the project in order to initialize git hooks. | ||
|
|
||
| > You can run `npm run lint-staged` at any time in order to run a style check on the staged files. | ||
| > `lint-staged` makes a call to prettier and eslint to check if there are any files that do not adhere to the code standard. | ||
| > It does NOT overwrite any files. | ||
| > NOTE: If you want to skip the hook for whatever reason, you can run `git commit --no-verify ...` | ||
| VS Code Recommendations: | ||
|
|
||
| 1. Install the Prettier VS Code extension `esbenp.prettier-vscode`. This will allow you to format files based on prettier rules. | ||
| 2. Install the eslint VS Code extension `dbaeumer.vscode-eslint`. This will allow you to see lint errors as you're writing code. | ||
| 3. Install the Volar extension `vue.volar`. This provides Vue language features. | ||
|
|
||
| > Note: The recommended extensions to install for this project should appear as a notification in the bottom right corner of the VSCode screen the very first time you open the project. You can also open the command palette and go to "Show Recommended Extensions." Alternatively, you can directly navigate to `.vscode/extensions.json` and install the listed extensions. | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters