Pixel2Motion: A Codex and Claude Skill That Turns Raster Logos Into Animated SVG

The gap Pixel2Motion fills between a PNG logo and a usable motion file

Most logo animation work starts badly. Someone has a raster logo, usually a PNG or a screenshot, and the fastest path to something moving is to trace it, or to drop the bitmap into a video editor and animate the whole rectangle. Both produce output that looks wrong at small sizes or cannot be edited later. Pixel2Motion's premise is that the vector has to be correct and addressable before any keyframes exist. The README states the goal directly: raster logo to smooth minimal SVG, then SVG logo animation, then an interactive HTML motion demo. The audience is narrow and specific. It is for people who work inside Codex or Claude and want the logo motion step to be a repeatable skill rather than a manual session in a vector editor. The repository is tagged as a claude-skill and a codex-skill, which tells you the intended interface is an agent reading SKILL.md, not a GUI. If you animate logos occasionally and by hand, the overhead of a spec file, overlay iterations and frame captures will feel heavier than the task.

Why the static vector is treated as a contract, not a draft

The design decision that shapes everything else is the split between fitting and choreography. The README describes the CueRecord fitting sequence as a series of overlays where the vector candidate is repeatedly compared against the raster source until mark scale, dot placement, wordmark baseline and ink weight hold up. Only then is motion authored. That ordering matters because it means the SVG is not a byproduct of the animation. It is the final-frame contract. The README is explicit that the resulting SVG keeps mark, dot and wordmark as separate addressable parts, which is what allows motion.css to target semantic ids instead of wrapping the whole logo in a transform. There is also a stated quality rule that runs against the usual metric. Pixel2Motion optimizes IoU as a diagnostic, but smoothness and structure are the hard gates, and a high-IoU jagged trace is rejected when a lower-complexity smooth vector explains the logo better. That is a real editorial position. It means the tool will sometimes choose a less pixel-accurate path because the accurate one is unusable for animation. Whether you agree depends on whether the logo is going to be scaled up, where jagged control points become visible.

The deliverable set and what each file is responsible for

The README lists seven outputs, and the division between them is the clearest signal of how the workflow is meant to be audited. logo.svg is the static vector, structured for motion. motion.css holds the authored choreography and targets semantic SVG ids, so the animation is a separate artefact you can read and diff rather than something baked into the markup. logo_motion.html is described as a dependency-free showcase with replay, slow motion, speed control, QA hooks and atomic motion studies. motion_spec.md is the written brief: personality, usage context, part inventory, choreography sketch, timeline, easing tokens and QA notes. Then there are three evidence categories. outputs/fit_iterations/*.png holds the geometry overlays. outputs/motion_frames/*.png and outputs/motion_strip.png hold deterministic motion frames. outputs/final_render.png and outputs/html_render.png are static render checks. The teal overlays in the fitting strip are described as QA checkpoints, not the deliverable, which is worth repeating to anyone who sees them in the repository and mistakes them for the product.

Running the pipeline: the four scripts and their arguments

The workflow in the README is a numbered sequence, and steps three through six are concrete commands. Fitting the static vector runs render_overlay.py with the SVG, the source raster, and three output flags: --out for the overlay PNG, --render-out for the static render, and --report for a fit_metrics.json file. When smoothness is a concern, svg_path_audit.py takes the SVG and writes --out-svg for bezier_segments.svg plus --report for bezier_audit.json, which gives you a way to inspect complex curves before committing to them. Building the showcase runs animate_svg_showcase.py with logo.svg, --css motion.css, --out logo_motion.html, --title, and --duration-hint 1500 in the example. Capturing frames runs capture_motion_frames.py against the generated HTML with --times 0,300,700,1000,1250,1500, --out outputs/motion_frames, --strip outputs/motion_strip.png, and --compare-final outputs/final_render.png. The --times list is a fixed set of millisecond offsets, which is what makes the captures deterministic rather than a screen recording. Step two, writing the motion brief in motion_spec.md before touching any code, is the part most likely to be skipped and the part the rest of the workflow depends on.

Where the skill stops being the right tool

The clearest limitation is stated by the project itself rather than hidden. The static fitting methodology is documented in full in the companion Pixel2SVG-HTML project, not here. So half of what determines output quality lives in a second repository, and this one assumes you either already have a clean motion-ready SVG or are willing to follow the sibling project's method. That is a real coupling. If your logo is already a well-structured SVG, step three is largely wasted effort, and you are running overlay comparisons against a source bitmap for a vector that already matches. The second constraint is the QA loop. Frame capture and comparison against final_render.png implies a headless browser in the environment, and the README does not describe a fallback. If the agent environment cannot render HTML, you get the SVG and the CSS but not the evidence. Third, the README's fitting example uses a single logo.svg and source.png pair. Nothing in the material describes batch processing or a manifest, so treating this as a bulk converter for a folder of logos is an assumption the documentation does not support. The repository also shows no retrieved releases, so there is no versioned artefact to pin against.

How this differs from tracing or from a timeline-based animation tool

The obvious alternative is an automatic bitmap tracer followed by a generic SVG animation library. The difference is in what gets rejected. A tracer optimizes for pixel agreement and will happily emit a path with hundreds of control points that matches the source closely and animates badly, because stroke-dashoffset reveals and per-part transforms want a small number of clean subpaths. Pixel2Motion inverts that priority, treating IoU as a diagnostic and smoothness and structure as the gates, and it gives you svg_path_audit.py specifically to look at curve complexity before you build on it. The second alternative is a timeline-based motion tool, where you animate the logo visually and export a video. That produces a finished asset but not an editable one: no addressable ids, no motion.css you can hand to a front-end developer, no motion_spec.md describing easing tokens. Pixel2Motion's output is source code plus evidence. The trade is speed. A timeline tool gives you a preview in minutes; this gives you a spec, a fitted vector, an HTML page and a strip of PNGs, and expects you to review the overlays before moving on.

Maintenance surface, licensing and what to check before you depend on it

The licence is MIT, which permits commercial use and modification, though the README points to a separate commercial service at pixel2motion.com described as offering more polished workflows and production support beyond the open-source skill. Read that as a scope statement rather than a restriction: the skill is the open part, the service is the supported part. Nothing in the supplied material states what the commercial service includes, so do not assume feature parity in either direction. On maintenance, the repository is not archived and the last push is dated 2026-08-21, but no releases were retrieved, which means there is no changelog to read and no version number to pin. The upgrade cost is mostly in the reference files: the workflow's first step is to read SKILL.md and the relevant reference files before fitting or choreographing, so a change in those references changes behaviour without a code diff. The scripts themselves are small and argument-driven, which limits breakage. Before depending on it, verify three things: that your environment can run the headless capture step, that the companion Pixel2SVG-HTML method produces vectors you are happy with, and that the --duration-hint and --times values you choose line up with the animation length you actually authored in motion.css.

Editorial conclusion

Adopt Pixel2Motion if you already drive Codex or Claude for design work and want the logo-to-motion step to leave inspectable artefacts behind: logo.svg, motion.css, motion_spec.md and a folder of overlay PNGs. Do not adopt it if you need a one-click converter for a batch of logos, or if you cannot run headless browser capture, because the motion QA step depends on it. Before committing, read SKILL.md and the reference files it points at, run render_overlay.py on one of your own logos and check the fit_metrics.json report, then confirm that capture_motion_frames.py produces the frames you expect on your machine. The static fitting methodology lives in the companion Pixel2SVG-HTML repository, so if your vector is already clean you are paying for a stage you do not need.

Official sources

1. Issues
2. License: MIT
3. nolangz/pixel2motion on GitHub
4. Project website
5. README