GigaTIME turns an H&E slide into a virtual mIF profile, and stops there

A missing HF_TOKEN shows up as a download error

Access to the weights is gated, and the failure mode is not a polite authentication prompt. You have to agree to the terms to reach the models, and once you have access the HuggingFace read-only token goes into the environment:

export HF_TOKEN=<huggingface read-only token>

Skip it and the error you get back talks about connections rather than credentials:

ValueError: We have no connection or we passed local_files_only, so force_download is not an accepted option.

That message sends people hunting for a network problem when the cause is an unset variable. Once the token is in place the load path is a snapshot download plus a `torch.load` pinned to the CPU, which matters if you are only inspecting the checkpoint:

from huggingface_hub import snapshot_download
import torch

repo_id = "prov-gigatime/GigaTIME"
local_dir = snapshot_download(repo_id=repo_id)

weights_path = os.path.join(local_dir, "model.pth")
state_dict = torch.load(weights_path, map_location="cpu")
model.load_state_dict(state_dict)

The checkpoint on HuggingFace is `prov-gigatime/GigaTIME`, and the same model is listed in the Azure AI Foundry catalogue.

Training is one 300-epoch line across eight GPUs

The training script is released alongside the inference code, and the documented invocation is a single command carrying every hyperparameter inline, with no config file and no defaults worth relying on:

python scripts/db_train.py --arch gigatime   --tiling_dir "gigatime_training_path"  --window_size 256       --batch_size 32     --sampling_prob 1     --name GigaTIME_model    --output_dir "Output_Directory"    --epoch 300 --input_h 512 --input_w 512 --lr 0.001 --loss BCEDiceLoss --val_sampling_prob 1 --num_workers 12 --gpu_ids 0 1 2 3 4 5 6 7 --crop True --metadata "Gigatime metadata file"

The shape of it tells you the intended scale. Eight GPU ids, 256-pixel windows, 512 by 512 input crops, a batch size of 32, a learning rate of 0.001, and 300 epochs, with `BCEDiceLoss` as the objective and a separate validation sampling probability of 1. Twelve data loader workers are assumed. Cropping is switched on explicitly with `--crop True`, and a metadata file has to be supplied by path. For anything lighter there is a notebook rather than a small command: `scripts/gigatime_training.ipynb` walks the same workflow as a one-epoch demo, which is the sensible first thing to run before committing eight GPUs to it.

GigaTIME-Flash swaps the CNN backbone for a foundation model

The newer variant is a different architecture, not a smaller copy of the same one. GigaTIME-Flash is built on top of GigaPath-Flash and is described as delivering better prediction quality, six times faster inference and eight times less GPU memory than the original GigaTIME, which the README elsewhere identifies as CNN-based. So the quality and the efficiency claims point the same direction rather than trading off, which is the usual reason a lightweight variant exists. The weights are at `prov-gigatime/GigaTIME-flash` on HuggingFace, and the entry point is `scripts/gigatime_flash_testing.ipynb`. The more interesting notebook is the whole slide one, `scripts/gigatime_flash_tcga_wsi_inference.ipynb`, which takes a full TCGA slide, tiles it, runs the model over the tiles and stitches the pieces into a slide level virtual mIF map across all channels. The prediction unit moves from a patch to an entire slide, which is the difference between a demo and something you could look at a specimen with. The model card is the place to check the details before you commit, since the three claims, quality, speed and memory, are the project's own numbers rather than independently confirmed ones. Both variants point at the same task, so the decision between them is about hardware and about how much you trust a newer checkpoint, not about capability.

The documented interface is notebooks, not an importable package

The repository is six entries at the top level: `.gitignore`, `LICENSE`, `README.md`, `data/`, `environment.yml` and `scripts/`. There is no `setup.py`, no `pyproject.toml`, no package directory and no console entry point, which is consistent with the primary language being recorded as Jupyter Notebook. Everything you are meant to run lives in `scripts/`, and the three tutorials are the actual API documentation. `scripts/gigatime_testing.ipynb` loads the model and runs predictions on the sample patches. `scripts/gigatime_flash_testing.ipynb` does the same with the Flash model. `scripts/gigatime_training.ipynb` explains the training workflow as a one-epoch demo. Plan on reading a notebook to learn the call signature rather than importing a module, and on copying a script if you need the behaviour in your own pipeline. The presence of `environment.yml` at the root and the absence of a requirements file is the same decision seen from the other side: this is built to be reproduced from a repository checkout, not installed from an index.

Check the pinned torch build before you create the environment

The environment instructions put the caveat first, which is the right order. Conda is the recommended environment manager, the codebase was tested with Python 3.11 on A100 GPUs for optimal reproducibility, and before you create anything you are told to check that the `torch` version written into `environment.yml` matches your own GPU and CUDA driver setup. After that it is two commands:

conda env create -f environment.yml

which produces an environment named `gigatime`, activated with `conda activate gigatime`. The torch check is not boilerplate. A mismatched build shows up as a runtime failure deep inside a notebook, at which point you have no way to tell whether the fault is your driver or the model. The A100 note is about what was tested rather than what is required, but it does mean the reproducibility claim and the hardware claim travel together: the same run on a different card is your problem to establish, not the project's.

Fifty paired patches are the whole evaluation set

The data you get is deliberately small and deliberately paired. Fifty H&E and mIF patch pairs from the test set are available for evaluation, distributed as a zip from a Dropbox link, and the setup is one command after the download:

unzip sample_test_data.zip -d ./data/

The instruction afterwards is that the extracted folder must end up located in `./data/`, which is worth doing carefully because a nested directory one level too deep is the sort of thing that produces a confusing empty result rather than a clear error. Fifty patches is enough to confirm that a prediction looks sane and that the pipeline runs end to end. It is not enough to estimate accuracy, and the project does not claim it is: the intended use is supporting researchers who reproduce the reported experimental results or build on top of them, and the evaluation numbers live in the Cell paper rather than in this repository. Read the pairs as a smoke test for your setup, not as a benchmark set. The paired structure is what makes them useful at all: an mIF image for the same tissue patch is the ground truth the model was trained to predict, so overlaying the two is the fastest way to see whether your pipeline is wired correctly. If the overlay looks wrong, the cause is more often a misplaced directory or a channel ordering mistake than a model problem.

The licence notice rules out clinics and deployments alike

The permitted uses are narrow and stated twice, once under intended use and again under licence notice. The data, code and model checkpoints are for two things only: future research on pathology AI models, and reproducibility of the experimental results reported in the reference paper. They are not for clinical care or for any clinical decision making purpose. The out of scope section closes the other door: any deployed use case, commercial or otherwise, is out of scope, and although the models were evaluated on a broad set of publicly available research benchmarks, those evaluations are for research use only. The licence notice itself adds that the model is not a medical device, not clinical support, not a diagnostic tool, and not a substitute for professional medical advice, diagnosis, treatment or judgement, and it puts the review burden on the user rather than on the model. The text visible here cuts off mid sentence at the end of that paragraph, so the last clause of the responsibility statement is not complete in the copy in front of me.

Four checkpoints in the family, all Apache-2.0, none released

GigaTIME sits inside a wider family and the table is worth reading, because the two halves come from different lineages. GigaPath is the whole-slide foundation model, published in Nature in 2024. GigaPath-Flash is its efficient counterpart, on arXiv in 2026. GigaTIME takes spatial proteomics prediction from H&E and is the one published in Cell in 2026, with GigaTIME-Flash as the efficient version of that same task, also on arXiv in 2026. All four are Apache-2.0, as is the repository itself, and GigaTIME is additionally listed in the Azure AI Foundry catalogue under the Microsoft research umbrella. There are no GitHub releases, so there is nothing to pin and no version history to diff; the last push to main landed on 7 August 2026. Practical consequence: if you need a reproducible identifier for a checkpoint, the HuggingFace model card is the thing to record, not a release tag.

Editorial conclusion

Reach for it when you want to see what multiplex immunofluorescence would show on a slide you already have stained for H&E, and when you are reproducing or building on published spatial proteomics results. It is not a clinical tool and not a deployable one, and the licence notice says so in terms that leave no room to argue. Before you build anything on it, confirm three things: that the `torch` build pinned in `environment.yml` matches your GPU and CUDA driver, that you have agreed to the model terms and exported `HF_TOKEN` before you hit a confusing download error, and that your data resembles the fifty paired patches the project ships for evaluation. Check which variant you actually want too, since the CNN-based GigaTIME and the Flash model built on GigaPath-Flash are separate checkpoints with different notebooks.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. prov-gigatime/GigaTIME on GitHub
4. README