Por que o resultado da mesclagem de várias varreduras é tão grande? [fechadas]


10

Eu tento mesclar 14 geotiff assim:

insira a descrição da imagem aqui

Cada geotiff tem cerca de 50Mb. Eu preciso de um geotiff na saída

Meu fluxo de trabalho:

gdalbuildvrt -input_file_list list.txt test.vrt 

(onde minha lista contém o nome dos tifs)

Então :

gdal_translate -of Gtiff test.vrt test.tif
Input file size is 79841, 59955

Funciona, mas o resultado é um geotiff de 13,3 Gb! Para 14 arquivos, cada 50 Mb, tentei um geotiff de 700 Mb, não 13 Gb.

Eu sei que o gdal não é compactado por padrão, então tentei este comando:

gdal_translate -of Gtiff -co COMPRESS=JPEG test.vrt test_compressed.tif

Mas a "mesclagem" do arquivo é muito grande para a compactação JPEG:

Input file size is 79841, 59955
0ERROR 1: JPEGPreEncode:Strip/tile too large for JPEG
ERROR 1: WriteEncodedTile/Strip() failed.
ERROR 1: JPEGPreEncode:Strip/tile too large for JPEG
ERROR 1: WriteEncodedTile/Strip() failed.
ERROR 1: An error occured while writing a dirty block
...

Então, tentei outro fluxo de trabalho e converti todos os meus tifs em jpeg (14 Mb cada), construí um arquivo vrt e o traduzi com compactação LZW. Mas o geotiff de saída é de cerca de 5 Gb.

Você poderia me dizer qual é a melhor prática para fazer o trabalho e se é possível obter um geotiff de 14 * 50Mb?

Eu não tentei, mas pensei em mesclar essas tifs no photoshop e depois re-georeferenciar com as coordenadas superior esquerda / direita inferior. Com esse fluxo de trabalho, acho que terei 14 * 50 Mb, mas não tenho certeza. E eu quero aprender as melhores práticas da gdal, então não tentei no momento


chegando à mordida: se a entrada for tif com 8 bits e a exportação for 32 bits por padrão, você terá sérios problemas. portanto, mantenha sua definição de bytes como está. E lembre-se: o tif completo será prob. tem 20x 50mb como um tiff é sempre retangular

Se eu entendi, o número que apontei em verde nesta captura de tela deve ser o mesmo à esquerda e à direita?

bits

Sua imagem de saída terá mais pixels que a soma das imagens de entrada, mas isso não explica a grande diferença. Sugiro que você analise as características de suas imagens com base no gdalinfo para ver qual compressão é usada e verifique se as extensões estão corretas.

Os 14 tifs de 50 Mb eram originalmente 14 tifs de 700 Mb que eu processei com gdal_translate com -co COMPRESS = JPEG. Eu comprimi a varredura para reduzir o número de Mb, mas talvez não fosse uma boa ideia?

Essa captura de tela representa as informações de 2 gdal do mesmo geotiff (01.tif), à esquerda da captura de tela está o gdalinfo do Gtiff não compactado de 700 Mb, e à direita o mesmo Gtiff com COMPRESS = JPEG, portanto 50 Mb, com o diff em verde:

Não compactar e compactar gdalinfo do arquivo 01.tif

De acordo com mim, as extensões estão corretas porque no qgis ele corresponde a outras fontes de dados e imagens de satélite.

* supondo que suas imagens de entrada tenham o mesmo tamanho, produz 20.000 * 12.000 pixels por imagem de entrada, o que é grande para uma imagem de 50 Mb; talvez você esteja cruzando a extensão do seu sistema de coordenadas ao criar o mosaico. *

Não sei ao certo o que você quer dizer com "ultrapassar a extensão". Mas tentei abrir meus 5 Gb LZW no QGIS, e a extensão é boa, porque combina com outra fonte de dados.

Sua resposta me faz perceber que o Gtiff não tem o mesmo tamanho, você acha que poderia ser a causa do aumento do tamanho quando mesclado? Porque gdal prefere arquivos do mesmo tamanho. Eu fiz um gdalinfo em cada Gtiff para obter seu tamanho, há uma diferença muito pequena entre o tamanho de Gtiff:

02.tif Size is 19956, 11981
03.tif Size is 19959, 11993
04.tif Size is 19961, 11992
05.tif Size is 19958, 11993
06.tif Size is 19958, 11990
07.tif Size is 19956, 11984
08.tif Size is 19956, 11993
09.tif Size is 19958, 11993
10.tif Size is 19958, 11989
11.tif Size is 19958, 11985
12.tif Size is 19958, 11993
13.tif Size is 19959, 11993
14.tif Size is 19960, 11994

Então você deve observar a profundidade de pixel de suas imagens: se sua entrada estiver em Bytes,> deverá manter bytes. gdal_translate -de Gtiff -ot Byte -co COMPRESS = LZW test.vrt test.tif

Eu tentei esse comando, mas o gdal me disse que o tamanho da tiff foi excedido.

Input file size is 79841, 59955
0...10...20...30...40...50..ERROR 1: TIFFAppendToStrip:Maximum TIFF file size exceeded. Use BIGTIFF=YES creation option.
ERROR 1: WriteEncodedTile/Strip() failed.

Mas se eu tiver que criar um grande tiff, isso não resolverá o meu problema, porque ele tem mais de 4 Gb. A profundidade do pixel é importante no meu caso? (Foto HD de mapas, depois georreferenciada, não DEM)

Observação 1: converter suas imagens em jpeg antes de criar um vrt não ajuda e você pode perder dados.

Não é sério se eu perder um pouco de informação. Prefiro não perdê-lo, é claro, mas se preciso, não é um problema. Eu estava convencido de que a saída seria mais leve se eu trabalhasse com jpeg, mas, como conclusão, não é verdade quando a saída é Gtiff. Portanto, essa não é uma boa solução. Eu desisto desta solução.

> Observação 2: usar um vrt é útil: você tem certeza de que precisa do GTiff?

Sim, preciso de um Gtiff, porque preciso importá-lo em um aplicativo móvel que precise de entrada de geotiff para funcionar (acho que o aplicativo também pode receber entrada em PDF geoespacial, mas nunca trabalho com ele e quero entender meu problema com gdal, porque não é a primeira vez que o tenho).


Eu tentei -co lado a lado = sim -co bigtiff = sim -co compressa = jpeg -co fotométrico = ycbcr e eu tentei -co TILED = sim -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512

Esses 2 comandos funcionam bem, tenho um tamanho de ~ 700 Mb. É exatamente o que eu esperava.

Agora eu tenho outro problema: ele não pode ser aberto rapidamente pelo QGIS. Eu tenho que esperar 15 minutos (mas eu saí antes do QGIS abrir a tif com êxito). Não sei porque. E no meu aplicativo Android, ele não funciona (talvez seja a causa de "lado a lado = sim"). Eu tenho que ler alguns documentos sozinho.


Use -co azulejos = yes -co BigTIFF = yes -co compressa = jpeg -co fotométrica = YCbCr
user30184

Respostas:


2

Sua imagem de saída terá mais pixels que a soma das imagens de entrada, mas isso não explica a grande diferença. Sugiro que você analise as características de suas imagens com base no gdalinfo para ver qual compressão é usada e verifique se as extensões estão corretas. (supondo que suas imagens de entrada tenham o mesmo tamanho, produz 20.000 * 12.000 pixels por imagem de entrada, o que é grande para uma imagem de 50 Mb; talvez você esteja cruzando a extensão do seu sistema de coordenadas ao criar o mosaico.) observe a profundidade de pixel de suas imagens: se sua entrada foi em bytes, você deve manter bytes.

gdal_translate -of Gtiff -ot Byte -co COMPRESS=LZW test.vrt test.tif 

Observação 1: converter suas imagens em jpeg antes de criar um vrt não ajuda (ele será descompactado antes da próxima etapa) e você poderá perder dados.

Observação 2: usar um vrt é útil: você tem certeza de que precisa do GTiff?

EDIT: Não há milagre com o tamanho de suas imagens, mas você deve usar um tif lado a lado como saída para poder usar a compactação jpeg com seus dados grandes (-co TILED = yes -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512 ) Se permanecer muito grande, a única solução é usar gdalwarp para reamostrar em uma resolução mais baixa.


chegando à mordida: se a entrada for tif com 8 bits e a exportação for 32 bits por padrão, você terá sérios problemas. portanto, mantenha sua definição de bytes como está. E lembre-se: o tif completo será prob. tem 20x 50mb como um tiff é sempre retangular.
Riccardo

De onde você tirou 20000 x 12000? O resultado mostrado na questão iria sugerir a imagem de entrada é 79.841 x 59955.
Mal Genius

79841, 59955 é o tamanho da entrada vrt. mas há 5 linhas e 4 colunas, dividi ~ 80000 por 4 e ~ 60000 por 5. Como eu disse, isso pressupõe que as imagens tenham o mesmo tamanho e estejam posicionadas como na figura.
Radouxju 8/07

Eu respondi editando minha pergunta original, espero que seja assim que eu tenha que continuar.
Grimdaemon
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.