PowerPaint: One Inpainting Model for Insertion, Removal and Outpainting

The problem PowerPaint solves, and who it is for

Most inpainting pipelines are assembled from separate models. One checkpoint handles object removal, another handles outpainting, and a third handles text-guided insertion with a ControlNet attached. Each has its own preprocessing, its own mask conventions and its own failure modes, so a product that needs all three ends up shipping three inference paths.

PowerPaint's claim is that a single model can cover text-guided object inpainting, object removal, shape-guided object insertion and outpainting. The README states this directly: "PowerPaint is a high-quality versatile image inpainting model that supports text-guided object inpainting, object removal, shape-guided object insertion, and outpainting at the same time." The intended audience is engineers and researchers building image editing features who would otherwise wire several checkpoints together, plus anyone who wants to experiment with the model through the Gradio interface without writing inference code.

The project comes from open-mmlab and is associated with the paper "A Task is Worth One Word: Learning with Task Prompts for High-Quality Versatile Image Inpainting" (arXiv 2312.03594), presented at ECCV 2024. The license is MIT. That combination matters: it is a research release with a permissive license, not a commercial product with a support contract.

How task prompts replace separate inpainting checkpoints

The mechanism the README names is learning with tailored task prompts. Rather than training one model per task, PowerPaint conditions a shared model on a prompt that identifies which task is being asked for. The task prompt is what separates an insertion request from a removal request, so the same weights serve both.

The repository layout reflects this. The top level holds app.py, a powerpaint/ package, a requirements/ directory and assets/ for the README images. The code is Python, and the README references a gradio_PowerPaint.py file alongside app.py in its release notes, so the Gradio interface is the primary entry point rather than a library-first API.

There is a second architectural layer. The April 6, 2024 news entry says the team retrained a new PowerPaint "taking inspiration from Brushnet" and that they "preserve the cross-attention layer that was deleted by BrushNet for the task prompts input." That sentence is the most informative design note in the README: the cross-attention layer is kept specifically so task prompts have a path into the model. It also explains why there are two model families rather than one. The v1 weights and the BrushNet-based v2 weights are different checkpoints with different launch arguments, and the README treats them as separate deployment options.

One more mechanism is worth flagging because it changes how you call the model. PowerPaint is compatible with ControlNet, so a control image (Canny, Depth, HED or Pose in the README's examples) can constrain what gets generated inside the mask. For object removal, the README recommends a Guidance Scale of 10 or higher and suggests raising it further if undesired objects appear in the masked area. That is a real tuning knob, not a default you can ignore.

Installing PowerPaint and running the Gradio demo

The README gives two installation routes. The first creates a Python 3.9 conda environment and installs from the requirements file. The second builds the environment from a checked-in YAML file, which is the faster path if you do not need to inspect each dependency.

# Clone the Repository
git clone git@github.com:open-mmlab/PowerPaint.git

# Create Virtual Environment with Conda
conda create --name ppt python=3.9
conda activate ppt

# Install Dependencies
pip install -r requirements/requirements.txt

If you prefer the environment file, the README offers this single command instead of the create-and-install pair above.

conda env create -f requirements/ppt.yaml
conda activate ppt

Model weights are not in the repository. They are pulled from Hugging Face with Git LFS, into a checkpoints directory you create by cloning. The README's v1 path looks like this.

# Set up Git LFS
conda install git-lfs
git lfs install

# Clone PowerPaint Model
git lfs clone https://huggingface.co/JunhaoZhuang/PowerPaint-v1/ ./checkpoints/ppt-v1

python app.py --share

After that command the Gradio interface starts and the --share flag produces a public link. For the BrushNet-based model the launch command changes, and so does the checkpoint directory. Note the underscore in the repository name PowerPaint_v2 on Hugging Face, which differs from the hyphenated ppt-v2 directory you clone into.

# Clone PowerPaint Model
git lfs clone https://huggingface.co/JunhaoZhuang/PowerPaint_v2/ ./checkpoints/ppt-v2

python app.py --share --version ppt-v2 --checkpoint_dir checkpoints/ppt-v2

A first real use is object removal, because it needs no text prompt. Upload an image, draw the mask, select the tab labeled Object removal inpainting, and the model fills the masked region from surrounding context. If unwanted objects appear in the fill, raise the Guidance Scale rather than rewriting a prompt.

Where PowerPaint is the wrong tool

The checkpoint split is the first practical problem. The README documents two model families, v1 and the BrushNet-based v2, and the May 22, 2024 news entry says v2-1 was released to rectify "some existing issues that were present during the training process of version 2." That is an admission that v2 had training problems, and it means a v2 deployment has a known-better successor. Nothing in the README states which of the three weight sets is recommended for new work, so that decision falls to you.

There is no release history in the repository metadata. The README's news section ends in May 2024, and the most recent push recorded for the repository is 2026-08-15. A push date is not a changelog, and the README does not document a rollback procedure, a versioning policy or a migration path between v1, v2 and v2-1. If your team needs to pin a checkpoint and know what changed between pins, the repository does not give you that.

Installation is a conda environment with Python 3.9 and a requirements file, plus Git LFS for the weights. There is no documented container image, no PyPI package, and no entry point other than app.py. Teams that deploy with Dockerfiles or lockfile-based package managers will be writing that packaging themselves. The README also does not document rollback, so a bad checkpoint swap has no documented reversal.

Finally, this is a diffusion inpainting model. It is the wrong tool for deterministic edits such as cloning a region, resizing a subject or compositing a known asset. If the output must be reproducible pixel for pixel, a generative model is the wrong class of tool regardless of how good the results look.

PowerPaint against IOPaint and BrushNet

The related searches around this project point at IOPaint and BrushNet, and the comparison is genuinely useful because the three sit at different layers.

IOPaint is an inpainting application. It is the thing a user opens, loads an image into, paints a mask in and exports from. PowerPaint is a model. The README's own images are hosted under the Sanster/IOPaint GitHub path, which reflects that the two projects have been used together, and "Iopaint powerpaint" is a phrase people search for. The practical difference: if you want a finished editing tool, IOPaint is the application layer; if you want weights to call from your own pipeline, PowerPaint is the model layer. Adopting PowerPaint does not give you the surrounding editor.

BrushNet is closer to a sibling. The README states that the retrained PowerPaint took inspiration from BrushNet, and that PowerPaint preserves the cross-attention layer BrushNet deleted, specifically for task prompt input. That is the concrete architectural difference: BrushNet's design removes a path that PowerPaint keeps, so PowerPaint can accept task prompts through it. If you are choosing between them, the question is whether you need one model to switch between insertion, removal, shape-guided insertion and outpainting, or whether a single-purpose inpainting model is enough. PowerPaint's whole premise is the former.

A third option is simply calling a hosted inpainting API. That trades the conda environment and Git LFS weight download for a per-request cost and a dependency on someone else's uptime. The README does not discuss cost or serving, so that trade is yours to price.

Maintenance, upgrade cost and the MIT license

The repository is not archived, and the last push was on 2026-08-15. The README's news entries stop at May 22, 2024, so the visible feature history in the documentation is older than the repository activity. The README does not document a release process, a changelog or a deprecation policy for the v1, v2 and v2-1 weights.

Upgrade cost concentrates in the weights, not the code. Moving from v1 to v2 changes the launch command and the checkpoint directory, and v2-1 exists to fix training issues in v2. Because the checkpoints are pulled with git lfs clone from Hugging Face rather than installed as a versioned package, there is no dependency resolver that will tell you a newer weight set exists. You track that yourself.

The license is MIT, and the LICENSE file sits at the repository root. MIT is permissive, which generally means fewer distribution constraints than a copyleft license would impose on the code. Two caveats are worth stating plainly without giving legal advice. First, the license covers the repository; the model weights are hosted separately on Hugging Face under the JunhaoZhuang namespace, and the README does not restate the weight license terms. Second, the README does not address training data provenance or output rights. If you plan to ship generated images commercially, read the LICENSE file and the Hugging Face model cards rather than assuming MIT settles every question.

Editorial conclusion

Adopt PowerPaint if you need one inpainting model that covers insertion, removal, shape-guided insertion and outpainting, and you are willing to manage the v1 and v2 checkpoint split yourself. Skip it if you want a maintained application with a stable installer, or if you need a hosted API with a service contract. Before committing, verify which checkpoint your task needs by cloning both ./checkpoints/ppt-v1 and ./checkpoints/ppt-v2 and running app.py --version ppt-v2 --checkpoint_dir checkpoints/ppt-v2, then confirm the MIT LICENSE file at the repository root covers your distribution plan.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. open-mmlab/PowerPaint on GitHub
4. Project website
5. README