正確なテキストと数字のために「下描き」を使う

 (samcollins.blog)
1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • underdrawing は、数字やテキストの位置を含む下描き画像をまず決定論的なツールで作成し、その上から画像生成モデルが視覚的スタイルを施すことで精度を高める方法
  • 50個の飛び石をらせん状に配置し、1から50まで番号を付ける課題では、Gemini 3 Pro と ChatGPT Images 2 は underdrawing なしでは数字と順序を安定して正しく合わせられなかった
  • 同じ課題に underdrawing を併用した Gemini 3.0 Pro は、番号、ボタンの個数と順序、らせん形状が正しい結果を作れた
  • 実装は、SVG/HTML などのツールで数字やテキストを望む位置と向きに配置して画像として書き出し、その画像とテキストプロンプトをマルチモーダル画像モデルに一緒に入力する形で可能
  • この方法は毎回完璧というわけではないが、テキストや数字の配置が重要な画像生成において、決定論的な配置と生成モデルの視覚表現能力を分担して使えるようにする

核心的な文脈と実装方法

  • 100段階のアドベンチャーボード画像を作ろうとする過程で出てきたパターンで、「輪郭を与えてその上に塗らせる」という方法として整理されている

  • 決定論的レイヤー

    • SVG/HTML は視覚的には無機質だが、数学的な配置と精密さに強い
    • 数字やテキストを望む位置と向きに合わせて配置し、そのピクセルを含む画像として書き出せばよい
    • 形式は SVG、Python、Mermaid など、好きなツールを使える

  • 生成レイヤー

    • 画像生成モデル は視覚的に優れた結果を作れるが、数学やテキストについては信頼性が低い
    • Gemini 3.0 Pro のように画像とテキストを入力として受け取り、画像を出力できるマルチモーダル画像モデルに underdrawing 画像とテキストプロンプトを一緒に入力する
    • 例のステップ1のプロンプトでは、50個の飛び石を反時計回りの内向きらせんに配置し、各石に1から50まで連番を入れた SVG を作らせる
    • 例のステップ2のプロンプトでは、その画像を、職人製チョコレートとキャンディがらせん状の道として置かれた、低いアングルでわずかに傾いた写真風のクレイメーション・ジオラマに変換させる

  • 自動化と限界

    • Claude Code や Codex で各ステップを代行できる
    • 結果は良いが毎回完璧ではなく、最終成果物でも「71」は見えない

関連記事

1件のコメント

 
GN⁺ 2 시간 전
Hacker Newsの意見

  • LLMが本質的に得意なことと苦手なこと、つまり不可能という意味ではないが、根本的な制約のため成功可能性が低い仕事について、より深く理解していこうという流れは歓迎したい。
    ソフトウェアアーキテクチャは人が決め、関数の実装はLLMに任せるやり方や、データ分析そのものをさせるのではなくSQLクエリを書かせるやり方に近い。
    どんな作業単位がLLMに向いていて、どんなものが向いていないのかについて、より明確な作業分類体系と研究があればよいと思う。直感は少しずつ育ってきているが、まだここでよくつまずく人を多く見る。

    • 「アーキテクチャは人が決めて、関数はLLMに書かせる」というやり方は、少し前まではLLMコーディング支援ツールの初期ユーザーが推奨していた使い方だった。
      まずアウトラインを作らせて、各関数を別々に実装させるという形で、アニメーション作業から借りた用語でこのアプローチを紹介するブログ記事もHNに何度か上がっていた。
    • LLMに関して根本的な制約という表現はよく出てくるが、そのような制約が存在するという厳密な証明はまだ一つもない。
      2年前には文字数カウントや音韻処理のように、「根本的制約」のため不可能だと言われていた作業も、今ではツールなしでも大きな問題ではないことが多い。

  • 画像生成のプロンプトを読むたびに、モデルが明らかに無視した非常に具体的なディテールが見える。
    ここでも最後の2枚の画像のチョコレート／キャンディは職人の手作り感とは程遠く、あまりに無菌的な大量生産品のように見え、視点も正確ではない。
    モデルが大半を無視するなら、なぜこんなに冗長なプロンプトを書くのか疑問だ。

    • 「スタジオ照明」を頼んだら、写真の中にスタジオ照明機材を大量に入れてしまった例が気に入った。
    • キャンディは実際に職人の手作りっぽく見せようとしているのではなく、訓練データの中で企業がartisanalとして宣伝しラベル付けした画像に合わせようとしているのだろう。
      rustic、homemade、amateurのような表現の方がタグ付けには合っているかもしれない。
    • 画像生成を何度か使ってみたときも、まさにこういう部分で繰り返し失敗した。
      最初は自分のプロンプト作成能力不足だと思っていたが、こうした不一致を意識して見るようになるとかなり頻繁に現れる。
    • 詳細なプロンプトの大半はAIが生成したものだと思う。
    • これを全部思いつくのにどれくらいかかったのか気になる。
      最後のような小さな「ボタン」がらせん状に並んだ画像を欲しかったのなら、キャンディには見えないとしても、Blenderがあまり得意でない人でも半日あれば作れた気がする。

  • AI生成画像でテキストと数字を安定して得るための簡単な手法を見つけた。
    画像モデルが最初からこうしていないのが意外なくらいで、かなり便利に使っているので共有したかった。

    • ある意味ではControlNetの利用に近い。
      SVGだけをベース画像として使う同じ手法をしばらく使ってきたが、うまく機能している。
    • とても印象的で、シンプルかつ安定している。
      画像生成の研究所もすぐ取り入れそうだ。
    • これは一種の思考の連鎖(chain of thought)、つまり https://arxiv.org/abs/2201.11903 に近いのではないかと思う。
      ユーザーがモデルに0-shotで解かせる代わりに、1-shotまたはk-shotで解決策を助ける構造だ。
      似た手法を非常に効果的に使ったことがあり、この分野はあまりに新しく動きも速いため、共通用語がまだ不足している感じがあるので、ブログと例はとても有用だ。
      ただし、この現象はすでにもっと小さなコミュニティや別の名前で観察・理解されている可能性もありそうだ。
    • 要するに、まずSVGで正しい輪郭を作り、その画像をテキストプロンプトと一緒にGemini 3.0 Proへ送り、正確な数字とテキストが入るようレンダリングさせる方式だ。

  • これは正しい構造を持つ最初の画像をコードで作ったimg2imgにすぎない。

    • その通り、まさにその方法だ。
      Stable Diffusion初期から生成モデルを使っていたなら、かなり一般的で有用な手法で、スケッチ（SVG、手描きなど）を仮のControlNetのように使って生成モデルの出力を誘導するものだ。
      昔は建築ビジュアライゼーションの配置で似たようなアプローチを使っていた。
      ソファや椅子、その他の家具を特定の位置に置きたければ、Poserのようなツールで主要な「セットピース」の位置を大まかに決めた単純なシーンを作り、そこから深度マップを生成して、当時のSDXLのような生成モデルに入力し、オブジェクト配置を誘導できた。
    • おおむね著者の言う通りで、初心者向けに少し文脈を補っただけに近い。
    • そうだが、そのコードを作るときに別のコード生成モデルを使うことはできる。

  • このハックは確かに「なるほど、どうして思いつかなかったんだ」と感じるタイプのコツだ。
    次に画像生成が期待外れだったときに使えるようになったのはうれしい。

    • もともとStable Diffusionのアプリにもすでにimage-to-imageはあった。
      ただ当時は今ほど性能が良くなかっただけで、これがなぜ新しいと見なされるのかはよく分からない。

  • 標準的な反論はこうだ。LLMが本当に知的なら、なぜこの2段階プロセスの方がより良い結果を出すと自分で気づけないのか？

    • 基本レベルでは、画像モデルはテキストトークンを入力として受け取り、画像トークンを出力する構造にすぎない。
      戦略を立て、結果を確認し、やり直すには、その上にエージェント型プロセスが必要だ。
      Nano Bananaやgpt-image-2にはこうしたものが少し入っているようだが、モデルにコードを一発で書かせることと、ツールを備えたエージェントハーネスに処理させることの違いに近い。
      ごく基本的なエージェントでも、ChatGPT単体より良いコードを作れることがある。
    • LLMはたいてい「画像を作る」系のプロンプトを少し整えて別モデルに渡すようハードコーディングされているからだ。
    • 知らないものは知らない。
    • 実際のところ知的ではないからだ。
    • 誰もそうしろと依頼していないからだ。

  • こういうやり方はずっと前からあり、深度マップや線画を使ってシルエットを制御するのに似ている。

  • 結論部の「動くけれど、実はそうでもない」という感じが良かった。
    LLM／生成AIブームらしく、ごく狭い一つの例を当てるために複雑な努力を費やしたが、ほとんどできそうで結局きちんとはできていない、ということを記事全体で示している。

    • 一部でも動けば有用だ。
      人間が数字が合っているか確認するのは簡単だし、間違っていれば画像を再生成すればいい。
      モデルなしで最初から画像を作るより何桁も簡単だ。

  • よくある課題である「自転車に乗るペリカンのSVG」には、逆方向のアプローチを試せるのではないかと思った。
    SVGをそのまま吐かせると、当然ながら品質は低くなりがちだ。
    しかし画像生成なら見栄えの良い写実的な画像を簡単に作れるので、まず画像を生成し、それをモデルにトレースさせてSVG化すれば、まともな自転車ペリカンSVGを得る良い方法になるかもしれない。
    結局、人間だってメモ帳に数字だけ入力してSVGアート作品を作ることはまれで、要点はやはりそれを画像として見て考えることにある。

  • 人間が正確にやろうとする方法にも似ているように見える。
    アーティストに、修正やスケッチなしで大きな円形配置の石を一発で描き、順番どおりに番号まで入れろと言ったら、配置ミスが起きても不思議ではない。