Que formato e configurações usar para fotos de antenas no QGIS?

A questão que se segue foi mais sobre como lidar com antenas com ArcGIS:

Formato mais eficaz para gerenciar fotografia aérea apenas para visualização

Parece que existem 2 opções principais para armazenar / reamostrar / reprojetar etc. antenas:

1. JP2000 / JP2 / JPEG 2000 (recentemente 5 códigos para manipulação GDAL)
2. ECW (wavelets compactadas ERDAS (.ecw))
3. outro que eu perdi?

O que eu entendi, dependendo da versão do QGIS para ambos, geralmente precisa ser instalada em algumas bibliotecas adicionais. A ECW tem algumas limitações - para comprimir as necessidades de comprar licença?

Testei o jpeg que não posso usar para arquivos grandes (limitação de dimensão máxima) e também é lento com dimensões maiores.

A resposta deve conter:

1. O que está disponível por padrão no QGIS 2.0.1 desktop e / ou OSGEO?
2. Como funciona com arquivos grandes - aumentar / diminuir o zoom (pirâmides)?
   • é Creation Options - RESOLUTIONS para pirâmides jp2?

Com base nas respostas huckfinn, em alguns outros comentários e em conjunto com minhas descobertas:

O formato vencedor é JPEG2000 (por que e qual versão é mencionada abaixo Por que não outras )

Por que não outros:

1. JPEG
   • Limitação de tamanho, tamanho e dimensões dos dados (4 GB e 65500x65500)
   • Não há possibilidade de pirâmides (internas) = ​​quanto maior a imagem, mais tempo será necessário para exibi-la quando aplicar mais zoom / mais zoom / menos zoom
2. GeoTIFF
   • Bom para grades, mas para imagens rasterizadas, não há compactação com perdas efetiva, exceto JPEG = o mesmo problema que JPEG
3. ECW e Sr. SID
   • Você precisa de uma licença especial para poder salvar no ECW e no Sr. SID - não é possível fazer isso por padrão com o GDAL (QGIS). Se você possui uma licença especial, provavelmente não precisa ler esta resposta porque o processamento de imagens é o seu pão diário (nossa empresa geralmente obtém imagens no formato ECW de nossos clientes)
4. Servidor de banco de dados / mapa
   • Definitivamente, é uma boa opção se você já possui um servidor de banco de dados / mapa em execução ou pelo menos sabe como fazê-lo com facilidade e rapidez. Nesse caso, os dados podem ser salvos no GeoTIFF ou em qualquer outro meio e são enviados normalmente como JPEG para o seu cliente - navegador da Web ou software de desktop como o QGIS. Mas se você não possui servidor e deseja algo fácil de carregar / ver imagens facilmente no QGIS, isso é muito complicado.

PORQUE JPEG2000:

Como publiquei na minha pergunta - o GDAL fornece mais opções para salvar no formato JPEG2000, mas conforme listado no site da GDAL, ele não deve ser fornecido na versão padrão do GDAL. Tentei provavelmente 6 versões diferentes do QGIS durante o teste e todas elas tinham pelo menos uma opção JPEG2000 (no Windows 7). Para ter certeza de que sugiro instalar a versão OSGeo4W (32 ou 64 bits) do QGIS e verificar no shell OSGeo4W se algum código JPEG2000 está disponível. (no Windows, basta executar o OSGeo4W shell no menu Iniciar / Programas e escrever lá no comando gdal_translate --formatsou gdalwarp --formats).

Em todas as versões do QGIS Tentei havia JP2OpenJPEG código (biblioteca OpenJPEG (v2)) disponível. E depois de alguns testes mais longos, incluindo outros, achei o mais útil.

Vantagens do JP2OpenJPEG

• livre para usar para abrir / salvar
• nenhum limite de tamanho "pequeno" (definitivamente pode ir além de 65500x65500)
• compressão muito eficaz (possível definir%)
• inclui pirâmides (visualizações) para visualização rápida (também é possível definir)

(opções para definir a compactação ( -co QUALITY ), pirâmides ( -co RESOLUTIONS ) e mais - http://www.gdal.org/frmt_jp2openjpeg.html )

Exemplo simples de conversão no QGIS usando gdal_translate (no QGIS, vá para Raster / Converion / Translate , defina o que você precisar e, possivelmente, clique no botão editar para ajustar o comando para atender às suas necessidades):

gdal_translate -of JP2OpenJPEG -co QUALITY=10 srcGridOrImage image.jp2  

Para o tópico 2: Aqui está uma investigação mais longa do JP2, porque eu também estava interessado, em usar uma compactação mais eficiente. E o resultado IMO é: No GDAL / QGIS (como um QgsRastrerDataProvider), você não pode combinar a compactação jpeg2000 adequada e opções de cache rápido, como conjuntos de blocos e estruturas de blocos de uma maneira simples.

Normalmente eu prefiro o GeoTiff para Raster-DB's, ele é bem suportado pela GDAL há muito tempo e possui muitos recursos para facilitar a vida.

Você pode encontrar os recursos do driver de dados JP2 na página gdal. Para suas necessidades jp2k, o JPEG2000 (dependências da libjasper) está listado nesta página: http://www.gdal.org/frmt_jpeg2000.html . Conforme listado em http://www.gdal.org/formats_list.html, o "driver" suporta leitura, gravação, é limitado a 2GiB e é incorporado desde o GDAL versão 1.9 e possui algumas opções de bloqueio ...

Portanto, para ter certeza do que é possível com o JP2, criei um conjunto de testes.

Uso fotos ariais grandes para detectar aves marinhas no mar Báltico com um tamanho de ca. 12000 por 10000 pixels (RGB) e uma resolução de 2 cm (espero que seja grande o suficiente). No momento, tenho 270 arquivos com capacidade de cerca de 130 GiB no meu QGIS-Project. E funciona fluentemente e bem em um sistema operacional Debian 7.0 Linux de 64 bits com núcleos Opteron de 8 GB e 4xAMD. ... mas com o GeoTiff.

Para obter um acesso rápido na GIS-Tool, as imagens são referenciadas e reamostradas com o GDAL usando as seguintes etapas e opções (.. desculpe pelo estilo de script bash):

Referenciando a imagem com conjuntos de dados do gps-log:

    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

As variáveis ​​$ [u | o] [l | r] [x | y] são os cantos da imagem fornecidos pelo cálculo fotogramétrico e a variável $ wd é a largura da imagem, $ hg a altura da imagem e $ cwd $ chg a ponto central.

Altere a imagem com opções de conjunto de blocos para o mundo real:

    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

Os parâmetros: --config GDAL_CACHEMAX 2000 -wm 2000 -wo NUM_THREADS = 4 informa ao ferro para usar muito cache e quatro threads do processador para calcular o material. A reamostragem é feita de maneira bilinear e o sistema de coordenadas é UTM-32. Isso é feito pelas opções -co TILED = YES -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512.

Escreva pirâmides no GeoTiff nos níveis de zoom 2,4,8 e 16:

    gdaladdo -r gauss $geo_tif 2 4 8 16

O GeoTiff resultante mostrado por gdalinfo é:

 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

Portanto, no GeoTiff, tudo está bem! Se eu tentar criar um JP2 com uma etapa de conversa direta:

 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)

e falha. Pode ser que a mensagem de erro tenha uma pista ou outro formato que você possa usar.

A tentativa com a ferramenta gdal_translate fornecerá um JP2000 adequado

 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

e a taxa de compactação é 1: 8, mas perdemos as propriedades do conjunto de blocos e blocos, conforme mostrado por 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)

O último teste foi usar o GeoTiff com uma compressão JPEG interna, mas obtemos:

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

Então, para onde ir a partir daqui. A página lib do driver JPP Jasper lib do GDAL lista alguns parâmetros para criar a imagem jp2000 com opções de bloco:

 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.

mas a questão é: qual deles será usado o qgis.

Para o tópico 1. O QGIS usa GDAL como QgsRasterdataProvider. Portanto, os recursos de leitura e gravação de um formato raster são implementados pela lib GDAL. Você pode encontrar um formato suportado no seguinte link http://www.gdal.org/formats_list.html . O comando gdal-config --formats fornece uma visão geral de quais itens de formato são incorporados à sua lib ou edição. O que é fornecido pela sua edição depende do seu pacote, sistema operacional e assim por diante. Para mais informações, leia http://trac.osgeo.org/gdal/wiki/BuildHints .