Czy obszar nodata w przeglądzie ortofotografii po ponownym próbkowaniu jest biały?

Mam zestaw zdjęć ortofotograficznych, z których każdy jest w pełni wypełniony danymi, ale po złożeniu razem zasięg nie tworzy prostokąta, więc są obszary nodata.

W MapGuide muszę mieć możliwość wyświetlania tych obszarów nodata w kolorze białym, aby moi użytkownicy nie musieli marnować czarnego tuszu podczas drukowania.

Na dużą skalę, gdzie wyświetlam bezpośrednio oryginalne obrazy w pełnej rozdzielczości, nie stanowi to problemu. Właśnie ustawiłem kolor tła mojej mapy na biały, a obszary, na których nie ma ortofotografii, wyświetlają tło.

Aby uzyskać wydajność, muszę być w stanie scalić wszystkie te obrazy źródłowe w złożony obraz przeglądowy o ponownej próbce do wyświetlania w mniejszych skalach, w których więcej ortofotografii jest jednocześnie widocznych.

Próbowałem użyć GDAL do scalenia i ponownego próbkowania przeglądu, ale domyślnie wydaje się, że tworzy ponownie próbkowaną kompozytową płytkę GeoTIFF z czernią w obszarach nodata, a MapGuide nie pozwala mi ustawić czerni jako przezroczystej na rastrach kolorów.

Czy istnieje sposób, aby skutecznie uzyskać to, czego chcę?

Podałem odpowiedź, na której skończyłem przy użyciu GDAL, ale chciałbym zobaczyć rozwiązania wykorzystujące inne narzędzia do przetwarzania obrazu i aplikacje GIS, zarówno otwarte, jak i zastrzeżone.

Najłatwiejszym sposobem poradzenia sobie z tym problemem było użycie wirtualnego formatu GDAL . Ten format pozwolił mi potraktować cały zestaw obrazów jako pojedynczy obiekt obrazu i przekształcić go w trzy stosunkowo proste kroki.

Tworzenie wirtualnego zestawu danych

GDAL (w tym pliki binarne Windows GISInternals Tamasa Szekeresa i najnowsze wersje OSGeo4W ) zawiera narzędzie o nazwie gdalbuildvrt, którego można użyć do zbudowania początkowego wirtualnego zestawu danych.

Jednym z prostych sposobów wykorzystania tego jest dodanie wszystkich obrazów do pliku tekstowego, a następnie użycie tego pliku tekstowego jako danych wejściowych do gdalbuildvrt. Oto przykład (musisz umieścić drugie polecenie z powrotem w jednym wierszu):

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

Zostanie Ci plik XML, który możesz traktować jako pojedynczy obraz dla wszystkich operacji GDAL. Również wewnętrznie reprezentuje nodata jako biały, ale ukrywa definicję nodata przed czytającymi ją narzędziami.

Tworzenie przeglądu ponownie próbkowanego

Następnie wykonasz ponowne próbkowanie i wyjście obrazu poglądowego. Możesz to zrobić za pomocą gdal_translate lub gdalwarp . Dla każdego z nich pamiętaj, że wynikowy rozmiar będzie wynosić width * height * 3(liczba 8 bitów pasm) bajtów. Jeśli będzie to więcej niż 4 GB, warto przyjrzeć się opcjom GeoTIFF dla składni, aby określić BigTIFF jako wynik (-co „BIGTIFF = TAK”).

W przypadku gdal_translate musisz określić wymiary obrazu wirtualnego za pomocą wygodnego polecenia gdalinfo . Weź te wymiary i podziel każdy według pewnego spójnego współczynnika, aby określić szerokość i wysokość pliku wyjściowego w pikselach.

Polecenie będzie wyglądać mniej więcej tak (w jednym wierszu):

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

W przypadku gdalwarp musisz znać wynikowy rozmiar pikseli; w tym przypadku używam miernika .5. Będziesz także chciał zadzwonić na metodę ponownego próbkowania. Wolę sześcienną linię do przeglądów ortofotografii. Jest bardziej miękki, ale nie będziesz go używać do pełnej rozdzielczości, a z mojego doświadczenia wynika, że ​​tworzy bardziej kompresowalny obraz, jeśli używasz czegoś takiego jak JPEG lub 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

Możesz także rozważyć użycie opcji kompresji JPEG dla tych przeglądów GeoTIFF po ponownym próbkowaniu; znacznie zmniejsza plik wyjściowy ( według Franka ) tylko z marginalnym spadkiem wydajności.

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

Przegląd

Będziesz także chciał uruchomić poręczną komendę gdaladdo nad wynikowym obrazem, aby zbudować wewnętrzne „piramidy”, dzięki czemu prośby o mniejszą rozdzielczość niż pełne wymiary obrazu można spełnić przy pomocy podzbioru danych. Wzrost wydajności w większości przypadków jest więcej niż wart miejsca na dysku. Będziesz chciał pobawić się poziomami, których tu używasz; w przypadku bardzo dużych obrazów możesz upuścić niektóre. Polecenie gdaladdo wygląda mniej więcej tak:

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

Sugeruję eksperymentowanie z tymi poziomami w celu uzyskania optymalnej wydajności. Może się okazać, że inny interwał próbkowania jest lepszy dla twojej aplikacji lub, w zależności od rozmiaru obrazu, że możesz upuścić niektóre z wyższych liczb (lub że potrzebnych jest więcej)

Ponadto, jeśli generujesz przegląd zewnętrzny (używając opcji -ro), rozważ dodanie linii konfiguracji kompresji JPEG:

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

(Uważam, że są one dziedziczone z nadrzędnego GeoTIFF dla osadzonych przeglądów)

Notatki

W obliczu tego problemu zapytałem na kanale #gdal na freenode.irc.net. To niesamowity zasób i jestem głęboko wdzięczny Howardowi Butlerowi, Frankowi Warmerdamowi, a nawet Rouaultowi za pomoc w tym.

Tak, ale dzięki próbom i błędom udało mi się ustalić, że -vrtnodata 255 powoduje oznaczenie wszystkiego , co jest białe jako nodata, a nie tylko poza mapą, które gdal2tiles traktuje następnie z przezroczystością alfa zgodnie z flagą -a.

W rezultacie część obrazu źródłowego jest przezroczysta, w moim przypadku białe części przerywanych dróg. To nie jest terminal, ale z pewnością byłoby fajnie móc określić gdal2tiles kolor „bez obrazu src”, albo w wyniku oryginalnych pustek w vrt, albo w wyniku wypaczenia. Dla mojego zestawu odcień byłby właśnie tym.

Po jeszcze więcej prób i błędów wydaje się, że kluczem są hidenodata. Nie wiem, dlaczego te narzędzia są tak minimalnie udokumentowane. Oto, co dla mnie działa, gdal 1.8.

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

Nie znam się zbyt dobrze na GDAL, ale myślę, że dostępna jest metoda lub polecenie, w którym można ustawić piksel o określonej wartości z inną wartością?

Nie ma z tym nic wspólnego, ale w zwykłym SQL coś podobnego (tylko dla zilustrowania - jest to znacznie bardziej pseudo-kod):

AKTUALIZACJA rastra ZESTAW piksel = 255 GDZIE piksel = NoData;

Chciałbym poznać odpowiedź!