点群からメッシュ化して生成したOBJをアップロードしたところ、形状は正しく表示されているのに、テクスチャだけが元画像より暗く見えることがあります。手元の編集画面では適切な明るさだったにもかかわらず、ブラウザ上の表示、共有先のビューア、別の端末などで確認すると、壁面や路面の中間調が沈み、陰影が強すぎるように見えるケースです。
この現象は、単純に画像の明るさが不足しているとは限りません。テクスチャ画像をどの色空間として解釈するか、表示用の非線形な値と照明計算に使う線形な値をどの段階で変換するか、画像に埋め込まれたカラープロファイルを処理系がどう扱うかによって、同じ画像でも見え方が変わります。また、OBJに付随する材質設定、撮影時にテクスチャへ焼き込まれた影、表示環境の照明やトーン変換が重なることで、色空間の問題に似た暗さが発生する場合もあります。
点群OBJアップロードの実務では、見た目だけを頼りに画像を明るく加工すると、原因を隠したまま別の表示環境で白飛びや色ずれを起こすおそれがあります。重要なのは、元画像、生成テクスチャ、材質ファイル、アップロード先の読み込み設定、表示環境を順番に確認し、どの工程で差が生じたのかを切り分けることです。本記事では、点群OBJのテクスチャが暗く見えるときに確認したい色空間設定を5つに整理し、再アップロード前の実務的な検証方法まで解説します。
点群OBJでテクスチャが暗く見える仕組み
OBJは、頂点座標、面、法線、UV座標、材質の割り当てなどを記述できる形式です。一般的なテクスチャ付きOBJでは、画像そのものをOBJ内部へ格納するのではなく、別ファイルの材質情報を介して画像を参照します。そのため、OBJ、材質ファイル、画像ファイルがそろっていても、画像の色空間や表示変換まで、すべての読み込み環境へ同じ意味で伝わるとは限りません。The Library of Congress+1
写真やカラー画像は、一般にディスプレイでの表示を前提とした非線形の値で保存されます。代表的な運用では、カラー画像をsRGB相当の転送特性として読み込み、照明や反射の計算前に線形な値へ変換し、最終表示時に出力用の色空間へ変換します。一方、法線、粗さ、金属度、マスク、深度などの画像は見た目の色ではなく数値データなので、カラー画像と同じ変換を加えないのが基本です。カラー情報を持つテクスチャをsRGB系として扱い、内部の照明計算を線形空間で行う考え方は、現代的な3D描画仕様や実装でも採用されています。Khronos Registry+2Three.js+2
問題は、OBJとMTLだけでは、画像がどの色空間を前提にしているかを読み込み側が一意に判断できない場合があることです。表示用カラーを線形データとして扱ったり、線形値を表示用カラーとして復号したり、入力変換や出力変換を重複させたりすると、中間調やコントラストが変わります。ただし、誤設定によって暗くなるか明るくなるかは、画像の保存状態、読み込み時の指定、内部の作業色空間、出力変換の順序によって変わります。「リニア設定なら必ず暗くなる」「ガンマ値を上げれば必ず直る」と決めつけることはできません。
さらに、点群からメッシュとテクスチャを生成する工程では、複数写真の露出差を均す処理、色合わせ、陰影補正、テクスチャアトラス化などが行われることがあります。生成済みテクスチャに撮影時の影が残っている状態で、アップロード先が追加の照明、影、環境遮蔽を適用すると、同じ場所の明暗が重なったように見えます。この場合は色空間だけでなく、テクスチャに照明成分がどの程度含まれているかを確認する必要があります。
暗さの原因を正しく判定するには、画像の画素値そのものが暗いのか、画像は正常でも3D表示の処理で暗くなるのかを分けて考えます。元のテクスチャ画像を複数の一般的な画像表示環境で開き、見え方が大きく変わらなければ、アップロード先の色空間指定、材質計算、照明、トーン変換が候補になります。画像単体でも暗い場合は、撮影、点群処理、テクスチャ生成、画像書き出しの段階ですでに暗くなっている可能性があります。
チェック1 テクスチャ画像の色空間と書き出し条件を確認する
最初に確認したいのは、テクスチャ画像がどの用途のデータとして書き出されたかです。壁面、路面、構造物などの見た目を表すカラー画像は、通常、表示用の色データとして扱います。これに対し、法線、粗さ、金属度、マスク、深度などを表す画像は、見た目の色ではなく数値データとして扱うため、同じ色変換をかけるべきではありません。
点群OBJで使われる写真テクスチャは、多くの場合、見た目を再現するカラー画像です。ここで、画像がsRGB相当の値で保存されているのに読み込み側が線形データとして扱う、または線形値で書き出された画像をsRGB相当として復号するといった不一致があると、中間調が意図と異なる値になります。結果が暗くなるか明るくなるかは処理順序によるため、症状だけで変換方向を断定せず、書き出し側と読み込み側の設定を対で確認します。
実務では、元写真、点群処理後のテクスチャ、アップロード後の表示を同じ場所で比較すると切り分けやすくなります。比較する場所は、白い壁、灰色の路面、色の均一な標識面、日陰と日向の境界などが適しています。元写真と生成テクスチャの時点で中間調が沈んでいる場合は、アップロード先より前の工程で露出や色変換が変化しています。生成テクスチャまでは適正で、アップロード後だけ暗い場合は、読み込み側の色空間指定、材質、照明、出力変換を優先して調べます。
この確認では、画像編集画面の見た目だけで判断しないことも重要です。編集画面にはカラーマネジメント、表示プロファイル、校正表示などが適用されていることがあり、別の画像表示環境と見え方が一致しない場合があります。可能であれば、代表点のRGB値やヒストグラムも確認し、元画像と書き出し画像の間で中間調が大きく移動していないか、暗部が黒くつぶれていないかを見ます。ただし、異なる色空間のRGB値は単純比較できないため、比較前に色空間とプロファイルの条件をそろえることが必要です。
テクスチャアトラスを生成した場合は、元画像からの切り出しと合成の過程も確認します。複数写真を合成すると、撮影時刻、向き、露出、ホワイトバランスの違いにより明暗差が生じ、自動補正によって一部領域が暗く調整されることがあります。これは色空間の誤りとは限りません。特定の面や特定の写真由来の領域だけが暗い場合は、色空間よりも写真選択、露出均一化、ブレンディングの影響が大きい可能性があります。
画像を明るく再加工する前には、必ず元ファイルを残します。原因が読み込み側の設定だった場合、明るく加工した画像へ正しい色変換が適用されると、今度は明るすぎる表示になることがあります。元画像、色空間確認用画像、公開候補画像を分け、ファイル名でも判別できる状態にしておくと、再アップロード時の取り違えを防げます。
チェック2 カラープロファイルの変換と埋め込み状態を確認する
次に、テクスチャ画像へ埋め込まれたカラープロファイルを確認します。カラープロファイルは、画像内の数値をどの色として解釈するかを補助する情報です。画像にプロファイルが埋め込まれていても、アップロード処理の途中で変換または削除されたり、3Dビューア側が画像のプロファイルではなく独自の色空間指定を優先したりすると、手元の表示と共有先の表示に差が出ることがあります。
特に注意したいのは、広い色域のプロファイルや、撮影・編集環境固有のプロファイルをそのままテクスチャへ残している場合です。表示側が正しく色変換できれば問題はありませんが、アップロード時の画像最適化や3D描画処理が同じ扱いをするとは限りません。点群OBJを複数環境で共有する場合は、互換性を重視して、公開先が想定する標準的な表示用色空間へ正しく変換し、変換後の画像を確認する方法が扱いやすいです。
ここで重要なのは、「プロファイルを指定すること」と「色を変換すること」は同じではない点です。画像の画素値を変えずに別のプロファイル名だけを割り当てると、数値の意味が変わり、見た目が大きくずれる場合があります。元の色をできるだけ保ちながら別の色空間へ移すには、元プロファイルを正しく認識したうえで色変換を行います。出所が不明な画像へ推測でプロファイルを割り当てると、暗さや色ずれを悪化させるおそれがあります。
テクスチャ画像が複数枚ある場合は、すべてのプロファイル条件と書き出し方針をそろえます。一部だけ異なる色空間になっていると、OBJ全体ではまだらな明るさに見えることがあります。建物の一面だけ暗い、地面だけ彩度が低い、別のアトラスへ切り替わる境界で色が変わるといった症状は、画像ごとのプロファイル差、露出差、書き出し条件の不一致を疑う手掛かりになります。
画像形式によっては、色の解釈に関する補助情報が複数含まれることがあります。アップロード先がどの情報を保持し、どの段階で変換するかは実装によって異なります。実務上は、公開用画像を一度、公開先で推奨される条件へ統一して正規に書き出し、別名で保存したうえで、画像単体と3D表示の双方を比較する方法が安全です。変換前の画像を上書きせず、再検証できる状態を保ちます。
プロファイルを削除すれば必ず直るわけではありません。プロファイルを取り除いた画像が、表示側で想定と異なる色空間として解釈されることもあります。大切なのは、曖昧な状態をなくし、変換後の画像がどの色空間を前提としているか、アップロード先がその画像をどの色空間として扱うかを明確にすることです。
また、画像の拡張子だけを変える方法は避けます。ファイル名の末尾だけを変更しても、内部の画像形式、圧縮方式、プロファイル、転送特性は適切に変換されません。必ず正規の画像書き出し処理を行い、変換後の画像が単体で開けること、寸法や画素数が意図せず変わっていないこと、材質ファイルの参照名と一致していることを確認します。
チェック3 アップロード先のsRGB・リニア設定を確認する
テクスチャ画像自体に問題が見つからない場合は、アップロード先が画像を表示用カラーとして扱っているか、線形な演算用データとして扱っているかを確認します。カラー画像と数値データ画像では、読み込み時に必要な色変換が異なります。用途に合わない指定をすると、中間調、彩度、コントラストが変化しますが、暗くなるか明るくなるかはビューアの内部処理と出力設定によって異なります。
アップロード画面や材質設定に、カラー、ベースカラー、拡散色、sRGB、リニア、データ、非カラーなどの区分がある場合は、テクスチャの用途と一致しているかを見ます。名称は環境によって異なりますが、壁や地面の見た目を表す写真テクスチャであれば、通常は表示用カラーとして扱う設定が候補です。法線、粗さ、マスクなどの画像がある場合は、それらまで同じ設定へ変更しないよう注意します。すべての画像を一括で表示用カラーとして扱うと、陰影や反射の計算が不自然になることがあります。
設定項目が見当たらない場合は、検証用の単純な画像を使う方法があります。白、黒、複数段階の灰色、彩度の高い色を含む小さな基準画像を用意し、簡単な面へ割り当ててアップロードします。白と黒だけでは転送特性の違いが分かりにくいため、中間の灰色を複数含めることが重要です。中間調の並びが画像単体と3D表示で大きく異なる場合は、入力色空間、内部変換、出力色空間のどこかが一致していない可能性があります。
元の点群OBJを直接修正する前に、少数の面と一枚のテクスチャだけで試験すると、検証時間を短縮できます。大容量のOBJでは、再アップロードに時間がかかり、変更箇所も追いにくくなります。形状、UV、材質参照を最小構成にした試験データを用意し、表示用カラーとして指定した場合と、データ扱いにした場合の差を比較します。試験結果と設定の組み合わせを記録すれば、本番データにも同じ考え方を適用できます。
アップロード処理で画像が自動変換される場合にも注意が必要です。容量削減や配信用最適化のため、画像形式、圧縮方式、画素数、アルファ、プロファイル情報などが変更されることがあります。元ファイルをそのまま表示しているとは限らないため、可能であればアップロード先の対応形式、推奨色空間、自動変換の仕様を確認します。仕様が公開されていない場合は、基準画像を使った比較試験で挙動を把握します。
暗く見えるからといって、表示側の露出や明るさを最初に上げるのは避けたほうが安全です。露出調整は、入力画像の色空間、材質値、照明、出力変換が妥当であることを確認した後の最終調整として行います。誤った色空間のまま露出だけを補うと、暗部は見えるようになっても、中間調の階調、色相、彩度が不自然に残ることがあります。
OBJとMTLには、現代的な3D形式のように、すべてのテクスチャ用途と色空間を明確に伝える共通の仕組みが十分にそろっていません。そのため、同じファイルでも読み込み環境によって初期解釈が異なることがあります。アップロード先に色空間指定がない場合は、推奨される画像条件へ統一し、基準データで表示結果を確認する運用が現実的です。
チェック4 MTLの材質値と照明の二重適用を確認する
OBJとともに使われる材質ファイルには、テクスチャ画像の参照先だけでなく、拡散色、環境色、透明度、光沢などの値が記述されることがあります。表示側によって対応範囲や解釈が異なるため、同じOBJと材質ファイルでも見え方が一致しない場合があります。テクスチャが暗いと感じたときは、色空間だけでなく、材質値が画像へ乗算されていないかを確認します。
代表的なMTLの運用では、拡散色に相当するKdと、拡散テクスチャに相当するmap_Kdが組み合わされます。Kdが白ではなく暗い灰色になっていると、読み込み側の実装によってはテクスチャ全体へ暗い係数が掛かり、元画像より暗く表示されます。材質ファイルを確認し、カラー画像へ意図しない暗い色が設定されていないかを見ます。MTLの一般的な解釈では、map_Kdの値はKdと組み合わせて使われます。The Library of Congressただし、すべての値を機械的に最大へ変更すると材質表現が変わるため、まず検証用の複製データで影響を確認します。
テクスチャに撮影時の陰影が含まれている場合は、表示側の照明との重なりにも注意します。点群から作られた写真テクスチャには、建物の影、樹木の影、曇天時の明暗、局所的な露出差などが残っていることがあります。そこへ方向性の強い照明、投影影、環境遮蔽が加わると、暗い領域がさらに沈んで見える場合があります。この症状は、面の向きによって暗さが変わる、視点や光源を動かすと陰影が変化する、陰影効果を弱めると改善するといった特徴があります。
色空間の問題と照明の問題を分けるには、一時的に陰影の影響を抑えた表示で確認します。照明を均一にし、投影影や環境遮蔽を弱め、可能であればテクスチャ色を照明の影響なしで確認できる表示へ切り替えます。この状態でも暗ければ、画像の色空間解釈や材質値が原因である可能性が高まります。均一な表示では適正に見え、通常表示でだけ暗い場合は、法線、光源、影、材質反射、トーン変換を調べます。
法線の向きや面方向が不適切な場合も、面が黒く沈んで見えることがあります。特定方向を向く面だけ暗い、裏側から見ると状態が変わる、面の境界で急に明暗が切り替わる場合は、法線や面の向きを疑います。これは色空間の問題ではありませんが、点群OBJアップロード後の見え方では混同されやすいポイントです。テクスチャ単体が正常で、材質値も適正なのに一部面だけ暗い場合は、法線の再計算、スムージング、面方向の確認が必要です。
透明度の値やアルファの扱いによって、背景との合成結果が暗く見える場合もあります。MTLの透明度に関する記述や画像のアルファは、読み込み側の対応状況によって挙動が異なることがあります。半透明が不要な材質であれば、意図しない透明度が入っていないかを確認します。輪郭だけが黒ずむ場合は、アルファの有無、プリマルチプライの扱い、画像の縁に含まれる色、背景色との合成を調べます。
材質ファイルを修正した後は、OBJ内の材質名と対応しているか、参照する画像名が正しいかを再確認します。修正したつもりでも、アップロード時に古い材質ファイルを同梱していたり、同名ファイルの旧版が参照されたりすると、表示は変わりません。検証時はファイル名や版番号を分け、アップロード先のキャッシュや旧データの残存にも注意します。
チェック5 表示端末・ブラウザ・トーン変換の差を確認する
最後に、表示端末、ブラウザ、3Dビューア、画面設定、トーン変換の差を確認します。点群OBJのテクスチャが暗く見える現象は、データ自体ではなく、表示環境の組み合わせによって発生することがあります。特定の端末だけ暗い、同じ端末でも別のビューアでは見え方が違う、画面の表示モードを変えると印象が大きく変わる場合は、表示側の要因を切り分けます。
ディスプレイには、明るさ、コントラスト、色温度、省電力表示、周囲光への自動調整、広色域表示などの機能があります。これらの条件が異なると、暗部がつぶれて見えたり、全体が暖色または寒色へ寄ったりします。現場事務所の外部モニター、屋外で使う携帯端末、一般的な事務用画面では、同じ画像でも印象が異なります。公開前の確認では、少なくとも二つ以上の表示環境で見比べ、片方だけの見え方を基準にしないことが大切です。
ブラウザで表示する場合も、画像ファイル単体の色管理と、3Dビューア内部のテクスチャ処理は分けて考える必要があります。画像タグで正しく見えるテクスチャが、3D表示では暗くなる場合、ブラウザ全体の問題とは限りません。3D描画側での入力色空間指定、レンダーターゲット、後処理、出力色空間、トーン変換を確認します。同じブラウザでも、異なるビューアや設定では結果が変わることがあります。ブラウザ側の画像カラーマネジメントが存在していても、3Dビューア内部のテクスチャ指定と出力変換は別途確認が必要です。MDN Web Docs+1
高い輝度範囲を扱う描画と一般的な表示の間では、トーン変換によって中間調やハイライトの見え方が変わる場合があります。露出値、トーン変換方式、後処理の設定によっては、ハイライトを圧縮する一方で中間調が暗めに感じられることがあります。ただし、明るい領域があるだけで自動的に全体が暗くなるとは限りません。自動露出や輝度適応が有効な場合は、シーン内容に応じて見え方が変わる可能性もあるため、固定露出との比較が有効です。
トーン変換の影響を確認するには、露出、コントラスト、トーン変換方式、後処理を一つずつ変更し、どの設定が暗さへ影響しているかを見ます。複数項目を同時に変えると原因が分からなくなるため、初期値を記録してから一項目ずつ試します。設定を戻せるように、変更前の数値と画面状態を保存しておくと安全です。
ブラウザや端末による差を確認するときは、スクリーンショットだけで判断しないようにします。スクリーンショットは表示結果の記録には役立ちますが、作成時と閲覧時の色管理、圧縮、共有サービスの変換が加わることがあります。元のテクスチャ画像、3D画面、スクリーンショットを別のものとして管理し、どの段階の差を比較しているかを明確にします。
また、周囲の明るさも見え方へ大きく影響します。明るい屋外では暗部が見えにくくなり、暗い室内では同じ画像が明るく感じられることがあります。点群OBJを現場で確認する用途では、屋内の編集環境だけでなく、実際に利用する明るさ条件でも確認します。必要に応じて表示側の明るさ調整を用意しつつ、データ自体を過度に明るく加工しない運用が安定します。
複数環境で比較した結果、すべて同じように暗い場合は、画像、材質、照明設定の問題へ戻ります。一つの環境だけ暗い場合は、その端末の画面設定、表示プロファイル、3Dビューアの色空間指定、出力設定を優先します。この切り分けによって、正常なテクスチャを不必要に再加工することを防げます。
暗さの原因を短時間で切り分ける検証手順
点群OBJのファイル容量が大きい場合、原因を探るたびに全データを再アップロードすると作業が長引きます。短時間で切り分けるには、本番データを複製し、代表的な一部分だけを使った検証用データを作ります。壁面、地面、陰影のある場所、明るい場所を含む小さな範囲を選び、テクスチャ枚数と面数を減らします。
最初に、テクスチャ画像を単体で確認します。元写真や正常時の画像と比べてすでに暗い場合は、撮影、点群処理、テクスチャ生成、書き出しへ戻ります。画像単体が正常なら、同じ画像を単純な面へ割り当て、アップロード先での色空間解釈を見ます。この段階で差が出れば、入力色空間の指定、自動画像変換、材質の初期値、出力変換が主な候補です。
次に、材質値を単純化した検証版を作ります。テクスチャへ余計な色係数、透明度、強い光沢が加わらない状態にし、均一な照明または照明の影響を抑えた表示で確認します。これで正常になる場合は、元の材質設定または照明との組み合わせが原因です。変化しない場合は、プロファイル、表示用カラーと線形データの区分、自動画像変換、出力色空間を再確認します。
検証では、一回の再アップロードで変更する項目を一つにします。テクスチャの色空間、プロファイル、材質値、照明、露出を同時に変更すると、改善しても原因を特定できません。変更内容、使用したファイル名、アップロード日時、表示結果を簡単に記録しておくと、同じ試行を繰り返さずに済みます。
暗さを比較しやすくするには、複数段階の灰色を含む基準画像を利用します。画面表示をスクリーンショットから数値化する方法には端末や表示変換の影響が含まれるため、厳密な測色には向きませんが、同じ端末、同じ条件での相対比較には役立ちます。中間調が全体的にずれるのか、暗部だけがつぶれるのか、照明方向に応じて変わるのかを見ることで、色空間、露出、照明のどこを優先するか判断しやすくなります。
本番データへ反映する前には、検証用データで再現性を確認します。一度だけ正常に見えても、再読み込みや別端末で元へ戻る場合は、キャッシュ、一時的な表示設定、旧版ファイルの参照が影響している可能性があります。同じファイルを再度開き、別の表示環境でも確認し、結果が安定してから本番OBJを更新します。
再アップロード前にそろえたいファイル構成
色空間を修正しても、アップロードするファイルの組み合わせが古いままだと改善しません。OBJ、材質ファイル、テクスチャ画像を一つの作業用フォルダーへまとめ、参照関係を整理します。材質ファイル内の画像名が実際のファイル名と一致していること、大文字と小文字、拡張子、空白、記号がずれていないことを確認します。
画像を色変換した場合は、元画像と同じ名前で上書きするより、検証段階では別名にしたほうが安全です。材質ファイルの参照先も新しい名前へ変更し、どの版を使っているか明確にします。本番公開時に名前を整理する場合でも、検証履歴が残るように元データを別の場所へ保管します。
相対パスで参照できる構成にしておくと、別の端末やアップロード環境へ移したときの不一致を減らせます。作業端末固有の絶対パスが残っていると、アップロード先が画像を参照できず、テクスチャなしの材質色や代替表示になる場合があります。テクスチャが暗いと思っていたものが、実際には画像未読込による材質表示だったというケースもあるため、アップロード後に画像が正しく読み込まれているかを確認します。
複数のテクスチャ画像がある場合は、色空間、プロファイル、画素形式、透明度、拡張子の方針を統一します。一枚だけ異なる条件が残ると、表示環境によってその画像だけ見え方が変わることがあります。変換処理を一括で行った場合も、処理漏れや書き出し失敗がないか、画像枚数、寸法、ファイルサイズを確認します。
圧縮ファイルでアップロードする場合は、展開後の階層が意図どおりになるかを確認します。OBJと材質ファイルだけが直下にあり、画像が想定外の階層へ入ると、参照できない場合があります。ファイルをまとめた後、別の空フォルダーへ展開し、その状態からOBJを開く試験を行うと、参照漏れを発見しやすくなります。
アップロード先に旧版が残る場合は、同名ファイルのキャッシュにも注意します。修正後の画像へ置き換えたのに表示が変わらないときは、別名の画像と材質を使った検証版で比較します。単に画面を再読み込みするだけでなく、対象データの版、更新時刻、材質参照先が新しいものになっているかを確認します。
色空間を直しても暗い場合に確認する項目
色空間とプロファイルを整えても暗い場合は、撮影条件とテクスチャ生成処理へ視点を戻します。点群化に使った写真が露出不足であれば、正しい色空間で表示しても暗さは残ります。特に、逆光、強い日陰、トンネル内、構造物の下面、夕方の撮影では、暗部の情報が不足しやすくなります。
写真ごとの露出差が大きいと、テクスチャ合成時に暗い写真が選ばれた部分だけ色が沈むことがあります。面単位で暗さが変わる場合や、写真の境界に沿って明暗差が出る場合は、色空間よりも画像選択、露出均一化、ブレンディングの問題が疑われます。元写真の撮影時刻と方向を確認し、必要に応じて露出差の小さい写真群で再生成します。
UVのずれによって、暗い領域や画像外周付近を参照している可能性もあります。テクスチャの位置がずれ、壁面へ本来の影部分が貼られていると、全体が暗く見えることがあります。形状の一部だけ不自然に暗く、境界が面やUV島の形に沿っている場合は、UV座標と画像の対応、余白、ラップ設定を確認します。
法線や面方向の不具合も再確認します。色空間の不一致では、画像全体の中間調が一定の傾向で変化することが多い一方、法線の不具合では、面の方向、光源、視点に応じて明暗が変わります。カメラや光源を動かしたときに暗い場所の見え方が変化するなら、照明計算の影響を優先して調べます。
環境遮蔽、投影影、霧、距離減衰、背景色との合成など、表示側の演出も暗さへ影響します。これらを一時的に弱め、テクスチャそのものの色を確認します。表示効果を恒久的に無効にすることが目的ではなく、どの効果が暗さへ寄与しているかを把握し、必要な効果だけを適切な強さへ戻すことが目的です。
画像の透明度やプリマルチプライ処理の違いによって、輪郭や半透明部分が暗くなることもあります。全体ではなく縁だけ黒ずむ場合は、アルファ情報、画像の縁色、背景合成を確認します。透明表現が不要なテクスチャは、公開用としてアルファなしで書き出す方法を検討できます。ただし、フェンスや植生など透明表現が必要な対象では、用途を保ったまま合成条件を整えます。
テクスチャが読み込まれていない場合も見落とせません。画像参照に失敗すると、ビューアがMTLのKdや既定色だけで面を表示し、結果として暗い灰色や黒に見えることがあります。色空間調整を続ける前に、開発者向けログ、アップロード時の警告、画像参照パス、ファイル名の一致を確認し、テクスチャが実際に適用されていることを確かめます。
点群OBJの見え方を安定させる運用ルール
毎回の案件で色空間の確認をやり直さないためには、テクスチャ生成からアップロードまでの標準手順を決めておくことが有効です。最初に、カラー画像はどの色空間へ統一するか、プロファイルをどのように扱うか、画像形式と透明度をどうするかを決めます。法線、粗さ、マスクなどのデータ画像を使う場合は、カラー画像とは別のルールで管理します。
次に、検証用の基準OBJを用意します。複数段階の灰色、白、黒、代表的な色を含むテクスチャと、単純な面形状を組み合わせた小さなデータを保存しておくと、アップロード先の仕様変更や端末更新後にも確認できます。以前と同じ基準データの見え方が変わった場合は、制作データではなく表示環境やアップロード処理の変更を疑えます。
書き出し設定は担当者ごとに変えず、作業記録へ残します。色空間、プロファイル、画像圧縮、画素数、アルファ、材質値、照明、露出、トーン変換を記録しておけば、再現性が高まります。問題が発生したときも、前回正常だった条件と比較しやすくなります。
撮影段階では、極端な露出差を避けることが重要です。点群の形状精度が確保できていても、写真の暗部がつぶれていれば、テクスチャの見え方は安定しません。日向と日陰をまたぐ対象では、撮影順序や時刻を工夫し、できるだけ急激な明るさ変化を避けて記録します。自動露出を使う場合も、写真間で大きな差が生じていないか現場で確認します。
アップロード後の合格基準も決めておきます。手元の画面と完全に同じ色へ合わせることだけを目標にせず、主要な面の階調がつぶれていないこと、暗部の情報が確認できること、複数端末で実用上大きな差がないこと、材質境界やUV境界に不自然な明暗差がないことなどを確認します。表示端末の特性まで完全に統一することは難しいため、用途に必要な範囲を基準化します。
修正時は、画像の明るさ加工を最後の手段にします。最初に色空間、プロファイル、読み込み区分、材質値、照明、出力変換、表示環境を確認し、それでも元画像自体が暗いと判断できた場合に限り、露出や階調を調整します。この順序を守ることで、別環境での白飛びや色ずれを減らせます。
LRTK Phoneを使って取得・管理する現場データを点群OBJとして活用する場合も、形状や座標だけでなく、テクスチャの生成条件、画像の色空間、材質参照、共有先での表示確認を作業手順へ含めることが重要です。現場で確認した見え方と、共有先へアップロードした後の見え方を比較し、案件ごとの書き出し条件を記録しておくと、後工程での手戻りを抑えやすくなります。
まとめ
点群OBJのテクスチャが暗く見えるときは、画像をすぐに明るく加工するのではなく、どの工程で見え方が変わったかを順番に切り分ける必要があります。最初にテクスチャ画像の用途、色空間、書き出し条件を確認し、次にカラープロファイルが正しく認識され、必要な色変換が行われているかを見ます。そのうえで、アップロード先がカラー画像を表示用データとして扱っているか、線形な数値データとして扱っているかを確認します。
重要なのは、sRGBとリニアの不一致があれば必ず特定方向へ暗くなるわけではないことです。暗くなるか明るくなるかは、入力画像の保存状態、読み込み時の指定、内部の作業色空間、出力変換の順序で変わります。症状だけから変換方向を決めず、基準画像と最小構成のOBJを使い、一項目ずつ比較することが安全です。
画像と色空間に問題がない場合は、材質ファイルのKdとテクスチャの組み合わせ、透明度、撮影時の影と表示側照明の重なり、法線の向きなどを調べます。さらに、端末、ブラウザ、3Dビューア、画面設定、トーン変換の差を比較し、特定環境だけの問題か、データ全体の問題かを判断します。
再アップロードでは、一度に複数の設定を変えず、検証用の小さなOBJで一項目ずつ確認する方法が効果的です。OBJ、材質ファイル、テクスチャ画像の版をそろえ、相対参照、ファイル名、旧版、キャッシュも確認すると、修正した画像が正しく反映されているか判断しやすくなります。
点群OBJアップロード後の見え方を安定させるには、色空間、プロファイル、材質、照明、出力変換、表示環境を一つの流れとして管理することが大切です。LRTK Phoneを活用する現場でも、取得したデータを共有・確認する工程まで含めて条件を統一し、暗部のつぶれや不要な色ずれを抑えた点群OBJ運用につなげていきましょう。