[OSGeoJapan-discuss] gdalで画像結合が遅くて困っています。

2013年 8月 11日 (日) 21:50:35 PDT

斉藤様

かやまと申します

画像のタイル化ですが、gdal2tiles.py  とかでやるならば入力の元画像にvrtが利用できます
からvrtをtiffに変更する必要は無いと思います。


2013年8月12日 12:20 斎藤 直正 <nsaito ＠ msk-web.co.jp>:

> 山手 様
>
> ご連絡が遅くなってしまって済みせん。
> ご教示頂きありがとうございます。
>
>  ・gdalwarpで -co TILED=YES -co BLOCKXSIZE=512 -co BLOCKYSIZE=512オプションを追加する
>>
> この方法も試してみました。（オプションBLOCKSIZEY⇒**BLOCKYSIZEに変更）
> 確かに速くなります。
> ただ、もう一声＼(^o^)／という感じでしょうか(^^ゞ
> もう少し小ぶりなデータセットならば良いかと思いました。
> 画像の結合だけに着目していたのそう思いましたが、**gdalwarp自体を他の用途 に使う分には
> 極めて有効に使えると思っています。
>
> 次に、
>
>
>  gdalbuildvrt -hidenodata -vrtnodata "0 0 0" ../dest_dir/merge.vrt *.tif
>> で仮想的にマージ画像を作成することができます。
>> 大きなファイルが扱いづらそうだと思われる場合にどうぞ。
>>
>> もし効果がありましたらお教えいただけると大変助かります。
>>
> -hidenodata -vrtnodate・・・・**の効果が今一つ航空写真を使っている為か見 えなかったので、
> それらのオプションを外して
>
> gdalbuildvrt ../dest_dir/merge.vrt *.tif
>
> として試してみました。
>
> 最初の段階で、**大量のファイルで以下のエラーが数百個は出たかな(^^ゞ
> Warning 6: gdalbuidvrt dose not support heterogenous projection. Skipping
> xxxx.tif
> vrtファイルもまともに生成されませんでした。
> 原因は、**元のオルソフォトは投射方法が無秩序にバラバラであったり、**登録されて
> いなかったり・・・これが原因だと思い。
> 全てのファイルをシェルスクリプトで変換（元ファイルは、.**tifと.tfwで構成 されていたが、
> 出力結果は.**tifへと合成してくれるのでこれも助かりましたｗ）
>
> gdal_transkate -a_srs epsg:xxxx srcxxx.tif ../geotiff/dstxxxx.tif
>
> その後、上記のgdalbuidvrtを実行したら、**あっという間に合成してくれました。
>
> 更に、**タイル画像を作るのに必要なtifファイルを作りたかったので、**以下の
> コマンドでtifファイルを生成。
>
> gdal_translate merge.vrt merge.tif
>
>  数時間掛かったと思いますが、**寝落ちしている間に作ってくれていましたｗ
>
> 問題は、無事画像が生成されているのか？心配でしたので、**睡魔と闘い
> ながら・・・縮小画像を生成。
>
> gdalwarp -tr 100 100 merge.tif dst_short.tif
>
> 激粗の画像が生成され、**取りあえず画像生成が上手く行っていることを確認。
> 後で、入力ファイルをmerge.**vrtに変えてやっても出来ることを確認しました。
>
> 結論としては、手順は増えますが・・・・
> ・GDAL_CHASHMAXの値を適当な値にする。（**これは必須ですね。）
> ・大きなファイルを結合する時は、場合によって、**gdalbuildvrtで仮想ファイル を作成
> ・gdal_translateで実画像化
>
> という手順が最も速く実現出来ました。
>
> 小規模だと、**そのままgdalwarpでやってもトータル時間はあまり変わら**ない？かも
> 知れませんが、ファイル数多かったり、**最終的に出来あがる結合後のファイルが
> 大きくなる様ならば、**gdalbuidvrtを使うべきと思いました。
>
> 御蔭さまで、**無事画像結合が現実的な時間で出来るようになりました。
> 次は、画像のタイル化に挑戦予定・・・というか、既にヤバそう(**^^ゞ
>
> ありがとうございました。
>
> 以上
>
>
> (2013/08/08 23:58), arctic_tern ＠ mf-atelier.sakura.**ne.jp<arctic_tern ＠ mf-atelier.sakura.ne.jp>wrote:
>
>> 斎藤様
>>
>> 山手と申します。
>>
>> あまり効果がないかもしれませんが、**以下の２つも試してみていただけますでしょうか。
>>
>> ・gdalwarpで -co TILED=YES -co BLOCKXSIZE=512 -co BLOCKSIZEY=512オプションを追加する
>>
>> TILED TIF形式にすることで、**キャッシュされる画像範囲がブロック単位になるはずです。
>> ブロックサイズはデフォルトでは256ですが、**変更したい場合は上のようにしてください。
>>
>> ・ワープ画像は個別に作って、マージ画像をVRTにする
>>
>> gdalbuildvrt -hidenodata -vrtnodata "0 0 0" ../dest_dir/merge.vrt *.tif
>> で仮想的にマージ画像を作成することができます。
>> 大きなファイルが扱いづらそうだと思われる場合にどうぞ。
>>
>> もし効果がありましたらお教えいただけると大変助かります。
>>
>> 以上、よろしくお願い申し上げます。
>>
>>
>>  岩崎 様
>>>
>>> 早々のご回答ありがとうございます。
>>>
>>> これやってたら、1年掛かるやんけー(~_~;)
>>> と思っていたので、ありがとうございます。
>>>
>>> 最悪、メモリディスク作って・・・とか、**分割して結合も考えたりはしていた
>>> のですが、
>>> ブログの内容も拝見させて頂き、十分理解出来ました。
>>>
>>>  それと、gdalwarpで画像を結合する場合、**初めに結合した範囲のデータを作って、**その範囲のデータをすべて処理するようにも思います。
>>>>
>>> これも確かにそんな動きですね。
>>> なんか、毎度毎度同じような初期化やってるような感じで、**無駄じゃないのか
>>> なぁ？もっと効率良く出来ないのかな？
>>> オプションで逃げれないのかな？とか考えていましたが・・・
>>>
>>> ありがとうございます。
>>> 早速、やってみます。
>>>
>>> 以上
>>>
>>>
>>>
>>> (2013/08/08 23:02), Nobusuke Iwasaki wrote:
>>>
>>>> すみません、途中で送信してしまいました。
>>>>
>>>> 以下のブログに解説が書かれています。
>>>> http://d.hatena.ne.jp/yellow_**73/20110427<http://d.hatena.ne.jp/yellow_73/20110427>
>>>>
>>>> それと、gdalwarpで画像を結合する場合、**初めに結合した範囲のデータを作って、**その範囲のデータをすべて処理するようにも思います。*
>>>> *場合によると、四分割なり、**八分割なりの結合ファイルを作成して、**それを結合した方がいいかもしれません。
>>>> 結合結果が10万✕10万ピクセルであれば、**一晩で結合できました。
>>>>
>>>> 詳しいことは、どなたかフォローいただければと思います。
>>>>
>>>> 2013年8月8日 22:54 Nobusuke Iwasaki <wata909 ＠ gmail.com>:
>>>>
>>>>> 斎藤さま
>>>>>
>>>>> 岩崎と申します。
>>>>>
>>>>> 私のやった経験の範囲なのですが、GDAL_CACHEMAX で使用するメモリ量を多くすると、かなり早くなりました。
>>>>>
>>>>> 2013年8月8日 22:25 斎藤 直正 <nsaito ＠ msk-web.co.jp>:
>>>>>
>>>>>> 斎藤と申します。
>>>>>> 初めて投稿させて頂きますの、不躾な点があるかと思いますが
>>>>>> 宜しくお願いしますm(_)m
>>>>>>
>>>>>> 現在、700枚程の航空写真をタイル画像にしようと思い、**まずは画像合成？結合
>>>>>> からということで、Windows 7からgdal_merge.pyを使用してみたところ、ファイ
>>>>>> ル数が
>>>>>> 多すぎて、**コマンドラインからはみ出る様なエラーが発生し上手く利用できま**せ
>>>>>> んでした。
>>>>>>
>>>>>> そこで、Linux（CentOS 6.4）にgdalをソースからインストールして、
>>>>>> gdalwarpを以下のコマンドで実行してみたところ、**とてつもなく時間が掛かって
>>>>>> しまい困惑しています。（**24時間で2枚しか処理できませんでした）
>>>>>> gdalは gdal-1.10.0を使用しています。
>>>>>>
>>>>>> # gdalwarp *.tif ../dest_dir/all.tif -dstnodata -9999 -srcnodata -9999
>>>>>> Creating output file that is 214000P x 195000L.
>>>>>> Processing input file 09xxxx1.tif.
>>>>>> for band 1, destination nodata value has been clamped to 0, the
>>>>>> original
>>>>>> value being out of range.
>>>>>> 0...10...20...30...40...50...**60...70...80...90...100 - done.
>>>>>> Processing input file 09xxxx2.tif.
>>>>>> for band 1, destination nodata value has been clamped to 0, the
>>>>>> original
>>>>>> value being out of range.
>>>>>> 0...10...20...30...40...50...**60...70...80...90...100 - done.
>>>>>>
>>>>>> ＜以下省略＞
>>>>>>
>>>>>> gdalは以下のconfigureオプションで作成しています**。
>>>>>> # ./configure --with-perl --with-php --with-python --with-expat
>>>>>> --with-expatlib=/usr/lib64 \
>>>>>> --with-poppler --with-expatinc=/usr/include --with-libtiff=/usr
>>>>>> --with-geotiff=/usr/ \
>>>>>> --with-threads
>>>>>>
>>>>>> # make
>>>>>> # make install
>>>>>>
>>>>>> ちなみに、
>>>>>> --with-expatlib=/usr/lib64
>>>>>> --with-expatinc=/usr/include
>>>>>> については、configure --helpで見ると、
>>>>>> --with-expat-lib=/usr/lib64
>>>>>> --with-expat-inc=/usr/include
>>>>>> であるべきなのですが、--with-expat-libと「**expat」と「lib」もしくは
>>>>>> 「inc」の間に
>>>>>> 「-」を入れるとエラーではじかれるので、間の「-」**が無いのが正しそうだと
>>>>>> 思っています。
>>>>>>
>>>>>> その後、pythonのツールを有効にしようと思い、**以下のコマンドを実行しています。
>>>>>>
>>>>>> # cd swig/python/
>>>>>> # easy_install GDAL
>>>>>> # python setup.py build
>>>>>> # python setup.py install
>>>>>>
>>>>>> 各種必要なライブラリ等は、**yumやrpmなどでインストールを施してインストール
>>>>>> したつもりです。
>>>>>>
>>>>>> やり方に問題があるのでしょうか？
>>>>>> マシン環境が悪いのか？
>>>>>>
>>>>>> gdal以外の方法でも構わないので、**高速化させる方法があればご教示頂けない
>>>>>> でしょうか？
>>>>>>
>>>>>> ちなみに、ファイル数を70ファイルぐらいに限定し、**コマンドを以下の様に
>>>>>> 少し変更してみたのですが、それだと、**1時間で３ファイルぐらいは処理してく
>>>>>> れているようです。
>>>>>>
>>>>>> # gdalwarp *.tif ../dest_dir/all.tif -dstnodata -9999 -srcnodata -9999
>>>>>> -multi
>>>>>>
>>>>>> -multiを追加しました。思い付きで、**並列処理してくれるのかな？と思っていま
>>>>>> すが、
>>>>>> 違うのかな？速くなった気がほとんどしないような・・・
>>>>>>
>>>>>> 以上、宜しくお願いします。
>>>>>>
>>>>>>
>>>>>> --
>>>>>> //////////////////////////////**///////////////////////////
>>>>>> 株式会社 エムエスケー
>>>>>> 斎藤 直正
>>>>>> TEL:0598-51-7471 / FAX:0598-52-4849
>>>>>> E-mail:nsaito ＠ msk-web.co.jp  URL:http://www.msk-web.co.jp
>>>>>> //////////////////////////////**///////////////////////////
>>>>>>
>>>>>> ______________________________**_________________
>>>>>> OSGeoJapan-discuss mailing list
>>>>>> OSGeoJapan-discuss ＠ lists.**osgeo.org<OSGeoJapan-discuss ＠ lists.osgeo.org>
>>>>>> http://lists.osgeo.org/**mailman/listinfo/osgeojapan-**discuss<http://lists.osgeo.org/mailman/listinfo/osgeojapan-discuss>
>>>>>>
>>>>>
>>>>> --
>>>>> 岩崎 亘典
>>>>>
>>>>
>>>>
>>> --
>>> //////////////////////////////**///////////////////////////
>>> 株式会社 エムエスケー
>>> 斎藤 直正
>>> TEL:0598-51-7471 / FAX:0598-52-4849
>>> E-mail:nsaito ＠ msk-web.co.jp  URL:http://www.msk-web.co.jp
>>> //////////////////////////////**///////////////////////////
>>>
>>> ______________________________**_________________
>>> OSGeoJapan-discuss mailing list
>>> OSGeoJapan-discuss ＠ lists.**osgeo.org<OSGeoJapan-discuss ＠ lists.osgeo.org>
>>> http://lists.osgeo.org/**mailman/listinfo/osgeojapan-**discuss<http://lists.osgeo.org/mailman/listinfo/osgeojapan-discuss>
>>>
>> >
>>
>
>
> --
> //////////////////////////////**///////////////////////////
> 株式会社 エムエスケー
> 斎藤 直正
> TEL:0598-51-7471 / FAX:0598-52-4849
> E-mail:nsaito ＠ msk-web.co.jp  URL:http://www.msk-web.co.jp
> //////////////////////////////**///////////////////////////
>
> ______________________________**_________________
> OSGeoJapan-discuss mailing list
> OSGeoJapan-discuss ＠ lists.**osgeo.org <OSGeoJapan-discuss ＠ lists.osgeo.org>
> http://lists.osgeo.org/**mailman/listinfo/osgeojapan-**discuss<http://lists.osgeo.org/mailman/listinfo/osgeojapan-discuss>
>
-------------- next part --------------
HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...
URL: <http://lists.osgeo.org/pipermail/osgeojapan-discuss/attachments/20130812/1e0f1840/attachment-0001.html>