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

25

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.

Jerzy
źródło
2
To pytanie dotyczy GIS, ale podejrzewam, że masz większe szanse na uzyskanie odpowiedzi na temat SO, które ma silną społeczność ekspertów R. Jeśli nie otrzymasz odpowiedzi szybko, po prostu oflaguj to pytanie, a moderator przeprowadzi dla Ciebie migrację.
whuber

Odpowiedzi:

9

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ę.

R Thiede
źródło
+1 za linkowany artykuł, ale ważne informacje są poza witryną i zostaną nam utracone, jeśli ta strona kiedykolwiek się przewróci lub się poruszy. Proponuję podać podsumowanie tego artykułu, aby w przypadku, gdy strona nie byłaby dostępna, nawet chwilowo, czytelnicy mieliby coś do pracy dla przyszłych badań i myślenia. Dzięki!
matt wilkie
Słusznie! 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 ich trwania. Przykładowe polecenie: „czas gdal_translate -outsize <wymiary miniatury> -of GTiff <plik skompresowanego obrazu> <plik miniatury>”
R Thiede
1
dzięki! Skomponowałem podsumowanie do samej odpowiedzi, więc jest bardziej samodzielne (patrz link do edycji w lewym dolnym rogu każdej odpowiedzi / pytania).
matt wilkie
@RThiede miał poważny problem: wydaje się teraz, że link do bloga nie jest już ważny?
Matifou
@RThiede Twój link jest martwy, czy możesz podać nowy?
Majid Hojati,
6

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.

Simbamangu
źródło
4

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.

V Stuart Foote
źródło
Aby manipulować danymi NetCDF (źródło rastrowe lub w inny sposób) w R, oto linki do dwóch hostowanych pakietów CRCD R CRAN, ncdf4 - cran.r-project.org/web/packages/ncdf4/index.html i RNetCDF - cran . r-project.org/web/packages/RNetCDF/index.html
V Stuart Foote
4

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.

Zeph
źródło
2

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.

John Caron
źródło
+1 za punkt, w którym losowy dostęp lub odczyt dowolnej lokalizacji różni się bardzo od sekwencyjnego jeden po drugim, dopóki cały plik nie zostanie odczytany. Mogę być poza bazą, ale myślę, że Geotiff obsługuje również przechowywanie kafelków i dowolny dostęp, po prostu przez strip / row jest najbardziej powszechny i ​​szeroko obsługiwany. Również w dzisiejszych czasach „bardzo duże pliki” w GIS mają zwykle zasięg wielu GB. ;-)
matt wilkie
2

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

Brad Nesom
źródło
2

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]

użytkownik55937
źródło