Formats d'image et chaîne de traitement
Landry Breuil <breuil@craig.fr>
Formats d'image
Chaîne de traitement
Compressions
Traitements à la volée
Une image, c'est quoi ?
- Une matrice
- Une ou plusieurs bandes de valeur (précision? couleur?)
- Une compression
- Des métadonnées
- Norme ISO de 1992 (travaux préliminaires dans les années 80)
- Compression avec perte, paramétrable
- Effet de flou
- Quantification par blocs puis compression
- Pas de transparence! (enfin, des bricolages web)
format | tif | jpeg 100% | jpeg 90% | jpeg 75% |
zoom 3x | | | | |
taille | 11.5M | 2.7M | 960K | 560K |
- Norme ISO de 2000
- Version améliorée de jpeg
- Streaming via JPIP, métadonnées GML JP2
- Format de diffusion par défaut IGN
- *Mais* foule de librairies pour le lire/écrire
- ERDAS ECW, OpenJPEG (BSD), JasPer (ref, MIT), Kakadu, MrSid...
- Avec des performances en lecture/écriture variables.. et un coût
format | TIFF | JasPer | OpenJPEG 100% | OpenJPEG 75% |
taille (3 img) | 215M | 103M | 68M | 54M |
- Format propriétaire (ER Mapper, ERDAS, Intergraph..)
- SDK binaire disponible en démo, ancienne version 3.3 pseudo-libre
- Compression par ondelettes
- Ancien format proposé par l'IGN
- Compression équivalente a JP2? ~10% de moins ?
format | TIFF | JP2ECW (90%) | JP2ECW (75%) | ECW |
taille (6 img) | 430M | 38M | 21M | 35M |
- Specifié en 1996, norme ISO en 2004
- 24 bits ou palette
- Palette -> estompe les couleurs...
- De 1 à 4 canaux, transparence
- Compression sans perte
- Parfait pour les données 'scans' (?) ou vectorielles
format | PNG 24bits | PNG palette | JPEG |
ortho, zoom 7x | | | |
bd forêt, zoom 4x | | |
- Domaine public depuis 1992, norme ISO en 1998
- Pas qu'un format, un conteneur (JPEG-in-TIFF?)
- Compression avec ou sans perte
- Espaces colorimétriques
- Métadonnées GeoTIFF
- Encodage par tuiles ou bandes
- Extrémement souple - dénominateur commun ?
- Parfait pour les données photo ?
Aperçus/pyramides
- Les SIG permettent de créer des 'aperçus' à différentes sous-échelles
- Ils seront automatiquement utilisés en fonction de l'échelle de rendu
- Peuvent aussi être compressés (pas *toujours* une bonne idée)
- En fonction des formats, embarqués ou externes (.ovr)
- gdaladdo, QGIS Raster->Divers->Construire des apercus
95M SCEXP50_STD_0690_6550_L93_E100.jp2 (6 nvx)
32M SCEXP50_STD_0690_6550_L93_E100.tif
11M SCEXP50_STD_0690_6550_L93_E100.tif.ovr (4 nvx)
Chaîne de traitement
GDAL/OGR
- Couteau suisse du SIG
- Découpage raster avec un masque (gdalwarp -cutline)
- Manipulation d'ensemble de rasters (gdaltindex, gdalbuildvrt)
- Calculatrice raster (gdal_calc.py)
- Connection directe aux BDD
ogrinfo --config PG_LIST_ALL_TABLES YES PG:"dbname=gisdata user=postgis host=db"
Découpage spatial/attributaire de vecteurs
ogr2ogr -where "POPULATION > 10000" -spat xmin ymin xmax ymax
Opérations spatiales (calcul de géométries)
ogr2ogr -dialect SQLITE -sql 'SELECT GUnion(GEOMETRY) from dallage'
Traitement de MNT (gdaldem)
Compression
- Pb des images brutes livrées en TIFF
- ~150To en 8 ans
- Puissance de calcul, IO, archivage
- 2014: Tests sur 10T ERDF, gain 20% avec DEFLATE en ~30j (usb)
- 2017: Tests sur ~25T 4 Agglos RTGE, gain 90% avec JPEG-in-TIFF+YCBCR 95%+TILED en ~10j
- Peut presque atteindre la même compression que l'ECW, sans pbm d'intérop
taille | variante (6 dalles RVB) |
430M | TIFF original |
354M | DEFLATE+TILED |
102M | JP2OpenJPEG+YCBCR |
212M | JPEG2000 |
49M | JPEG-in-TIFF+YCBCR 90%+TILED |
35M | ECW original |
Mapserver
- Prend en entrée tous les formats supportés par GDAL
- Par défaut en sortie, propose:
- png (24 bits)
- png8 (palette)
- jpeg (compression 75%)
- tif, gif, pdf, svg, kml, kmz
- Permet de configurer plus finement les formats de sortie, ie envoyer du png a la place du jpeg, forcer une palette 16 couleurs, du jpeg non compressé...
- Le format demandé par le client aura un impact direct sur la taille de l'image renvoyée, et son temps de calcul!
Couche | scan | ortho 10cm |
Echelle | png | png8 | jpeg | png | png8 | jpeg |
1:5000 | 2.9M, 0.9s | 650k, 0.8s | 310k, 0.2s | 3.1M, 3.5s | 1M,3.3s | 300k, 3.2s |
1:20000 | 3.2M, 5.3s | 830k, 5.4s | 470k, 4.9s | 3.2M, 4.4s | 1M, 5.4s | 330k, 5.8s |
1:100000 | 3.0M, 2.3s | 700k, 1.3s | 430k, 2.2s | 1.5M, 0.3s | 490k, 0.3s | 170k, 0.1s |
Courbes de niveau à partir de raster
DATA "/data/wxs/mnt/craig/vrt/all.vrt"
CONNECTIONTYPE CONTOUR
PROCESSING "CONTOUR_ITEM=elevation"
PROCESSING "CONTOUR_INTERVAL=0,5000:10"
PROCESSING "CONTOUR_INTERVAL=5000,10000:50"
GEOMTRANSFORM (smoothsia([shape], 10))
CLASS
NAME "50m"
MAXSCALEDENOM 10001
TEXT (round([elevation],1))
EXPRESSION (round([elevation],50) = [elevation]
and round([elevation],100) != [elevation])
...
Clustering de points (adresse/hameaux)
LABELITEM "nom_ld"
PROCESSING "NATIVE_FILTER=nom_ld is not null"
PROCESSING "CLUSTER_KEEP_LOCATIONS=ON"
# clustering en groupant par nom de lieu-dit
CLUSTER
MAXDISTANCE 1000
REGION "ellipse"
GROUP ('[nom_ld]')
END
Différence entre WMS et WMTS
- WMS
- renvoie une image unique
- superposition de X couches dans une requête
- format, échelle et projection choisi par l'utilisateur
- dans le cas d'un serveur tuilé, la réponse est assemblée à partir des tuiles du cache
- interrogeable
- WMTS
- renvoie X tuiles de 256 px de coté
- pour une seule couche
- format, échelle et projections fixes (le SIG zoome a l'affichage)
- le serveur renvoie directement ce qui est dans le cache, aucun calcul
- dans QGIS, juste une liste de couche/projections
- non interrogeable
- En fonction des cas, je choisis...
- WMTS si je veux un affichage ultra rapide, et que le format du cache est adéquat (fond ortho tuilé en jpeg, donnée vectorielle tuilée en png)
- WMS si je veux pouvoir interroger, ou plus de souplesse sur projection/format
Mapproxy
- Propose du WMS et du WMTS (TMS, WMS-C..)
- Prend en entrée tous les formats proposés par Mapserver (donc autant prendre la meilleure qualité possible)
- Peut proposer plusieurs formats paramétrables en sortie (png, jpeg..)
- Mais le plus important est le choix du format pour le stockage des tuiles!
- Le format utilisé pour les tuiles aura un impact direct sur la taille totale du cache..
- .. et sur la qualité de l'image renvoyée au client.. en fonction du format demandé!
Format de cache | ortho | scan | relief |
png24 | 130k | 162k | 86k |
png8 | 27k | 50k | 29k |
jpeg, 90% | 24k | 52k | 18k |
jpeg, 100% | 56k | 110k | 52k |
Cache | rtge | ortho_2013 | scans_ign | relief |
zone | Agglos | Auvergne | AURA | Auvergne+GG |
zooms | 1:4k - 1:500 | Max - 1:313 | 1:640k - 1:5k | Max - 1:5k |
taille | 480G | 420G | 18G | 13G |
tuiles | 3.1M | 56M | 965k | 380k |
Cas d'école: RTGE + PCRS vecteur
- Ortho tuilée en png24 (meilleur qualité possible)
- PCRS vecteur en png8 (donnée vecteur + transparence nécessaire)
- De l'importance de bien choisir son format de requête...
format | PNG | JPEG | JPEG + PNG |
taille | 722k | 968k | 965k |
zoom 3x |
|
|
|
/