Anime4KCPP v3: A CNN Upscaler With a CMake Dependency Web

The Problem It Solves Is Pipeline Placement, Not Magnification

Most upscalers are standalone programs. You point one at a file, wait, and get a bigger file back. That works until you need upscaling to happen inside a larger chain: a frame server, a filter graph, a video decode path where frames are already in memory. Anime4KCPP is built for that second case. The repository describes it as a high performance anime upscaler, and v3 as using a CNN based algorithm that aims to be simple and efficient. The audience is therefore narrow and specific: people who process anime video through AviSynth, VapourSynth or DirectShow and want the upscale as one node in the graph, plus people who want a CLI or a GUI for one-off image work and a Python binding for scripting. If you only ever upscale a single PNG by hand, the filter modules are dead weight you will still pay for at configure time.

What the CNN Backend Actually Requires From Your Machine

The core module is where the CNN work happens, and it is configured through CMake options rather than runtime flags. Three of them matter: AC_CORE_WITH_CUDA, AC_CORE_WITH_OPENCL and AC_CORE_WITH_EIGEN3. CUDA is listed as a manual acquisition, meaning CMake will not fetch it for you; the README states the minimum tested CUDA Toolkit version is 11. OpenCL is acquired automatically, and Eigen3 likewise. There is also AC_CORE_WITH_FPNG, which pulls in fpng, and the core module depends on ruapu, stb and half regardless, all acquired automatically. The practical reading is that the CNN does not run on a single hardcoded path. You pick a compute backend at build time, and the set of backends you enable determines what the binary can do on a given GPU. The README does not publish per-backend performance numbers, so any claim about which backend is faster on your hardware would be guesswork; the honest position is that you have to measure it yourself after building, and the project gives you no benchmark harness in the material supplied.

Getting It Built: The Commands the README Gives

The documented Windows path with MinGW-w64 is a mkdir build; cd build, then cmake -G "MinGW Makefiles" .. -DAC_CORE_WITH_OPENCL=ON -DAC_ENABLE_STATIC_CRT=ON, then cmake --build . --config Release -j8, then cd bin and ./ac_cli -v to confirm the binary responds. The MSVC path is the same shape with cmake -G "Visual Studio 17 2022" .. -DAC_CORE_WITH_OPENCL=ON. Note what is not in either command: no video module, no GUI, no filters. Those are opt-in through AC_BUILD_VIDEO, AC_BUILD_GUI, AC_BUILD_CLI, AC_BUILD_FILTER_AVISYNTH, AC_BUILD_FILTER_VAPOURSYNTH, AC_BUILD_FILTER_DIRECTSHOW, AC_BUILD_BINDING_PYTHON and AC_BUILD_TESTS. Dependency handling has two modes. With internet access, CMake downloads and configures most required dependencies automatically. Without it, you download them yourself, and the README notes that most are located via find_package while others use pkg-config or explicit paths, with dedicated variables such as AC_PATH_FFMPEG, AC_PATH_EIGEN3, AC_PATH_CLI11, AC_PATH_FPNG, AC_PATH_RUAPU, AC_PATH_STB, AC_PATH_AVISYNTH_SDK, AC_PATH_VAPOURSYNTH_SDK, AC_PATH_DIRECTSHOW_BASECLASSES and AC_PATH_CLI11. Setting one of those variables makes CMake search your path first and overrides the default search locations. That override behaviour is the part people get wrong: a stale AC_PATH_FFMPEG will silently win over a correct system FFmpeg.

Three Version Floors That Decide Which Modules Compile

The README lists version constraints that are easy to skim past and expensive to discover late. CUDA Toolkit minimum tested version is 11. FFmpeg libraries minimum is FFmpeg 4, and FFmpeg covers four separate libraries here: libavcodec, libavformat, libavutil and libswscale, all gated behind AC_BUILD_VIDEO and all located via pkg-config or AC_PATH_FFMPEG. VapourSynth SDK 4 is required, and it is also located via pkg-config or AC_PATH_VAPOURSYNTH_SDK. Qt5 and Qt6 are both stated to be acceptable for the GUI. For non-MSVC compilers, the build uses a modified version of the DirectShow BaseClasses maintained in a separate repository. That last point is a real constraint, not a footnote: the DirectShow filter path is Windows-only, and the README states it has been tested with MinGW-w64, ClangCL and MSVC. If you are building on Linux, the DirectShow module is simply not part of your universe, and the AviSynth module carries the same Windows association in practice.

Where the Build System Becomes the Failure Mode

The dependency table is long, and its length is the project's main cost. Fifteen rows, split across automatic and manual acquisition, with a mix of find_package, pkg-config and explicit path variables. The failure mode is not a crash, it is a configure step that succeeds against the wrong library or fails with a message that points at the wrong dependency. Two specific traps are visible in the material. First, the manual dependencies (CUDA Toolkit, FFmpeg, Qt) are the ones CMake will not fetch, so an offline build has to supply them before configure runs. Second, the AC_PATH_XXX variables override default search locations, so once set they persist in a CMake cache and can mask a later, correct installation. The README offers no troubleshooting section and no CI recipe in the supplied text, which means the first build on an unfamiliar machine is genuinely exploratory. This is a project where the build is a bigger commitment than the usage.

Anime4KCPP Versus a Shader-Based Upscaler

The natural alternative is the original Anime4K, which is a set of GLSL shaders intended for real-time playback in mpv. The difference in approach is structural. Anime4KCPP is a compiled library with a CNN backend and multiple host integrations; the shader approach is a text file loaded by a player, with no build step, no CUDA Toolkit, no FFmpeg linkage and no C++17 compiler requirement. If your goal is to watch a video with upscaling applied live, the shader route reaches that goal with far less setup. Anime4KCPP reaches goals the shader route does not: batch processing through a CLI, embedding in a VapourSynth or AviSynth script, a DirectShow filter for Windows capture or playback graphs, Python bindings through pybind11, and a GUI. There is also a WebAssembly build, since the README points to an Anime4KCPP Playground for upscaling images in the browser. That playground carries its own caveat, quoted from the README: for the Microsoft Edge browser, optimal performance requires disabling Enhanced Security for the site. That is a browser-level security setting being traded for throughput, and it is worth knowing before you point anyone at the playground.

Licence, Maintenance and the Cost of Upgrading

Anime4KCPP is GPL-3.0. That is a copyleft licence, and the practical consequence is that if you distribute a binary that links the library, the terms of the GPL apply to that distribution. This is not legal advice and the specifics depend on how you link and ship, but the direction of the constraint is clear enough to plan around: internal use is one thing, shipping a closed product that statically links this is another. On maintenance, the release history shows v2.5.0 in January 2021, v3.0.0 in August 2025, and v3.2.0 in May 2026. The four-year gap between v2.5.0 and v3.0.0 is the notable fact. It means the v3 line is young relative to the project's age, and it also means anyone who built against v2.5.0 faced a long period without upstream movement before the CNN rewrite landed. The upgrade cost between major versions is not documented in the supplied material, so treat a v2 to v3 migration as an unverified path until you check the release notes for that specific jump. The dependency floors (CUDA 11, FFmpeg 4, VapourSynth SDK 4) also mean your toolchain, not the project, is the thing most likely to age out first.

Editorial conclusion

Adopt Anime4KCPP if you already have an FFmpeg or VapourSynth pipeline and want upscaling as a filter stage rather than a separate processing step, and if GPL-3.0 is acceptable for how you distribute the result. Do not adopt it if you need a zero-dependency tool, if you are targeting a non-Windows DirectShow workflow, or if you cannot accept a copyleft licence in your build. Before committing, verify three things on your own machine: that the CUDA Toolkit you have meets the documented minimum of version 11, that your FFmpeg libraries are at least version 4, and that your VapourSynth SDK is version 4, because those three thresholds decide whether the corresponding modules build at all.

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. TianZerL/Anime4KCPP on GitHub