点群や三次元メッシュをOBJ形式で書き出し、クラウド型の点群ビューアや三次元データ共有環境へアップロードした際、作業画面で確認した色と異なって見えることがあります。具体的には、モデル全体が暗くなる、白っぽくなる、彩度が高くなる、コンクリートや土の色が不自然になる、影の部分が黒くつぶれるといった変化です。
形状や座標が正しく表示されていても、色に関する受け渡しが正しいとは限りません。点群OBJアップロード後の見え方は、OBJファイルだけでなく、MTLファイル、テクスチャ画像、頂点カラー、入力色空間、照明計算、出力色空間、露出、トーンマッピング、ブラウザ、モニターなどの影響を受けます。
特に注意したいのが、一般的なカラー画像で使われるsRGB系の非線形な値と、照明計算で扱う線形な値の変換です。ただし、「変換が一回抜けると必ず暗くなる」「二重に変換すると必ず白っぽくなる」とは限りません。入力側のsRGBから線形への変換、照明計算、画面出力側の線形から表示用への変換のうち、どの段階が不足または重複したかによって、暗く見える場合も明るく見える場合もあります。
本記事では、「点群 OBJ アップロード」で検索している実務担当者に向けて、色味が変わるときに確認したい五つの見直し項目を解説します。あわせて、テクスチャ参照の不具合や照明の違いをガンマ異常と取り違えないための切り分け方、再アップロード前の検証方法、色再現を安定させる運用方法も紹介します。
点群OBJアップロード後に色味が変わる理由
OBJは、頂点座標、点、線、面、法線、テクスチャ座標などを表現できる三次元形状用の形式です。ただし、写真由来の表面色をOBJファイル本体だけで管理しているとは限りません。一般的なテクスチャ付きモデルでは、OBJがMTLファイルを参照し、MTLファイルがテクスチャ画像を参照します。OBJとMTLの対応にはmtllibやusemtlなどの記述が使われ、MTLには色、透明度、テクスチャ参照などが記録されます。([loc.gov][1])
この構成では、形状と色が複数ファイルに分かれています。そのため、OBJだけをアップロードして形状が表示されても、元の色が再現されるとは限りません。MTLファイルが不足している、テクスチャ画像が含まれていない、参照先のファイル名が一致していない、アップロード先が一部のMTL記述に対応していないといった場合には、既定色や簡略化された材質で描画される可能性があります。
点群やメッシュによっては、テクスチャ画像ではなく、頂点ごとに赤、緑、青の値を持たせる頂点カラーが使用されます。ただし、OBJの頂点カラーは元の中核仕様で一律に定義された必須機能ではなく、広く使われている拡張的な記法です。代表的な記法では頂点座標の後ろにRGB値を0から1の範囲で記録しますが、対応状況や別記法の扱いはソフトウェアによって異なります。([loc.gov][1])
色データが正しく渡っていても、画面に表示されるまでには複数の色変換が行われます。一般的なカラー画像は表示に適した非線形の転送特性を持ち、照明や合成の計算では線形な作業空間へ変換して扱うのが基本です。例えば現代的な3D仕様では、ベースカラー画像をsRGBの転送特性で保存し、計算前に線形値へ復号する考え方が明示されています。([GitHub][2])
入力画像を線形化せずに計算した場合、出力側の変換を省略した場合、すでに変換済みの値へ再変換した場合では、見え方の変化方向が異なります。そのため、暗いか明るいかだけで原因を断定せず、入力画像の解釈、照明計算、画面出力の各段階を分けて確認する必要があります。
また、暗く見える現象がすべてガンマや色空間の問題とは限りません。三次元ビューアでは、テクスチャの色に照明、影、環境光、露出、反射、アンビエントオクルージョン、トーンマッピングなどが加わることがあります。元の作業画面が照明の影響を抑えた表示で、アップロード先が立体感を強調する表示であれば、同じテクスチャでも暗部が増えたように感じられます。
背景色による見え方の差もあります。同じ灰色の面でも、黒い背景では明るく見え、白い背景では暗く見えることがあります。元の作業環境とアップロード先で背景色が違う場合、データ上の色が大きく変わっていなくても、印象が変化します。
原因を正しく特定するには、入力画像、生成されたテクスチャ、OBJ書き出し直後のローカル表示、アップロード後の表示、閲覧端末という各段階を分けて確認することが重要です。
見直し1 入力画像とテクスチャの色空間を統一する
最初に確認したいのは、点群やメッシュの作成に使用した入力画像と、OBJに関連付けられたテクスチャ画像の色空間です。色空間や転送特性は、画像内の数値をどのような色と明るさとして扱うかを決めます。
同じように見える画像でも、読み込み側が想定する色空間と実際の画像が一致していなければ、変換後の色が変わることがあります。撮影機器や画像編集の設定が混在している場合、入力画像ごとに明るさ、コントラスト、彩度、色温度が異なり、その差が三次元モデルの表面に現れる可能性があります。
点群OBJアップロード後に色が変わったように見えても、実際にはアップロード前のテクスチャ生成段階ですでに変化していることがあります。最初の切り分けでは、書き出し元の三次元画面だけで判断せず、生成されたテクスチャ画像を単独で開いて確認します。
元の撮影画像とテクスチャ画像を比較し、テクスチャ画像の段階ですでに暗い場合は、アップロード先のガンマ設定よりも、画像統合、露出補正、色調補正、テクスチャ生成時の保存処理を優先して確認します。反対に、テクスチャ画像は正常で、三次元表示にしたときだけ変化する場合は、表示側の色変換、材質、照明が主な確認対象です。
入力画像の条件が統一されていないと、複数の画像から一枚のテクスチャを作成する際に、一部だけ色が変わる可能性があります。モデル全体が均一に暗くなるのではなく、面ごとに色が切り替わる、継ぎ目が見える、同じ材質なのに場所によって色温度が異なる場合は、ガンマ設定だけでなく元画像の露出差やホワイトバランス差を疑います。
実務では、撮影時の自動露出や自動ホワイトバランスにより、移動するたびに画像の色が変わることがあります。屋外から日陰へ移動した場合や、空が大きく写る画像と地面が大きく写る画像が混在した場合は、同じ対象物でも撮影画像ごとに明るさや色温度が変わります。
画像生成処理に色調を均一化する機能があっても、白飛びや黒つぶれで失われた情報を完全に復元できるとは限りません。後工程のガンマ調整で階調を持ち上げても、撮影時に記録されていない細部は戻りません。入力画像の段階で極端な露出差を減らすことが、アップロード後の安定した色再現につながります。
テクスチャ画像を画像編集工程へ渡す場合は、保存時の色空間変換にも注意します。通常のカラー用テクスチャは、アップロード先が想定する色空間へそろえる必要があります。一般的にはsRGBが広く使われますが、対象サービスが別の前提を定めている場合は、その仕様を優先します。
OBJや従来のMTLだけでは、テクスチャ画像をどの色空間として解釈すべきかを十分に明示できないことがあります。画像にICCプロファイルが付いていても、三次元ビューアが同じように参照するとは限りません。そのため、識別情報だけに頼らず、アップロード先がカラー画像をどの色空間として扱うかを確認し、小さな試験データで再現性を確かめます。
入力画像、生成直後のテクスチャ、OBJ書き出し後のテクスチャを同じ閲覧条件で比較し、どの段階から色が変わったかを記録します。この確認により、入力側の問題か、三次元表示側の問題かを大きく絞り込めます。
見直し2 OBJ・MTL・頂点カラーの受け渡しを確認する
二つ目の見直しは、OBJ、MTL、テクスチャ画像、頂点カラーの受け渡しです。ガンマの問題に見える色味変化でも、実際にはテクスチャが読み込まれておらず、代わりにマテリアルの基本色やアップロード先の既定材質が表示されている場合があります。
OBJ内には、使用するMTLファイル名や、各面に適用するマテリアル名が記録されます。MTLファイルには、拡散色、透明度、照明モデル、テクスチャ画像の参照先などが記録されます。これらの対応が崩れると、形状だけが表示され、色は簡略化される可能性があります。
アップロード時には、OBJだけでなく、対応するMTLファイルとテクスチャ画像も一つのデータセットとして扱います。アップロード用フォルダーを作り、その中に必要なファイルをまとめます。元の保存場所にあるテクスチャを絶対パスや別フォルダーで参照したままOBJを移動すると、書き出し元では表示できても、アップロード先では画像を見つけられないことがあります。
ファイル名の違いにも注意が必要です。MTLに記載されたテクスチャ名と実際の画像ファイル名が一致しなければ、参照に失敗する可能性があります。大文字と小文字の違い、拡張子の違い、空白、全角文字、特殊記号、階層の違いが原因になることもあります。
実務用のアップロードデータでは、ファイル名を半角英数字と扱いやすい記号にそろえ、過度に長い名称を避けると管理しやすくなります。同じ名前のテクスチャ画像を複数案件で使い回すと、再アップロードやキャッシュ確認時に取り違えやすいため、案件、版、作成日などを識別できる名称を付けます。
MTLに記録されている拡散色も確認します。実装によっては、テクスチャ画像とMTLの拡散色を組み合わせて表示します。拡散色が白に近ければテクスチャへの影響は小さくなりますが、灰色や特定色が設定されていると、モデル全体が暗く見えたり色が偏ったりする場合があります。ただし、組み合わせ方はビューアによって異なるため、同じMTLでも結果が一致するとは限りません。
テクスチャを正常に読み込めているかを確認するには、特徴的な模様、文字、ひび割れ、色の境界を見ると分かりやすくなります。細かな模様が消えて単色に近くなっている場合は、ガンマではなく、テクスチャ参照の失敗や低解像度化を疑います。
透明度の設定も色味に影響します。完全に不透明なつもりでも、MTL内のdやTrなどが想定と異なる解釈を受けると、背景色が混ざり、白っぽくまたは暗く見えることがあります。透明度の記述は実装差が出やすいため、検証時は不透明材質へ単純化して比較すると切り分けやすくなります。
頂点カラーを使用している場合は、まずアップロード先がOBJの頂点カラー拡張へ対応しているかを確認します。代表的な記法では、v行の座標値に続けて0から1のRGB値を記録しますが、別の拡張記法を出力するソフトウェアもあります。読み込み側の前提が一致しなければ、色情報が無視されたり、意図しない色になったりする可能性があります。
テクスチャと頂点カラーの両方が含まれているデータでは、どちらが優先されるか、両方が乗算されるかを確認します。頂点カラーが線形の乗数として扱われる実装では、灰色の頂点カラーがテクスチャ全体を暗くすることがあります。色の受け渡しを安定させるには、主に使用する方式を決め、不要な色情報を重ねないことが有効です。
見直し3 アップロード先の入力変換と出力変換を確認する
三つ目は、アップロード先で行われる入力色空間の解釈、線形化、照明計算、画面出力時の変換です。テクスチャ画像や頂点カラーが正しく読み込まれていても、表示側が色データをどのように扱うかによって、最終的な明るさが変わります。
一般的なカラー用テクスチャをsRGBとして扱う場合は、照明計算の前に線形値へ変換し、計算後に画面表示用の色空間へ変換する流れが基本です。これに対し、法線、粗さ、金属度、マスクなどのデータ用画像は、カラー画像と同じsRGB変換をかけないのが一般的です。カラー用とデータ用の画像を取り違えると、材質や陰影が不自然になる可能性があります。
アップロード後にモデル全体が暗くなる場合は、画面出力側の変換が不足していないか、テクスチャが必要以上に線形化されていないか、照明や露出が低すぎないかを確認します。反対に、全体が白っぽい、彩度が高い、コントラストが弱い場合は、入力テクスチャを線形化していない、出力変換を重複させている、露出やトーンマッピングが強いといった候補があります。
重要なのは、明るさの方向だけで原因を決めないことです。入力変換を省略した場合と、出力変換を省略した場合では結果が逆方向になることがあります。ガンマ値を一つだけ見て判断せず、テクスチャの色空間指定、レンダラーの作業色空間、出力色空間を一連の設定として確認します。
アップロード先にガンマ、明るさ、露出、コントラスト、トーンマッピングなどの設定がある場合は、可能な範囲で一度既定値へ戻します。利用者側に設定が表示されないサービスでは、仕様書やサポート情報でカラー画像の扱いを確認します。
ガンマと露出は似た変化に見えることがありますが、役割は異なります。露出はシーン全体の明るさや高輝度部の見え方へ影響し、ガンマや転送特性の不一致は中間調の階調へ強く現れます。ただし、トーンマッピングや照明が同時に働くと目視だけでは区別しにくいため、一項目ずつ固定して比較します。
自動露出が使われているビューアでは、視点を変えるだけで明るさが変化する可能性があります。モデルの暗い部分を画面いっぱいに表示すると明るくなり、空や白い面が多く入ると暗くなるような挙動があれば、自動調整の影響を疑います。
色を比較するときは、自動露出を停止できる場合は固定し、同じ視点、同じ背景、同じ拡大率で確認します。停止できない場合は、モデルが画面内に占める割合をそろえ、明るい背景や暗い背景が比較ごとに変わらないようにします。
トーンマッピングにも注意が必要です。高輝度の情報を画面内へ収める処理は白飛びを抑えられる一方、方式によって彩度、コントラスト、明部の色相が変わることがあります。測量記録や現況比較では、見栄えを優先した強い調整より、比較条件を固定できる中立的な設定を基準にします。
見直し4 書き出し時の色補正と二重適用を確認する
四つ目は、OBJを書き出す前後に行われる色補正です。点群処理やメッシュ作成の作業画面には、見やすさを高めるための明るさ、コントラスト、彩度、色温度、影の強さなどの表示設定が用意されていることがあります。
ここで重要なのは、作業画面の見た目と、実際に書き出されるテクスチャ画像の色が必ずしも一致しないことです。作業画面だけに適用される表示補正であれば、OBJ書き出し時のテクスチャには反映されません。その場合、作業中は明るく見えていても、書き出し後やアップロード後は暗く見えることがあります。
反対に、作業画面で使用していた補正をテクスチャ画像へ焼き込み、さらにアップロード先でも露出、ガンマ、トーンマッピングなどを強く適用すると、補正が重なります。中間調が過度に明るくなる、黒に近い部分が灰色に浮く、明部の色差が分かりにくくなるといった変化が起こる可能性があります。
書き出し設定を確認するときは、色補正の有無だけでなく、どの補正が実データへ反映されるかを確認します。表示専用の設定、テクスチャ生成時の設定、画像保存時の設定、アップロード後の表示設定を区別しないと、同じ「明るさ」や「ガンマ」という名称でも役割を取り違えます。
陰影の焼き込みも、色味を変える要因です。写真から生成したテクスチャには、撮影時の影や明暗がすでに含まれています。さらに書き出し時に陰影やアンビエントオクルージョンを焼き込み、アップロード先でも照明や影を加えると、暗部が強調される場合があります。
建物の軒下、構造物の裏側、掘削部、法面の凹部など、一部だけ極端に暗い場合は、モデル全体のガンマよりも、撮影時の影、焼き込み陰影、法線、環境光の不足を確認します。モデル全体のガンマや露出を上げると、暗部は見やすくなっても、日なたの部分が白っぽくなり、比較に必要な色差を失うことがあります。
色を確認するテストでは、可能であれば陰影を追加していないテクスチャを用意し、アップロード先で照明の影響を抑えられる表示モードと比較します。照明なしでは正常で、照明を有効にすると暗くなる場合は、テクスチャのガンマよりも材質や光源の影響が大きいと判断できます。
テクスチャ画像の圧縮設定も確認します。画像を強く圧縮すると、細かな色差が失われ、色の境界ににじみやブロック状の乱れが発生します。遠目には色味が変わったように見えても、拡大すると圧縮劣化や縮小処理である場合があります。
圧縮による変化は、ガンマ調整では改善できません。検証用のデータでは圧縮を抑え、色味が正常であることを確認してから、必要な容量まで段階的に調整します。アップロード先が自動的に画像を縮小または再圧縮する場合は、その変換後の解像度も確認します。
テクスチャ画像を一枚に統合する処理でも、画像の再保存や色変換が行われる可能性があります。統合前は正常でも、統合後の画像だけ暗い場合は、アトラス生成、画像結合、保存形式、カラープロファイル、転送特性の扱いを確認します。
書き出し条件を変更するたびに同じファイルへ上書きすると、どの設定で作成したデータか分からなくなります。検証用データには、補正の有無、圧縮条件、陰影の有無、作成日時などを識別できる名前を付けます。設定と結果を対応させて残すことで、再現性のある条件を再利用できます。
見直し5 照明・ブラウザ・モニターの表示条件をそろえる
五つ目は、アップロードされたモデルを閲覧する環境です。色データと表示設定が同じでも、照明、ブラウザ、端末、モニター、OSの表示補正によって見え方が変わることがあります。
まず確認したいのは、色味の変化がすべての閲覧端末で起きるのか、一部の端末だけで起きるのかです。複数の端末で同じ傾向が出る場合は、アップロードデータやサービス側の設定が原因である可能性が高まります。一台だけで異なる場合は、その端末固有の画面設定やブラウザ環境を確認します。
三次元ビューアの照明設定は、色味へ大きく影響します。方向性の強い光が使われていると、光が当たる面は明るく、反対側は暗くなります。元の作業画面が均一な明るさで表示されていた場合、アップロード後の立体的な陰影を色の変化と感じることがあります。
環境光が弱いと、影になる部分が黒くつぶれやすくなります。環境光を強くすると暗部は見やすくなりますが、強すぎると全体が白っぽく平面的に見えます。ガンマを調整する前に、照明の方向、強さ、環境光、影、アンビエントオクルージョンの有無を確認します。
照明を無効にした表示や、テクスチャの色を照明なしで確認できる表示モードがある場合は、それを利用します。照明なしでは正常で、照明を有効にすると暗くなる場合は、ガンマよりも光源、材質、法線の影響が大きいと考えられます。
法線の向きや補間が不適切な場合も、部分的に暗く表示されます。面の表裏が反転している、法線がばらついている、平滑化の境界が意図と異なるといった状態では、テクスチャ自体が正常でも黒い斑点や不自然な陰影が現れます。
背景色も比較条件へ影響します。黒い背景と白い背景では、同じモデルでも明るさの印象が変わります。元の作業画面とアップロード先で背景色が異なる場合は、可能な範囲で同じ背景色へそろえて比較します。
ブラウザによる差を確認するときは、同じ端末で複数の一般的なブラウザを使い、同じURL、同じ視点、同じ表示倍率で比べます。一つの環境だけで色が変わる場合は、ブラウザ、GPU設定、拡張機能、OSの色管理、保存された表示データなどが影響している可能性があります。
画面を暗くする拡張機能、ハイコントラスト表示、夜間モードなどが有効になっていると、三次元表示の色も変わることがあります。検証時には、追加機能を無効にした初期状態に近い閲覧環境を用意します。
モニターには、明るさ、コントラスト、色温度、映像向け表示、写真向け表示、省電力表示などの設定があります。表示を強調するモードでは、彩度やコントラストが高くなり、点群の色が実際より鮮やかに見えることがあります。
周囲の明るさに合わせて画面輝度や色温度を自動変更する設定も、比較を難しくします。昼間と夜間で色が変わる場合や、明るい部屋と暗い部屋で見え方が異なる場合は、自動調整を一時的に停止し、一定の画面条件で確認します。
社内や協力会社と色味を比較する際は、モニターを撮影した写真だけで判断しないことも重要です。画面写真には、撮影機器側の自動露出やホワイトバランス、画面の反射、撮影角度の影響が加わります。可能であれば、同じ視点で取得した画面保存データを共有し、元のテクスチャ画像と並べて確認します。
ガンマ異常と別の表示不具合を切り分ける方法
点群OBJアップロード後に色が変わったとき、すぐにガンマ値を変更すると、原因の切り分けが難しくなります。まず、色味の変化が色空間や転送特性の不一致によるものか、テクスチャ参照、照明、法線、圧縮、露出などによるものかを見分けます。
モデル全体で中間調の階調が一様に変化し、模様やテクスチャの位置は正しい場合は、入力色空間や出力色空間の不一致が候補になります。ただし、暗くなったか明るくなったかだけでは、どの変換が不足したかを断定できません。
モデル全体が白っぽくなり、黒い部分が灰色へ持ち上がり、明部の色差が失われている場合は、出力変換の重複だけでなく、露出、トーンマッピング、自動補正も確認します。彩度だけが不自然に高い場合は、色空間の変換や広色域画像の扱いも候補です。
模様や写真の情報が消え、単色の面になっている場合は、テクスチャ参照に失敗している可能性があります。この状態でガンマを変えても、元の色は復元できません。OBJ、MTL、テクスチャ画像の関連付けを確認します。
特定の面だけ暗い、見る方向によって黒くなる、モデルを回転すると明暗が大きく変わる場合は、照明、法線、面の表裏、材質の問題を疑います。色空間の不一致は通常、視点を変えたときの変化よりも、モデル全体の階調傾向として現れます。
色の境界に四角い乱れがある、細かな模様がにじむ、同系色の階調が段階状になる場合は、画像圧縮、テクスチャ縮小、量子化の可能性があります。アップロード先がテクスチャを自動変換している場合も、細かな色差が失われます。
アップロード直後だけ色が粗い、時間がたつと高精細になる場合は、サービス固有の低解像度プレビューや変換処理中の表示である可能性があります。ただし、すべてのサービスが同じ動作をするわけではないため、処理完了表示や仕様を確認してから判断します。
同じファイルを再アップロードしても変化が反映されない場合は、古い表示データ、ブラウザキャッシュ、同名ファイルの取り違えが候補になります。検証では版番号を付けた別名で登録し、アップロード日時と設定を記録すると比較しやすくなります。
色味の問題を切り分けるときは、元画像、テクスチャ画像、アップロード前のローカル表示、アップロード後の照明なし表示、通常表示という順番で比較します。どの段階から変化しているかが分かれば、確認すべき設定を限定できます。
再アップロード前に実施したい検証手順
大容量の点群OBJを何度もアップロードして検証するのは効率的ではありません。問題が発生している範囲を小さく切り出し、軽量な試験モデルを作ると、設定変更と結果確認を短時間で繰り返せます。
試験範囲には、暗い部分、中間的な明るさ、明るい部分を含めます。可能であれば、灰色の構造物、土、植生、路面、標識など、異なる色を持つ対象が入る範囲を選びます。単一色に近いモデルでは、階調変化と色相の偏りを判断しにくいためです。
最初に、元画像と生成されたテクスチャ画像を比較します。この段階で色が変わっていれば、入力画像、画像編集、テクスチャ生成、画像保存を見直します。テクスチャ画像が正常であれば、次の段階へ進みます。
次に、OBJ、MTL、テクスチャ画像を一つの検証用フォルダーへまとめます。MTLに記載された画像名と実際のファイル名が一致しているか、画像が別フォルダーや絶対パスを参照していないかを確認します。
アップロード前に、OBJをローカルの三次元表示環境で開きます。ここですでに暗い場合は、OBJ書き出し、MTL、頂点カラー、テクスチャの色空間、ローカル表示設定に原因があります。ローカルでは正常で、アップロード後だけ変わる場合は、アップロード先の変換、材質、照明、出力設定が確認対象です。
アップロード先では、変更できる範囲でガンマ、露出、コントラスト、トーンマッピング、照明を既定値へ戻します。その状態で同じ視点の画面を保存し、基準とします。
次に、一つの設定だけを変更します。入力色空間の指定を変更したら、露出や照明は変えません。露出を変更するときは、色空間の設定を基準へ戻します。このように一項目ずつ試すことで、どの設定が変化に影響したかを判断できます。
比較時は、視点、拡大率、背景色、モデルの向き、画面輝度をそろえます。視点やモデルの向きが変わると照明の当たり方も変わるため、同じ色設定でも異なって見えます。
検証用ファイルは上書きせず、設定ごとに分けて保存します。色補正なし、sRGB指定、陰影なし、圧縮条件変更など、内容を識別できる名称を付けます。アップロード日時も記録すると、古い表示結果との取り違えを防げます。
目視だけで差を判断しにくい場合は、同じ位置を画面保存し、並べて比較します。ただし、画面上の色には照明や出力変換が含まれるため、テクスチャ画像の数値と完全に一致するとは限りません。数値比較は、元画像との完全一致を証明するためではなく、設定変更による変化量を確認するために使います。
試験モデルで適切な設定を確認できたら、同じ条件で本番データを書き出します。本番データをアップロードした後も、試験モデルと同じ箇所を確認し、データ量、テクスチャ解像度、自動圧縮の違いによる変化がないかを確認します。
色味の変化を防ぐための運用ルール
点群OBJアップロードのたびに担当者が目視で色を調整すると、案件や作業者によって結果がばらつきます。継続的に点群を作成、共有する場合は、撮影から表示確認までの条件を標準化することが重要です。
撮影時は、極端な露出差を減らします。明るい空と暗い構造物を同時に撮影する環境では、画像ごとの明るさが大きく変化しやすくなります。同じ対象を複数方向から撮影する場合も、時間帯や天候が大きく変わると、テクスチャ上に色の継ぎ目が生じる可能性があります。
入力画像を処理する際は、色空間、明るさ補正、ホワイトバランス、コントラストの扱いを統一します。案件ごとに異なる設定を使う必要がある場合は、変更内容と理由を記録します。
テクスチャ生成では、画像統合、色調補正、解像度、圧縮率、陰影の扱いを標準化します。見栄えを良くする設定と、現況を比較しやすくする設定は必ずしも同じではありません。業務目的に合わせて基準を決めます。
施工記録や現況確認では、色を過度に強調すると、表面状態を誤認する可能性があります。暗部を見やすくする補正も、明部の情報を失わない範囲で行います。見やすさと再現性のどちらを優先するかを事前に決めておくことが大切です。
OBJの書き出しでは、色補正をテクスチャへ反映するか、表示側で調整するかを統一します。両方で同種の補正を行うと原因追跡が難しくなるため、どの工程を基準にするかを明確にします。
OBJ、MTL、テクスチャ画像は一つのデータセットとして管理します。異なる書き出し結果のファイルを混在させず、一回の書き出しごとに専用フォルダーへ保存します。
ファイル名の規則も統一します。案件名、作成日、版番号、設定の種類などを識別できる名称にすると、再アップロードや比較時の取り違えを防げます。MTLから参照されるテクスチャ画像の名前を変更した場合は、参照内容も更新します。
アップロード先の確認条件として、背景色、照明、露出、入力色空間、出力色空間、トーンマッピング、視点を決めます。同じデータでも確認条件が違えば、色の合否判断が変わります。
基準となる小さな試験モデルを保存しておく方法も有効です。閲覧環境の更新、ブラウザの変更、端末の入れ替えがあったときに同じモデルを表示すれば、表示処理の変化を早期に確認できます。
社内で色の確認結果を共有するときは、単に「暗い」「薄い」と表現するだけでなく、元画像、テクスチャ画像、ローカル表示、アップロード後のどこで違いがあるかを記録します。モデル全体なのか、一部の面だけなのか、中間調だけなのかも共有すると、原因を絞り込みやすくなります。
アップロード前の確認工程を標準手順へ組み込むことも重要です。大容量データをすべて処理してから色の問題に気づくと、再書き出しと再アップロードに大きな手間がかかります。小さな範囲で試験し、色と形状の両方を確認してから本番データを処理する方が効率的です。
まとめ
点群OBJアップロード後に色味が変わる場合は、ガンマの数値だけを変更するのではなく、色が入力から表示までどのように受け渡されているかを段階的に確認することが重要です。
一つ目の見直しは、入力画像とテクスチャ画像の色空間です。元画像、生成されたテクスチャ、書き出し後の画像を比較し、どの段階で色が変化したかを確認します。
二つ目は、OBJ、MTL、テクスチャ画像、頂点カラーの受け渡しです。テクスチャ参照が切れている場合や、マテリアル色とテクスチャが組み合わされている場合は、ガンマを変更しても元の色を再現できません。OBJの頂点カラーは拡張的な記法であり、対応状況を事前に確認する必要があります。
三つ目は、アップロード先の入力変換、照明計算、画面出力変換です。変換の不足や重複による見え方は、どの段階で起きたかによって暗くも明るくもなり得ます。色空間、露出、トーンマッピングは一項目ずつ固定して確認します。
四つ目は、書き出し時の色補正です。作業画面の表示補正がテクスチャへ反映されるか、陰影や露出補正が別工程でも重なっていないかを確認します。画像圧縮やテクスチャ統合による劣化も、ガンマ異常と取り違えないようにします。
五つ目は、照明、ブラウザ、端末、モニターの条件です。同じデータでも照明や背景色が違えば、色の印象は変わります。複数端末で同じ変化が起きるかを確認し、比較時の表示条件をそろえます。
原因調査では、小さな試験モデルを使い、元画像、テクスチャ、ローカル表示、アップロード後の表示を順番に比較します。一度に複数の設定を変えず、設定ごとの結果を保存することで、再現性のある条件を見つけやすくなります。
現場で取得した点群や三次元データを継続的に活用するには、撮影、生成、OBJ書き出し、アップロード、表示確認までの工程を標準化することが大切です。利用目的と対応機能を確認したうえで、LRTK Phoneを含む現場向け計測機器や点群共有環境を組み合わせることも、作業手順を整理する選択肢になります。