以下の整理版は、リポジトリで別途行った分析・再構成実験の結果です。現在のDrowPack Webツールがすべてのアップロードに対し、同じ60,114→28 pathの整理を自動適用したり、同一の見た目を保証したりするという意味ではありません。自動トレースの構造と限界を示す事例として公開します。
問題：SVGなのに、拡大すると輪郭が揺れていた
分析対象のartwork_vector.svgには、PNG、JPEG、WebPを格納する<image>要素がありませんでした。フィルター、マスク、クリップpathもありませんでした。つまり、ラスター画像をSVG内に埋め込んだファイルではなく、実際のpath座標だけを持つSVGです。それでも拡大すると、外側の円、髪、小さな装飾の周囲に、ピクセルの階段をなぞったような凹凸と断片が見えました。
原因は「偽のSVG」ではなく、ラスターに由来する形状でした。トレーサーはアンチエイリアスされた縁の複数の中間色を別々の領域として読み取り、ピクセル境界を細かな直線・曲線の座標で記録しました。ベクターになった後も座標そのものが粗ければ、拡大するほど粗い形がはっきり見えます。
元ファイルから直接数えた値
60,114個のうち53,039個は小さなトレース断片で、そのうち暗い輪郭・ノイズ断片とみなせる小さなdark pathは20,118個でした。色の帯は28個でしたが、各帯の中に非常に多くの小断片が分散していました。半ピクセル座標が523,692個あることも、元のピクセルグリッドを細かく追った痕跡と一致します。
| ファイル | サイズ | path要素 | 埋め込みラスター | 意味 |
|---|---|---|---|---|
artwork_vector.svg | 10.63MB | 60,114 | 0 | 自動トレース元ファイル |
clean_redraw.svg | 1.26MB | 28 | 0 | 細部を多く残した自動整理版 |
clean_web.svg | 666.5KB | 28 | 0 | Web表示用に強く単純化 |
clean_flat.svg | 437.9KB | 14 | 0 | 色数と小さなディテールをさらに削減 |
28個のpath要素は28個の図形を意味しない
ブラウザーのDOMで数える<path>要素と、pathデータ内に記録された実際の図形数は異なります。下表のMは、新しいsubpathを開始する移動コマンドです。同じスタイルの断片を1つの複合pathにまとめると、DOM要素数は大きく減っても、内部の座標とsubpathは残ることがあります。
| 段階 | 正確なバイト数 | 元ファイル比 | DOM path | M subpath | 元レンダーとの比較 |
|---|---|---|---|---|---|
| 元ファイル | 11,148,983 | 基準 | 60,114 | 62,588 | 基準 |
| 無損失の構造整理 | 6,093,154 | -45.35% | 60,114 | 62,588 | ピクセル単位で同一 |
| 複合pathへの統合 | 5,131,778 | -53.97% | 28 | 62,588 | MAE 0.0356/255、差 >10のピクセル 0.0002% |
| 実験的スムージング | 5,233,587 | -53.06% | 28 | 62,588 | MAE 0.1059/255、差 >10のピクセル 0.1570% |
複合path版のDOM要素は28個だけですが、元ファイルと同じM 62,588個、L 197,516個、Q 105,892個を保持しています。この段階で主に減ったのは、繰り返しタグとDOMノードであり、元の座標の複雑さそのものではありません。
すべての比較PNGは、同じローカルChrome環境で1067×1600としてレンダリングしました。MAEは元画像に対するRGBチャンネルの平均絶対誤差です。「差 >10」は、RGBのいずれか1チャンネルでも10を超えて異なったピクセルの割合です。この実験で測定したのはSVGの生ファイル構造とレンダリング後のピクセル差だけです。ネットワーク転送、解析時間、CPU、メモリー、読み込み速度は測定していないため、ファイルが小さくなったことだけから高速化を主張することはできません。
レンダリング前後を比較
左は自動トレース元ファイルをレンダリングした基準画像、右は別の整理パイプラインによるclean_redraw.svgのレンダーです。整理版では大きな色面と輪郭をまとめ、小断片を減らしていますが、すべての細部を同じように保つ無損失の結果ではありません。
視覚情報は豊富ですが、小さな境界断片と階段状の座標がSVG構造内に大量に残っています。
大きな色面は単純になりましたが、髪、衣装、枠の小さな質感や曲線の一部が変わっています。
全体を縮小した画面だけでは、両方とも似て見える場合があります。円形の枠、髪の青いハイライト、ドレスのひだ、本の細い線を拡大し、「ノイズの減少」と「意図されたディテールの損失」を同時に確認してください。
自動整理の実験で行ったこと
- 元SVGを2倍の解像度でレンダリングしました。既存pathをそのまま単純化するのではなく、見た目の基準を作り直しました。
- ダウンサンプリングと弱いぼかしを適用しました。ピクセル単位の階段と、非常に小さな色の断片を減らす準備をしました。
- 元画像系統の限られたパレットへ量子化しました。似た中間色が際限なく分割されるのを抑えました。
- 多数決フィルターと小さな連結成分の除去を適用しました。孤立した点、halo、小さな輪郭断片を結合または削除しました。
- 外周につながる白い背景を、きれいな長方形へ置き換えました。内部の白いハイライトと外部背景を区別しようとしました。
- 色領域のcontourを再検出しました。座標を単純化し、滑らかなcubic Bézier pathへ変換しました。
整理版もPNGを埋め込まないpathベースのSVGです。ただし、「元pathのすべての点を保持」する方式ではなく、レンダリングされた視覚情報を基に色領域を再構成したため、小さなディテールがまとまったり変わったりすることがあります。
改善したことと失ったこと
| 観察項目 | 改善の可能性 | 伴うリスク |
|---|---|---|
| DOM/pathの複雑度 | 60,114要素を28個の複合pathへ削減 | 1つのpath内にある複数のloopは、依然として編集が複雑な場合がある |
| ファイルサイズ | 10.63MBから1.26MBまたは666.5KBへ | 細部とパレットを減らすほど元画像との差が大きくなる |
| 輪郭ノイズ | 小さな点や階段状の断片が減少 | 繊細なまつ毛やハイライトまで弱くなる場合がある |
| 背景 | 外周につながる白い領域を整理 | 内部の白と背景の判定を誤ると穴が生じる |
| 曲線 | contourの単純化とBézier fitting | 作者が意図した正確な曲線は推測できない |
この事例から得た実用的な結論
- SVG内にラスターがなくても、自動的にきれいなベクターになるわけではない
- path数が多いことは、情報量またはノイズが多いことを示す場合があり、品質スコアではない
- 構造だけをまとめる無損失最適化はファイルを小さくできても、粗い座標そのものは直せない
- 自動スムージングは輪郭を和らげるが、小さな形や作者の意図を変えることがある
- Web表示、編集、業務納品では、それぞれ別の合格基準を使うべきである
- 正確な業務用ベクターが必要なら、高解像度・レイヤー付きの元データ、または手作業のベジェ再作成が最も確実である
Web表示だけが目的なら、clean_web.svgのように強く整理した結果が実用的なことがあります。色面を再編集するなら細部を多く残した整理版の方が向いていますが、自動再構成された図形という限界は残ります。商標、大判印刷、精密カッティングには手作業での確認が必要です。