点群OBJにおける頂点色の基本
点群データをOBJ形式でアップロードしたところ、点の位置や形状は表示されるのに、現地で確認できていた色が灰色や単色へ変わることがあります。構造物、地表、植生、設備、資材などを色で見分けたい場合、座標が残っていても色情報が再現されなければ確認作業に支障が生じます。
原因を調べる前に押さえておきたいのは、OBJが本来、三次元形状を記述するために広く使われてきたテキスト形式であり、頂点色が原仕様の必須項目ではないことです。一般的なOBJでは、頂点位置を表すv行、テクスチャ座標を表すvt行、法線を表すvn行、面を表すf行などが使われます。点を表す要素も記述できますが、点群としての読み込み方や表示方法はソフトウェアやアップロード先によって異なります。
頂点位置は、通常、vに続けてX、Y、Zの値を記録します。OBJの記述では、同次座標の重みとして第4成分のwを持つ形もあります。一方、頂点色へ対応する一部の実装では、X、Y、Zの後ろに赤、緑、青の値を追加するxyzrgb形式の拡張表現が使われます。この頂点色表現は広く採用されているものの、すべての読み書き環境で同じように扱われる保証はありません。
そのため、v行に座標より多くの数値が並んでいるだけで、それらをすぐに色情報だと判断するのは安全ではありません。第4成分がwなのか、後続の三成分がRGBなのか、さらに独自の属性が追加されているのかは、出力元の仕様と実際の行構造を合わせて確認する必要があります。
また、点群の画面表示に色が付いていても、その色が各点へ保存されたRGBとは限りません。高さ、反射強度、分類、取得時刻などの属性に応じて、閲覧ソフトウェアが疑似色を付けている場合があります。このような表示色は、RGB属性として書き出す処理を行わない限り、OBJの頂点色として残らないことがあります。
点群OBJの頂点色が消えたときは、表示設定だけを調整するのではなく、元データにRGBがあるか、OBJへどの形式で記録されたか、アップロード先がその形式を読めるか、途中の変換で属性が残ったかを順番に確認することが重要です。
頂点色が消える原因を切り分ける考え方
頂点色が表示されない原因は、データ取得、編集、OBJ出力、変換、アップロード、表示という工程に分けて考えると整理しやすくなります。
最初に確認するのは、元の点群と出力済みOBJのどちらにRGBが存在するかです。元データにRGBがなければ、アップロード先の設定だけで実色を復元することはできません。元データにRGBがあっても、OBJ出力時に座標だけが書き出されていれば、色はその段階で失われています。
次に、OBJへ頂点色が記録されている場合は、アップロード先が同じ拡張表現へ対応しているかを確認します。OBJ対応と案内されていても、面、法線、テクスチャ、マテリアル、点要素、頂点色のすべてに対応しているとは限りません。形状だけが正常に読み込まれ、頂点色が無視される場合もあります。
その次に確認したいのが数値の解釈です。広く使われるxyzrgb形式では、RGBを0から1の範囲で表す例が一般的です。一方、元の点群属性では0から255の整数でRGBを保持することも多いため、OBJへ変換する際に正規化が必要になる場合があります。出力側と読込側の想定が異なると、白っぽい、暗い、色合いが異なるといった表示になります。
最後に、点数削減、頂点統合、座標変換、結合、面生成、再出力などの中間処理を確認します。処理機能によっては、座標だけを対象にし、RGBなどの属性を出力しないことがあります。反対に、RGBを保持できる機能でも、出力設定で対象属性を選ばなければ色が残らない場合があります。
このように、ファイル内の有無、読込側の対応、値の解釈、中間処理の四つへ分ければ、色が失われた工程を推測だけでなく実データの比較によって絞り込めます。
確認項目1 OBJファイル内に色情報が記録されているか
最初の確認項目は、アップロード対象のOBJに頂点色が実際に記録されているかどうかです。元の画面で色が見えていたという情報だけではなく、出力後のファイル内容と出力設定を確認します。
OBJは一般にテキストで記述されるため、確認用に複製したファイルから先頭付近のv行を調べられます。大容量ファイルを通常のテキスト編集ソフトで直接開くと動作が重くなる場合があるため、先頭部分を抽出できる確認手段や、行単位で閲覧できる方法を使う方が安全です。
座標のみを持つ頂点行は、基本的にvの後ろへX、Y、Zが続きます。第4成分としてwが続く場合もあります。頂点色を持つxyzrgb形式では、X、Y、Zの後ろにR、G、Bが続きます。ただし、独自拡張によって別の成分が加えられる例もあるため、成分数だけで意味を確定せず、出力元の仕様を照合します。
複数のv行を比較し、座標以外と考えられる三成分が点ごとに変化しているかを見ることも有効です。全行で同じ値が続いている場合は、単色として出力された可能性があります。後続成分が見当たらない場合は、頂点色が保存されていない可能性が高くなります。ただし、色がMTLや画像テクスチャで表現されている面モデルでは、v行にRGBがなくても色を持つことがあるため、関連ファイルの有無も確認します。
元データの属性一覧では、赤、緑、青に相当する項目が存在するかを確認します。反射強度、分類番号、高さなどしかない場合、画面上の色は疑似色である可能性があります。写真測量などから生成した点群であっても、処理条件や出力設定によってRGBを含めずに保存されることがあります。
OBJの書き出し設定に、頂点色、カラー属性、RGB、点属性などに相当する項目がある場合は、その項目が有効かを確認します。名称は環境ごとに異なるため、OBJを選択しただけでRGBも必ず含まれるとは考えない方が安全です。
元データにRGBがあり、色を含める設定も有効なのに、出力後のv行へRGBが記録されていない場合は、その出力機能がxyzrgb形式へ対応していない可能性があります。この場合は、同じ環境で利用できる別の出力方式を検討するか、アップロード先が受け付ける別形式を確認します。
確認は先頭数行だけで終わらせず、可能であれば中間や末尾付近のv行も見ます。通常は全頂点で同じ構造になりますが、変換不良やファイル結合の影響で、途中から成分数が変わる場合もあるためです。
OBJ内の色の有無を最初に確認すれば、問題が出力前にあるのか、アップロード後にあるのかを早い段階で切り分けられます。
確認項目2 アップロード先が頂点色の拡張表現に対応しているか
OBJ内に頂点色が記録されていることを確認できたら、次にアップロード先がその表現を読み取れるかを調べます。
OBJの頂点色は原仕様の必須項目ではなく、xyzrgbなどの拡張的な慣行として扱われています。そのため、OBJの形状へ対応する読込機能であっても、頂点色を保持しない場合があります。読込処理がX、Y、Zだけを取得すれば、点の位置や面は表示できても、R、G、Bは反映されません。
点群としてアップロードする場合は、頂点色への対応だけでなく、OBJ内の点をどのように扱うかも確認します。点要素を参照して表示する仕組み、面だけを対象とする仕組み、v行を点群として独自に解釈する仕組みなどがあり、対応範囲はアップロード先によって異なります。
受け入れ仕様では、OBJ対応という記載だけで判断せず、点群として読み込めるか、xyzrgb形式の頂点色を保持できるか、アップロード後に頂点色を表示するモードがあるかを確認します。内部変換が行われるサービスでは、変換後のデータ構造へRGBが引き継がれるかも重要です。
切り分けには、少数の点で構成した確認用OBJが役立ちます。実データと同じ行構造を使いながら、赤、緑、青など判別しやすいRGBを設定し、アップロード後に色の違いが出るかを確認します。実データが点要素を含むなら確認用データも同じ構造にし、面を含むなら同じように面を持たせます。構造を変えると、頂点色ではなく点や面の対応差を検証してしまうためです。
確認用データでも単色になる場合は、頂点色が読み取られていない可能性があります。一方、確認用データは正常で実データだけが単色になる場合は、値の範囲、成分数の不統一、中間変換、ファイル規模など別の要因を調べます。
アップロード後の表示モードも確認します。RGBが保持されていても、単色、標高色、分類色、反射強度色など別の表示属性が選択されていると、元の頂点色は見えません。元のカラー、RGB、頂点色、実色などに相当する表示へ切り替えられるかを調べます。
読み込み中の仮表示や表示品質の切り替えについては、アップロード先ごとに挙動が異なります。単色で見えた時点ですぐに色が削除されたと断定せず、解析や読み込みが完了しているか、同じデータを別の表示条件で確認しても結果が変わらないかを見ます。ただし、特定のサービスが負荷軽減のために色属性を省略すると一般化することはできないため、最終判断はそのサービスの仕様に基づいて行います。
アップロード先の対応状況が不明な場合は、確認用データの結果と受け入れ仕様を合わせて判断します。小規模な検証を先に行えば、大容量の現場データを何度も変換する負担を抑えやすくなります。
確認項目3 色の数値範囲と並び順が正しいか
OBJ内に色情報があり、アップロード先も頂点色へ対応している場合は、RGBの数値範囲と並び順を確認します。
広く使われるxyzrgb形式では、R、G、Bを0から1の範囲で記録する方法が一般的です。たとえば、赤を強くしたい点ではRが1に近く、GとBが0に近い値になります。実際の対応範囲は読込実装によって異なるため、アップロード先の仕様が示されている場合は、その定義を優先します。
元の点群では、RGBを0から255の整数として保持していることがあります。この値をそのまま、0から1を想定するOBJ読込機能へ渡すと、期待どおりに表示されない可能性があります。反対に、0から1へ正規化された値を、0から255を前提とする独自の変換処理へ渡した場合は、暗く見えることがあります。
したがって、0から1と0から255の両方をOBJの共通仕様として扱うのではなく、元属性の範囲、OBJ出力時の変換、アップロード先の期待値を分けて確認することが重要です。0から255のRGBを0から1へ変換する場合は、通常、各成分を255で割りますが、実際の変換は出力機能の仕様に従います。
色成分の順序も確認します。一般的なxyzrgb形式はR、G、Bの順ですが、表計算データや独自形式から変換する際に列を取り違えると、赤い対象が青く見えるなど、現地と異なる色になります。色が完全に消えるのではなく、色相だけが大きく変わる場合は、列の割り当てを確認します。
追加成分の扱いには特に注意が必要です。v行の第4成分はwとして使われる場合があり、独自実装ではRGB以外の値が追加されることもあります。RGBAのような表現を出力する環境があっても、それをOBJの一般的な共通仕様とみなすことはできません。透明度に見える値がある場合も、読込側が同じ意味で解釈するとは限らないため、出力元と読込先の仕様を照合します。
値が負数になっている、想定範囲を超えている、数値ではない文字が混じっている、一部のv行だけ成分数が違うといった不整合も確認します。読み込み側によっては、該当行を無視したり、RGBを欠落扱いにしたり、ファイル全体の解析を中止したりします。
数値の区切りと小数点も確認します。OBJでは通常、空白で成分を区切り、小数点にはピリオドを使います。カンマ区切り、全角空白、見えにくい制御文字などが混在すると、読み込み結果が変わる可能性があります。変換元が表計算形式や地域設定の影響を受けるテキスト形式である場合は、出力後の記述を実際に確認します。
複数の地点からv行を抽出し、R、G、Bが適切に変化しているかも見ます。三成分がすべて同じ値であればグレースケールとして出力されている可能性があり、特定の成分だけが常にゼロなら列の欠落や割り当てミスが考えられます。
修正は、元の大容量OBJを直接一括置換するより、元データから正しい設定で再出力する方が安全です。座標値と色値が同じ行に並ぶため、単純な文字置換では座標まで変更するおそれがあります。まず複製した少量データで期待値を確認し、結果が正しいと判断できてから全体を再出力します。
確認項目4 変換や軽量化の途中で色情報が失われていないか
四つ目の確認項目は、元データからアップロード用OBJを作るまでの中間処理です。点数削減、結合、座標変換、面生成、再出力などを行うと、設定や機能の仕様によってRGBが引き継がれないことがあります。
点群処理には、座標だけを対象とする機能と、RGB、反射強度、分類などの属性も保持できる機能があります。処理画面に属性選択がある場合は、X、Y、ZだけでなくR、G、Bが出力対象になっているかを確認します。機能が属性を保持できるとしても、既定設定でRGBが外れている可能性があります。
点の間引きでは、単純に一部の点を選ぶ処理なら、選ばれた点のRGBを残せる場合があります。一方、複数点を代表点へまとめる処理では、代表点の色をどのように決めるかが必要です。平均、最近傍点の採用、属性の破棄など、結果は処理方式によって異なります。色境界を重要視する場合は、座標の軽量化だけでなくRGBの集約方法も確認します。
近接頂点の統合でも同じ問題があります。異なるRGBを持つ複数頂点が一つになると、色を平均するか、特定の点の値を採用するかによって境界の見え方が変わります。RGBを引き継がない設定であれば、処理後の頂点から色がなくなることもあります。
点群から面モデルを生成する処理では、色の表現方法が変わる場合があります。元の各点にRGBがあっても、面生成後は頂点色として保存する場合、MTLの材質色へ変換する場合、画像テクスチャへ焼き付ける場合、色を出力しない場合があります。OBJだけをアップロードして色が消えたときは、変換後にMTLや画像ファイルが作られていないかを確認します。
複数の点群を結合するときは、属性構成と数値範囲をそろえます。一方がRGBを持ち、もう一方が座標だけの場合、結合後の欠損値をどのように扱うかは処理機能によって異なります。また、一方が0から1、もう一方が0から255であれば、結合前に同じ範囲へ統一しないと表示が不自然になる可能性があります。
座標変換、原点移動、単位換算、高さ補正なども確認対象です。座標だけを変える処理であっても、新しいファイルを書き出す段階でRGBを出力対象から外せば色は失われます。処理の名称から属性保持を推測せず、変換後の属性一覧やv行を確認します。
軽量化のために色の階調を減らす処理が行われる場合は、完全な欠落ではなくても、色の差が小さくなって単色に近く見えることがあります。元データと変換後データを同じ表示条件で比較し、RGBの種類や分布が大きく変わっていないかを見ます。
圧縮ファイルでアップロードする場合は、色の方式に応じて必要なファイルが含まれているかを確認します。xyzrgb形式だけで色を表すOBJであれば、RGBはOBJ内にあります。MTLや画像テクスチャを使う場合は、OBJ、MTL、画像の参照関係が保たれている必要があります。
原因を特定するには、各工程で確認用ファイルを保存します。最初のOBJ出力直後、点数削減後、座標変換後、結合後というように段階ごとのv行と表示を比較すれば、どの処理でRGBが変わったかを追跡しやすくなります。
頂点色とマテリアルやテクスチャを混同しない
点群OBJの色を確認するときは、頂点色、マテリアル、テクスチャの違いを整理する必要があります。どれも見た目へ影響しますが、色の保存場所と読込条件が異なります。
頂点色は、各頂点へR、G、Bを関連付ける方法です。xyzrgb形式では、頂点位置とRGBを同じv行へ記録できます。別画像を必要としない点は扱いやすい一方、OBJの原仕様に含まれる必須表現ではないため、対応する読込機能が必要です。
マテリアルは、主に面の表面特性を定義する仕組みです。OBJからMTLを参照し、MTL側に材質名、色、透明度、画像参照などを記録します。OBJだけを移動またはアップロードし、MTLを含めなければ、材質色が反映されないことがあります。
テクスチャは、画像を面へ対応させて色や模様を表す方法です。一般に、OBJ内のテクスチャ座標、MTL内の画像参照、実際の画像ファイルがそろう必要があります。画像への相対パスやファイル名が変わると、形状は表示されても画像が見つからず、単色になることがあります。
点だけを表示する点群では、頂点色が扱いやすい場合がありますが、面モデルへ変換した後は、頂点色、材質色、テクスチャのいずれを使うかが処理設定によって変わります。元の点群が写真に近い色で見えていても、面生成後に画像テクスチャへ変換されていれば、OBJ単体では同じ見た目を再現できません。
OBJ内のv行へRGBがあり、関連画像を使わない構成なら、頂点色として渡している可能性があります。mtllibやusemtlの記述があり、MTLや画像が生成されている場合は、マテリアルまたはテクスチャが色の主体である可能性があります。ただし、両方を含むデータもあるため、表示側がどの属性を優先するかを確認します。
アップロード前に、色を頂点色で渡すのか、マテリアルやテクスチャで渡すのかを明確にします。方式が混在すると、アップロード先が片方だけを読み込んだり、意図しない方を優先したりすることがあります。受け入れ仕様に合わせて構成をそろえることが、色の欠落を防ぐ基本です。
原因を効率よく特定する確認手順
点群OBJの頂点色が消えたときは、大容量の現場データを何度も変換するより、小さな確認用データで工程を分けて検証する方が効率的です。
最初に、元の点群へR、G、B属性が保存されているかを確認します。高さ、反射強度、分類などから作られた疑似色ではなく、点ごとのRGBが存在することを確かめます。
次に、色の違いが分かりやすい範囲から少数の点を抽出し、実データと同じ設定でOBJへ出力します。確認用ファイルだけ別の構造にすると、実際の問題を再現できないため、点要素、面、出力属性、数値範囲を可能な限りそろえます。
出力後は、v行の成分を確認します。X、Y、Zだけなのか、第4成分のwがあるのか、X、Y、Zの後ろにR、G、Bが続くのかを、出力仕様と照合します。この時点でRGBがなければ、元属性または出力設定の問題を優先して見直します。
RGBがある場合は、中間変換を加えずにアップロードします。表示モードを頂点色へ切り替えて色が出れば、出力直後のOBJとアップロード先の組み合わせではRGBを扱えると判断できます。色が出なければ、読込対応、点と面の解釈、数値範囲を確認します。
小規模データが正常に表示できたら、実際の工程を一つずつ追加します。点数削減後に確認し、次に座標変換後、結合後という順で比較すれば、RGBが変わった処理を特定しやすくなります。
色が暗い、白い、色相が違う場合は、R、G、Bの範囲と順序を確認します。確認用ファイルで既知のRGBを使えば、読込結果との対応を見やすくなります。編集する場合は、必ず複製した小規模ファイルを使い、元データを変更しないようにします。
各段階では、画面表示だけでなく属性の有無も確認します。表示モードが違えば、RGBが残っていても別の色に見えるためです。ファイル内の構造と表示結果を両方記録することで、原因を誤認しにくくなります。
点群OBJを安定してアップロードするための運用
頂点色の消失を防ぐには、問題が起きた後の修正だけでなく、出力条件と確認方法を標準化しておくことが重要です。
まず、取得直後の元データを保管し、編集後の点群、アップロード用OBJと分けて管理します。軽量化や変換を繰り返したファイルだけを残していると、RGBが失われた後に元の状態へ戻れません。工程ごとに保存しておけば、属性の変化を比較できます。
次に、OBJ出力時の条件を記録します。頂点色を含めるか、RGBの範囲をどう扱うか、点または面のどちらで出力するか、点数削減を行うか、座標系や単位をどうするかを残します。使用した出力機能の名称とバージョンも記録しておくと、更新後に結果が変わった場合の確認材料になります。
確認用の小規模OBJを基準データとして用意する方法も有効です。異なるRGBが明確に分かる点を含め、実運用と同じ構造で保存します。アップロード環境や変換機能を変更したときに同じファイルを試せば、対応状況の変化を確認できます。
ファイル名には、元データ、色付き出力、点数削減後、座標変換後など、工程を判別できる情報を含めます。同じ名前で上書きすると、どの段階でRGBが変わったかを追いにくくなります。特殊文字や極端に長い名称を避けることも、受け渡し時の混乱を減らす助けになります。
アップロード前には、形状だけでなく色も検査します。頂点数、座標範囲、ファイル容量に加えて、v行の成分数、RGBの範囲、値の変化、関連ファイルの有無を確認します。想定と異なる場合は、アップロード後の表示設定だけで解決しようとせず、出力工程へ戻ります。
複数の担当者が点群を扱う場合は、「色付き」の意味をそろえます。実際のRGBなのか、標高による疑似色なのか、分類色なのかによって、残すべき属性と出力方式が異なります。作業手順書では、色の種類と確認方法まで明記します。
アップロード後の確認項目も統一します。全体が単色になっていないか、現地と大きく異なる色になっていないか、一部だけRGBが欠けていないか、別の表示属性が選ばれていないかを確認します。読み込み完了前の表示だけで判断せず、処理状態も合わせて見ます。
このような運用を整えれば、頂点色が消えた場合でも、元データ、出力設定、OBJ内容、アップロード結果を順に比較できます。担当者の経験だけに頼らず、基準データと記録を残すことが再発防止につながります。
現場で取得した点群を活用する際の注意点
建設、測量、設備管理、維持管理などでは、点群のRGBが対象物の把握を助けます。地面と植生、構造物の境界、設備の位置、材料の違いなどを視覚的に確認しやすくなるためです。
ただし、頂点色は位置精度を示す情報ではありません。色が鮮明でも、座標系、標高、単位、基準位置が正しいとは限りません。反対に、RGBが表示されなくても、座標と形状が正しく保存されている場合があります。位置と色は別の検査項目として扱います。
屋外で取得した点群では、日照、影、反射、撮影方向などの影響で色むらが生じることがあります。OBJへRGBが正しく保存されていても、取得時点から暗部や白飛びが含まれている可能性があります。アップロード前後で同じ色むらが見えるなら、ファイル欠損ではなく取得条件の影響も考えます。
複数日に取得した点群を結合すると、時間帯や天候の違いによって明るさや色味が変わり、境界が目立つことがあります。これは頂点色の欠落とは別の問題です。RGBの有無だけでなく、撮影条件や色補正の方針も記録しておくと判断しやすくなります。
OBJへ変換する目的も明確にします。点の位置とRGBをそのまま確認したいのか、面モデルとして共有したいのか、閲覧用に軽量化したいのかによって、適した色の表現方法が異なります。
点群として扱う場合は、座標とRGBが点ごとに保持されることを重視します。面モデルとして扱う場合は、頂点色だけでなく、マテリアルや画像テクスチャの方が目的に合うこともあります。アップロード先で何を確認するかを先に決め、その対応範囲に合わせて出力方法を選びます。
LRTK Phoneなどで取得または出力した点群を共有する場合も、実際に保存される属性、OBJ出力時の設定、アップロード先の対応範囲を確認します。取得画面で色付きに見えたことだけを根拠に、出力後のOBJへ同じRGBが含まれると断定することはできません。
取得後は元データを保管し、少量の確認用データでRGBを検証してから対象範囲全体をアップロードすると安全です。取得、変換、アップロードを一連の工程として記録すれば、どの段階で頂点色が変わったかを追跡しやすくなります。
まとめ
点群OBJをアップロードした後に頂点色が消える場合は、まず元の点群にRGBがあるか、出力後のOBJへRGBが記録されているかを確認します。画面上の色が高さや反射強度などによる疑似色であれば、そのままでは頂点色として残らないことがあります。
OBJの頂点色は、原仕様の必須項目ではなく、X、Y、Zの後ろへR、G、Bを追加するxyzrgb形式などの拡張的な慣行です。アップロード先がOBJへ対応していても、頂点色や点群としての解釈まで対応しているとは限りません。
v行の第4成分はwである場合があるため、座標の後ろに数値があるだけで色情報と断定しないことが重要です。出力元の仕様を確認し、どの成分がR、G、Bなのかを照合します。
広く使われるxyzrgb形式では、RGBを0から1で表す例が一般的です。元データが0から255でRGBを持つ場合は、OBJ出力または読込時の変換条件を確認します。両方の範囲を共通仕様として扱わず、出力側と読込側の期待値を合わせます。
さらに、点数削減、頂点統合、面生成、座標変換、結合などの途中処理でRGBが失われていないかを確認します。処理機能が属性を保持できても、出力対象からR、G、Bが外れていれば、最終OBJには色が残りません。
頂点色、マテリアル、テクスチャは異なる仕組みです。頂点色ならOBJ内のv行、マテリアルならMTL、テクスチャならMTLや画像ファイルとテクスチャ座標が関係します。色がどこへ保存されているかを確認し、必要な関連ファイルをそろえます。
原因を効率よく特定するには、実データと同じ構造を持つ小さな確認用OBJを使い、出力直後、軽量化後、座標変換後、アップロード後を順に比較します。ファイル内の属性と画面表示の両方を確認すれば、色が失われた工程を絞り込みやすくなります。
現場で取得した点群を継続的に活用するには、元データの保管、出力条件の記録、基準となる確認用ファイルの作成、アップロード後の検査を標準化することが有効です。LRTK Phoneで取得または出力した点群についても、保存される属性とアップロード先の対応を確認しながら運用することで、色の欠落を早期に発見しやすくなります。