▍AI Dev Lab
VecTrace

VecTrace ができるまで — 画像を SVG ベクターに変換する

画像のベクター化ツールの開発ログ。 imagetracerjs で色の量子化から境界追跡・ベジェ近似までを行い、 拡大しても劣化しない SVG パスに変換する実装と、 他の画像ツールとの使い分けを記録しています。

ロゴをもらったら PNG だった。名刺に大きく刷りたいのに、拡大するとぼやける。

この「PNG しかない」問題は地味に多くて、そのたびに Illustrator を開いて手でトレースするか、有料の変換サービスに画像をアップロードするかの二択でした。前者は面倒、後者は他人のサーバーにロゴを渡すのが気持ち悪い。

VecTrace は、画像をブラウザの中だけで SVG(ベクター画像)に変換するツールです。何もインストールせず、画像も外に出さず、拡大しても劣化しない SVG を作ります。


#🎯 ラスターとベクターの違い

まず用語を整理します。

ラスター (PNG/JPG)ベクター (SVG)
中身色のついた点の集まり線・曲線・塗りの数式
拡大ぼやける・ギザギザ何倍でもくっきり
向くもの写真ロゴ・アイコン・図形

ロゴやアイコンは本来ベクターであるべきものです。ところが実際に手元にあるのは PNG だけ、というケースが多い。VecTrace がやるのは、点の集まりを見て、そこにある線や面を推測し、数式で描き直すことです。これを「トレース」と呼びます。


#🏗️ 技術選定:imagetracerjs

トレースはゼロから書くと大仕事です。色の量子化、エッジの追跡、曲線の近似——どれも一つの研究テーマになるくらいの内容があります。

そこで、この分野で枯れている imagetracerjs を使いました。andras jankovics 氏によるライブラリで、大きく 3 段階の処理をやってくれます。

  1. 色量子化 — 画像の色を指定数のパレットに減らす(例: 数万色 → 8 色)
  2. エッジ追跡 — 同じ色の領域の境界線を辿る
  3. ベジェ近似 — 辿った境界を滑らかな曲線(ベジェ曲線)で近似する

有名な potrace(白黒特化)と違い、imagetracerjs はカラー画像をそのまま多色 SVG にできるのが選定理由でした。

これも他のサービス(pitch-flip、py-pad)と同じく、CDN からスクリプトタグで読み込む方式です。

ts
const TRACER_CDN = "https://cdn.jsdelivr.net/npm/imagetracerjs@1.2.6/imagetracer_v1.2.6.js"

function loadTracer: Promise<ImageTracerLike> {
 if (typeof window !== "undefined" && window.ImageTracer) {
 return Promise.resolve(window.ImageTracer)
 }
 if (!loadPromise) {
 loadPromise = new Promise<ImageTracerLike>((resolve, reject) => {
 const s = document.createElement("script")
 s.src = TRACER_CDN
 s.async = true
 s.dataset.imagetracer = "1"
 s.onload = => {
 if (window.ImageTracer) resolve(window.ImageTracer)
 else reject(new Error("ImageTracer unavailable after load"))
 }
 s.onerror = => reject(new Error("Failed to load imagetracerjs"))
 document.head.appendChild(s)
 })
 }
 return loadPromise
}

loadPromise を保持して、初回だけ読み込む形。バンドルには含めていません。


#🎚️ プリセットが本体

imagetracerjs は調整パラメータが多く、生で触ると難しいライブラリです。numberofcolors(色数)、pathomit(小さすぎるパスを捨てる閾値)、ltres / qtres(直線・曲線の許容誤差)、blurradius(前処理のぼかし)……。

これを全部ユーザーに委ねると、たいていの人は最初の 1 枚で挫折します。そこで、用途別に効くパラメータの組を「プリセット」として固めました。

ts
export const PRESETS: TracePreset[] = [
 {
 id: "logo", jp: "ロゴ / アイコン",
 oneLine: "少色 で くっきり。 ロゴ や アイコン の SVG 化 に 最適",
 options: { numberofcolors: 8, pathomit: 8, ltres: 1, qtres: 1, blurradius: 0, ... },
 },
 {
 id: "photo", jp: "写真",
 oneLine: "多色 + 軽い ぼかし。 写真 を ポスター 風 ベクター に",
 options: { numberofcolors: 32, pathomit: 4, ltres: 1, qtres: 1, blurradius: 2, ... },
 },
 {
 id: "poster", jp: "ポスター化",
 oneLine: "色 を 大胆 に 削った シルクスクリーン 風 の 面 構成",
 options: { numberofcolors: 6, pathomit: 12, ltres: 1.5, qtres: 1.5, blurradius: 3, ... },
 },
 {
 id: "sketch", jp: "線画 (白黒)",
 oneLine: "白黒 2 値 で 輪郭 を 抽出。 塗り絵 や ステンシル に",
 options: { numberofcolors: 2, pathomit: 6, ... },
 },
]

プリセットの設計思想はシンプルで、色数 (numberofcolors) がすべての起点です。

  • ロゴは色が少なく境界がはっきりしているので 8 色、ぼかしなし
  • 写真は階調が豊かなので 32 色、軽くぼかして色の境界を整理
  • ポスター化はあえて 6 色まで削り、面を大胆にまとめる
  • 線画は 2 色(白黒)にして輪郭だけを取り出す

色数を減らすほど「面」がまとまり、SVG のパスも減って軽くなる。増やすほど元画像に近づくが、パスが増えてファイルも重くなる。このトレードオフを、ユーザーが数値ではなく「ロゴ」「写真」という言葉で選べるようにしたのがプリセットです。


#🔄 変換そのものは短い

パラメータさえ決まれば、変換は一発です。

ts
export async function traceToSvg(imgd: ImageData, opts: TraceOptions): Promise<TraceResult> {
 const tracer = await loadTracer
 const t0 = performance.now
 const svg = tracer.imagedataToSVG(imgd, {
 numberofcolors: opts.numberofcolors,
 pathomit: opts.pathomit,
 ltres: opts.ltres,
 qtres: opts.qtres,
 blurradius: opts.blurradius,
 strokewidth: opts.strokewidth,
 scale: opts.scale,
 roundcoords: 1,
 viewbox: true,
 desc: false,
 })
 return { svg, ms: Math.round(performance.now - t0), bytes: new Blob([svg]).size }
}

Canvas から取った ImageData を渡すと、SVG 文字列が返ってきます。viewbox: true にしているのは、SVG に viewBox 属性を持たせて拡大縮小を効かせるため。roundcoords: 1 で座標を丸めて、無駄に長い小数を削りファイルを軽くしています。desc: false はライブラリが埋める説明コメントを消す指定です。

処理時間とバイト数を返しているのは、「何色にすると何 KB になるか」がその場で分かるようにするため。ベクター化は色数とファイルサイズが直結するので、この数字が見えると調整しやすくなります。


#😓 苦労したところ

#写真は「そのまま」だと破綻する

写真をトレースすると、階調のグラデーション部分が細かい斑(まだら)だらけの SVG になり、かえって元より汚くなります。しかもパスが数万本に膨れてファイルが重い。

対策が blurradius(前処理のぼかし)です。トレース前に軽くぼかすと、細かいノイズが均されて色の面がまとまり、パスが激減します。写真プリセットで blurradius: 2、ポスター化で 3 を入れているのはこのため。ベクター化の質は、実はトレースそのものより前処理で決まるというのが、作ってみて一番の発見でした。

写真を写真らしく残したいなら、そもそもベクター化は向いていません。VecTrace の写真プリセットは「ポスター風にする」ものだと割り切って、UI でもそう案内しています。

#色数を上げれば良い、わけではない

直感的には「色を増やせば元画像に近づいて良い」と思いがちですが、実際は色数を上げるとパスが爆発的に増え、SVG が PNG より重くなることすらあります。ベクターにする意味は「軽くて拡大に強い」ことなので、重くなったら本末転倒です。

なので各プリセットの色数は「用途として十分な最小値」に寄せています。ロゴが 8 色なのは、ほとんどのロゴが実際には数色で描かれているからで、それ以上は誤差を拾うだけです。

#白黒線画の閾値

線画プリセット(2 色)は塗り絵やステンシル用途を想定していますが、元画像のコントラストが低いと、線がかすれたり潰れたりします。ここは前処理だけでは吸収しきれず、「元画像のコントラストが高いほどきれいに出る」ことを案内に添えるにとどめました。何でも自動で完璧にはならない、という正直さは残すことにしています。


#🔭 今後の拡張

  • 元画像のプレビュー比較 — トレース前後を並べて、色数スライダーでリアルタイムに変化を見る
  • パス数・サイズの内訳表示 — どの色がパスを増やしているかを見せる
  • 背景の自動透過 — 白背景を検出して透明にする(ロゴ用途で需要が大きい)
  • 単色化オプション — 抽出した形を任意の 1 色で塗り直す(アイコンのシルエット化)

#💡 このサービスから言えること

ライブラリの難しさは、プリセットで隠せる。 imagetracerjs は生で触ると調整項目が多くて挫折するライブラリですが、用途ごとに効く値を固めてしまえば、ユーザーは「ロゴ」「写真」と選ぶだけで済みます。パラメータを全部見せるのが親切とは限らない——むしろ、良い初期値を用意して選択肢を絞るほうが使われる、というのは他のサービスにも通じる学びでした。

もうひとつは前処理の効きです。トレードオフの核心(色数とファイルサイズ、ぼかしと質)がどこにあるかを掴むと、パラメータの意味が腑に落ちます。変換処理の質は、変換本体より前後の下ごしらえで決まることが多い。 画像を扱うサービスを作るたびに、この感覚は強くなっています。

そして、ロゴのような「その人にとって大事な画像」を扱う以上、ブラウザ内で完結して外に送らないという設計は、機能ではなく信頼の前提です。変換したい画像を他人のサーバーに渡さなくていい、というだけで選ぶ理由になる場面は確かにあります。

[ ./next_action ]

読んだら、 VecTrace を実際に動かす。

この開発ログは VecTrace をどう作ったかの記録です。 読み終わったらそのままサービス本体へ戻って、 実物で価値を確かめてください。

[ ./related_logs ]

関連する開発ログ

all logs →
ShadowTwin

立体パズルの別解を作る:同じ影と最少の積み木

ShadowTwinの開発記録。3方向の図から別々の最少配置を2つ探す仕組み、5問の独立全探索、スマホの横並び比較、保存・再編集と入力検査を解説します。実照明の計算や能力診断ではありません。

read log →
SlitCard

スリットアニメーションを作る:4コマの合成と透明原稿の設計

SlitCardの開発記録。4コマの帯を交互に合成し、すき間と黒帯で別のコマを見せる仕組みを解説。同縮尺の台紙・透明シートSVG、50mm確認線、手動プレビュー・初期非表示、再編集と実出力検査を整理します。

read log →
WindowLight

日当たりシミュレーションを作る:窓の光を床へ投影する幾何モデル

WindowLightの開発記録。太陽位置近似から窓の4隅を床へ投影し、凸多角形を部屋で切り取る設計を解説。国立天文台の16時刻との限定照合、大気差・低高度・実際の採光との違い、SVGと設定の再編集を整理します。

read log →
GridLights

電源構成の比較を作る:割合と実量を100個の電球で読み解く

電源構成比較GridLightsの開発記録。12か国の年次発電データを最大剰余法で100個の電球に変換し、割合とTWhを比較する設計を解説。欠損を0補完しない7分類、予想と実値、出典付きSVGと実データ検証を整理します。

read log →
SoundLoom

音のお絵かきを作る:実WAVから絵を測り直す設計

音のお絵かきの開発記録。描画を正弦波のPCMとWAVへ変換し、保存音声の周波数をGoertzel法で測って比較する仕組みを解説。音量・測定窓・量子化の限界と、編集・離脱時の古い結果を抑止する検証を整理します。

read log →
MazeLoom

宝探し迷路を作る:寄り道まで含めた最短ルートの探索

宝探し迷路の開発記録。通路を木として生成し、現在地と3つの宝の取得状態を組み合わせて最短ルートを探す仕組みを解説。問題コードの版固定、画面と解答付きPDFの一致、手数と印刷の検証を整理します。

read log →