Balans kolorów i publikuj w geoserver dużą liczbę zdjęć w wysokiej rozdzielczości

Mam dużą liczbę obrazów RapidEye (+300 Gb), które chcę wykorzystać jako mapę bazową aplikacji online. Do tej pory udało mi się służyć im jako ImagePyramid w geoserver, wykonując kroki przedstawione w prezentacji o nazwie „Geoserver na sterydach”. Problem polega na tym, że nie byłem w stanie zrobić właściwego balansu kolorów, więc patrząc na cały zestaw danych, mozaika wygląda bardzo słabo, ale kiedy powiększam, robi się lepiej (zdjęcia poniżej).

Mój proces to:

1. Konwertuj wszystkie obrazy na 8-bitowe, epsg 4326, interpolacja sześcienna za pomocą gdal
2. Wygeneruj wirtualny raster gdal ze wszystkimi obrazami (gdalbuildvrt)
3. Wygeneruj piramidę obrazu (gdal_retile z kompresją i uprawami geotiff) i opublikuj na geoserver (używając histogramu w stylu warstwy)

Wszelkie wskazówki, jak poprawić proces i uzyskać lepszy balans kolorów?

Wierzę, że to rozumiem.

Wymusiłem średni odcinek histogramu odchylenia standardowego +2 na każdym obrazie RapidEye podczas konwersji na 8bit.

Użyłem skryptu python do identyfikacji obrazu min, maks, średniej i SD. Następnie ustawiłem wartość średniej - 2SD (lub obrazu min, w zależności od tego, która wartość była wyższa) na 2 i średniej + 2SD (lub maks.) Na 254. I dla bezpieczeństwa, pierwotna wartość zero na obrazie została ustawiona na 1 i 2 ^ 16 ustawiono na 255. NoData ustawiono na 0.

Oto wektory funkcji przenoszenia:

original image values = [0, mean-2SD, mean+2SD, 65536]
rescaled values = [1 2, 254, 255]

Poniżej kilka zrzutów ekranu. Problemy, które muszę teraz rozwiązać, to

1. Usuń czarną ramkę wokół imagePyramid
2. Uzyskaj lepiej wyglądający obraz po powiększeniu w pełnym zakresie. Teraz wygląda jak stary telewizor ustawiony na niewłaściwy kanał

Edytuj
Teraz umieściłem kod w GitHub. Minęło trochę czasu, odkąd go użyłem. Kod jest nieco niechlujny, podobnie jak repozytorium. Ale nadal powinno działać.
https://github.com/dvictori/rapideye_hist2sd

Daniel, czy są to zdjęcia z bardzo różnych pór roku? A może pory dnia? Jeśli są to różne pory roku, uzyskanie dobrego balansu kolorów może być dość trudne. Ale jeśli są różne pory dnia, wówczas zastosowanie korekcji kąta słońca może znacznie pomóc. Dobrym przybliżeniem pierwszego rzędu dla kąta słonecznego jest pomnożenie pikseli razy 1,0 / cos (angle_of_sun_off_directly_above). Więc nie ma regulacji, jeśli słońce jest bezpośrednio nad nim, zwiększając się do ... no nieskończoności, gdy zbliżasz się do świtu / zmierzchu.

W przeszłości miałem złe wyniki przy użyciu dopasowania histogramu między scenami w nakładających się regionach do składania dużych mozaik, ponieważ uzyskujesz dziwne efekty dryfowania po mozaice. Myślę, że bardziej użytecznym podejściem może być dopasowanie histogramu do obrazu docelowego w kolorze podstawowym (być może atrakcyjna mozaika tego obszaru). Interesuje mnie również sposób rozwiązania tego problemu. Charlie Loyd z MapBox również może mieć przemyślenia.

Czasami używałem programu OSSIM Image linker z dopasowaniem histogramu do tworzenia mozaik o zrównoważonym kolorze. Samouczek programu Image linker podaje przykład http://download.osgeo.org/ossim/docs/pdfs/ImageLinker_Tutorial.pdf Jednak program Image linker nie jest aktywnie utrzymywany i nie wiem, czy działa. Geocell Ossim jest bieżącym programem, ale nie ma na ten temat wielu dokumentów użytkownika. Pamiętam, że aby osiągnąć dobry wynik, najpierw przetworzyłem moje sceny Landsata kolejno za pomocą OpenEV, stosując pewne rozciąganie LUT, aby obrazy miały wizualnie podobny wygląd. Potem OSSIMowi łatwiej było dokonać ostatecznego dopasowania. Produkt końcowy wyglądał tak dobrze, jak ten, który wykonałem za pomocą narzędzia mozaikowego ER Mapper.