GANILLA: A CycleGAN Fork That Swaps the Generator for Illustration Transfer

The gap GANILLA fills between photo translation and drawn illustration

CycleGAN translates between two image domains without paired examples. The README's own framing is that GANILLA targets a narrower case: image to illustration translation, with the paper published in Image and Vision Computing. The repository ships dataset statistics and sample grids under docs/figs, including a Miyazaki style-transfer example and an ablation figure, so the intended domain is hand-drawn or painted illustration rather than photographic style transfer. The audience is researchers and engineers who want to reproduce or extend that specific result in PyTorch, not teams looking for an inference API. The acknowledgments state the code is heavily inspired by CycleGAN, which is the single most useful fact about the project: you are adopting a fork with a modified generator, and you inherit the parent's training loop, dataset loaders and command-line surface along with it.

What resnet_fpn actually changes in the pipeline

The one flag that distinguishes a GANILLA run from a CycleGAN run is --netG resnet_fpn, which appears in both the training and test examples in the README. Everything else in the command line is unchanged: --dataroot, --name, --model cycle_gan. The generator is therefore the substitution point, and the rest of the architecture (the two-domain discriminator setup, the cycle consistency objective, the checkpoint naming) comes from the CycleGAN lineage. The README does not describe the FPN internals, so anyone who needs to know how features are combined across scales has to read the paper or the model source. That is a real documentation gap for a repository whose whole contribution is the generator. The repository also points to a separate style-content-cnn repo containing train and test procedures plus pretrained weights for both the style and content CNNs, which tells you the paper's evaluation depends on a second codebase you have to fetch independently.

Commands, flags and where checkpoints have to sit

Installation is a clone plus pip install -r requirements.txt, with ./scripts/conda_deps.sh offered as the Conda path. Datasets come from bash ./datasets/download_cyclegan_dataset.sh followed by a dataset name such as maps or monet2photo. Training is python train.py --dataroot ./datasets/maps --name maps_cyclegan --model cycle_gan --netG resnet_fpn, and testing mirrors it with test.py and the same three flags. For a pretrained model the README is explicit about placement: the file goes at ./checkpoints/{name}_pretrained/100_net_G.pth, and the released weights live on Hugging Face under samethi/ganilla. Inference against those weights uses python test.py --dataroot datasets/monet2photo/testB --name {name}_pretrained --model test. The distinction between --model test and --model cycle_gan matters operationally: the README notes that cycle_gan loads and generates in both directions, which is unnecessary when you only want one side. For unpaired inputs there is --dataset_mode single, and the README adds that you may want to specify --netG to match the architecture of whatever model you trained. Visdom is the training dashboard, started with python -m visdom.server and read at localhost:8097, with intermediate HTML at ./checkpoints/maps_cyclegan/web/index.html.

The dependency range is the first thing that will break

The prerequisites section asks for Python 2 or 3 and PyTorch 0.4 or newer. That is an unusually wide claim for a 2020 codebase, and it is the kind of statement that ages badly: PyTorch 0.4 predates the 1.0 release, and APIs that the CycleGAN lineage relied on have moved since. Nothing in the README pins a torchvision version, and requirements.txt is not reproduced in the material, so the actual constraint set is invisible until you install it. The CUDA path is stated only as CPU or NVIDIA GPU plus CUDA CuDNN, with no version matrix. If you are on a recent PyTorch build and the released 100_net_G.pth fails to load, the README offers no fallback beyond matching --netG to the trained model's architecture. There are no tagged releases in the material either, so there is no version to pin against and no changelog describing what changed between commits.

Where GANILLA is the wrong tool

The repository is a research artifact, not a service. There is no inference CLI beyond the test.py script, no ONNX or TorchScript export mentioned, no batching guidance for production throughput, and no evaluation metrics script described in the README. If your goal is to stylize user uploads at request time, you would be wrapping a training-oriented research codebase and owning the operational work yourself. The single-direction mode (--model test) reduces compute by skipping the reverse generator, but the README does not state latency or memory figures, so capacity planning has to come from your own measurement. The project is also explicitly scoped to illustration translation; the sample figures are illustration datasets and Miyazaki-style anime images, and nothing in the material suggests the pretrained weights generalize to photographic style transfer or to arbitrary artistic domains. Using it outside that domain means retraining, which means the dataset download scripts and the unpaired CycleGAN format.

How it differs from plain CycleGAN in practice

The honest comparison is with junyanz/pytorch-CycleGAN-and-pix2pix, which the acknowledgments name as the inspiration. The difference is not the training procedure, the data format, or the command-line interface, all of which GANILLA inherits. The difference is the generator: GANILLA runs with --netG resnet_fpn, where the base repository's default generator options are the ResNet and U-Net variants. In practical terms, if you have an existing CycleGAN pipeline, adopting GANILLA is a matter of adding one flag and, if you use the released weights, honoring the checkpoint naming convention. The cost of that narrow delta is that you take on a fork that tracks the upstream project rather than a library with its own release cadence. If your work is not illustration-specific, the upstream repository is the more sensible dependency because it has the same code minus the fork's divergence. The GANILLA authors have also published follow-on work, WAIT for animation-to-illustration video translation and Adversarial Segmentation Loss for sketch colorization, both linked from the updates section, so the project is a point in a research line rather than a maintained product.

Licence, maintenance and what the repository does not tell you

The licence field resolves to NOASSERTION, which means no licence could be determined from the repository metadata. The README contains no licence section, so the terms governing commercial or derivative use cannot be established from the material at hand. Read the LICENSE file in the repository before you build anything on top of it, and treat the absence of a clear identifier as a blocker for anything beyond personal experimentation until you have. Maintenance signals are mixed: the last push date is recent, and the updates section records releases in October 2023 and February 2021, but there are no tagged releases and the README still advertises PyTorch 0.4+. The citation block asks for attribution via the 2020 Image and Vision Computing paper and the 2017 DRAW paper, which is a normal academic expectation but also a signal that the artifact exists to support publications. Budget for the upgrade cost accordingly: you are not tracking a versioned dependency, you are tracking a branch, and any fix you need may have to be carried locally.

Editorial conclusion

Adopt GANILLA if you already work inside the pytorch-CycleGAN-and-pix2pix codebase and want the paper's generator as a drop-in: clone the repo, set --netG resnet_fpn, and either train on a downloaded CycleGAN dataset or drop a pretrained checkpoint at ./checkpoints/{name}_pretrained/100_net_G.pth. Do not adopt it if you need a packaged library, a pinned dependency set, or a permissive licence you can read off the repository page, because the licence field returns NOASSERTION and the README asks for PyTorch 0.4+, a range that spans several breaking API generations. Before committing, verify the licence file in the repository itself, check that your PyTorch version still loads the released weights, and confirm the --netG value matches whatever checkpoint you downloaded, since the README warns that the generator architecture has to line up.

Official sources

1. giddyyupp/ganilla on GitHub
2. Issues
3. README