whiteboard-animator Review 2026 — The CPU-Only Render Engine That Turns a Static Whiteboard Image Into a Hand-Drawn Video

The Pitch: One Command From Static Image to Hand-Drawn Video

whiteboard-animator, released September 8, 2026 by masihsultani under MIT, answers a deceptively simple question: what if a finished whiteboard picture could draw itself? Give it a whiteboard-style image and it writes the text word by word, traces the outlines, fills the shapes with brush strokes, and draws branched line art one stroke at a time — the way a person at a whiteboard would. Add a narration file and the drawing paces itself to the voice. One command, CPU only, no API keys:

pip install whiteboard-animator
whiteboard-animate sketch.png --duration 8 -o sketch.mp4

The repo is candid about its pedigree: this is the render engine behind the Whiteboard format at Kinoslide (kinoslide.ai), released open source so anyone can animate their own images. The README links complete narrated videos made with the engine — The Yen Carry Trade Unwind and General Relativity in 2 minutes — as evidence of what the pipeline produces. It passed ~100 stars within two days of release.

How the Engine Draws

The render pipeline is five stages, and each one reads like someone who has watched a lot of whiteboard videos and got angry about the details:

1. Finds the ink. Every connected blob of non-white pixels becomes a component. A bundled CRAFT text detector (ONNX, CPU — an 83 MB export of CRAFT-pytorch’s craft_mlt_25k, MIT) marks which components are text so words are written rather than traced like shapes.
2. Orders the components the way a hand would. Containers before contents, shapes before their labels, text in reading order, small dots attached to the glyph they belong to.
3. Gives each one a time slot. Slots scale with the square root of area, so a big fill does not hog the timeline. With a region plan, slots use estimated narration pacing instead.
4. Assigns every pixel a reveal time. Strokes follow their skeleton from a real endpoint, so a V starts at a tip and not the apex. Closed outlines get one travelling front. Fills get an outline pass, then either an angled sweep or bristled brush strokes depending on size. Line art with junctions is decomposed into sequential pen paths, so an X or a grid does not grow from the middle outward.
5. Streams frames to ffmpeg. Newly finished pixels are committed once, and only pixels currently fading are blended each frame.

At render time there is no model apart from the small text detector. No GPU, no training, no API keys. If the model cannot be loaded the engine still runs and treats text as ordinary strokes.

Narration, Region Plans and the Honest Boundary

With narration, the default behaviour is that the drawing finishes inside the audio and the finished frame holds until the audio ends. Multiple scenes concatenate in order, each with its own audio. Quality presets cover the usual range: low (20 fps, 500k), medium (24 fps, 1500k, default), high (24 fps, 3000k), and images whose longest side exceeds 1280 px are downscaled.

The interesting control is the region plan: a JSON file that specifies what the image contains, the drawing order, and the narration text associated with each part. Boxes are normalized 0 to 1000 with the origin at the top left, and each region carries a label, role (main_concept), an expected_visual, a reveal_order and a reveal style. With a plan, the engine allocates the first 75% of the audio to drawing windows, and each region’s share blends its fraction of annotation characters (70% weight) and bounding-box area (30% weight); if all annotations are empty it uses box area alone. A region can finish early and hold until the next window.

The README draws the honest boundary here: this estimates pacing from text; it does not analyze speech or align to spoken-word timestamps. Pauses, changes in speaking rate and uneven phrase lengths can cause the drawing to lead or lag the voice. For exact cue times you pass explicit start and end times in an element_plan to the lower-level WhiteboardAnimator.render_to_file API, which takes an RGB numpy array and writes a silent MP4 — and whose constructor exposes every tuning knob: fade length, fill detection thresholds, brush angle and width, the S-curve that decides when a fill uses brush strokes instead of a sweep, and the line-art decomposition thresholds.

The one optional cloud feature is --detect-regions, which asks Gemini to work out the drawing order from the image and the narration text — it needs the gemini extra and a GOOGLE_API_KEY. --save-regions writes the detected plan next to the output so you can edit it and re-render with --regions, which is a nice human-in-the-loop pattern: let the model propose, then fix the order by hand.

What Makes a Good Input

The engine expects ink on white. Pixels lighter than 240 gray are background, and near-white is snapped to white. Clean marker-style drawings with a handful of flat colours animate best; photos, gradients, and textured or coloured backgrounds will not. That constraint is both the limitation and the reason the output looks coherent — the reveal logic depends on clean segmentation, and the repo is upfront that non-white backgrounds and SVG input with real vector tracing are the open problems it wants help with.

Engine Alone vs the Full Kinoslide Product

The README includes a comparison table that is unusually clear about what the open-source engine does and does not do. The repo animates an image you already have, joins multiple scenes into one video, and paces narration from a region plan. Kinoslide — the hosted product — additionally writes the script from a PDF or prompt, generates the scene images, supplies narration with Gemini and ElevenLabs voices, handles narration pacing automatically, and offers hosted rendering, sharing and editing. In other words: whiteboard-animator is the deterministic render core, open-sourced, and the product layers the generative parts on top. For a content operator that is a useful separation — you can build your own pipeline on the engine without signing up for the hosted product, or use the hosted product and know exactly what is underneath.

Honest Limits and Who It’s For

The limits are structural and stated. White-background images only. Narration pacing estimated from text, not aligned to speech — with exact cue times requiring the lower-level API. One paid-API feature (Gemini region detection) in an otherwise local tool. An 83 MB model plus scientific Python dependencies and ffmpeg with libx264 on the first install. Raster rendering rather than vector tracing. And it is a two-day-old, single-author project at review time — though the seven commits include CI and integration tests that run the real bundled model through CLI-to-MP4 checks, which is more engineering rigour than most day-two releases.

Who should care? Educators, course creators and explainer producers who already have finished whiteboard diagrams and want deterministic, scriptable, CPU-only animation with full control over drawing order — people who would rather own a precise render engine with a JSON plan format than trust another black-box video generator. For that audience, whiteboard-animator is a rare thing in the 2026 AI-video landscape: a tool that does exactly one job, does it locally, and tells you honestly where its boundaries are.