忍者ブログ
場所取り そのうち引っ越すかも http://maglog.jp/gltest/
[1] [2] [3]
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

最近動画などを編集していて、 HDD が圧迫されつつあるので、要らない巨大ファイルを発見するためのスクリプトを書いてみた。

ディレクトリツリーを再帰的に辿ってツリー全体のサイズを集計する機能と、ディレクトリツリー内でトップ20までの大きさのファイルをリストアップする機能がある。

動画を編集していると中間ファイルもやたらとデカいので、GB単位で空き容量が消えていく。中間ファイルは最終的には必要ないので消せば良いのだが、消すことを忘れていたり、消していいファイルであるか否かを忘れていたりする。そんな中でディスクを多く消費しているファイルからチェックしていけば作業効率が良いので、こんなものを作ってみたわけである。

コマンドライン上で引数を与えないとカレントディレクトリを、引数を与えるとそのディレクトリをチェックする。深いディレクトリツリーの探索にはそれなりに時間がかかる。また、最後にサイズでソートするので処理中にはアウトプットされず、終了時にまとめてリストが出力される。

例:
perl lif.pl
perl lif.pl C:\some\directory\path


出力例:
Directory list in perl:
       0.434:   perl/sucren.pl
       1.752:   perl/lif.pl
       2.918: d perl/.svn
       5.104: d .

Top 20 largest single files:
       0.002: perl/.svn/format
       0.232: perl/.svn/all-wcprops
       0.434: perl/sucren.pl
       0.434: perl/.svn/text-base/sucren.pl.svn-base
       0.521: perl/.svn/entries
       1.729: perl/.svn/text-base/lif.pl.svn-base
尚、単位はKBである。

Windows では動作したが、他のプラットフォームでどうなるかはテストしていない。
Perl のバージョンは 5 以上。

書きなぐったスクリプトなので実行効率の点ではあまりよくないかもしれない。もし使う上で気に入らないなら、スクリプトなので好きなようにいじっちゃってください。あと、使ったために起こった損害については責任持てませんよ。
PR
ブログの趣旨とはかなり離れるが、ふとやってみたくなったので微速度撮影(正確な呼び方はよくわからないけど、英語では time lapse というらしい)してみた。

こういう動画は高価な専門の機材を持っていないとできないものと思っていたが、意外と簡単にできておもしろい。

使ったカメラは安物のwebカメラとコンパクトデジカメの2つだ。

4番目の動画まではwebカメラで撮ったものだが、さすがに画質は良いとはいえない。

5,6番目の動画はデジカメでインターバル撮影して連結したもの。最後の動画はのHD相当(1280x960)のピクセル数だ。残念ながら明瞭に撮れる天候のコンディションではなかったが、コンパクトデジカメでHD動画が撮れる可能性を示した面白い結果だ。

動画は「続きを読む」で。
 

gltestss110s.jpg RIMG1558s.jpg

前回で取り上げた地形のハイトマップ(標高データ)は、解像度が約100mで
あり、人間スケールのオブジェクトを置くには少々粗い。そこで、頂点を補完することを考えてみた。

単なる線形補間だと、曲率の高い地点で不自然な「折れ曲がり」が見えてしまうので、スムーズな補間を行いたい。この要求を満足するものに自然スプライン補間があった。

理論的なところは全くフォローできていないが、下のページなどを参考にして2次元スプライン補間を実装することができた。

http://next1.cc.it-hiroshima.ac.jp/MULTIMEDIA/numeanal1/node16.html


これは補間を行いたい区間の両端と、その一つ外側のデータ点のみがあれば補間できるため、動的LODによってポリゴンを削減した部分まで計算に入れる必要が無く、比較的高速にオンメモリで計算できるという利点がある。ただし、地形のような莫大な数の点を補間するとなると計算のオーバーヘッドも無視できなくなってくるので、オフライン計算やキャッシュが有効であろう。

1枚目の画像はSRTM3をデータ源としてレンダリングした富士山頂付近をキャプチャしたものの補間前と後の比較である。画像では補間は16分割して行ったが、理論上はいくつにでも分割できる(厳密に言うと、ピラミッドバッファのサイズから上限が決まってくる)。

なお、実際の富士山頂にも登ってみたが、2枚目の画像のような光景だった。

リアルの地形データからなめらかな地形を描画したいときには、有効な方法ではなかろうか。

続きにスプライン補間のソースを掲示する。
 

gltestss98.jpg gltestss99.jpg

以前から北米のハイトマップは手にしていた(グランドキャニオン)が、今回はより身近な地形データを使ってみた。

今回のデータソースもやはり NASA のプロジェクトになる。
Visible Earth の BMNG Raw Topography というコンテンツだ。

http://visibleearth.nasa.gov/view_rec.php?id=8391

これは全世界を約500mのメッシュで区切ったラスタデータで、 86400x43200 の解像度を持つ。ダウンロードしたZipファイルを展開すると 7GB にもなる膨大なデータだ。標高データはメートル単位で記録されている。

これさえあれば、地球上のどの点でもそこそこの正確さで再現できるが、あまりにも重いのでメインメモリに乗りきらないのが難点である。
少し気になるのは、ビッグエンディアンと説明には書いてあるのだが、実際にはリトルエンディアンであることだ。 Intel で読み込もうと思ったらバイトオーダーの変更が必要になる。

このデータは SRTM30 と RAMP2 という二つのサーベイの結果を合成したものらしい。それぞれ赤道周りと極地方を計測したものだ。どちらもレーダー衛星であるが、これだけの分解能をもつレーダー測地はなかなかすごい技術だと思う。

1枚目の画像はこの膨大なファイルをピクセル間引きして表示しているところ。

2枚目の画像は富士山付近を切り取って表示したものである。

他に日本の標高データソースとしては国土地理院の電子地図があるが、CD媒体で7500円もする。

http://www.jmc.or.jp/data/gsi.html


これに対し、以下のようなオープンな利用規約でデータを提供してくれるところは、さすが NASA といったところか。

NASA Terms of Use

For all non-private uses, NASA's Terms Of Use are as follows:
The imagery is free of licensing fees
NASA requires that they be provided a credit as the owners of the imagery

Visible Earth Addendum

Beyond the NASA Terms, the Visible Earth team requests, but does not require:
The Visible Earth be provided a credit as the location that the imagery was found at
A URL be provided, either to the Visible Earth (http://visibleearth.nasa.gov/) or to the page providing the link to the used image.
 
billiardss04.jpg

 
今まで特に不便を感じていなかったのでトライしていなかったが、 OpenGL を扱う上で大きなハードルになっている多バイト文字の描画について、今回は実験の結果をまとめる。 (尚、 DirectX の言語対応についてはよく知らないが、世の中には右手系の座標空間で日本語を使いたい人もいるはずだ!)

長いので全文は「続きを読む」で。


忍者ブログ [PR]
カレンダー
04 2024/05 06
S M T W T F S
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
フリーエリア
最新コメント
最新トラックバック
プロフィール
HN:
gltest
性別:
非公開
自己紹介:
バーコード
ブログ内検索
アクセス解析