Anime2Sketch: A GAN Sketch Extractor for Anime and Illustration

What Anime2Sketch extracts, and for whom

The repository describes itself as a sketch extractor that works well on illustration, anime art, and manga. The intended output is a line drawing: the README shows examples of illustration art converted to lineart, hand-drawn photos turned into clean linearts, and freehand sketches simplified. The teaser asset is a GIF from Vinland Saga, so frame-by-frame extraction from animation is an expected use.

The likely user is someone building a dataset or a pipeline who needs line art as an intermediate representation. That includes people preparing sketch-to-image training pairs, cleaning scanned manga for downstream processing, or producing lineart for coloring workflows. The paper behind it, Adversarial Open Domain Adaption for Sketch-to-Photo Synthesis, is about sketch-to-photo synthesis, so the extractor is a component of a larger generative pipeline rather than a finished product.

It is not a general edge detector. The README makes no claim about photographs of objects, and the domain is stated narrowly as illustration, anime art and manga. If your input is a photo of a person, the documentation gives you no reason to expect a useful line drawing.

The mechanism: a GAN trained by the AODA authors

Anime2Sketch is an application built on the AODA paper. The repository contains testing code and pretrained weights, and the README states plainly that the project is a sub-branch of AODA, with training instructions living in that other repository. So the model architecture itself is not documented here; what you get is an inference wrapper around weights someone else trained.

The practical consequence is that you cannot inspect the training objective from this repository alone. What the README does tell you is that there are two weight sets. The default one is the standard extractor. The second is described as an artifact-free version that works with dark or low contrast images, downloaded from a separate Google Drive link and placed in the same weights/ folder. That is a real fork in behaviour: if your source frames are dark, the default weights are the wrong ones, and the README does not explain how the two differ internally, only what the second one is for.

The pipeline is single image in, single image out, driven by test.py. There is no batch scheduler, no queue, no server. Each invocation loads the model, processes the dataroot argument, and writes to output_dir.

Getting it running: test.py, arguments and weights

Installation is a single requirements file: pip install -r requirements.txt. The prerequisites list Python 3, Pillow and PyTorch, with a recommendation to use Anaconda, and support for Linux, macOS or Docker. CPU or an NVIDIA GPU with CUDA CuDNN are both listed.

Before anything runs you must download weights from Google Drive and place them in the weights/ folder. This is a manual step with no checksum, no version tag and no script. If that Drive link dies, the repository has no fallback, since there are no published releases to pin against.

The test command takes three arguments:

python3 test.py --dataroot /your_input/dir --load_size 512 --output_dir /your_output/dir

dataroot accepts a file or a directory. load_size exists because of a memory limit, and the README states that the input is resized before processing, 512x512 by default. output_dir is where results land. The README's own example uses test_samples/madoka.jpg with results/ as the destination.

The Docker path is documented with a Makefile. make docker-build builds the image, and make docker-run runs it. Input and output directories are mounted as volumes. The example command mounts the repository at /workspace, test_samples at /input and output at /output. Running CPU only requires editing two lines: the Dockerfile CMD must drop the GPU options and become a plain python test.py invocation with /input, 512 and /output, and the Makefile docker-run line must drop --gpus all. Those are the only two changes the README names.

The 512 pixel resize is the real constraint

load_size is not a tuning knob you can raise freely. The README attributes it directly to a memory limit, which means the default 512x512 is a ceiling chosen to keep inference inside available memory, not an aesthetic preference. For a full-page manga scan or a wide animation frame, that resize discards detail before the network ever sees the image.

How much that matters depends on your line weight. Thin hatching and small screentone regions are exactly the kind of high-frequency content that a downscale to 512 pixels can smear. The README offers no tiling scheme, no patch-based inference, and no guidance on preserving aspect ratio or recovering detail at the original resolution. If your input is much larger than 512 on a side, you are relying on the network to reconstruct lines from a reduced image, and the repository gives you no tool to verify whether it did.

The second failure mode is input domain. The dark and low contrast weight set exists precisely because the default model produces artifacts on such images. There is no automatic detection. You have to know your input is dark and pick the other file yourself. A pipeline that mixes bright and dark frames will need to route them, and the README does not describe how to decide the threshold.

Anime2Sketch versus a classical edge detector

The obvious alternative for line extraction is a classical edge detector such as Canny or a difference-of-Gaussians filter, available in OpenCV and scikit-image. The difference in approach is fundamental. A classical detector responds to local intensity gradients and has no model of what a drawing is. It will fire on texture, on gradients in shading, and on compression noise, and it will miss a low-contrast line that sits next to a strong edge.

Anime2Sketch instead applies a learned mapping trained on illustration and anime art, so the output is biased toward the kind of lines a human artist would draw. That is why the README can show simplification of freehand sketches and conversion of hand-drawn photos into clean linearts: the model is suppressing content it has learned is not linework. The cost is that the behaviour is not inspectable. With Canny you can reason about thresholds and reproduce a result exactly. With a GAN you get weights, and the only control surface exposed here is load_size and which of the two weight files you loaded.

If your inputs are clean, high contrast, and you need deterministic, tunable output, a classical detector is the better tool. Anime2Sketch earns its place when the input is stylized art and you want the output to look like a drawing rather than like an edge map.

Maintenance, licensing and what is not in this repository

The licence is MIT, stated in the README and shipped as a LICENSE file. That is permissive and places few obligations on how you use the code, but note the boundary: the MIT grant covers this repository. The pretrained weights are distributed through Google Drive links rather than through the repository or a package index, and the README says nothing about the terms attached to those files. If you plan to ship a product that depends on the weights, that distinction is worth resolving before you build on them. Nothing here is legal advice.

Maintenance signals are mixed. The last push is dated 2026-09-08, but the Updates section ends in January 2022 and no releases were retrieved. The commit history and the changelog tell different stories, and without inspecting the repository directly you cannot tell whether recent activity is substantive or housekeeping. There is no versioned artifact to depend on, which means an upgrade is a git pull plus a manual re-download of weights if they changed.

The larger maintenance cost is the training path. The README says training instructions live in the AODA repository, so fine-tuning on your own art style means leaving this project entirely and working in a codebase whose relationship to these weights is not spelled out here. If your requirement is a model you can retrain, Anime2Sketch is the wrong entry point.

Who should run this, and what to check first

This is a fit for engineers who need offline line extraction from anime frames or illustration files, who are comfortable with a manual weight download, and whose images are near the 512 pixel working size or can tolerate the resize. The single-file test.py interface and the two-line CPU Docker adjustment make it quick to try, and MIT licensing keeps the code side simple.

It is a poor fit for anyone who needs a training loop, a hosted endpoint, throughput guarantees, or reproducible pinned artifacts. The absence of releases and the external weight hosting are structural, not cosmetic. If your pipeline cannot tolerate a manual Google Drive step in provisioning, look elsewhere.

Before committing, check three things in this order. Confirm both Google Drive weight links still resolve, since nothing in the repository mirrors them. Decide which weight file your input needs by inspecting brightness and contrast across your sample set, because the README gives no automatic switch. Then run the README's own example, python3 test.py --dataroot test_samples/madoka.jpg --load_size 512 --output_dir results/, and compare the output against a Canny baseline on the same image at the same 512 size. If the learned output does not visibly beat the classical one on your actual art, the extra weight download and the opaque model are not buying you anything.

Editorial conclusion

Adopt Anime2Sketch if you need offline line extraction from anime frames or illustration files and can accept a fixed 512x512 resize and a manual weight download. Do not adopt it if you need training, batch throughput guarantees, or a hosted API, because the README points training to the separate AODA repository and there are no releases to pin. Verify first that the Google Drive weights still resolve, that your CUDA or CPU path matches the Dockerfile CMD line you intend to use, and that a 512 pixel resize preserves the line detail your downstream task depends on.

Official sources

1. Issues
2. License: MIT
3. Mukosame/Anime2Sketch on GitHub
4. README