StyleGAN.pytorch: a legacy PyTorch reimplementation you adopt on purpose

The problem it solves is reproducibility, not state of the art

Most StyleGAN code you find today is a descendant of NVIDIA's later official releases. This repository predates those PyTorch releases. The README describes it as "a historical, unofficial PyTorch implementation of the original StyleGAN," and states that it is kept useful for historical reproducibility, code reading, and experiments that depend on this codebase. That sentence is the whole scope. If your goal is to train a competitive generator on a modern GPU, this is not the tool, and the README says so directly by pointing new projects at NVIDIA's official StyleGAN2-ADA PyTorch implementation. If your goal is to understand how progressive growing, equalized learning rate, and per-layer style injection were assembled in PyTorch before an official version existed, the repository is a readable artifact. The audience is narrow on purpose: researchers reproducing older results, engineers porting ideas out of the paper, and anyone maintaining an experiment that already depends on these exact module names and config keys.

What the generator actually does per training step

The architecture follows the paper. A latent vector Z passes through a mapping network to produce a per-layer W code, sometimes called dlatent, which is injected at each synthesis layer. The README notes that Z is not saved automatically; the normal path samples it in memory. Training uses progressive growing with fade-in, so resolution increases in stages, and the generator weights are tracked with an exponential moving average. Equalized learning rate, PixelNorm, and minibatch standard deviation layers are all listed as implemented. Style mixing regularization is present, as is the truncation trick at generation time. On the optimization side, the generator step applies global gradient-norm clipping with a maximum norm of 10.0 before the optimizer update. The README states this behavior is covered by the CPU test suite and that the discriminator step is unchanged, which is a useful detail: if you modify the discriminator, you are outside what the tests exercise. Conditional mode exists and changes the data flow: labels come from ImageFolder and are passed to both the generator and the discriminator, with loss set to 'conditional-loss'.

Getting a run started: config keys and the two commands that matter

Installation is a single command, python -m pip install -r requirements.txt, with an explicit caveat. The README says requirements.txt "intentionally reflects the historical project and does not pin versions," and that the modern compatibility baseline is still being established. Treat that as a warning, not boilerplate: you are responsible for choosing a Python, PyTorch, and CUDA combination that works. Training starts by picking a config under configs/ and editing four things: output_dir, dataset.img_dir, dataset.resolution, and the device settings. The README also warns that the shipped configs contain machine-specific paths, so a run will fail until you edit them. Then: python train.py --config configs/sample.yaml. The sample configs assume the historical progressive workflow and generally assume CUDA. Dataset layout depends on dataset.folder, which selects either a flat directory or a directory of subdirectories. Conditional training is a separate config: copy configs/sample_conditional.yaml, set dataset.img_dir, output_dir, and n_classes, where n_classes must equal the number of class subdirectories. In that mode dataset.folder is ignored because ImageFolder is always used, and the entry point checks the class count before starting. Resuming takes explicit checkpoint paths through --start_depth, --generator_file, --gen_shadow_file, --discriminator_file, --gen_optim_file, and --dis_optim_file. Note the generator shadow file: that is the EMA copy, and resuming without it loses the averaged weights.

Reusing a latent code, and why interpolation needs a noise seed

Generation is split across two scripts. generate_samples.py takes --config, --generator_file, --num_samples, and --output_dir; generate_grid.py takes --config, --generator_file, and --output_dir. Both expect a generator checkpoint produced by this repository or by the conversion workflow. The more interesting path is --input. The README is precise about this: the --input path expects a post-mapping W/dlatent code, not a Z vector, and the script validates the shape and converts to float32 before synthesis. The documented way to produce one is to call gen.g_mapping(z) under torch.no_grad() and save w[0] as a .npy with shape [num_layers, dlatent_size], which the README illustrates as [12, 512] for a 128x128 model. That shape detail matters because it is the contract between the two scripts; get the layer count wrong and the shape check rejects it. Interpolation has a separate trap. Noise is sampled independently at every synthesis layer by default, so an animation built by lerping between two W codes will flicker unless the synthesis noise is fixed. The documented fix is gen.eval() followed by gen.set_noise_seed(123), then interpolating W with torch.lerp across the frames. That is a real design consequence of the original architecture, not a bug in this port.

The unimplemented list is the honest part of the README

The repository states plainly what is missing: no multi-GPU or distributed training, no FP16 or mixed precision, no modern packaging or installation workflow, and no maintained pretrained-weight release. Pretrained weights and datasets are not included. The project status section goes further and says the repository does not currently claim a supported Python/PyTorch/CUDA compatibility matrix, CPU-only support, numerical equivalence with NVIDIA checkpoints, or reproducible training on modern environments. Each of those omissions has a practical cost. Without mixed precision, memory per sample is higher than you may be used to, which caps resolution on a given card. Without distributed training, a multi-GPU machine gives you nothing here. Without a packaging workflow, you cannot pip install this and expect imports to resolve outside the repository checkout. And without a pretrained-weight release, generation is only useful once you have trained your own checkpoint or converted one, which brings us to the conversion path. convert.py handles TensorFlow-to-PyTorch checkpoint conversion, but the README labels it a legacy path and says conversion compatibility is not currently verified. It also needs a separate TensorFlow environment compatible with the original NVIDIA checkpoint tooling, which is a second, unrelated dependency tree to maintain.

Where NVIDIA's official code differs, and why that difference is structural

The README names the alternative itself: NVIDIA's official StyleGAN2-ADA PyTorch implementation. The difference is not a version number. StyleGAN2-ADA is the architecture revised after the original paper, with adaptive discriminator augmentation built into the training loop, and it ships as an official implementation with maintained pretrained weights. This repository implements the original StyleGAN as described in the paper, with progressive growing and fade-in as the resolution strategy. Those are different training regimes, not two builds of the same thing. If you need pretrained generators to sample from, official StyleGAN2-ADA gives you that and this repository does not. If you need to study or reproduce the original progressive-growing loop, or you have an experiment written against these config keys and module names, the official code is a different architecture and a different codebase, so switching means a rewrite rather than an upgrade. The honest framing is that this repository and the official one serve different tasks, and the README's recommendation is about default choice for new work, not about equivalence.

Maintenance cost and the licence question

The README calls this "legacy research software under conservative maintenance." That phrase sets expectations: fixes arrive slowly, and there is no compatibility matrix to lean on. Your recurring cost is environment work. Because requirements.txt does not pin versions, every fresh install is a small research task, and a working environment is something you document yourself or you lose it. There are no releases, so there is no version to pin against; you track the master branch or a commit of your choosing. The licence is the other open item. The repository metadata reports NOASSERTION, which means no standard licence identifier was detected, and the supplied material contains no licence text to quote. I cannot tell you what terms apply, and I will not guess. Before you ship anything derived from this code, read the repository's licence file or contact the author directly. That is a factual gap in the material, not a formality to skip.

Who should clone this, and who should close the tab

Clone it if you are reading the original StyleGAN training loop in PyTorch, if you need the conditional mode with its ImageFolder class-count check, or if you are maintaining an experiment already written against these config keys and checkpoint arguments. The CPU test suite covering the generator gradient-clipping path gives you a small amount of confidence when you modify that step. Close the tab if you need multi-GPU, mixed precision, pretrained weights, or a verified conversion from NVIDIA checkpoints, because the README lists all four as absent or unverified. Also close it if you need a licence you can evaluate today, since the metadata reports NOASSERTION and no licence text is present in the material. The first thing to verify on a fresh clone is not the model code; it is whether train.py imports at all under your installed PyTorch, since the repository makes no claim that it will.

Editorial conclusion

Adopt this repository if you need to read or reproduce the original StyleGAN training loop in PyTorch, including progressive growing, the truncation trick, or the conditional mode, and you are willing to pin your own environment because requirements.txt deliberately does not. Do not adopt it for new image-generation work, multi-GPU training, FP16, or anything that needs verified numerical equivalence with NVIDIA checkpoints, since none of that is implemented or validated here. Before committing, verify three things on your own machine: that the config paths under configs/ match your dataset layout, that your PyTorch and CUDA versions can actually run train.py, and that the checkpoint conversion path in convert.py works for your source weights, which the README explicitly marks as unverified.

Official sources

1. huangzh13/StyleGAN.pytorch on GitHub
2. Issues
3. README