[Portugal] Re: Carregamento de dados raster

Rui Pedro Henriques henriques.rui gmail.com
Domingo, 11 de Março de 2012 - 20:47:33 EDT


Olá Duarte,

Obrigado pelos contributos, vou testar juntamente com o que fui 
construindo até ao momento com os contributos anteriores e que consiste 
em criar novas imagens com compressão JPEG, a opção YCBCR e TILED. 
Posteriormente construo pirâmides e por fim um mosaico.

Acabei agora mesmo de correr este ultimo teste, por isso ainda não fiz 
muitas comparações mas está já consideravelmente melhor que no inicio.

O conjunto original de imagens tinha 5GB
O conjunto das imagens processadas (mais os ovr) fica em 12GB e demora 
cerca de 1h10 a criar.
(Antes de usar a compressão JPEG ficava com 90GB e demorava 1h00 a 
criar. Sem a opção YCBCR, o desempenho era muito mau).

O script que estou a usar é o seguinte:

#!/bin/bash

touch log.txt
echo "Starting: "`date +"%Y-%m-%d_%H-%M-%S"` >> log.txt
mkdir original_files
mkdir optimized

for FILE in *.jpg
do
   echo "Processing "$FILE
   BASE=`basename $FILE .jpg`
   TILEFILE=tl_t_${BASE}.tif
   gdal_translate -of GTiff -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co 
TILED=YES -a_srs EPSG:27493 $FILE $TILEFILE
   gdaladdo -ro --config INTERLEAVE_OVERVIEW PIXEL --config 
COMPRESS_OVERVIEW JPEG $TILEFILE 2 4 8 16 32 64 128 256 512 1024
done

gdalbuildvrt mosaic.vrt tl_t_*.tif
mv *.j* original_files
mv tl_t_* optimized
mv mosaic.vrt optimized

echo "Ending: "`date +"%Y-%m-%d_%H-%M-%S"` >> log.txt



On 03/12/2012 12:21 AM, duartecarreira wrote:
> Rui,
>
> Parece-me que usar um vrt é lento em escalas pequenas porque o mapserver tem
> de abrir todos os ficheiros... ao fazer zoom in o desempenho vai ficando
> cada vez melhor.
>
> Quando criaste um mosaico jpeg obtiveste um tamanho maior que o original? A
> opção YCBCR é importante nos ficheiros tiff com compressão jpeg para manter
> o tamanho 2-3x menor que o default.
>
> Se o mosaico jpeg não deu bons resultados, podes usar uma abordagem mista,
> que me tem dado bons desempenhos - criar um mosaico "intermédio" com 4x a
> resolução do original.
>
> Ou seja, para escalas grandes que usufruem dos ortos originais mostras no
> mapserver o vrt de todos os ortos (mesmo sem pirâmides, mas isso podes
> testar se é melhor criar ou não). Para escalas menores usas no mapserver
> este tal mosaico com 4x menos resolução, e com pirâmides.
>
> Como tens imagens de 10cm eu tentaria com 6 ou 8x menos resolução... mas só
> testando.
>
> Ou seja, usando o vrt que "cola" todos os originais, crias o tal mosaico
> intermédio, e aumentas o tamanho do pixel 4x, usando o gdal_translate com a
> opção -outsize 25% 25%, e as outras opções todas que usaste:
> -of gtiff -co compress=jpeg -co tiled=yes -co tfw=yes -co bigtiff=yes
>
> E crias as pirâmides, só acrescentando a config do ycbcr:
> gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR
> --config INTERLEAVE_OVERVIEW PIXEL -ro mosaico.tif 2 4 8 16 32 64 128......
>
> Isto cria um ficheiro .ovr que podes usar como uma imagem no qgis para ver o
> desempenho. Se quiseres um tamanho menor podes experimentar valores de
> compressão com a opção "--config JPEG_QUALITY_OVERVIEW 0-100". Já usei
> valores de 60 sem que os utilizadores reparassem muito, mas degrada a
> imagem...
>
> Para testar tudo gosto de usar o qgis. Adiciono o mosaico vrt e limito-o à
> escala recomendada pelo qgis. Adiciono o novo mosaico e faço-o ser visível
> "depois" desta escala. Para testar faço zoom ao mosaico, e depois zoom in
> sucessivos até chegar à escala dos originais. Em principio o desempenho deve
> ser óptimo.
>
> Em resumo:
> layer 1 =  vrt dos originais
> layer 2 = tif + ovr
>
> --
> View this message in context: http://osgeo-org.1560.n6.nabble.com/Carregamento-de-dados-raster-tp4562923p4568618.html
> Sent from the OSGeo Portuguese Local Chapter mailing list archive at Nabble.com.
>
>
> _______________________________________________
> Portugal mailing list
> Portugal  lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/portugal
-------------- próxima parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.osgeo.org/pipermail/portugal/attachments/20120312/e1bad202/attachment-0001.html


Mais informações acerca da lista Portugal