Szybkość różnych formatów danych rastrowych

Mam problem ze zlokalizowaniem jakiejkolwiek dyskusji lub porównawczego testu porównawczego różnych formatów plików rastrowych (np. Do zastosowania w analizie danych w R). Czy ktoś ma wgląd w to, dlaczego poszczególne formaty mogą być szybsze lub wolniejsze? A może różnice powinny być minimalne?

W szczególności interesuje mnie, czy konwersja rastra (np. Pliku GEOTIFF) do innego formatu (np. NetCDF) jest zawsze opłacalna w celu przyspieszenia odczytu / zapisu i innych operacji.

Oto mój stary blog na temat rozmiaru pliku i czasu dostępu do formatów. Nie badałem prędkości zapisu, tylko czas dostępu. Powiedziałbym, że prawdopodobnie byłyby bezpośrednio powiązane, ale nie byłyby w stanie ręczyć za to.

Podsumowanie artykułu: Wygląda na to, że Packbits zapewnia najlepszy czas dostępu (kosztem miejsca na dysku), podczas gdy Deflate zapewnia średni / wolny czas dostępu dla plików pośrednich / małych. Możesz także bardziej empirycznie przetestować czasy dostępu, tworząc miniatury o różnych rozmiarach i określając czas, jaki to zajmie. Przykładowe polecenie:time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file>

Zakładając, że jedyną istotną rzeczą dla R w tym przypadku jest to, jak szybko może odczytać dane z pliku, tak jak każdy inny proces, to powinno dać ci dobrą wskazówkę.

W przypadku operacji odczytu / zapisu możesz przetestować szybkość tych operacji za pomocą system.time (). Oto niektóre wyniki ładowania pliku DEM do R (pakiet Raster) przetłumaczonego na cztery formaty (ASCII, IMG i TIF bez kompresji i deflacji). Na przykład na rastrze ~ 26 MB:

> system.time(dem <- raster("~/workspace/TEMP/kideporegion.img"))
 user  system elapsed 
 0.154   0.002   0.157 

„Elapsed” podaje całkowity czas (sekundy) potrzebny na operację. Uruchamianie operacji 10 razy i sprawdzanie średniego czasu, jaki upłynął:

              mean   diff
ASC         0.2237 0.3317
IMG         0.1544 0.0318
tif-Deflate 0.1510 0.0099
tif-none    0.1495 0.0000
tif-pack    0.1513 0.0118

TIFF bez kompresji jest najszybszy ... tuż za nim Deflate (0,1% wolniej) i TIFF-Packbits (1,8% wolniej), a następnie IMG (3,2% wolniej) i ASC (33% wolniej). (To jest na Macbooku Pro 2,4 GHz z dyskiem SSD, więc szybkie operacje na dysku)

Jest to po prostu ładowanie plików, a nie manipulowanie nimi.

Może tak naprawdę nie jest kwestią tego, który format obrazu rastrowego ma lepsze testy porównawcze otwarcia - raczej, które formaty obrazu rastrowego są najskuteczniejszymi źródłowymi formatami rastrowymi do otwierania i czytania jako dane wejściowe do tablicy numerycznej R. A następnie - jaki jest najbardziej efektywny format wyjściowy z R, zakładając, że wyprowadzasz wyniki z powrotem do rastra.

Tak czy inaczej, jeśli zamierzasz pracować z rastrem w R, prawdopodobnie użyjesz pakietów rgdal i R ncdf w celu uzupełnienia zawartości pakietu Raster . Zasadniczo polegając na poleceniu gdalwarp . Musisz opracować zależności formatu, aby dokonać wyboru rastra. Dużo zasięgu znajdziesz na SO i na różnych forach OSGEO i R / blogach / wiki.

Ponieważ jednak jest to forum GIS, na którym korzystanie z Pythona odbywa się we względnej przewadze, zauważę, że praca z danymi rastrowymi w tablicy numpy Pythona ma zalety, z podobną zależnością od bibliotek gdal do ładowania, konwersji i eksportu rastra. Niektórzy ludzie uważają zarządzanie pamięcią i strukturę kodu w Pythonie za lepsze niż natywne R - być może rzucić okiem na RPy2 lub PypeR, które mogą być odpowiednie do analizy.

Wielkim pytaniem jest to, czy zamierzasz odczytać cały raster z pliku do pamięci przed przetworzeniem, czy też plik jest tak duży, że będziesz przetwarzał go przyrostowo, lub przetwarzać jakiś podzbiór całego pliku.

Jeśli załadujesz to wszystko do pamięci, będziesz robił głównie dostęp sekwencyjny, a najszybszym formatem będzie wyrzucanie zwykłego i skompresowanego magazynu (w zależności od rzeczy, takich jak szybkość twojego procesora w porównaniu do dysku). Każdy z formatów plików binarnych będzie prawdopodobnie bardzo blisko (ASCII będzie wolniejszy).

Jeśli potrzebujesz przetworzyć podzbiór bardzo dużego pliku, format, który grupuje podzbiór, który chcesz bliżej, może być szybszy - np. Kafelki lub format, który może obliczać przesunięcia. Czasami zyskują tu podejścia nieskompresowane, ponieważ obliczenie, gdzie dana część obrazu znajduje się w pliku, może być trywialne, szczególnie jeśli potrzebujesz tylko części bardzo dużego wiersza, ale kompresję można przeprowadzić w sposób ziarnisty, który działa dobrze dla niektórych wzorce dostępu.

Przykro nam, ale prawdopodobnie będziesz musiał przeprowadzić analizę porównawczą w zależności od wzorca dostępu, a nie uzyskać jeden rozmiar dla wszystkich. Może to oczywiście zależeć nie tylko od formatu pliku i powyższych czynników, ale także od sterowników tego formatu i oprogramowania.

Sposób, w jaki myślisz o tego rodzaju problemach, polega na tym, jak twoja aplikacja uzyskuje dostęp do pliku, a w jaki sposób dane są w nim umieszczone. Chodzi o to, że jeśli możesz uzyskać dostęp do swoich danych sekwencyjnie, będzie to znacznie bardziej wydajne niż w przypadku dostępu losowego.

GeoTIFF to zbiór „obrazów” lub tablic 2D. NetCDF to pamięć ogólnego przeznaczenia dla tablic wielowymiarowych. Ale jeśli przechowujesz tablice w ten sam sposób w netCDF, jak w GeoTIFF, uzyskasz mniej więcej taką samą wydajność.

Można również zmienić kolejność danych w netCDF, więc w zasadzie można zoptymalizować wzorce odczytu. Domyślam się, że większość aplikacji GIS jest zoptymalizowana pod kątem układu GeoTIFF 2D, więc nie ma wiele do zyskania przez zmianę układu.

Wreszcie, mówię, że to naprawdę ma znaczenie tylko wtedy, gdy masz bardzo duże pliki, co najmniej dziesiątki megabajtów.

Przeczytałem kilka stron na ten temat kilka lat temu i od tego czasu używałem tiff z kompresją packbitów, kafelkami z nagłówkiem geotiff i jestem szczęśliwy.

artykuł o zespole arcpad

wiki

Ale po przeczytaniu poniższego rozważę ponownie i być może użyję odmiany deflate.

Witryna Arcpad

Tak wiele pakietów używa GDAL pod maską, np. Rgdal, QGIS, GRASS, itp. Gdybym używał jednego z tych pakietów, pomyślałbym o konwersji moich obrazów na vrt. Często widziałem, że zaleca się, aby w przypadku potrzeby użycia dwóch poleceń GDAL plik pośredni był plikiem vrt, ponieważ obciążenie związane z odczytem jest minimalne (np. Http://www.perrygeo.com/lazy-raster-processing -with-gdal-vrts.html ). Wygląda na to, że Twój przepływ pracy to: przekonwertuj raz i przeczytaj wiele razy. Może vrt byłoby odpowiednie.

[Edytuj: link dostosowany]