MipView

MipView is a lightweight Linux-first desktop viewer for .nii / .nii.gz medical images.

It is designed as a focused research tool for:

• ITK-SNAP inspired image viewing,
• segmentation overlay inspection,
• interactive patch selection,
• patch saving,
• patch-wise volumetric computation (e.g., normalization, standardization, filtering, etc.),
• orthogonal MIP / MinIP inspection of selected, modified patches.

MipView is intentionally minimal. The goal is to build a small, reliable viewer before adding more advanced features.

---

Current Status

MipView is under active development, but the prototype is already here! Please have a try and share your feedback through GitHub issues.

Launching MipView

Installed or packaged usage:

mipview

This is the primary end-user launch command and the expected launch path for container and Neurodesk-style environments.

Local development from a repository checkout:

bash setup.sh
bash run.sh

setup.sh is a development bootstrap helper. It creates or reuses a local .venv and installs the project from pyproject.toml. It is not the canonical container installation path.

Repository compatibility wrapper:

bash run.sh

run.sh is a simple repository/dev wrapper. It tries the launch commands in this order:

• repo-local .venv/bin/mipview
• mipview on PATH
• PYTHONPATH=src python -m mipview for source checkouts

Or make it executable once:

chmod +x run.sh
./run.sh

Source-checkout fallback:

PYTHONPATH=src python -m mipview

Expected local development flow:

1. bash setup.sh
2. bash run.sh

Expected installed/container/Neurodesk flow:

1. Install the package into the environment
2. Launch with mipview

Container / pip-based dependency install:

pip install -r requirements.txt

This requirements.txt mirrors the runtime dependencies used by the app and is intended for Docker-style installs. In installed/container environments, the intended launch command remains mipview.

CI note:

• GitHub Actions validates three install paths (setup.sh, pip install -e ., and pip install -r requirements.txt) and runs a headless startup smoke test for each.

Branch And Release Workflow

• development: active feature development and testing branch.
• master: stable source branch for releases.
• Pull requests should be merged from development into master for stable releases.

Code Structure

The current codebase is organized around a small top-level mipview package:

.
├── run.sh
├── setup.sh
├── requirements.txt
├── pyproject.toml
├── scripts/
│   └── bootstrap_helpers.sh
└── src/mipview/
    ├── __init__.py
    ├── __main__.py
    ├── main.py
    ├── annotation/
    ├── io/
    │   └── nifti_io.py
    ├── patch/
    │   ├── extractor.py
    │   ├── history.py
    │   ├── saver.py
    │   └── selector.py
    ├── segmentation/
    │   ├── models.py
    │   └── validation.py
    ├── state/
    ├── tools/
    ├── ui/
    └── viewer/

In practice, the main runtime flow is:

1. python -m mipview enters through mipview/__main__.py.
2. main.py creates the Qt application and main window.
3. ui/main_window.py coordinates loading, viewer updates, patch actions, segmentation overlay state, and tool execution.
4. viewer/ modules render slices and manage tri-planar interactions.
5. state/, io/, patch/, segmentation/, and tools/ provide the supporting logic behind those UI actions.