ORCA: Optimized Registration through Conditional Adversarial networks
Requirements ✅
For an optimal experience with ORCA, ensure the following:
- Operating System: ORCA runs smoothly on Windows, Mac, or Linux.
- Memory: At least 32GB of RAM ensures ORCA operates without a hitch.
- GPU: For blazing-fast predictions, an NVIDIA GPU comes highly recommended. But if you don't have one, fret not! ORCA will still get the job done, just at a more leisurely pace. For training new models, you must have a GPU!
- Python: Version 3.9.2 or above. We like to stay updated!
Installation Guide 🛠️
Navigating the installation process is a breeze. Just follow the steps below:
For Linux and MacOS 🐧🍏
- Create a Python environment, for example, 'orca-env'.
python3 -m venv orca-env
- Activate your environment.
source orca-env/bin/activate # for Linux
source orca-env/bin/activate # for MacOS
- Install ORCA.
pip install orcaz
Usage Guide 📚
Command-line tool for data folder processing 💻
orcaz -d <path_to_patient_dir> -m <mode>
Here <path_to_patient_dir> refers to the directory containing your subject's PET and CT images.
Where <mode> is the name of the mode for which we want to use the tool, from the available options.
train: Yes we can !! Orca can be used to train your own models as a generic cGAN paltform. More instructions for that to follow !
pred : This option will use orca only to generate a synthetic CT from your PET data.
coreg: Option to generate synethic CT and perform the coregistration pipeline with an output of the co-registered CT. ORCA in its full glory !!
Using ORCA requires your data to be structured according to specific conventions. ORCA supports both DICOM and NIFTI formats.
Required Directory Structure 🌳
Please structure your dataset as follows for coregistration:
EXAMPLE_Data_folder/
├── S1
│ ├── S1_CT
│ │ ├── xyz_1.dcm
│ │ ├── xyz_2.dcm
│ │ ├── .
│ │ ├── .
│ │ ├── .
│ │ └── xyz_532.dcm
│ └── S1_FDG_NAC_PT
│ ├── xyz_1.dcm
│ ├── xyz_2.dcm
│ ├── .
│ ├── .
│ ├── .
│ └── xyz_532.dcm
├── S2
│ ├── S2_CT
│ │ ├── xyz_1.dcm
│ │ ├── xyz_2.dcm
│ │ ├── .
│ │ ├── .
│ │ ├── .
│ │ └── xyz_532.dcm
│ └── S2_FDG_NAC_PT
│ ├── xyz_1.dcm
│ ├── xyz_2.dcm
│ ├── .
│ ├── .
│ ├── .
│ └── xyz_532.dcm
├── S3
│ ├── S3_CT.nii
│ └── S3_FDG_NAC_PT.nii
├── S4
│ ├── S4_CT.nii.gz
│ └── S4_FDG_NAC_PT.nii.gz
In all these cases, ORCA can be executed on the directories one by one
orcaz -d S1 -m coreg
orcaz -d S2 -m coreg
orcaz -d S3 -m coreg
Note: If the necessary naming conventions are not followed, ORCA will not process the data in the directory.
Naming Conventions for files 📝
There is none! Currently orca requires the naming of the subject subfoders inlcude particular names. The patient identifier can be placed in the start of each subfolder
For instance, S1_CT and S1_FDG_NAC_PT, or S1_CT and S1_FDG_AC_PT.
S2_CT and S2_PSMA_NAC_PT.
S3_CT and S3_FACBC_NAC_PT.
S4_CT and S4_DOTA_NAC_PT.
S5_CT and S5_AGNOSTIC_NAC_PT.
Output
After successful completion, the co-registered CT is saved as dicom data in ORCA_CT_DICOM.
Intermediate images and warp files are stored within the ORCA-VXX-YYYY-MM-DD-HH-MM-SS folder
S1
├── CT
├── NAC_FDG_PET
├── ORCA_CT_DICOM
├── ORCA-V01-2023-09-28-00-02-52
Directory Structure for sCT prediction only
The above dataset structure will also work in prediction mode, but the CT directory is not necessary:
For prediction the following is sufficient.
EXAMPLE_Data_folder/
├── S1
│ └── S1_FDG_NAC_PT
│ ├── xyz_1.dcm
│ ├── xyz_2.dcm
│ ├── .
│ ├── .
│ ├── .
│ └── xyz_532.dcm
├── S2
│ └── S2_FDG_NAC_PT
│ ├── xyz_1.dcm
│ ├── xyz_2.dcm
│ ├── .
│ ├── .
│ ├── .
│ └── xyz_532.dcm
├── S3
│ └── S3_FDG_NAC_PT.nii
In all these cases, ORCA can be executed to generate sCT on the directories one by one
orcaz -d S1 -m pred
orcaz -d S2 -m pred
orcaz -d S3 -m pred
Metadata
Release files for orcaz 0.1.5
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| orcaz-0.1.5.tar.gz | 63.0 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| orcaz-0.1.5-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 132.2 kB
Release files / orcaz-0.1.5.tar.gz
| Download URL | orcaz-0.1.5.tar.gz |
|---|---|
| Size | 63.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
47a9dc0375fd5b312f89b3f89586b8bfd57c0a230a453ba8e433d3a7a676d518
|
|
BLAKE2b-256 checksum How to use checksums |
9cb664adc1f3e48ff424e321eba14cd04cfa70ee44673af21bc59acc33a5ff69
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/5.1.1 CPython/3.9.20
|
Release files / orcaz-0.1.5-py3-none-any.whl
| Download URL | orcaz-0.1.5-py3-none-any.whl |
|---|---|
| Size | 69.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
5c2df8ff3223efd90df5a61399a2206eb1e9de944af47207a00cfd01ff41a12a
|
|
BLAKE2b-256 checksum How to use checksums |
1f3be97a6868da3eea579d50a301930932aa78ff2ce120aae82631bac12b244a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/5.1.1 CPython/3.9.20
|
Security for orcaz 0.1.5
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.