【ITニュース解説】My filter preview looked perfect. The export had seams.

ブラウザ上で動作する画像編集ツールを使っていると、プレビュー画面では完璧に見えていたのに、いざ画像をエクスポートしてファイルを開いてみると、薄い縦の線（シーム、つまり継ぎ目）が入っていたり、色調がわずかにずれていたりする現象に遭遇することがある。これはツールの不具合のように思えるかもしれないが、実はブラウザが画像を処理する上で避けては通れない、技術的な制約と工夫の結果として生じるものだ。

デスクトップで動く画像編集ソフトウェアと異なり、ブラウザ内で動作するアプリケーションには「メモリ」という厳しい限界がある。オンラインのデザインツールでは、例えば一辺が8192ピクセル（約4800万ピクセルに相当）にもなる巨大な画像を、何枚ものレイヤーに分けて編集できるものもある。これら全てのレイヤーを元の解像度でメモリに保持したまま、ユーザーがスライダーを動かすたびにリアルタイムで処理しようとすると、ブラウザのタブはあっという間に固まってしまうだろう。

そこで、ブラウザベースのツールでは賢い工夫がされている。ユーザーが操作するプレビュー画面は、意図的に元の画像よりも低い解像度で描画されているのだ。これは「ダウンサンプリング」と呼ばれ、画面に表示するのに十分な解像度まで画像を縮小することで、使用するメモリ量を大幅に削減し、軽快な動作を実現している。ユーザーがフィルターを調整するなどの操作を行うと、その処理はこのダウンサンプリングされたデータに対して実行される。画面サイズで見ている限り、低解像度で処理された結果と、本来のフル解像度で処理された結果は見た目にはほとんど変わらないため、プレビューは速く、正確に見えるわけだ。

しかし、いざ「エクスポート」の指示を出すと、話は変わる。ツールはプレビュー用の低解像度データを捨て、オリジナルのフル解像度の画像データに対して、改めてフィルター処理を最初から実行する。このとき、プレビュー時とは異なるピクセルグリッド（画素の並び方）やサンプリング方法が使われるため、プレビューでは隠れていた、フル解像度でしか現れないようなわずかな不整合が表面化する可能性がある。これが、プレビューとエクスポートで結果が食い違う原因の一つとなる。

特に厄介なのが「シーム」、つまり継ぎ目の問題だ。フル解像度で4800万ピクセルもの画像全体にフィルター処理を一度に行おうとすると、ブラウザが一度に割り当てられるメモリの上限を超えてしまう場合がある。このため、高解像度のフィルター処理では、画像をいくつかの水平な「帯（ストリップ）」に分割し、それぞれの帯を順番に処理しては元の画像に戻す、という方法が取られる。

問題は、この帯を完全に独立して処理してしまうことにある。もしフィルターが、画像をぼかす「ブラー」やシャープにする「シャープネス」のように、隣接するピクセル（画素）の情報を参照して計算するタイプ（これを「畳み込みカーネル」と呼ぶ）だった場合、帯の境界部分では、隣の帯にあるはずのピクセル情報を読み取ることができない。結果として、帯の片側と反対側で、境界線上のピクセルが異なる情報源に基づいて計算されてしまい、わずかながら色のズレや不連続な変化が生じる。これが、エクスポートされた画像に現れる薄い「継ぎ目」の正体だ。

このシーム問題を解決するには、「オーバーラップ（重複）」という工夫が必要になる。具体的には、各帯を処理する際に、隣接する帯との共有部分を少し広げて（マージンを設けて）処理する。このマージンを含めてフィルター処理を行うことで、フィルターは境界部分のピクセルを計算する際にも、常に十分な周辺ピクセル情報を参照できるようになる。処理が完了したら、余分なマージン部分を切り落としてから、各帯を元の位置につなぎ合わせる。こうすることで、境界線上のピクセルは両側から同じ周辺環境に基づいて計算されるため、色のズレがなくなり、継ぎ目は見事に消える。プレビュー処理では、そもそも画像全体が単一のメモリバッファに収まるサイズだったため、帯に分割する必要がなく、このシーム問題は発生しなかったわけだ。

もしこの現象を自分で確認したい場合は、簡単な手順で再現できる。まず、実際にエクスポートしたいサイズ（例えば巨大なピクセル数）で新しいキャンバスを作成する。次に、そこに画像を読み込むか、フィルターを適用する。そしてPNGやWebP形式でエクスポートし、そのファイルを画像ビューアなどで100%や、さらに拡大して400%で開いてみる。プレビュー画面はあくまで「代理」であり、エクスポートされたファイルこそが「真実」である。もし両者に違いがあれば、それは解像度や画像の結合に関する問題であり、色の問題ではないことを示している。

ちなみに、このような技術的な問題を解決する際に非常に役立つのが「非破壊編集」という機能だ。これは、フィルターの適用がピクセルの色を直接変更するのではなく、単に「こんなフィルターを適用する」というパラメータとして保存される仕組みを指す。元の画像データは一切変更されないため、フィルターの設定を何度でも調整し直し、そのたびにエクスポートして結果を比較することができる。もし元のピクセルが直接書き換えられてしまう方式だったら、少し設定を変えるたびに画像を再読み込みする必要があり、問題の特定に膨大な時間がかかっていただろう。

この経験から得られる教訓は、一見地味だが非常に重要だ。ブラウザで動く画像編集ツールを評価する際には、そのプレビュー画面の見た目だけで判断してはいけない。必ずフルズームでエクスポートした結果を確認するべきである。プレビューはあくまで高速な動作と、画面上で正しく見えることに最適化されている。画像のバンディング（色調の段階的な変化）や継ぎ目、わずかなぼやけといった、フル解像度でしか表面化しない問題は、プレビューとエクスポートの間のギャップに潜んでいる。そして、そのギャップを埋めることこそが、実際のシステムエンジニアリングの腕の見せ所なのだ。