メインコンテンツまでスキップ

テキストベースの画像について

· 約7分
ぐみ
ぐみ
author

テキストベースの画像をどう処理する？ からの 画像ファイルの deploy 方針まで。

更新履歴
  • 2025/11/26：「結局スケール指定が必要なんだね」追加
  • 2025/11/23：公開

ニンニクのホイル焼きから派生。

スクリプトの動作確認​

実はスクリプトの動作確認を兼ねてました。

AI との会話を固定サイズ指定した Web ブラウザ越しにスクリーンショットで撮って、固定位置で crop するスクリプトを作ったので、その動作確認も兼ねて。

これなら一節の区切りまでが画面に収まらない場合の連結でも、１つずつ載せる場合でも使い回しが効いていい感じ。

だめじゃん…​

crop の座標がズレることがあって、なんでなのか調査したら、macOS で撮るウィンドウのスクリーンショットのウィンドウ位置が変動してた （なぜか偶数回目と奇数回目で置かれる座標が異なってた、多分回数じゃない別の要因だと思うけど？）。

ウィンドウそのものじゃなくて シャドウも含めるからだと思うんだけど、よくわかりません。 油断した。

ということで、画像の扱いを根本から見直して「拡大 -> ガウス処理 -> 縮小」まで画像でやって、最後に Web ブラウザに得意な範囲で再度縮小してもらうことにしました。 to-blog-image アクションを手作りしました（image magick を使って上の処理をしつつ png から webp に変換まで、をマルチパスで）。

これで

  • 昨今の表示環境を考慮した視認し易い大きさ
  • レイアウトを気にせず
  • その時の雰囲気を残したまま
  • ツール処理せず手で crop できるようになった

はず、です。

当面は「スケーリング 200% の広い表示域」と「スケーリング 300% の狭い表示域」の２つまでを満たします。 「まで」というのは、それより上の表示環境で見ると、たぶんちょっとモヤっとするはず、という意味です。 （私にはこれよりいい表示環境が用意できないので、理論上の話です）。 それ未満の表示環境では、ちょっとジャギるはずです （画像処理で境界緩和してるので 逆にキリッとするかも？）。

BlogSwitchFitImage.tsxっていうコンポーネントを自作して「画像ファイル」「表示領域」の両方を閾値分けすることにしました。 スケーリングを合わせれば css だけで対応できますが、素材のスケーリングをいちいち気にするのが嫌になったから。 使うツールや出力の仕方で「なんでそこだけ違うの！？いつのまに…」って時々なる。

表示しきれないとわかっている場合は、素直にスクロールバーを出すことを許容することにしました。 こちらは BlogSingleFixImage.tsx っていうコンポーネントを自作して、画像から解像度取得して、解像度の表示領域を「スクロールバーが出ることを承知で」横幅設定します。 Single とあるとおり、１つの画像ファイルだけを扱います。 私の使い方固有なのですが、画像が大きすぎる場合と 画像が１つしか用意できない場合で、見せ方が同じだからです。

以前は見えないくらい縮小されていたはずなので 改善といえるけど、めんどいなって思う。 これいい！って手で切り取ってそれをぽいっとするだけでできてくれたらいいのに。 完全な答えをまだ持ち合わせていないのです。

重くなってきた​

１つ１つの画像は 100KByte 前後ですが、数が多くなってきて転送量が増えてきました。 このままでは github にも負担がかかるし、電波状況のよくない環境で deploy すると結構時間がかかるし、色々と無駄だと思ってきたので改善しようと考えました。

いくつか候補はあるのですが、最終的に行き着くところを決めちゃおう。

CDN 配信が契約も登録も料金もなく使える！ なんて気前のいい話。

raw.githubusercontent + CDNによる画像ファイルのdeploy

この方法を使うとして。 先に作った２つの React コンポーネントが img[src] として作る部分をどうするか、って話に。

これも候補はいくつかありますが、mdx を使っているので draft フロントマターを使うことにしました。

でもすでに使っているところは新たに追加するのは めっちゃめんどいので、デフォルトを false にして、値が渡ってこなかったら CDN を使うということに。 そして、これから作るときは draft フロントマターをパラメータとして渡せばいいってことにしました （true / false が渡るので後で消したりしなくてもいい）。

結局スケール指定が必要なんだね​

だめだ…

今度は文字の大きさが揃ってないことがとっても気になる！

ここがちょっと小さくて読みづらいかな？というのならいいのだけど、そうじゃなくて。 文字が大きすぎて主張してるみたいに見える ことがあるんだね。

普通の写真とかなら気にならないんだけど、テキストだからなあ。

そんなわけで、React コンポーネントに手を入れて scale 指定を個別に可能にするようにしました。

ほんとに１つ１つの画像に対してすることもできるけど、フロントマターを渡して使うことを想定してます。 これなら今後スケールが変わるときにも同じ文字の大きさを維持できるようになります。

そして github らしく履歴管理することにしました。 どーなることやら。

actions で deploy​

actions と pages の仕様が微妙に変化しててあちこちデバッグしながらなんとか deploy 完了 （artifacts も加わってた）。 この仕組みって誰得なんだろう？

ソースが github にあって、それが展開された成果だよってことが履歴に残ることが価値、ということなのかなあ。

てっきり git リポジトリを Web サイトにマッピングしてるのかと思ったらそうじゃなくて、中継で使ってるだけなんですね。 割り切ってる、多分これが最後の形なんだろうなあって思います。

調べたら artifacts deploy が今の標準でした。 透明性を評価基準としての「平らな地続きの選択肢」ではなく「壁で隔てた選択肢」にすることにしたんだね。 かつての弱点を利用するなんて、本質を見抜く洞察と学習することの重要性が表れてる。 こわー。

gh-pages ブランチで公開する方式は、いずれ削除されるか有料化するのかな。

本記事で使用しているスクリーンショットは、OpenAI の対話型 AI との実際の会話画面を記録したものが含まれます。 当サイトの情報は個人の意見であり、正確性・完全性を保証するものではありません（AI が生成した回答を含む）。