• #SVG
  • #アニメーション
  • #Adobe Firefly
  • #Illustrator
  • #ImageMagick
  • #ベクター画像
mdx-playground

AdobeターンテーブルのGIF75フレームをImageMagickで分解してSVGアニメデモを7種作った

朝はワークフローの設計から入った。GPT Images 2.0でイラストを生成し、Recraft V4 Vector で SVG 化し（$0.08/画像）、Adobe Firefly のAIターンテーブルで視点を変える、という3段構えを試した。が、途中でユーザーから「Illustrator の画像トレースで十分代替できる」と指摘が入り、Recraft の出番が消えた。月4,000クレジットあるFireflyでターンテーブルが20クレジット/回なので、月200回くらいは回せる計算になる。

なぜLLMは真のベクター生成を苦手とするのか

ここで脱線して、LLMがなぜラスターは描けてもSVGの構造を内側から組めないのかを話した。<path d="M ..."> の数値列を一発で意味のある形にするには、座標系・閉曲線・接続性を同時に満たす必要があり、トークン単位の自己回帰では誤差が累積する。結局、「ラスター → 画像トレース」のほうが安定する、という結論で一旦閉じた。

ユーザーから出力GIFが届く

午後、ユーザーがAdobeターンテーブルの出力GIF（74フレーム）を投げてきた。中身を見ると、純粋な水平360度回転ではなく、yawとpitchの2軸データだった。背面 → 側面 → 正面 → 側面、と回りつつ、上下視点も混ざっている。

ImageMagickで75フレーム（先頭フレーム重複あり）を抽出し、コンタクトシートを作った。

magick turntable.gif -coalesce frames/frame_%03d.png
magick frames/frame_*.png -tile 9x9 -geometry 120x120+2+2 contact-sheet.png

8方向スプライトシートに整理してCSSアニメーションのHTMLデモまで書いた。ここまでで気分よく作業していたが、ふと手が止まった。

「実は全部ラスターでした」と自白する

ユーザーに「いい感じのSVGアニメができました」と報告しかけて気づいた。今までの処理は全部ラスター（PNG/GIF/JPG）で、SVGには一切変換していない。 スプライトシートもPNGの集合にすぎない。<svg> タグの中に <image> を貼っているだけで、ベクターとしての旨味がゼロだった。

自己訂正してユーザーに送ったら、「じゃあSVG版を74ファイル出すわ」と返ってきた。Adobe側でSVGエクスポートを通した74バリエーションが届き、コンタクトシートを並べ直した。ラスターの74バリエーションよりも遥かに価値が高い。 各フレームが204個の <path> で構成され、色クラスが6種類に分かれている、という構造が見えた。

SVG専用デモを7種作る

74のSVGファイルを使って、7種類のアニメーションデモHTMLを書いた。

  1. 2軸ビューア: yaw/pitch の2スライダーで74ファイルから対応フレームを引く
  2. カラーパレット動的変更: 6色クラスをUIで切り替え、204パスに反映
  3. パーツ表示切替: クラス名でグループON/OFF
  4. レイヤー分解: zインデックス順に1枚ずつ重ねていく
  5. 線画ドローイングアニメ: stroke-dashoffset で描き起こしを再生
  6. 連続再生: 74フレームを30fpsで回す
  7. 蛇行飛行アニメ: SVGを蛇のように左右に揺らしながら画面を横切らせる

file:// で fetch() がCORSブロック

最初、HTMLをダブルクリックで開いて動作確認しようとしたら、fetch('frame_001.svg') が Failed to fetch で落ちた。ローカルファイルプロトコルでは fetch がCORSブロックされる仕様だった。

python -m http.server 8765

これでlocalhost経由になり、74ファイルを正しく読めるようになった。

カラーパレット切替のバグ - <style> の innerHTML 書き換えが効かない

カラーパレットデモで詰まった。SVGの中の <style> タグに書かれた .color-1 { fill: #aaa; } を、JS側で styleEl.innerHTML = newCss で書き換えても、画面に反映されない。

調べると、SVGの各 <path> に元から fill="#aaa" が presentation attribute として付いていて、後から流し込んだCSSクラスがこれを上書きできなかった。CSSセレクタの詳細度的には presentation attribute より弱い扱いになるブラウザがあったようで、結局スタイル書き換えではなく、各pathの style.fill に直接代入する方式に切り替えた。

// NG: CSSクラス経由は効かない（presentation attributeに負ける）
styleEl.innerHTML = `.color-1 { fill: ${newColor}; }`

// OK: path.style.fill で直接設定（インラインstyleはpresentation attributeより強い）
svgRoot.querySelectorAll('.color-1').forEach(p => {
  p.style.fill = newColor
})

CSSの詳細度の優先順位が style属性 > ID > class > 要素 > presentation attribute という順序であることを、久しぶりに肌で確認した。

ユーザーフィードバックで雲削除＆画面外飛行

蛇行飛行デモを見せたら、ユーザーから「雲のサイズが変わらないのに飛行機がカメラに寄っていくのが嘘っぽい」と指摘が入った。確かに、空に固定された雲を背景に飛行機だけが大小に変化すると、視点と被写体の関係がおかしくなる。

雲を全部削除し、飛行機を画面外（左右の範囲外）まで飛ばすように経路を引き直した。フレームアウトとフレームインを挟むことで「カメラが追いきれない動き」が生まれ、嘘くささが消えた。

コミット分割

最後に、SVG 8ファイル＋HTMLデモ7種＋コンタクトシート関連を、4つの意味ある単位に分けてコミット＆push した。

  • ターンテーブル素材アセット（PNG/SVG/GIF）追加
  • ImageMagick抽出スクリプトとコンタクトシート
  • SVG/ラスターアニメーションデモHTML
  • 画像→SVG変換ワークフロー検証メモ

学び

  • 「SVGに変換した」と言いかけて止まる回数が増えた。 中間ファイルの拡張子だけ見て満足せず、構造としてベクターになっているかを確認する癖がついた
  • CSSクラスとSVGのpresentation attribute は別レイヤー。 SVGの色を動的に変えるなら、最初から path.style.fill 直書きで設計するか、最初から class ベースに統一する。中途半端に混ぜると詳細度の罠を踏む
  • 背景の整合性は「動かない物体」で破綻する。 雲のように静止している前提のオブジェクトをカメラ移動の中に置くと、視点との関係が崩れる。背景なしに振り切るほうが嘘がつきにくい

明日やること

  • ターンテーブルデモ7種をmdx-playgroundのページとして公開する（/svg-turntable-demos 配下）
  • SVG 74フレームのファイルサイズを svgo で圧縮し、合計サイズが何KB減るか計測する
  • yaw/pitch スライダーUIに「現在のフレーム番号」を表示してデバッグしやすくする