リサンプリングされたオルソフォトの概要のnodata領域を白にしますか？

オルソフォト画像のセットがあり、それぞれが完全にデータで満たされていますが、一緒に配置すると、カバレッジが長方形を形成しないため、データ領域がありません。

MapGuideでは、ユーザーが印刷時に黒インクを浪費する必要がないように、これらのnodata領域を白で表示できるようにする必要があります。

元のフル解像度の画像を直接表示する大規模な場合、これは問題ありません。地図の背景色を白に設定するだけで、オルソ写真がない領域に背景が表示されます。

パフォーマンスのために、これらのすべてのソース画像をリサンプリングされた複合オーバービュー画像にマージして、より多くのオルソ写真を一度に表示できる小さな縮尺で表示できるようにする必要があります。

GDALを使用して概要をマージおよびリサンプリングしようとしましたが、デフォルトでは、nodata領域に黒色のリサンプリングされた複合GeoTIFFタイルが作成されているように見え、MapGuideでは、カラーラスタで黒色を透明に設定できません。

私が効率的に欲しいものを手に入れる方法はありますか？

私はGDALを使用することになった答えを提供しましたが、他の画像処理ユーティリティとGISアプリケーション（オープンソースとプロプライエタリの両方）を使用したソリューションを見たいです。

この問題に対処する最も簡単な方法は、GDAL仮想フォーマットを使用することでした。この形式では、画像のセット全体を単一の画像オブジェクトとして扱い、比較的簡単な3つのステップで変換できました。

仮想データセットの作成

GDAL（Tamas SzekeresのGISInternals WindowsバイナリとOSGeo4Wの最新バージョンを含む）には、初期仮想データセットを構築するために使用できるgdalbuildvrtと呼ばれるユーティリティが含まれています。

これを使用する簡単な方法の1つは、すべての画像をテキストファイルに追加し、そのテキストファイルをgdalbuildvrtへの入力として使用することです。次に例を示します（2番目のコマンドを1行に戻す必要があります）。

dir /b *.tif > my_images.txt
gdalbuildvrt 
  -hidenodata 
  -vrtnodata "255 255 255" 
  -resolution highest 
  -input_file_list my_images.txt 
  my_image.vrt

これにより、すべてのGDAL操作の単一のイメージとして処理できるXMLファイルが残ります。また、内部的にnodataを白として表しますが、nodata定義をそこから読み取るツールから隠します。

リサンプリングされた概要の作成

次に、概要画像のリサンプリングと出力を実行します。これは、gdal_translateまたはgdalwarpのいずれかで実行できます。これらのどちらでも、結果のサイズはwidth * height * 3（8ビットバンドの数）バイトになることに注意してください。これが4GBを超える場合は、構文のGeoTIFFオプションを調べて、出力としてBigTIFFを指定する必要があります（-co "BIGTIFF = YES"）。

gdal_translateの場合、便利なgdalinfoコマンドを使用して仮想イメージのサイズを決定する必要があります。これらの寸法を取り、それぞれを一定の係数で除算して、ファイルの出力幅と高さをピクセル単位で決定します。

コマンドは次のようになります（1行）：

gdal_translate
  -outsize 53120 14000
  -co "TILED=YES"
  -co "PROFILE=GEOTIFF"
  -co "BLOCKXSIZE=256"
  -co "BLOCKYSIZE=256"
  my_image.vrt
  my_image.tif

gdalwarpの場合、結果のピクセルサイズを知る必要があります。この場合、私は0.5メートルを使用しています。また、リサンプリングメソッドを呼び出します。私は正射写真の概観のためにキュービックスプラインを好む。より柔らかくなりますが、これらをフル解像度まで使用することはありません。私の経験では、JPEGやECWのようなものを使用している場合は、より圧縮可能な画像が作成されます。

gdalwarp 
  -r cubicspline 
  -of GTiff 
  -dstnodata "255 255 255" 
  -tr 0.5 0.5 
  -co "PROFILE=GEOTIFF" 
  -co "BIGTIFF=YES" 
  -co "TILED=YES" 
  -co "BLOCKXSIZE=256"
  -co "BLOCKYSIZE=256"
  my_image.vrt 
  my_image.tif

これらのリサンプリングされたGeoTIFFの概要にJPEG圧縮オプションの使用を検討することもできます。（フランクによれば）パフォーマンスがわずかに低下するだけで、出力ファイルが大幅に縮小されます。

  -co "COMPRESS=JPEG" 
  -co "JPEG_QUALITY=80" 
  -co "PHOTOMETRIC=YCBCR"

概要

また、結果の画像に対して便利なgdaladdoコマンドを実行して内部の「ピラミッド」を構築し、画像の完全な次元よりも低い解像度のリクエストがデータのサブセットで満たされるようにすることもできます。パフォーマンスの向上は、ほとんどの場合、ディスクスペースに値する以上のものです。ここで使用するレベルで遊んでみたいと思います。非常に大きな画像の場合、一部を削除できる場合があります。gdaladdoコマンドは次のようになります。

gdaladdo 
  -r average 
  my_image.tif 
  2 4 8 16 32 64 128 256

最適なパフォーマンスを得るために、これらのレベルを試すことをお勧めします。アプリケーションには別のリサンプリング間隔の方が適している場合があります。または、画像サイズに基づいて、より高い数値の一部を削除することができます（またはそれ以上必要です）。

また、（-roオプションを使用して）外部の概要を生成する場合は、JPEG圧縮構成行を追加することを検討してください。

  --config COMPRESS_OVERVIEW JPEG 
  --config PHOTOMETRIC_OVERVIEW YCBCR 
  --config INTERLEAVE_OVERVIEW BAND 

（これらは、埋め込まれた概要の親GeoTIFFから継承されていると思います）

ノート

この問題に直面したとき、私はfreenode.irc.netの#gdalチャネルで尋ねました。これはすばらしいリソースであり、これを手伝ってくれたハワードバトラー、フランクウォーマーダム、さらにはルオーにも深く感謝します。

はい、しかし試行錯誤の結果、私は-vrtnodata 255がマップ外だけでなく、白であるすべてのものを nodataとしてフラグを立てる効果があることを明らかにすることができました。

つまり、ソース画像の一部が透明に設定されてしまいます。私の場合、破線の道路の白い部分になります。これはターミナルではありませんが、vrtの元のボイドまたはワープの結果として、「srcイメージなし」の色をgdal2tilesに指定できると便利です。私のセットでは、淡いブルーの色合いだけで十分でしょう。

さらに試行錯誤を繰り返した結果、hidenodataが鍵となるようです。これらのツールが最小限に文書化されている理由がわかりません。私に効くものはgdal 1.8です。

gdalbuildvrt test.vrt -vrtnodata "209 231 245" -hidenodata BX*.tif BY*.tif
gdal2tiles -p raster -s nztm.prj test.vrt out

私はGDALについてあまり詳しくありませんが、特定の値のピクセルを別の値で設定できるメソッドまたはコマンドが利用できると思いますか？

それとは関係ありませんが、単純なSQLでは次のようなものです（説明のために、これははるかに疑似コードです）。

UPDATEラスタセットピクセル= 255 WHEREピクセル= NoData;

答えを知りたい！