gdalを使用して画像をモザイクするときに、フェードアルファレイヤーを保持できますか?


12

一部の画像をgdalでモザイク処理していますが、各画像のエッジに向かってフェード/緩やかなアルファレイヤーを使用してモザイクの中央のシャープなエッジを削除することにより、最終結果を改善したいと思います。私が抱えている問題は、以下に示すように、個々の画像の緩やかなアルファレイヤーを持つ部分が、最終的なモザイクで半透明ではなく、その下の画像をマスクしていることです。

段階的なアルファレイヤーによる画像のマスキングモザイク

この段階的な透明度を使用して、ある画像を次の画像にフェードインすることが理想です。

モザイクを生成するために実行する手順は次のとおりです。

元の画像にgcpsを追加して位置を特定し、適切に方向付けします(各画像に順番に行われます)。

gdal_translate -of GTiff -a_srs EPSG:4326 -a_srs EPSG:4326 -gcp 1616 0 -88.2728612066 40.5175787437 -gcp <etc., etc.> <original_image_with_gradual_alpha>.tif <image_with_gradual_alpha_and_gcps>.tif

画像を適切な向きの新しいジオティフにワープします(各画像に対して順番に行われます)。

gdalwarp -s_srs EPSG:4326 -t_srs EPSG:4326 -dstnodata 0 <image_with_gradual_alpha_and_gcps>.tif <warped_geotiff_with_alpha>.tif

ワープされたすべての画像を1つのモザイクにまとめます。

gdalbuildvrt -srcnodata 0 mosaic.vrt <warped_geotiff_with_alpha_root>*.tif
gdal_translate mosaic.vrt mosaic.tif

リンクした画像はmosaic.tifです。

サンプル入力ファイルのgdalinfo:

Driver: GTiff/GeoTIFF
Files: dsc00562.tif
Size is 1616, 1080
Coordinate System is `'
Metadata:
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  TIFFTAG_XRESOLUTION=350
  TIFFTAG_YRESOLUTION=350
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0, 1080.0)
Upper Right ( 1616.0,    0.0)
Lower Right ( 1616.0, 1080.0)
Center      (  808.0,  540.0)
Band 1 Block=1616x1 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA 
Band 2 Block=1616x1 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA 
Band 3 Block=1616x1 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA 
Band 4 Block=1616x1 Type=Byte, ColorInterp=Alpha

段階的なアルファレイヤーを持つワープされたジオティフのgdalinfo:

Driver: GTiff/GeoTIFF
Files: geo_dsc00603.tif
Size is 1944, 1356
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-88.275727919349990,40.518829195724997)
Pixel Size = (0.000001599004942,-0.000001599004942)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  TIFFTAG_XRESOLUTION=350
  TIFFTAG_YRESOLUTION=350
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  ( -88.2757279,  40.5188292) ( 88d16'32.62"W, 40d31' 7.79"N)
Lower Left  ( -88.2757279,  40.5166609) ( 88d16'32.62"W, 40d30'59.98"N)
Upper Right ( -88.2726195,  40.5188292) ( 88d16'21.43"W, 40d31' 7.79"N)
Lower Right ( -88.2726195,  40.5166609) ( 88d16'21.43"W, 40d30'59.98"N)
Center      ( -88.2741737,  40.5177451) ( 88d16'27.03"W, 40d31' 3.88"N)
Band 1 Block=1944x1 Type=Byte, ColorInterp=Red
  NoData Value=0
Band 2 Block=1944x1 Type=Byte, ColorInterp=Green
  NoData Value=0
Band 3 Block=1944x1 Type=Byte, ColorInterp=Blue
  NoData Value=0
Band 4 Block=1944x1 Type=Byte, ColorInterp=Alpha
  NoData Value=0

最終モザイクのgdalinfo:

Driver: GTiff/GeoTIFF
Files: mosaic.tif
Size is 5702, 6846
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-88.278946072799997,40.524561377550008)
Pixel Size = (0.000001509761581,-0.000001509761581)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  ( -88.2789461,  40.5245614) ( 88d16'44.21"W, 40d31'28.42"N)
Lower Left  ( -88.2789461,  40.5142255) ( 88d16'44.21"W, 40d30'51.21"N)
Upper Right ( -88.2703374,  40.5245614) ( 88d16'13.21"W, 40d31'28.42"N)
Lower Right ( -88.2703374,  40.5142255) ( 88d16'13.21"W, 40d30'51.21"N)
Center      ( -88.2746417,  40.5193935) ( 88d16'28.71"W, 40d31' 9.82"N)
Band 1 Block=5702x1 Type=Byte, ColorInterp=Red
  NoData Value=0
Band 2 Block=5702x1 Type=Byte, ColorInterp=Green
  NoData Value=0
Band 3 Block=5702x1 Type=Byte, ColorInterp=Blue
  NoData Value=0
Band 4 Block=5702x1 Type=Byte, ColorInterp=Alpha
  NoData Value=0

プロセスの各段階の後にサンプル画像を含め、最終的なモザイクをここのドロップボックスリンクに含めまし -必要に応じて画像セット全体を提供できます。


2
gdal_warpにはアルファチャネルに関する既知のバグがあります。各ラスターのアルファバンドを個別にワープしてから、後で再結合してください(gis.stackexchange.com/questions/49706/…を参照)
Michael Stimson

素早い対応ありがとうございます!gdalwarpを実行する前にrgbバンドからアルファレイヤーを分離し、その後再結合することを意味しますか?
jeremyeastwood

それでおしまい。gdal_warpにはアルファのワープに関する問題があるため、RGBAではなくRGBとして扱います。gdal_translate -of GTIFF -b 1 -b 2 -b 3を分離するには(RGBAからRGBイメージを作成します)。
マイケルスティムソン

よし、リンクに従ってvrtで再結合しますか?gdalbuildvrt -separateを使用して再結合する場合、最初の画像から3つのバンドを取得し、2番目の画像から1つのバンドを取得する方法はありますか、またはgdalbuildvrtオプションを使用して結合する必要がありますか?
jeremyeastwood

1
いいえ、どのコマンドラインツールでもアルファブレンディングを実行できるとは思いません。QGIS(またはArcGis)には、ワーピング後にこの機能を実行できるラスター計算機がありますか?VRTにドロップするのと同じくらい簡単ではないことは確かです。VRTは、アルファブレンドではなく、下にあるピクセルを完全に上書きすると考えています。おそらく、それは改善要求として開発者に提供できるものです。
マイケルスティムソン

回答:


1

ワークフローの問題はアルファレイヤーにリンクされているのではなく、vrtを作成するときに最後の画像のみが使用されるという事実にリンクされています。

gdalmerge doc

重複する領域では、最後の画像が以前の画像の上にコピーされます。

gdalbuildvrt doc:

ファイル間にある程度の空間的な重複がある場合、ソースマターのリストに表示されるファイルの順序は、最後にリストされているファイルがコンテンツの取得元になります。優先順位の低いデータセットからデータを取得する可能性があるデータは考慮されませんが、現在、アルファ合成を行うためにアルファチャネルは考慮されていません(したがって、別のソースの上に表示されるalpha = 0のソースはコンテンツです) 。これは後のバージョンで変更される可能性があります。

したがって、実際には透明な領域は単純に透明であり、その下に見えるものは何もありません。

ブレンドを使用する場合は、gdalwarpを使用する必要があります。アルファバンドを処理し、ピクセル単位で指定された距離(-cblend distance)に基づいてブレンドします。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.