Boogu-Image-0.1: an Apache-2.0 image generation and editing family trained on a fraction of the usual data

The gap Boogu-Image-0.1 is trying to close

Closed multimodal systems such as Nano Banana Pro and GPT-Image-2, the README argues, do not win on a single model. They win because understanding, data quality and the training pipeline are unified across the whole system. Boogu-Image-0.1 is an attempt to reproduce that effect in the open, under a training compute budget the README describes as extremely limited compared with closed-source systems, and with a training data scale it puts at roughly one order of magnitude smaller than some existing open-source models. The audience is therefore narrow and technical: researchers and engineers who want an Apache-2.0 checkpoint family for text-to-image generation, fast generation, image editing and Chinese-English text rendering, and who care about how much data went into it. It is not aimed at people looking for a hosted image API. The README carries an explicit notice that the Boogu team does not currently provide any paid API, subscription or commercial service, and that anything sold under the Boogu-Image name is unofficial. It also states plainly that Boogu-Image-0.1 is a research project and not an official model release. Read those two sentences before you plan anything around it.

Four checkpoints, one repository, and the variants they map to

The family splits along two axes. Base and Turbo are text-to-image; Edit and Edit-Turbo are image-to-image. Turbo variants are four-step distilled versions of their counterparts, which is the mechanism behind the fast generation claim: fewer sampling steps rather than a smaller architecture. The repository layout reflects that split directly. inference.py and inference_turbo.py sit alongside inference_simple.py and inference_turbo_simple.py, and a second pair, inference_ti2i_simple.py and inference_ti2i_turbo_simple.py, covers image-to-image. Matching shell scripts (test_base.sh, test_turbo.sh, test_ti2i.sh, test_ti2i_turbo.sh) exist for each path, and each has an fp8 twin: test_base_fp8.sh, test_turbo_fp8.sh, test_ti2i_fp8.sh, test_ti2i_turbo_fp8.sh. That pairing is the clearest signal in the repository about intended deployment: full precision for quality checks, fp8 for fitting the model onto smaller cards. The boogu/ package holds the model code, utils/ holds helpers, and batch_data_samples/ plus input_image_examples/ provide the inputs the demo scripts expect. There is no training code in the top level, only inference. If you wanted to reproduce the data-efficiency result rather than use it, the repository does not give you that path.

Installing Boogu-Image-0.1 and running a first generation

The package metadata in pyproject.toml pins Python to >=3.10,<3.13, so a 3.12 environment is the safe upper bound. Dependencies include torch>=2.7.1,<2.12, diffusers[torch]>=0.35.2,<0.39, transformers[torch]>=4.57.3,<6, torchao>=0.15,<0.18 and cache-dit>=1.3,<2. Triton is declared only for Linux on x86_64, which tells you the primary development target without the README having to say it. A typical install from a checkout looks like this:

python -m venv .venv
source .venv/bin/activate
pip install -e .

The editable install pulls the runtime dependencies listed above. The repository also ships a requirements/ directory and a quick_start.sh, which the README points at as the shortcut path; if you use quick_start.sh you are trusting that script's own environment handling rather than the pyproject pins. Once the environment resolves, the inference scripts are the entry point. The simplest text-to-image path is inference_simple.py, and the corresponding shell script wraps it:

bash test_base.sh

Expect the script to load a Base checkpoint and write generated images to an output location defined inside the script. The README does not document the script's flags or its output directory in the text available here, so open test_base.sh before running it and check where it reads weights from and where it writes results. For the four-step path, test_turbo.sh is the equivalent. If your GPU cannot hold the full-precision weights, the fp8 variants (test_base_fp8.sh, test_turbo_fp8.sh) are the ones to try. Model weights are hosted on Hugging Face under the Boogu organization and on ModelScope; the README's badge links point to both. For image editing, the README recommends downloading the 1K Edit-Turbo checkpoint rather than the 1.5K one, because results are more stable at 1K.

Where Boogu-Image-0.1 breaks down

The most concrete limitation is stated in the release note for Boogu-Image-0.1-Edit: it supports only one reference image for now, with the team saying they will try to support more. Any editing workflow that composes two subjects, swaps a face onto a body, or otherwise needs several inputs at once is out of scope today, and no timeline is given. The second limitation is resolution behaviour. The Edit model accepts resolutions up to 2K, but the README says results are more stable at 1K, which is a quality cliff rather than a hard limit, and the kind of thing you only see by testing your own images. Third, the release history itself is a warning about checkpoint drift. On 2026-07-08 the team shipped an Edit-Turbo hotfix for severe image quality degradation and poor performance on removal and other editing tasks, and in June they patched the text-to-image Turbo model for visual artifacts across aspect ratios and background overfitting. If you pulled weights before those dates, you were running the affected revisions. Pin the revision you download, because the fix lives in a named branch (hotfix-1k-20260708, hotfix-1k5-20260708, hotfix-20260625), not in a version number. Finally, the README's own framing is a boundary: this is a research project, not an official model release, and there is no paid support tier behind it.

How the ecosystem routes around it: ComfyUI, vLLM-Omni and the NPU branch

If you already run ComfyUI, the Python scripts are probably not the integration you want. ComfyUI-Boogu exists as a separate repository, and Comfy-Org publishes Boogu-Image weights on Hugging Face, both announced on 2026-06-17. That route hands node wiring, model loading and output handling to ComfyUI, and it is the path most people searching for a Boogu workflow are actually looking for. The trade-off is that you inherit ComfyUI's release cadence rather than the repository's: when the Edit-Turbo hotfix landed on 2026-07-08, the question of when the ComfyUI side picked it up is not answered in the README. For serving rather than authoring, vLLM-Omni added Boogu-Image support on 2026-07-22, with a recipe in the vllm-project/vllm-omni repository. That is a different shape of deployment: an inference server rather than a script you run by hand, which matters if several clients need to share one GPU. And on 2026-07-23 the project announced initial NPU backend support on an npu branch, explicitly asking for feedback and bug reports. An initial backend on a side branch is not the same as a supported target, so treat it as something to evaluate rather than depend on. Three integrations in six weeks is a lot of surface area for a research release, and the maintenance cost of tracking all three falls on you.

What to check before you commit, and what the licence does not settle

The code is Apache-2.0, which is permissive and business-friendly for the inference code and the scripts in this repository. That licence does not automatically answer every question you will have. The model weights live on Hugging Face and ModelScope, and the README does not restate a weights licence, so check the model card for the checkpoint you actually download rather than assuming the repository licence covers it. The README's notice about unofficial paid services is a separate matter: it is a warning about trademark use, not a licence term. On maintenance, the last push to the default branch was on 2026-07-23, and the repository is not archived. The release notes show a dense June and July 2026: Base and Edit and Turbo on 2026-06-16, ComfyUI integrations on 2026-06-17, Edit-Turbo on 2026-06-30, the technical report on 2026-07-16, vLLM-Omni on 2026-07-22, NPU on 2026-07-23. No releases have been retrieved since. That pattern is consistent with a research push that has slowed, and you should plan upgrades around pinned checkpoint revisions rather than expecting a steady stream of fixes. The upgrade cost is mostly in the weights: the hotfixes changed checkpoints, not features, so an upgrade means re-downloading and re-validating your outputs, not rewriting integration code.

Editorial conclusion

Adopt Boogu-Image-0.1 if you want an Apache-2.0 checkpoint family you can load from Python, run through ComfyUI, or serve with vLLM-Omni, and if single-reference editing at 1K resolution matches your work. Do not adopt it if your pipeline needs multiple reference images in one edit, or if you require a vendor SLA: the README states the team provides no paid API, subscription or commercial service, and calls the release a research project rather than an official model release. Before committing, verify on your own hardware which checkpoint revision you are pulling (the Edit-Turbo hotfix revisions from 2026-07-08 are the ones the README recommends for image-to-image), confirm that your Python version falls inside the >=3.10,<3.13 range in pyproject.toml, and check whether the fp8 scripts match your GPU.

Frequently asked questions

Official sources

1. boogu-project/Boogu-Image on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README