noel-mni/noeltexturespy

Purpose and entry points

noelTexturesPy generates MRI texture maps from T1-weighted MRI, optionally paired with T2/FLAIR, using ANTsPy image-processing operations. It exposes the same processing capability through:

• Dash web application: src/noelTexturesPy/__main__.py, src/noelTexturesPy/app.py

• Headless batch CLI: src/noelTexturesPy/cli.py

• Core processing API: src/noelTexturesPy/image_processing.py

Application composition

The web runtime is a Python Dash application. app.py assembles the server and callback behavior, while layout.py defines the interactive UI and assets/ supplies browser-served styling/font resources.

• src/noelTexturesPy/app.py

• src/noelTexturesPy/layout.py

• src/noelTexturesPy/assets/css/all.css

The CLI is the non-browser boundary for HPC, scripting, and batch jobs. It accepts image paths, case identity, and output location, then invokes the shared pipeline rather than a separate implementation.

• src/noelTexturesPy/cli.py

• src/noelTexturesPy/image_processing.py

MRI processing pipeline

image_processing.py is the architecture’s central computation layer: it loads neuroimaging volumes, applies ANTsPy-based preprocessing/registration-oriented operations, and produces texture-derived image outputs. Utility and logging modules support this processing boundary.

• src/noelTexturesPy/image_processing.py

• src/noelTexturesPy/utils.py

• src/noelTexturesPy/custom_logging.py

Inputs are filename-classified as T1 and optionally T2/FLAIR. The pipeline operates on NIfTI-like MRI volumes and uses bundled MNI ICBM152 anatomical/template and tissue-prior images as spatial references.

• templates/mni_icbm152_t1_tal_nlin_sym_09a.nii.gz

• templates/mni_icbm152_gm_tal_nlin_sym_09a.nii.gz

• templates/mni_icbm152_wm_tal_nlin_sym_09a.nii.gz

Shared execution and output flow

Both interfaces converge on the processing layer: browser uploads/UI selections or CLI arguments establish a case and input paths; processing writes generated maps to the requested/result directory; the web layer presents progress and results. This shared-core design makes CLI outputs suitable for reproducible automated workflows while retaining interactive use.

Package initialization and module execution provide the installable Python command boundary.

• src/noelTexturesPy/__init__.py

• src/noelTexturesPy/__main__.py

• src/noelTexturesPy/app.py

Runtime dependencies and packaging

The primary runtime is Python with ANTsPy/ANTsPyNet-family dependencies, built through Pixi/Conda recipes. Custom recipes and an ANTsPyX patch indicate native imaging dependencies are intentionally controlled rather than fetched solely from generic Python packaging.

• pixi.toml

• recipes/antspyx/recipe.yaml

• recipes/antspyx/itk_patch.diff

Dockerfile packages the application for a published container image; docker-compose.yml supports local container orchestration. A separate web/ deployment configuration supplies Traefik reverse-proxy/TLS middleware configuration for hosted web deployments.

• Dockerfile

• docker-compose.yml

• web/traefik/rules/tls-opts.yml

Models, validation, and operational artifacts

Model acquisition is an explicit build/setup stage via scripts/download-models.py, separating heavyweight model assets from application source. Representative input volumes and expected texture-map outputs anchor regression validation of the pipeline and its interfaces.

• scripts/download-models.py

• tests/data/inputs/sub-00055/t1.nii.gz

• tests/data/ground-truth/t1_final.nii.gz