Jakiego formatu i ustawień należy używać do zdjęć z anten w QGIS?

10

Następujące pytanie, które dotyczyło bardziej obsługi anten z ArcGIS:

Najbardziej efektywny format do zarządzania zdjęciami lotniczymi wyłącznie do przeglądania

Wygląda na to, że istnieją 2 główne opcje przechowywania / ponownego próbkowania / ponownej projekcji itp. Anten:

  1. JP2000 / JP2 / JPEG 2000 (ostatnio 5 kodów do obsługi GDAL)
  2. ECW (fale skompresowane ERDAS (.ecw))
  3. jakieś inne, za którymi tęskniłem?

gdal dostępne formaty

To, co zrozumiałem w zależności od wersji QGIS dla obu, zwykle wymaga zainstalowania dodatkowych bibliotek. ECW ma pewne ograniczenia - do kompresji trzeba kupić licencję?

Przetestowałem jpeg, którego nie mogę używać do dużych plików (maksymalne ograniczenie wymiarów), a także działa wolno przy większych wymiarach.

Odpowiedź powinna zawierać:

  1. Co jest domyślnie dostępne w wersji QGIS 2.0.1 dla komputerów stacjonarnych i / lub OSGEO?
  2. Jak to działa z dużymi plikami - powiększanie / pomniejszanie (piramidy)?
    • jest Opcje tworzenia - ROZWIĄZANIA dla piramid jp2?
Miro
źródło
1
Tylko inne podejście: duża seria ortofotomów jest często obsługiwana jako usługa OGC WMS / WMTS z dostawcą zaplecza, takim jak GeoServer lub MapServer.
Jakob
2
GeoTIFF i NITF są wspólne dla zdjęć satelitarnych. Obsługiwany również w GDAL, ale nie jestem pewien, czy QGIS obsługuje NITF.
BradHards,
@Jakob - Widzę sens. Ale nadal zdjęcia muszą być jakoś zapisane na serwerze (w jakimś formacie), prawda?
Miro
@BradHards - Tiff był właściwie moim pierwszym wyborem, ale jedynym sposobem na skuteczne zapisanie go skompresowanego jest kompresja JPEG, która doprowadza mnie do takich samych ograniczeń maksymalnych wymiarów, jak gdyby był zapisywany bezpośrednio do JPEG. Chodzi o to, że w przypadku zdjęć satelitarnych potrzebna jest głównie kompresja bezstratna. Ale to pytanie koncentruje się bardziej na zdjęciach lotniczych, które mogą ponieść pewne straty w celu zaoszczędzenia ogromnego miejsca do przechowywania / przesyłania danych.
Miro

Odpowiedzi:

8

Na podstawie odpowiedzi huckfinn, kilku innych komentarzy i wraz z moimi ustaleniami:

Zwycięski format to JPEG2000 (dlaczego i która wersja jest wymieniona poniżej Dlaczego nie inni )

Dlaczego nie inni:

  1. JPEG
    • Ograniczenie rozmiaru zarówno rozmiaru, jak i wymiarów danych (4 GB i 65500 x 65500)
    • brak możliwości (wewnętrznych) piramid = większy obraz, tym dłużej trwa jego wyświetlenie, gdy przesuwasz / przybliżasz / oddalasz
  2. GeoTIFF
    • Dobre dla siatek, ale dla obrazów rastrowych nie ma skutecznej kompresji stratnej, z wyjątkiem JPEG = taki sam problem jak JPEG
  3. ECW i Mr. SID
    • Potrzebujesz specjalnej licencji, aby móc oszczędzać w ECW i Mr. SID - domyślnie nie możesz tego zrobić za pomocą GDAL (QGIS). Jeśli masz specjalną licencję, prawdopodobnie nie musisz czytać tej odpowiedzi, ponieważ przetwarzanie zdjęć to Twój chleb powszedni (nasza firma zazwyczaj otrzymuje zdjęcia w formacie ECW od naszych klientów)
  4. Serwer bazy danych / mapy
    • Jest to zdecydowanie dobra opcja, jeśli masz już jakiś serwer bazy danych / mapy lub przynajmniej wiesz, jak to zrobić łatwo i szybko. W takim przypadku dane można zapisać w GeoTIFF lub czymkolwiek innym i są one zazwyczaj przesyłane do klienta w formacie JPEG - przeglądarki internetowej lub oprogramowania komputerowego, takiego jak QGIS. Ale jeśli nie masz serwera i chcesz łatwo załadować / zobaczyć zdjęcia w QGIS, jest to zbyt skomplikowane.

DLACZEGO JPEG2000:

Jak napisałem w moim pytaniu - GDAL zapewnia więcej opcji zapisywania w formacie JPEG2000, ale jak podano na stronie internetowej GDAL, nie należy go udostępniać w domyślnej wersji GDAL. Próbowałem prawdopodobnie 6 różnych wersji QGIS podczas testowania i wszystkie miały przynajmniej jedną opcję JPEG2000 (w systemie Windows 7). Dla pewności sugeruję zainstalowanie wersji QGIS OSGeo4W (32- lub 64-bitowej) i sprawdzenie w powłoce OSGeo4W, czy dostępny jest kod JPEG2000. (w systemie Windows wystarczy uruchomić powłokę OSGeo4W z menu / programów startowych i napisać tam polecenie gdal_translate --formatslub gdalwarp --formats).

We wszystkich wersjach QGIS Próbowałem było JP2OpenJPEG kod (biblioteka openjpeg (v2)) dostępny. Po kilku dłuższych testach, w tym innych, okazało się, że jest to najbardziej przydatne.

Zalety JP2OpenJPEG

  • swobodnie używać do otwierania / zapisywania
  • brak limitu „małego” rozmiaru (z pewnością może znacznie przekroczyć 65500 x 65500)
  • bardzo skuteczna kompresja (możliwe ustawienie%)
  • zawiera piramidy (podglądy) do szybkiego przeglądania (również możliwe do ustawienia)

(opcje ustawienia kompresji ( -co JAKOŚĆ ), piramidy ( -co ROZDZIELCZOŚCI ) i kilka innych - http://www.gdal.org/frmt_jp2openjpeg.html )

Prosty przykład konwersji w QGIS przy użyciu gdal_translate (w QGIS przejdź do Raster / Converion / Translate , ustaw wszystko, czego potrzebujesz i ewentualnie kliknij przycisk edycji, aby dostosować polecenie do własnych potrzeb):

gdal_translate -of JP2OpenJPEG -co QUALITY=10 srcGridOrImage image.jp2  
Miro
źródło
6

Na temat 2: Oto dłuższe badanie JP2, ponieważ byłem również zainteresowany, aby użyć bardziej wydajnej kompresji. Rezultatem IMO jest: W GDAL / QGIS (jako QgsRastrerDataProvider) nie można w prosty sposób łączyć odpowiedniej kompresji jpeg2000 i opcji szybkiego buforowania, takich jak zestawy kafelków i struktury bloków.

Normalnie korzystam z GeoTiff dla Raster-DB, od dawna jest dobrze obsługiwany przez GDAL i ma wiele funkcji, które ułatwiają życie.

Możliwości sterownika danych JP2 można znaleźć na stronie gdal. Dla twoich potrzeb jp2k JPEG2000 (zależności libjasper) znajduje się na tej stronie: http://www.gdal.org/frmt_jpeg2000.html . Jak podano na stronie http://www.gdal.org/formats_list.html „sterownik” obsługuje odczyt, zapis, jest ograniczony do 2GiB i wbudowany od wersji GDAL 1.9 i ma pewne opcje blokowania ...

Aby być pewnym, co jest możliwe z JP2, stworzyłem zestaw testowy.

Używam dużych zdjęć arialowych do wykrywania ptaków morskich w Morzu Bałtyckim o wielkości ok. 12000 na 10000 pikseli (RGB) i rozdzielczość podłoża 2 cm (mam nadzieję, że jest wystarczająco duża). Mam w tej chwili 270 plików o pojemności około 130 GiB w moim projekcie QGIS. Działa płynnie i dobrze na 64-bitowym systemie operacyjnym Linux Debian 7.0 z rdzeniami Opteron 8 GB i 4xAMD. ... ale z GeoTiff.

Aby uzyskać szybki dostęp do GIS-Tool, obrazy są przywoływane i ponownie próbkowane za pomocą GDAL, przy użyciu następujących kroków i opcji (.. adsorbowanie stylu skryptu bash):

Odwoływanie się do obrazu za pomocą zestawów danych z dziennika GPS:

    gdal_translate \
    -of GTiff \
    -gcp   0     0 $ulx   $uly \
    -gcp   0   $hg $llx   $lly \
    -gcp $cwd $chg $cpx   $cpy \
    -gcp $wd     0 $urx   $ury \
    -gcp $wd   $hg $lrx   $lry \
    -a_srs epsg:32632 \ 
    $raw_tif $ref_tif

Zmienne $ [u | o] [l | r] [x | y] to rogi obrazu podane przez rachunek fotogrametryczny, a zmienna $ wd to szerokość obrazu, $ hg wysokość obrazu i $ cwd $ chg the środek.

Wypacz obraz z opcjami zestawu kafelków do prawdziwego świata:

    gdalwarp \
    --config GDAL_CACHEMAX 2000 -wm 2000 -wo NUM_THREADS=4 \
    -r bilinear -dstnodata '0 0 0' \
    -of GTiff \
    -t_srs epsg:32632 \
    -tr 0.02 0.02 \
    -co COMPRESS=LZW \
    -co TILED=YES \
    -co BLOCKXSIZE=512 \
    -co BLOCKYSIZE=512 \
    $ref_tif $geo_tif

Parametry: --config GDAL_CACHEMAX 2000 -wm 2000 -wo NUM_THREADS = 4 nakazują żelazku użycie dużej ilości pamięci podręcznej i czterech wątków procesora do obliczenia rzeczy. Ponowne próbkowanie odbywa się w sposób dwuliniowy, a układ współrzędnych to UTM-32 .. ale chcę płytki blokowe 512x512, aby operacje nawigacyjne (zoom, panoramowanie, punkt) były szybkie i płynne. Odbywa się to za pomocą opcji -co TILED = TAK -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512.

Zapisz piramidy w GeoTiff na poziomach powiększenia 2,4,8 i 16:

    gdaladdo -r gauss $geo_tif 2 4 8 16

Wynikowy GeoTiff pokazany przez gdalinfo to:

 Driver: GTiff/GeoTIFF
 Files: CF006135.TIF
 Size is 12419, 9900
 Coordinate System is:
 PROJCS["WGS 84 / UTM zone 32N",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
             SPHEROID["WGS 84",6378137,298.257223563,
                 AUTHORITY["EPSG","7030"]],
             AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4326"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",9],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","32632"]]
Origin = (656099.007276594405994,5998980.139660121873021)
Pixel Size = (0.020000000000000,-0.020000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
  Upper Left  (  656099.007, 5998980.140) ( 11d23'17.54"E, 54d 6'54.87"N)
  Lower Left  (  656099.007, 5998782.140) ( 11d23'17.17"E, 54d 6'48.47"N)
  Upper Right (  656347.387, 5998980.140) ( 11d23'31.21"E, 54d 6'54.60"N)
  Lower Right (  656347.387, 5998782.140) ( 11d23'30.84"E, 54d 6'48.20"N)
  Center      (  656223.197, 5998881.140) ( 11d23'24.19"E, 54d 6'51.54"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
 NoData Value=0
 Overviews: 6210x4950, 3105x2475, 1553x1238, 777x619
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
 NoData Value=0
 Overviews: 6210x4950, 3105x2475, 1553x1238, 777x619
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
 NoData Value=0
 Overviews: 6210x4950, 3105x2475, 1553x1238, 777x619

W GeoTiff wszystko jest w porządku! Jeśli spróbuję utworzyć JP2 z bezpośrednim krokiem konwersacji:

 gdalwarp -of jpeg2000 -co TILED=YES -co BLOCKSIZEX=512 -co BLOCKSIZEY=512 CF006135.TIF CF006135.jp2 
 Output driver `jpeg2000' not recognised or does not support
 direct output file creation.  The following format drivers are configured
 and support direct output:
   VRT: Virtual Raster
   GTiff: GeoTIFF
   NITF: National Imagery Transmission Format
   HFA: Erdas Imagine Images (.img)
   ELAS: ELAS
   MEM: In Memory Raster
   BMP: MS Windows Device Independent Bitmap
   PCIDSK: PCIDSK Database File
   ILWIS: ILWIS Raster Map
   SGI: SGI Image File Format 1.0
   Leveller: Leveller heightfield
   Terragen: Terragen heightfield
   netCDF: Network Common Data Format
   HDF4Image: HDF4 Dataset
   ISIS2: USGS Astrogeology ISIS cube (Version 2)
   ERS: ERMapper .ers Labelled
   RMF: Raster Matrix Format
   RST: Idrisi Raster A.1
   INGR: Intergraph Raster
   GSBG: Golden Software Binary Grid (.grd)
   PNM: Portable Pixmap Format (netpbm)
   ENVI: ENVI .hdr Labelled
   EHdr: ESRI .hdr Labelled
   PAux: PCI .aux Labelled
   MFF: Vexcel MFF Raster
   MFF2: Vexcel MFF2 (HKV) Raster
   BT: VTP .bt (Binary Terrain) 1.3 Format
   LAN: Erdas .LAN/.GIS
   IDA: Image Data and Analysis
   GTX: NOAA Vertical Datum .GTX
   NTv2: NTv2 Datum Grid Shift
   ADRG: ARC Digitized Raster Graphics
   SAGA: SAGA GIS Binary Grid (.sdat)

i to się nie udaje. Być może komunikat o błędzie zawiera wskazówkę lub inny format, którego możesz użyć.

Wypróbowanie za pomocą narzędzia gdal_translate da ci właściwy JP2000

 gdal_translate -of jpeg2000\
    -co TILED=YES -co BLOCKSIZEX=512 -co BLOCKSIZEY=512\
    CF006135.TIF CF006135.jp2

 ls -l 
 -rw-r--r-- 1 huckfinn huckfinn  63538529 Jan 28 23:55 CF006135.jp2
 -rw-r--r-- 1 huckfinn huckfinn       388 Jan 28 23:04 CF006135.jp2.aux.xml
 -rw-r--r-- 1 huckfinn huckfinn 519882980 Sep 30 21:01 CF006135.TIF

a stopień kompresji wynosi 1: 8, ale tracimy właściwości zestawu bloków i kafelków, jak pokazuje gdalinfo:

 gdalinfo CF006135.jp2 
 Driver: JPEG2000/JPEG-2000 part 1 (ISO/IEC 15444-1)
 Files: CF006135.jp2
        CF006135.jp2.aux.xml
 Size is 12419, 9900
 Coordinate System is:
 PROJCS["WGS 84 / UTM zone 32N",
     GEOGCS["WGS 84",
         DATUM["WGS_1984",
             SPHEROID["WGS 84",6378137,298.257223563,
                 AUTHORITY["EPSG","7030"]],
             AUTHORITY["EPSG","6326"]],
         PRIMEM["Greenwich",0],
         UNIT["degree",0.0174532925199433],
         AUTHORITY["EPSG","4326"]],
     PROJECTION["Transverse_Mercator"],
     PARAMETER["latitude_of_origin",0],
     PARAMETER["central_meridian",9],
     PARAMETER["scale_factor",0.9996],
     PARAMETER["false_easting",500000],
     PARAMETER["false_northing",0],
     UNIT["metre",1,
         AUTHORITY["EPSG","9001"]],
     AUTHORITY["EPSG","32632"]]
 Origin = (656099.007276594405994,5998980.139660121873021)
 Pixel Size = (0.020000000000000,-0.020000000000000)
 Metadata:
   AREA_OR_POINT=Area
 Corner Coordinates:
 Upper Left  (  656099.007, 5998980.140) ( 11d23'17.54"E, 54d 6'54.87"N)
 Lower Left  (  656099.007, 5998782.140) ( 11d23'17.17"E, 54d 6'48.47"N)
 Upper Right (  656347.387, 5998980.140) ( 11d23'31.21"E, 54d 6'54.60"N)
 Lower Right (  656347.387, 5998782.140) ( 11d23'30.84"E, 54d 6'48.20"N)
 Center      (  656223.197, 5998881.140) ( 11d23'24.19"E, 54d 6'51.54"N)

Ostatnim testem było użycie GeoTiff z wewnętrzną kompresją JPEG, ale otrzymujemy:

 gdalwarp -of GTiff \
  -co COMPRESS=JPEG \
  -co TILED=YES -co BLOCKSIZEX=512 -co BLOCKSIZEY=512\
  CF006135.TIF CF006135_IJPG.TIF
  Creating output file that is 12419P x 9900L.
  Warning 6: Driver GTiff does not support BLOCKSIZEX creation option
  Warning 6: Driver GTiff does not support BLOCKSIZEY creation option
  Processing input file CF006135.TIF.
  ....

Więc gdzie iść stąd. Strona lib sterownika JP2000 Jasper w GDAL zawiera listę parametrów do utworzenia obrazu jp2000 z opcjami blokowania:

 Encoding parameters, directly delivered to the JasPer library described in the JasPer documentation. Quoted from the docs:

``The following options are supported by the encoder:
imgareatlx=x    Set the x-coordinate of the top-left corner of the image area to x.
imgareatly=y    Set the y-coordinate of the top-left corner of the image area to y.
tilegrdtlx=x    Set the x-coordinate of the top-left corner of the tiling grid to x.
tilegrdtly=y    Set the y-coordinate of the top-left corner of the tiling grid to y.
tilewidth=w     Set the nominal tile width to w.
tileheight=h    Set the nominal tile height to h.
prcwidth=w  Set the precinct width to w. The argument w must be an integer  power of two. The default value is 32768.
prcheight=h     Set the precinct height to h. The argument h must be an integer power of two. The default value is 32768.
cblkwidth=w     Set the nominal code block width to w. The argument w must be an integer power of two. The default value is 64.
cblkheight=h    Set the nominal code block height to h. The argument h must be an integer power of two. The default value is 64.

ale pytanie brzmi: który z nich użyje qgis.

huckfinn
źródło
1
Dziękuję, naprawdę to doceniam. W międzyczasie zrobiłem też własne testy. Jak widzę JPEG2000 jest formatem, z którym należy się pogodzić. Jak wspomniałem wcześniej, TIFF nie ma używać, ponieważ mogę używać tylko kompresji JPEG (nie JP2000), więc istnieje ograniczenie rozmiaru. Użyłem sterownika (kodu) JP2OpenJPEG, który jest dostępny w mojej wersji QGIS / GDAL i nie ma ograniczenia rozmiaru. A co najważniejsze, ma dobre opcje tworzenia - między innymi Rozdzielczość i BLOK * ROZMIAR (oba ustawione na rozsądne wartości domyślne).
Miro
Dzięki, to są dobre wieści. Niestety, wheezy Debiana obecnie nie obsługuje tego sterownika .. ale dobrze wiedzieć, który z wielu jp2000'ów jest tym ostatnim. -
huckfinn
5

Na temat 1. QGIS używa GDAL jako QgsRasterdataProvider. Zatem możliwości odczytu i zapisu formatu rastrowego są implementowane przez bibliotekę GDAL. Obsługiwany format można znaleźć pod następującym linkiem http://www.gdal.org/formats_list.html . Polecenie gdal-config --formats daje ci przegląd tego, jakie formatowanie jest wbudowane w twoją bibliotekę lub edycję. To, co zapewnia wydanie, zależy od pakietu, systemu operacyjnego itd. Aby uzyskać więcej informacji, przeczytaj http://trac.osgeo.org/gdal/wiki/BuildHints .

huckfinn
źródło
Dziękujemy za gdal-config --formats. Pierwsza część układanki wykonana.
Miro
1
gdal-config --formats jest tylko dla systemów uniksowych. W systemie Windows można wykonać gdal_translate --formats lub gdalwarp --formats, aby zobaczyć, co jest dostępne.
Miro
Hm, to prawda gdal-config daje kompilatorom unixowym radę na temat bibliotek. OK, to nie ma sensu w systemie Windows (exegted cygwin lub mingw). Ale gdalinfo --format $ DRIVERNAME daje ci informacje.
huckfinn