MagicTryOn puts a diffusion Transformer behind garment preserving video try-on

Three ideas carry the method

MagicTryOn is described as a video virtual try-on framework based on a large-scale video diffusion Transformer, and the README sets out the design in three numbered claims. First, it adopts Wan2.1 diffusion Transformer as the backbone, so the generation is done by a video diffusion model rather than by an image model with a temporal trick layered on. Second, it employs full self-attention to model spatiotemporal consistency, which is the part that matters for video, because a frame-by-frame model that is consistent on its own will still drift in garment shape and position across a clip. Third, a coarse-to-fine garment preservation strategy is introduced, along with a mask-aware loss to enhance garment region fidelity, which is the part that matters for the clothes. The paper is on arXiv as MagicTryOn: Harnessing Diffusion Transformer for Garment-Preserving Video Virtual Try-on, and the project page and the Hugging Face checkpoints are linked from the README.

The release came in stages, and the training data is public

The news section in the README is a timeline worth reading, because it shows what is actually available. The paper appeared on arXiv on 2025-05-27. On 2025-06-09 the code was released, together with the inference demo and the 14B pretrained weights, and the weights were published on Hugging Face under the LuckyLiGY organisation. A 1.3B version followed on 2025-12-26, and the Turbo checkpoint was updated on 2026-04-19. The to-do list for the release is entirely ticked, covering the source code, the inference demo with the 14B weights, the customised try-on utilities, the 1.3B weights and the Turbo release. On the training side, the README is explicit that the current version is trained on public datasets including VITON-HD, DressCode and ViViD, and it asks the community to get in touch if they want to train on in-the-wild datasets, saying the authors are happy to provide the corresponding training scripts. That is a research project with a released model, not a product with a service behind it.

The environment is pinned to an older CUDA and Torch

The installation section is a conda environment plus a requirements file, and the versions in the comment are the ones to read first:

# python==3.12.9 cuda==12.3 torch==2.2
conda create -n magictryon python==3.12.9
conda activate magictryon
pip install -r requirements.txt
# or
conda env create -f environment.yaml

There is also an environment.yaml in the repository for the conda route. The one documented failure mode is worth repeating because it is common. If you hit an error while installing Flash Attention, the README says to download the installation package manually, matched to your Python version, CUDA version and Torch version, and install it with pip using the wheel name flash_attn-2.7.3+cu12torch2.2cxx11abiFALSE-cp312-cp312-linux_x86_64.whl. That single wheel name encodes the whole compatibility matrix, which tells you how tightly the environment is coupled. The requirements file is long and pinned, and it includes a detectron2 install straight from a pinned git commit, along with diffusers, transformers, accelerate, deepspeed, gradio and decord, so a working environment is a solved problem rather than an adventure, but only if you use the versions given.

Weights are fetched with the Hugging Face CLI

The checkpoint is not in the repository. The README gives a download command that uses the Hugging Face command line tool and, notably, points the endpoint at a mirror:

cd Magic-TryOn
HF_ENDPOINT=https://hf-mirror.com huggingface-cli download LuckyLiGY/MagicTryOn --local-dir ./weights/MagicTryOn_14B_V1

The local directory name carries the model size, which tells you which artifact you are getting, since the 14B checkpoint is the one the inference scripts default to. Using the mirror endpoint is a practical choice for anyone behind a network where the main host is slow, and it works because the environment variable is the standard override the tooling already understands. The 1.3B and Turbo checkpoints are separate downloads from the same organisation, and the turbo_inference/ directory in the repository is where the Turbo path lives.

Inference comes in an up and a low variant for both image and video

The demo section is organised by task, and each task has two scripts. For image try-on there is predict_image_tryon_up.py and predict_image_tryon_low.py, and for video try-on there is predict_video_tryon_up.py and predict_video_tryon_low.py. The commands are the same shape, and the GPU is chosen with the CUDA_VISIBLE_DEVICES variable:

CUDA_VISIBLE_DEVICES=0 python inference/video_tryon/predict_video_tryon_up.py

CUDA_VISIBLE_DEVICES=1 python inference/video_tryon/predict_video_tryon_low.py

The README notes that inference parameters are edited inside those scripts rather than passed on the command line, which is a research workflow rather than a library API. The Turbo path is separate again, with a config file and a checkpoint and an output folder:

CUDA_VISIBLE_DEVICES=0 python turbo_inference/bidirectional_inference_vivid.py --config_path configs/wan_bidirectional_dmd_from_scratch.yaml --checkpoint_folder ///model.pt  --output_folder result/tryon

The presence of both an up and a low variant for each task is the practical point. The high path is the quality setting the paper reports, and the low path exists because a 14B video diffusion model does not fit on a single consumer GPU, so the project gives you a degraded configuration rather than a hard failure.

Customised try-on is a five step preprocessing pipeline

Beyond the demos, the customised path assembles the inputs the model needs, and the README walks through them as five steps. A cloth caption is generated with Qwen2.5-VL-7B-Instruct, which may be used for conditioning or multimodal control, and the folder path has to be specified before running. A cloth line map is extracted with the AniLines-Anime-Lineart-Extractor, whose pre-trained models go into the inference/customize/AniLines/weights folder, run with the mode, binarize, fp16 and device arguments. An agnostic mask of the garment is generated, which the README calls essential for region control during try-on, and that checkpoint goes into inference/customize/gen_mask/ckpt. The input video has to be renamed to video.mp4 and laid out in a specific directory tree, and video2image.py converts the video into image frames. The mask step then has a detail that will bite you, since the README says to modify line 65 if you are extracting the mask for a lower_body or dresses garment, showing the two alternative calls to get_mask_location.

The licence and the hardware are the two real constraints

Two things decide whether this project is usable for you, and neither is the model. The first is the licence. The README carries a licence badge for CC BY-NC-SA 4.0, and the repository licence is one GitHub could not classify, so both need reading, but the badge points at a non-commercial licence with share-alike terms, which is a serious limit for anything commercial and for derived models. The second is the hardware. The headline checkpoint is 14B parameters, the 1.3B release exists precisely because the large one does not fit everywhere, and the video path with full spatiotemporal attention is the most expensive of the two. The repository layout matches that: magic_tryon/ and magictryon_turbo/ hold the model code, turbo_inference/ the Turbo scripts, inference/ the task scripts, config/ and configs/ the configurations, datasets/ the expected data layout, and assets/ the figures used in the README. The last push was on 2026-04-30 and there are no GitHub releases, so the repository is the distribution channel.

Editorial conclusion

Adopt MagicTryOn if you are researching video based virtual try-on and want the published model and training path rather than a product, since the code, the weights and the customised try-on utilities are all released and the paper describes the method. Do not adopt it for a commercial product without reading the licence, because the project is published under a non-commercial licence, and plan for research hardware, since the default checkpoint is 14B. Before you start, confirm the environment, because the install notes pin Python 3.12.9 with CUDA 12.3 and Torch 2.2 and a hand installed Flash Attention wheel, and check the weights mirror download path before the HuggingFace endpoint becomes an issue.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. vivoCameraResearch/Magic-TryOn on GitHub