備忘録

備忘録というなのポエム

【論文メモ3】Reproducibility and Practical Adoption of GEOBIA with Open-Source Software in Docker Containers.

タイトル:Reproducibility and Practical Adoption of GEOBIA with Open-Source Software in Docker Containers.

著者:Christian Knoth et al.

雑誌:remote sens. 2017,9, 290

 

ざっくり:

GEOBIA(Geographic Object-Based Image Analysis)をOSや環境に依存しないように行おうというもの.

(1)異なるパッケージのソフトとバージョンの変更に対応するために,(2)複雑な解析を非専門家が行えるように,Dockerを使用した.

 

解析対象地域はスーダンで,この画像もオープンアクセス.

 

解析はOTBでPCA・セグメンテーション(Watershed)を施し,QGISでオブジェクト統計量(エッジ強度の平均)を計算.

シェープや大きさの特徴量はSAGA GISで計算.

クラスタリングなどの処理はPython

 

その後はDockerの説明が続く。

https://hub.docker.com/r/nuest/qgis-model/

 ここにそのイメージがあるらしい.

 

 感想:

筆者は「reproducibility(再現性)」と「customizability(カスタマイズ性)」にこだわっており、Githubによるスクリプトの共有だけではなく、環境そのものの構築まで再現できるようなスクリプトが必要だということがわかった。

 

また論文中に出てきた「InterIMAGE」というセグメンテーションのツールは初耳であった。もちろんOSSなので、今度いじってみたい。

 

ただSection2.4でInterIMAGEが出てきたあたりで,前後との関連がよくわからなくなった.

 

次に読みたい論文:

Knowledge-based interpretation of remote sensing data with the InterImage system: Major characteristics and recent developments. 

本文中でInterIMAGEが出てきた時に引用されていた論文。

【論文メモ2】Evaluation and Bias Removal of Multilook Effect on Entropy/Alpha/Anisotropy in Polarimetric SAR Decomposition

タイトル:Evaluation and Bias Removal of Multilook Effect on Entropy/Alpha/Anisotropy in Polarimetric SAR Decomposition

著者:Jong-Sen Lee et al.

雑誌:IEEE TRANSACTIONS ON GEOSCIENCE AND REMOTE SENSING, Vol 46, No.10, October 2008.

 

ざっくり:

一様な地域のアンサンブル平均(空間平均?)では、エントロピーは過小評価され、アニソトロピーは過大評価されると言われている。

ルック数が増えるとコヒーレンス行列<T>のランク数(dim Im<T>)が上がるため、エントロピーは増加し、アニソトロピーは減少していく。

平均化アルファ角は固有値と、固有ベクトルに関するαの両方に依存するので、ルック数が増えると増加も減少もしうる。

 

この論文では都市、森林、荒い地表を対象に、モンテカルロシミュレーションコヒーレンス行列を評価した。

 

 【前半、シミュレーションの結果】

固有値

λ1は森林ではルック数を上げると減少していったが、都市と地表面では変化がなかった。都市ではλ1とλ2、λ2とλ3の差が大きかった。

 

エントロピー

49ルック以上でその増加は緩やかになった。

これはLopez-Martinez et al.が提案する81ルックより小さく、49ルックで十分とのこと。

ただしこのシミュレーションでは独立したサンプル(ピクセルのサンプル?)の平均なので、実用では81ルックとっておけば安全とのこと。

スペックルノイズの低減には5x5(25ルック)取ることを推奨している。

 

アニソトロピー:

やはり過剰検出。どのエリアもルック数を上げるにつれ、減少。

森林部での減少の速度は他の2つに比べて非常に遅いので、バイアス問題はもっとも重要。169ルックでもまだ過剰。

Lopez-Martinez et al.は121ルックは欲しいとのこと。

地表面と都市では81ルックで十分。

 

平均アルファ角:

ルック数によって増えたり減ったり。

25ルックを推奨、バイアス除去はアプリケーションによっては必要ない。

 

【後半、バイアス除去】

 

エントロピーのバイアス除去:

バイアスを測るために、エントロピー比Rを導入。

Rは ルック数を上げると線形的に減少。さらにレーダープラットホームと周波数とも独立に、同時に線形の関係にある。

 

アニソトロピーのバイアス除去:

森林・都市・地表面ともに区分線形関数で表すしかなかった。

試験的な結果は7x7で十分であった。

 

平均化エントロピーのバイアス除去:

バイアスの影響を受けるのは地表面のみ。

5x5か7x7で十分。

 

感想:

バイアス除去は慎重にやらないと痛い目にあうということがわかった。

ただ各種フィルタ演算とマルチルックの組み合わせをどうやればいいかまでは分からなかった。

 

次に読む論文:

1,An Entropy Based Classification Scheme for Land Applications of Poarimetric SAR. :Cloude-Pottier分解の原著論文。アルファ角とエントロピーがなぜ

実験的事実と整合しているのかが知りたい。

 

2,Inversion of srface parameters from polarimetic SAR.

地表面のでこぼこさの評価にアニソトロピーを使っているらしい。

 

3, Estimation of the Equivalent Number of Looks in Polarimetric Synthetic Aperture Radar Imagery

ENLに関する論文。

 

 

【論文メモ1】Individual Tree-Crown Delineation and Treetop Detection in High-Spatial-Resolution Aerial Imagery

論文を読まなすぎて流石にマズイと思い始めたので、やる気を高めるためにレビューしていきます。

 

タイトル:Individual Tree-Crown Delineation and Treetop Detection in High-Spatial-Resolution Aerial Imagery

著者:Le Wang et al.

雑誌:Photogrammetric Engineering & Remote Sensing. Vol.70, No.3, March 2004, pp.351-357.

 

ざっくり:

木をセグメントを用いてカウントする。使用した画像は高解像度(0.6 m)のマルチスペクトルバンドの航空写真。

マルチスペクトル→PCA→1バンド→画像平滑化→エッジ検出→オブジェクト検出(第一段階)→オブジェクト検出(第二段階、Watersehd)→樹冠検出の流れ。

 

この論文の面白い所は、セグメンテーションに必要なマーカー生成を二通りで行い、それを組み合わせて行う点。

マーカー生成はLocal non-maximum suppression(3x3の窓で極大値検出)とLocal maximum on morphologically ransformed distance(外側のオブジェクトとの等値線から極大値生成)のふた通り。

 

検証は目視がメイン。

FOSS4G と リモートセンシング【FOSS4G Advent Calendar 2016 】

FOSS4G Advent Calendar 2016 21日目の記事です。

技術寄りの話はみなさんが書かれているので、FOSS4Gとリモートセンシングの外観を書きます。

 

 

 

リモートセンシング(以下、リモセン)の世界に足を踏み入れてから私の研究はOSSに支えられてきました。

リモセンの解析には商用ソフトウェアのENVI/IDL、ArcGISが有名です。

 

しかし学生の身分としてはこれらの商用ソフトウェアを使うのは敷居が高いのが現状です(仮に研究室単位で購入できても、卒業したら使えなくなってしまいます)。

 

そこで登場するのがFOSS4Gです。OSS最高、プログラミング楽しい、万歳。

しかしGIS利用のFOSS4Gの日本語文献は沢山あるのですが、ことリモセンになると一気に少なくなります(あったとしても、結構情報が古かったり…)。

 

私もこの分野に足を踏み入れた当初は、どういうツールを使えばいいのか迷いました。

そこで当時の自分に送る、リモセン分野におけるFOSS4Gのツール群を分野ごとに書いていきます。

こんなツールもあるよ、これは違うというツッコミがありましたらコメント欄にお願いします。

以下、Linux利用者の見解です。

 

CUI解析ツール

GRASS GIS

ラスタ・ベクタ解析をシェル環境で行なえます。

CUIツール群とシェル環境の相性は抜群です。ちょっとしたラスタ演算やカラーテーブル処理(GDALでもできますが)、ちょっとコアな解析(入射角計算など)を一括処理出来るのが魅力的です。

 

ただ、複雑な数式に落とし込もうとすると結構厳しかったりします。

(ラスタ演算にはr.mapcalというものを使うのですが、if演算を組み合わせて書くなど可読性に欠けます。)

 

自分の周りの人はシェル環境で使っていますが、最新のバージョンであるGRASS 7.XではPython環境での利用を推奨しているようです。GRASS環境でのデータの取扱とPythonとのやりとりがどうなっているかは把握していませんが、もしかしたらラスタ演算をPythonでサラサラと書けるのかもしれません。

 

普段はバッチ処理をする場面が多くCUIでしか使わないのですが、GUI環境もしっかりしているようです(ただGUI利用だとQGISの方が日本では人気ですね)。

 

GDAL/ogr

地理情報コマンドライン/ライブラリ群です。

コマンドラインで個人的によく使うのが

  • gdalinfo(ヘッダ情報の閲覧)
  • gdallocationinfo(緯度経度での値の取り出し)
  • gdal_translate(切り貼り)
  • gdal_warp(座標系変換)
  • gdal_merge.py(バンド結合)
  • gdal2tiles.py(タイルレイヤの作成)
  • gdal_calc(簡単なマスク処理)です。

gdalbuildvrtを使うとカラーテーブルの変換も行えます。

またコマンドラインで足りない処理はAPIを使って、PythonC++で書くことが出来ます。

 

以下のリンクも参考になります。

月の杜工房 - gdal/ogr小技集

GDALコマンド

 

GUI解析ツール

QGIS

多くは語りません。

リモセン利用としては

  • 解析した結果(Geotiff)をドラック&ドロップでレイヤ(OpenLayersQuickMapServices)と重ね合わせる
  • 値のチェック(ooプラグイン
  • ポリゴンの作成

を頻繁に使います。

プラグインを利用すればもっと便利な解析が出来るはずなのですが、如何せんリモセンデータサイズが大きすぎて(〜数百GB)、GUI利用をする機会が少ないのが現状です。

 

 

データベース

PostGIS

PostgreSQLGIS拡張を加えたものです。

大規模リモセンデータを格納するのに使えます。

csvからのポリゴンデータ一括作成で以前使いました(今思うと他のツールで事足りた気がします)。

 

・ SpatiaLite

SQLiteGIS拡張を加えたものです。

SQLiteはユーザー設定が要らないので、個人的にはPostGISより使い機会が多いです。

 

SAR解析

PolSARPro

ポラリメトリックSARの解析の定番(?)です。

公式のドキュメントの物理テキストがやたらと充実しています。

Linuxでもインストールのバッチファイルのパスを変えればインストールできます。

とらりもん - PolSARpro

 

MapReady

Alaska Satellite FaciltyがリリースしているSAR解析ツール。

GUIツールとCUIツールがあります。

ドキュメントがかなりしっかりしているので期待していたのですが、GUIツールがLinuxにどうしても入りませんでした。

 

データのフォーマットが独自のものを使用しており、CUIツールで自動処理しようとするもツール群の流れがつかめず挫折。GUIが使えれば調査できるのですが…無念。

 

SAR Training Processer

こちらもAlaska Satellite Faciltyがリリースしているツールです。

SAR解析で使う数学を、段階を追って勉強できます。

こちらはLinuxでもインストール出来ました。

とらりもん - SAR Training Processer

 

Sentinel-1 Toolbox

Sentinel-1と名前がついていますが、他のSAR衛星もサポートしています。

こちらはインストールは出来たのですが、データのインポートでJavaのエラーが出て断念。

 

大気補正

6SV

大気補正の勉強の時に使ってみたいと思っているツールです。

Fortlan 77 で書かれているらしいです。

 

幾何補正

・gdal_translate、gdalwarp

 

可視化

OpenLayers

gdal2tiles.pyで解析結果をタイルにして、既存のレイヤと重ね合わせたり。

 

番外編

Google Earth

FOSS4Gではないですが、リモセン分野での利用者は多いです。

点群データと時系列衛星画像の整合性のチェック、ポリゴン・教師点の作成などが主な利用用途のようです(私は普段利用していないので…)。

 

最後に

リモセン分野のノウハウは以下のサイトに集約しています。

とらりもん - とらりもんHOME

FOSS4G利用者の皆様の知見をこちらのサイトに還元していただければ幸いです。

PRML勉強会 #4@筑波大学 に参加してきた

去る2015/05/29に筑波大で開催された「PRML勉強会 #4」に参加してきました。

初回から参加してきて、第二回・三回と発表してきたのですが、今回はレポートの締切が切羽詰まっていたので見学枠での参加となりました。

 

 

第二回まではPRML本の輪講という形で進めていったのですが、第三回からはPRML本+αという形になりました。

輪講のみだとどうしても発表がただの本の写しになりがちですが(実際に第二回の発表では自分がそうなってしまった)、各人が「PRML本の先のテーマ(応用)」や「PRML本では説明しきれていない所の補助」(+αの部分)を紹介していくことにより、興味を持って聞くことが出来ました。

 

自分は情報科学畑の人間ではないので、応用例の紹介はかなり有り難かったです(普段聞く機会が無いので…)。

 

他にもロバスト推定として、RANSACアルゴリズムの紹介がありました。

第二章でロバスト性について言及されており、t-分布で検証してみようと思ったのですが中々上手く行かず…。

RANSACアルゴリズムアルゴリズム自体は非常にシンプルなようなので、これなら自分でも実装・検証できそうです。

 

辻さんの発表では、自分が読み流していた「最小二乗法の幾何学的意味」について解説していただきました。

直交性の証明はかなりシンプルで美しく、唸るものがありました。

tsujimotter.hatenablog.com

(辻さんのブログです)

主催者の上田さんの発表ではIPythonの開発が終了し(!)、Project Jupyterに移り変わりつつあることを知りました。

また可視化ライブラリのSeabonのデモに、上田さんのセンスを感じました。

 

PRML勉強会#4 @筑波大学 を開催した #PRML学ぼう - Laplace's Demon

(上田さんのブログです)

 

PRML独学では習得できない新たな発見が毎回毎回あり、楽しみながら機械学習の勉強を進めることが出来てます。

 

次回は是非とも自分も発表したいです。

gnuplotで出力されるteminalを動かせない

Archで色々アップデートしたら、gnuplotのデフォルトのterminal window が変わってしまった。

 

どうやらversion 5 からデフォルトのterminalがQtになってしまったようだ。

 

今まで使っていたものはwxtらしい。

Qtの設定を弄るよりデフォルトのterminalを戻したほうが早そう。

 

man gnuplotのEnvironmentのところに、ホームディレクトリ以下に.gnuplotとしてドットファイルを置けば最初に読み込まれると書かれている。

 

# change default terminal

set term wxt

保存してgnuplotを再起動。最初の行に Terminal set to 'wxt'の文字を確認。

テスト

gnuplot> plot x
20時56分07秒: Warning: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1008,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.8).

エラーの詳細をググってみると、以下のページが引っかかった

problem with gnuplot and wxwidgets / Pacman & Package Upgrade Issues / Arch Linux Forums

gccのversionを5.1に上げれば良さそうだ。

ただ時間が無いので、この先はまたの機会に(このまま放置しそうだ…) 

awkでindexを指定したplotをする時、カンマ区切りCSVファイルで躓く

awkで異なるx,yの範囲のplotをする時、データ間を二行の空行で分け、indexをしていしてplotする。

(indexはなぜか0始まり。列は1始まりなのになぜ…)

 

表計算ソフト(LibreOffice Calc)でカンマ区切りCSVを指定して、それを読み込んでplotしようとすると何故かデータがブロックに分かれていない(index 0 で全てのデータが出力されてしまう)。

 

これは表計算ソフトでカンマ区切りCSVを出力すると、「二行の空行」が「カンマ区切りの羅列」になってしまうためだと考えられる。

 

Mousepadなど適当なエディターで「カンマ区切りの羅列」をちまちま削除する(Vimだと空行を挿入してもカンマになってしまう)か、何かしらの正規表現を用いて一括削除すれば解決する。