アカウント名:
パスワード:
絵画は完全な平面ではないので3Dデータとして残すべきではなかろうか?
2Dの場合は、ある小さな色つきの長方形(正方形)を並べたデータとして保存する、というデファクトスタンダードなデータ形式が存在するけど、3Dの場合ってそんな、デファクトスタンダードとなるような保存形式って存在するのだろうか?色つきの直方体(立方体)を並べるの? それともポリゴンを並べるの? キャンバスが布だったら、繊維の一本一本をポリゴン化した方が良いのでは? そういえば遮光器土偶を3Dデータ化したって話題を最近テレビで見たけど、そんな感じになるの? まあ3Dに対して完全など素人ならではの疑問なんだけど。
今回のようにスキャンして保存するという前提なら、直方体を並べる方式か、2D画像を複数枚並べて視差を表現する方式のどちらかが実現し易い範疇な気がする。
2Dでも3Dでも、繊維とか多角形とかの組み合わせで画像を表現する方式はあるけど(3DのゲームやCG動画はそう)、データ作成を自動化するところに技術的なハードルがある。// 最近の画像認識技術を使えば実現出来ても不思議はないと思うけど、もうあるのかな?
> 遮光器土偶を3Dデータ化したって話題NHKのサイトで見られるやつは、(見た感じでは)多角形の表面に2D画像を貼り付けた方式ぽい。拡大するとツルツルした形状。多分人間のモデラーが頑張ってる。その部分を自動化しないと絵画の複雑な表面を表現するのは厳しいんじゃなかろうか。
3D は色々なフォーマットがあるけど、ポリゴンベースなら Web3D で使う VRML(今は X3D?)かな。
> 色つきの直方体(立方体)を並べるソリッドベースだとデファクトスタンダードがない(ので色んな業界がデータ交換で困り、下請けは同じアプリ同じバージョンを買わないといけない地獄)。ボクセルベースについては詳しくないけど、研究系ではnetCDFなるものが使われているらしい。
> 繊維の一本一本をポリゴン化した方が良いのでは?記録用ではなく閲覧用であるなら、「キャンバスが布である」情報を載せた上でそれ用のレンダリングをした方が見栄えと速度の両立ができるかな。
ここまで巨大なテクスチャを表示するのって、ストリーミング技術からんできて大変だよなぁと思ったけど
ふと、ジョン・カーマック氏が中心となって開発したid TECH 5の特徴的機能「メガテクスチャ」ならうまくやれるんじゃね?
って思った
色付きの直方体が拡張としては簡単そうですけどね。
色の分解能が出ていませんでしたが、乱暴な計算ですけど各セル 8 バイト分くらい使ってるみたいですが、X,Y 以外に Z 方向をたとえば 2 バイト分追加取ったとしても 717 Gpx なら 1.4TB しか増えませんし、それで凸凹分解能を画像と同じサイズつまり立方体にするなら 65,536 段階で 13k μm ということで、一番凹んだところを 0 として 13mm の出っ張りまで再現できます。いわゆる油絵くらいの絵画ならその分解能相当の高さ方向に 2Bytes 足すだけで、それなりに情報量保存となりそうですがいかがでしょうかねぇ。
現代絵画とかになるともっと高さ方向が必要かもしれませんが、古典的絵画なら充分そうに思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
2Dではなく (スコア:5, すばらしい洞察)
絵画は完全な平面ではないので3Dデータとして残すべきではなかろうか?
Re:2Dではなく (スコア:0)
2Dの場合は、ある小さな色つきの長方形(正方形)を並べたデータとして保存する、というデファクトスタンダードなデータ形式が存在するけど、3Dの場合ってそんな、デファクトスタンダードとなるような保存形式って存在するのだろうか?
色つきの直方体(立方体)を並べるの? それともポリゴンを並べるの? キャンバスが布だったら、繊維の一本一本をポリゴン化した方が良いのでは? そういえば遮光器土偶を3Dデータ化したって話題を最近テレビで見たけど、そんな感じになるの? まあ3Dに対して完全など素人ならではの疑問なんだけど。
Re: (スコア:0)
今回のようにスキャンして保存するという前提なら、直方体を並べる方式か、2D画像を複数枚並べて視差を表現する方式のどちらかが実現し易い範疇な気がする。
2Dでも3Dでも、繊維とか多角形とかの組み合わせで画像を表現する方式はあるけど(3DのゲームやCG動画はそう)、データ作成を自動化するところに技術的なハードルがある。
// 最近の画像認識技術を使えば実現出来ても不思議はないと思うけど、もうあるのかな?
> 遮光器土偶を3Dデータ化したって話題
NHKのサイトで見られるやつは、(見た感じでは)多角形の表面に2D画像を貼り付けた方式ぽい。拡大するとツルツルした形状。
多分人間のモデラーが頑張ってる。その部分を自動化しないと絵画の複雑な表面を表現するのは厳しいんじゃなかろうか。
Re: (スコア:0)
3D は色々なフォーマットがあるけど、ポリゴンベースなら Web3D で使う VRML(今は X3D?)かな。
> 色つきの直方体(立方体)を並べる
ソリッドベースだとデファクトスタンダードがない(ので色んな業界がデータ交換で困り、下請けは同じアプリ同じバージョンを買わないといけない地獄)。
ボクセルベースについては詳しくないけど、研究系ではnetCDFなるものが使われているらしい。
> 繊維の一本一本をポリゴン化した方が良いのでは?
記録用ではなく閲覧用であるなら、「キャンバスが布である」情報を載せた上でそれ用のレンダリングをした方が見栄えと速度の両立ができるかな。
Re: (スコア:0)
ここまで巨大なテクスチャを表示するのって、ストリーミング技術からんできて大変だよなぁと思ったけど
ふと、ジョン・カーマック氏が中心となって開発したid TECH 5の特徴的機能「メガテクスチャ」なら
うまくやれるんじゃね?
って思った
Re: (スコア:0)
色付きの直方体が拡張としては簡単そうですけどね。
色の分解能が出ていませんでしたが、乱暴な計算ですけど各セル 8 バイト分くらい使ってるみたいですが、X,Y 以外に Z 方向をたとえば 2 バイト分追加取ったとしても 717 Gpx なら 1.4TB しか増えませんし、それで凸凹分解能を画像と同じサイズつまり立方体にするなら 65,536 段階で 13k μm ということで、一番凹んだところを 0 として 13mm の出っ張りまで再現できます。
いわゆる油絵くらいの絵画ならその分解能相当の高さ方向に 2Bytes 足すだけで、それなりに情報量保存となりそうですがいかがでしょうかねぇ。
現代絵画とかになるともっと高さ方向が必要かもしれませんが、古典的絵画なら充分そうに思います。