Coherent Line Drawing: photo to line art through a C++ pipeline

What Coherent Line Drawing automates

Coherent Line Drawing is a C++ implementation of the non-photorealistic rendering technique presented by Kang et al, the academic work the project links as its original reference. The aim is narrow and practical: take an ordinary photograph and produce a line drawing of it automatically, instead of having an artist trace contours by hand. The README describes the result as an easy to use, real time interactive graphical user interface, and the images in the demo folder show a photo reduced to strokes rather than to a flat stylization pass.

That target differs from what a general photo filter does. A filter usually decides, pixel by pixel, whether a point sits on an edge. This technique reasons about stroke continuity, so the output is meant to read as a drawn image with joined, flowing lines rather than a scatter of broken contour fragments. For an engineer the interesting part is that the method is exposed as source code. The repository ships a C++ implementation, a command line application built around the entry point src/cmd.cpp, and a browser port, so the pipeline can be wired into an existing job rather than being a desktop only toy.

The ETF and FDoG knobs the command line exposes

Every stage of the pipeline is controlled by numbers that the command line application surfaces as flags, and the set of defaults tells you how the author expects the tool to be used. Two flags control the edge tangent field stage: ETF_kernel sets the kernel size and defaults to 5, while ETF_iter sets how many refining passes the field receives and defaults to 1. Two more drive the flow based difference of Gaussians stage that produces the final strokes: CLD_iter sets the iteration count, also defaulting to 1, and sigma_c is labelled as line width with a default of 1. Two parameters follow: sigma_m is the degree of coherence with a default of 3, and rho is labelled noise with a default of 0.997. The last one is tau, the thresholding value, at 0.8.

The naming is a small trap for new users. sigma_c controls line width while sigma_m controls coherence, so the letters do not describe what the parameter actually does, and rho reads as noise yet carries a value close to 1. The defaults are tuned for ordinary photographs rather than for a specific subject. Adjusting them is manual work: the project supplies no automatic parameter search, and the README gives no guidance on which values suit which kind of image.

Building the C++ tool and running a first conversion

The build needs a C++ 17 toolchain, CMake, OpenCV 4 and WxWidget 3, with two documented exceptions: WxWidget 3 is not required for the command line application, and Boost is not required for the GUI application. If your environment is stuck on an older standard, there is a cpp11 branch described as functionally equivalent. The project states that it should work on Windows, Linux and macOS, and it ships two helper scripts for Linux that are the shortest path through a first build.

The build script accepts a clean, a debug and a jobs option, and the linter script checks code style with an in place formatting option:

# Usage: build.sh [options]
# Options:
#   -c, --clean       Clean build
#   -d, --debug       Build with debug mode
#   -j, --jobs        Use N cores to build
$ ./build.sh

# Usage: linter.sh [options]
# Check code style
# Options:
#   -i                In-place format
$ ./linter.sh

Once the binaries exist, the command line application is the entry point for scripted use, and the options list below is what the program prints when it starts. The test.sh file in the repository root is the reference for actual invocations, and the first and last flags are the ones that matter for a first run: a source image path and an output image path.

# Coherent-Line-Drawing Options:
#   -h [ --help ]            Help message
#   -s [ --src ] arg         Source image path
#   -o [ --output ] arg      Output image path
#   --ETF_kernel arg (=5)    ETF kernel size
#   --ETF_iter arg (=1)      Refining n times ETF
#   --CLD_iter arg (=1)      Iterate n times FDoG
#   --sigma_c arg (=1)       Line width
#   --sigma_m arg (=3)       Degree of coherence
#   --rho arg (=0.997)       Noise
#   --tau arg (=0.8)         Thresholding

A reader who wants a binary instead of a build can take a pre-built GUI version for Windows or macOS from the project releases page.

The WebGL port runs the whole pipeline in a browser

The newest direction in this repository is a GPU port that removes the C++ build from the loop entirely. The README presents a live demo running in the browser with no installation required, and states that every stage of the pipeline runs as a WebGL2 fragment shader, which is why all parameters update in real time. Implementation details live in the webgl directory, and the repository root carries a .nojekyll file, the marker used when publishing a GitHub Pages site that contains directories beginning with an underscore.

Two addresses are given. The homepage in the project metadata points to a hosted build on the author's own domain, and the README links a live demo hosted on GitHub Pages. The presence of both means the browser port is meant to be the easiest thing to try, ahead of the native application, and the release notes for v1.1.0 on 2026-07-08 name the WebGL port and an undefined behavior fix in the same entry, so the two arrived together.

The practical consequence for an engineer is a different trade-off. The browser path removes the OpenCV and WxWidget dependency chain and makes parameter tuning interactive, but it also ties the pipeline to a WebGL2 capable GPU and to a browser session. Anything that has to run unattended on a server still needs the native command line build.

wxWidgets and Boost are split across the two native targets

The dependency list is unusual enough to be worth reading carefully, because the two optional entries are not optional in the same way. WxWidget 3 is marked as not required for the command line application, and Boost is marked as not required for the GUI application. In practice that means a headless Linux box can compile the command line tool without pulling in a GUI toolkit, while a build of the interactive application still expects WxWidgets and does not need Boost.

The rest of the layout is conventional for a CMake project. Top level entries include CMakeLists.txt, a .clang-format file that pairs with the linter script, src, include and data directories, a demo directory holding the sample images, and the webgl directory for the browser port. The repository topics list cmake, cpp17, opencv, wxwidgets, computer-graphics and non-photorealistic-rendering, plus gcov and lcov, which points to code coverage instrumentation being part of the development setup. The README carries badges for a C and C++ CI workflow, a Travis build status and a codecov coverage graph, so the project treats continuous integration and coverage reporting as part of its routine.

That instrumentation also tells you something about verifying a change. A fork that alters the pipeline can be checked against the coverage tooling, but the repository does not publish a test corpus beyond the demo images, so behavioural verification is visual rather than numeric.

Six years of quiet, then a WebGL rewrite

The repository is not archived, and the last push was on 2026-07-11. The release history around that push is uneven. Version 1.0.1, a macOS build fix, dates from 2017-06-18. Version 1.0.3, described as a performance improvement and refactoring, dates from 2020-07-18. Version 1.1.0, which carries the WebGL port and an undefined behavior fix, dates from 2026-07-08. So the tree you would clone is recent work sitting on top of a codebase whose previous published version had been quiet for about six years.

That gap matters for two reasons. Anyone pinned to v1.0.3 is running code from 2020, and the v1.1.0 entry shows the pipeline contained an undefined behavior bug before that date, which means output from older builds can differ from output from current builds in ways the release notes do not itemize. Second, expect a small project rather than a staffed one. The maintenance activity that exists is recent and concentrated in a single burst of work.

The licence is MIT, in a LICENSE file at the repository root. That permits use, modification, distribution and commercial use, with the requirement that the copyright and permission notice be retained. The MIT text carries no patent grant and no warranty, so it says nothing about output quality or about the patent position of the underlying Kang et al. technique, which is a separate matter from the licence of this implementation.

Where coherent line drawing is the wrong tool

The constraints show up in the shape of the interface rather than in a list of warnings, because the project publishes no known limitations section. The style parameters are global scalars: a single sigma_c for line width and a single sigma_m for degree of coherence apply to the whole image. A photograph with a soft sky next to a sharp face will not get a different treatment for each region, so the operator is left hand tuning one compromise per picture. There is no per region control and no automatic parameter search in the documented options.

The command line application also exposes nothing about output format, resolution, color, batch directories or scripting interfaces. The README does not document batch processing, so rendering a large set of images means invoking the binary once per file, and there is no documented headless service mode. A project that needs thousands of conversions per night with a queue, a database and a progress endpoint will have to build that layer itself.

The rendering target is equally fixed. The pipeline produces line drawings, not color art, and the browser port adds no new output modes beyond what the native build does. If the requirement is a stylized photo that keeps its palette, this method solves a different problem and the effort belongs elsewhere.

Three ways to run the same algorithm, and what each one costs

The repository offers the same technique in three shapes, and the differences between them are about delivery rather than about output. The native graphical application gives real time parameter adjustment against a visible preview, but it needs a display, WxWidgets and a locally built binary, so it suits a designer at a desk and not a server. The command line application drops the GUI dependency, keeps the same style flags, and is the shape to script against, at the cost of no interactive preview, which is why a single conversion needs a few attempts with different values.

The WebGL port is the newest and the most convenient to evaluate, since it needs no installation and updates parameters in real time as fragment shader inputs. It is also the least suitable for unattended work, because it lives inside a browser and a WebGL2 capable GPU.

Comparison with other stylization methods is thinner here. The project links the Kang et al. paper as the original reference and a Chinese introduction, but it publishes no benchmark, no timing and no side by side comparison against other line drawing filters, so claims about relative quality have no backing in the repository itself. A filter based edge stylizer will give you contours without the coherence stage; the difference between the two is the reason this implementation exists, and reading the paper is the only comparison the project offers.

Editorial conclusion

Adopt Coherent Line Drawing if you need a scriptable, MIT-licensed line drawing of a photograph and can live with a small set of style parameters. Skip it if you need a service that renders thousands of images unattended, if color output matters, or if you want a tool with a steady stream of upstream fixes. Before committing, build the command line application from src/cmd.cpp, run it against your own photographs, and check the output on the OpenCV 4 version you plan to ship, since v1.1.0 was released on 2026-07-08 to fix an undefined behavior bug and the last push to the tree was on 2026-07-11.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. SSARCandy/Coherent-Line-Drawing on GitHub