16ビット深度マップ：バンディングの直し方とPNGの確認方法

最終更新日：2026年9月13日。以下のエンコード測定は合成グラデーションによるもので、AIによる深度推定の精度を比較するベンチマークではありません。

ブラウザでは滑らかに見える深度マップなのに、ディスプレイスメントをかけると表面に段々畑のような段差が出る。「16ビットPNG」で書き出しても何も変わらない。そんなときは、別の画像を生成したりメッシュを細かくしたりする前に、どの工程で値が階段状になったのかを確認してください。拡張子だけでは、その答えはわかりません。

結論：深度マップのバンディングを防ぐには？

次に使うアプリケーションが対応していれば、モデルが出力した浮動小数点の深度値から直接書き出した16ビットのグレースケールPNGを使います。8ビットのプレビュー、スクリーンショット、JPEG、写真用の圧縮ツールは経由させないでください。そのうえで、ディスプレイスメントを試す前に、ファイルのサンプル深度、値の範囲、異なる値の数を確認します。

16ビットの入れ物に移しても、失われた精度は戻りません。再現可能な実験では、16ビットで直接エンコードしたグラデーションは4,096種類の値を保っていましたが、8ビットのグラデーションを16ビットで保存し直したものは256種類しかありませんでした。しかも両方の16ビットファイルは、同じサンプル深度と0〜65,535の全範囲を示していました。

この手順で直せること、直せないこと

この手順が扱うのは、書き出し時の精度と、読み込み時によくあるミスです。AIによる相対的な深度を実測距離に変えること、隠れた形状を明らかにすること、誤ったシルエットを修正すること、加工に使えるレリーフを保証することはできません。シーンの深度推定と、彫刻用に作られた高さデータは目的が異なります。

基本的な考え方は深度マップの入門記事を参照してください。実際に書き出す場合、深度マップジェネレーターは初期設定で16ビットのグレースケールPNGを出力し、白が近い側か遠い側かを表示し、反転オプションも備えています。

AIによる処理では、最後のエンコード直前まで浮動小数点の値を保持します。一方、エッジとぼかしによる代替処理を使ったという警告が表示された場合、その処理は8ビットの値から始まるため、16ビットPNGでも最大256階調しか含まれません。

8ビット、16ビット、浮動小数点のどれを選ぶべき？

PNGのサンプル深度はチャンネルごとの値で、全チャンネルを合計したものではありません。「32ビット」のRGBA PNGは4つのチャンネルそれぞれに8ビットを持つため、同じグレー値を全チャンネルに入れても256階調のままです。W3CのPNG仕様では、グレースケールのサンプル深度として1、2、4、8、16ビットが定められており、PNGには浮動小数点のサンプル形式がありません。

この図が示すのはエンコードで表現できる階調数であり、モデルの精度や、すべての画像が持つべき値の数ではありません。平らな面なら値が1種類でも正常です。また、ファイルサイズが大きいことは、推定が優れている証拠にはなりません。

8ビットと16ビットの実験では何を測定した？

4,096×64ピクセルの横方向グラデーションを作り、0から1までを等間隔に4,096段階で並べました。これをNumPyとPillowで3通りにエンコードし、各PNGを開き直して、ヘッダー、異なる値の数、値の範囲、元のグラデーションに対する最大正規化誤差を測定しました。

3つ目の経路では、8ビットの各整数に257を掛けています。これで0は0に、255は65,535に対応するので、範囲は正しく見えます。それでも、最初の変換で失われた中間の値は再現できません。「16ビット」という表示や最も明るいピクセルだけを確認しても、重要な不具合を見逃すのはこのためです。

これらのファイルは同じ行の繰り返しで非常に圧縮しやすく、極端に小さくなっています。このバイト数から写真のファイルサイズは予測できません。この実験で切り分けたのは量子化だけです。深度モデルの比較、Blenderでのレンダリング検証、実際の彫刻品質の測定は行っていません。このページのWebP画像は説明用の図であり、精度を保ったダウンロード用マップではありません。

3つのファイルを再現するには、Python環境にNumPyとPillowをインストールし、次のコードを実行します。

import numpy as np
from PIL import Image

ramp = np.tile(np.linspace(0, 1, 4096), (64, 1))
a8 = np.rint(ramp * 255).astype(np.uint8)
a16 = np.rint(ramp * 65535).astype(np.uint16)
wrapped = a8.astype(np.uint16) * 257
for name, values in [("ramp-8", a8), ("ramp-16", a16),
                     ("ramp-8-in-16", wrapped)]:
    Image.fromarray(values).save(name + ".png")

ダウンロードしたPNGはどう検査する？

別のアプリケーションで保存し直す前に、ダウンロードしたままのファイルに対して実行してください。実験と同じPythonパッケージを使い、1チャンネルのPNGを前提としています。RGBのプレビュー画像を渡すと、それを黙って変換して深度データのように見せるのではなく、意図的に停止します。

from pathlib import Path
import numpy as np
from PIL import Image

path = Path("depth.png")
raw = path.read_bytes()
assert raw[:8] == b"\x89PNG\r\n\x1a\n"
assert raw[12:16] == b"IHDR"
print("PNG sample depth:", raw[24])
print("PNG color type:", raw[25])  # 0 = grayscale
values = np.asarray(Image.open(path))
assert values.ndim == 2, "Inspect the grayscale export, not an RGB preview"
print("Range:", int(values.min()), int(values.max()))
print("Distinct values:", np.unique(values).size)

• カラー表示のプレビューではなく、グレースケールのダウンロードファイルであることを確認します。
• 16ビットで書き出した場合は、サンプル深度が16になっているはずです。
• 値の範囲が、使うパイプラインに合っているか確認します。
• 異なる値の数は内容に照らして判断します。全画像に共通の合格ラインはありません。
• 想定外の平坦部が見つけやすい、なだらかな斜面を確認します。
• 精度が落ちる可能性のある変換をしたら、そのたびに検査し直します。

細部が多そうなのに値が256種類しかない画像は調べる価値がありますが、それは手がかりであって断定ではありません。意図的に平らにしたマスクなら、値が少なくても問題ありません。逆に、補間によって8ビットの元データから何千もの値が生まれても、元の推定値が戻るわけではありません。ファイルを検査しても、処理の履歴をすべて証明することはできません。

ほぼ真っ黒に見えるプレビューにも解釈が必要です。狭い数値範囲に保存された生の深度は、それを読み込む側のソフトウェアにとっては正しいデータかもしれません。次のツールが正規化された深度を前提とする場合にだけコピーを正規化し、元のファイルとスケール情報は残してください。画像サイズや形式の基本的な確認については、画像サイズの確認ガイドで、通常のファイル情報からわかることとわからないことを解説しています。

問題のないファイルがBlenderでおかしく見えるのはなぜ？

深度マップは数値データとして扱います。Image Textureノードでは色空間をNon-Colorに設定し、表示用の色変換がかからないようにします。画像を適切な高さ（Height）またはディスプレイスメントの入力につなぎ、マテリアルのディスプレイスメント方式を確認し、実際に形状を動かすのに十分なジオメトリがメッシュにあるかを確かめてください。

Blenderのディスプレイスメントに関するドキュメントでは、陰影だけを変えるバンプマッピングと、表面そのものを動かすため細かく分割されたジオメトリが必要になる本来のディスプレイスメントを区別しています。バンプではシルエットは変わりません。メニューの位置はバージョンによって異なるため、お使いのバージョンに対応したドキュメントに従ってください。

テスト中はディスプレイスメントのスケールを控えめにします。細部を増やす前に、Midlevel、UVマッピング、切り抜き、縦横比を確認してください。すべての設定を同時に変えると、どの工程が原因だったのか特定しにくくなります。

書き出しから読み込みまでの確実なチェックリスト

書き出す前に：

1. 元の写真と、ダウンロードしたままの深度マップを一緒に保管します。
2. 手前と背景がはっきり分かれた画像を選びます。
3. 書き出し形式を決める前に、物体の境界を確認します。
4. 対応するワークフローでは、16ビットのグレースケールPNGを直接書き出します。
5. この書き出しで明るい画素が近い側か遠い側かを記録します。

ダウンロードした後に：

6. 保存したファイルのヘッダー、範囲、異なる値の数を確認します。
7. データとして読み込み、位置のわかっている点で向きを確かめます。
8. 本番レンダリングの前に、適切なジオメトリで小さな範囲を試します。
9. 互換性のための変換をする前に、高精度のマスターを残します。
10. うまくいった設定を保存し、以後の書き出しと比べられるようにします。

深度マップのマスターを、ふだんの画像圧縮の手順に通さないでください。表示用に軽くした画像と、信頼できる数値データでは求められる条件が違います。同様に、汎用のAIアップスケーラーはテクスチャを作り出すことがあり、それが高さとして解釈されると不要な凹凸になります。

レリーフや彫刻用のアプリケーションで使う場合は、そのアプリケーションのサンプル処理とグレースケールの向きを、ドキュメントで別途確認してください。この記事では加工機での出力は検証していません。カメラから見た相対的な深度だけでは、レリーフの厚み、物理的な単位、加工設定は決まりません。

よくある質問

16ビットにするとAIの深度推定は正確になりますか？

いいえ。より細かい出力値を保てますが、モデルによるシーンの解釈の誤りは直りません。

8ビットPNGを16ビットに変換すればバンディングは消えますか？

入れ物を変えるだけでは失われた値は戻りません。平滑化で段差を目立たなくはできますが、深度データそのものが変わります。

16ビットPNGなのに異なる値が256種類しかないのはなぜですか？

途中で8ビットの工程を通った可能性があります。ただし、単純な画像なら値がその程度しかないのは正常です。

深度マップでは常に白が近い側ですか？

いいえ。規約はツールによって異なるため、書き出し側の「近い／遠い」の表示を確認し、手前にあるとわかっている点で確かめてください。

JPEGをディスプレイスメントマップとして使えますか？

レンダラーが受け付ける場合はありますが、非可逆圧縮のため、正確な深度値を保つマスターには向きません。

32ビットRGBAのPNGは16ビットグレースケールより高精度ですか？

グレースケールの深度マップでは違います。「32ビット」RGBAは8ビットのチャンネルが4つという意味なので、ツールが意図的に深度を複数チャンネルへ詰め込まない限り、グレー値は256階調のままです。

ブラウザのプレビューで両方のファイルが同じに見えるのはなぜですか？

表示用の変換で余分な数値精度が見えなくなるためです。元のデータを検査し、実際に使うアプリケーションで試してください。

この深度マップで実際の距離を正確に測れますか？

いいえ。正規化された相対的な推定値からは、物理的な距離も見えない形状もわかりません。