オンラインアプリケーションのベースマップとして使用したいRapidEyeイメージ（+300 Gb）が大量にあります。これまで、「ステロイドのジオサーバー」と呼ばれるプレゼンテーションで示された手順に従って、ジオサーバーでImagePyramidとしてそれらを提供することができました。問題は、適切なカラーバランスを行うことができなかったため、データセット全体を見るとモザイクが非常に悪いように見えますが、ズームインすると良くなります（下の写真）。
私のプロセスは：
プロセスを改善し、カラーバランスを改善する方法に関するヒントはありますか？
回答:
わかったと思う。
8ビットへの変換中に、各RapidEye画像で平均±2標準偏差ヒストグラムストレッチを強制しました。
Pythonスクリプトを使用して、画像の最小、最大、平均、およびSDを特定しました。次に、平均値-2SD（または画像の最小値のいずれか大きい方）を2に設定し、平均+ 2SD（または最大値）を254に設定します。 255に設定された2 ^16。NoDataは0に設定されました。
これらは伝達関数ベクトルです。
original image values = [0, mean-2SD, mean+2SD, 65536]
rescaled values = [1 2, 254, 255]以下は、いくつかの画面キャプチャです。今修正しなければならない問題は
編集
GitHubにコードを配置しました。使ってからしばらく経ちました。コードは少し複雑で、リポジトリも複雑です。しかし、まだ動作するはずです。
https://github.com/dvictori/rapideye_hist2sd
ダニエル、これらの画像は非常に異なる季節のものですか？または一日の時間？季節が異なる場合、色のバランスをとるのはかなり難しいかもしれません。しかし、それらが異なる時間帯である場合、太陽の角度の補正を適用することが顕著に役立つ場合があります。太陽の角度の適切な1次近似は、ピクセルに1.0 / cos（angle_of_sun_off_directly_above）を掛けることです。そのため、太陽が真上にある場合は調整せず、夜明け/夕暮れに近づくと...無限に増加します。
過去には、重複する領域のシーン間でヒストグラムマッチングを使用して大きなモザイクを組み立てるという悪い結果がありました。モザイク全体に奇妙なドリフト効果が生じるからです。より有用なアプローチは、ベースカラーのターゲットイメージ（おそらく、そのエリアの魅力的なランドサットモザイク）に対するヒストグラムマッチングのようなものかもしれません。この問題を解決する方法にも興味があります。MapBoxのチャーリーロイドも考えているかもしれません。
私は時々、カラーバランスの取れたモザイクを作成するために、ヒストグラムマッチングでOSSIMイメージリンカーを使用しました。画像リンカのチュートリアルには、いくつかの例がありますhttp://download.osgeo.org/ossim/docs/pdfs/ImageLinker_Tutorial.pdf ただし、画像リンカは積極的に管理されておらず、動作するかどうかはわかりません。Ossimジオセルは現在のプログラムですが、それに関するユーザードキュメントはあまりありません。良い結果を得るために、最初にOpenEVでLandsatシーンを1つずつ前処理し、LUTストレッチを適用して画像を視覚的にほぼ同じ外観にすることを覚えています。その後、OSSIMが最終マッチングを行うのが簡単になりました。最終製品は、ER Mapperモザイクユーティリティを使用して作成したものとほぼ同じように見えました。