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.
^do podziału linii, który zostanie połączony po wykonaniu (np. dodaj^na końcu każdego przykładu linii kodu powyżej, aby zachować czytelność i zdolność do uruchamiania). Ważne zastrzeżenie: nigdy nieTak, 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.
źródło
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ź!
źródło