KOMMANDOInternetMatérielsPrestationsNEXTSTEP·OPENSTEPFormationsPartenairesRéférences



[Banniere]

[Version imprimable]

Traitements par lot et opérations NON interactives [suite]

Paru dans DREAM n°57 / décembre 1998 Yannick Cadin

Dans le précédent article, nous utilisions convert (du lot d'utilitaires ImageMagick) pour extraire une petite portion d'une image volumineuse. Nous allons ici améliorer encore ce processus, prétexte pour présenter d'autres commandes intéressantes.

Mais surtout, nous nous affranchirons d'un petit problème que l'on rencontre avec les commandes ImageMagick, à savoir le chargement intégral des images avant leur exploitation. Inconvénient partagé avec bon nombre d'utilitaires graphiques.

Autrement dit, pourquoi charger une image pouvant faire plusieurs milliards d'octets alors que seule l'extraction d'une infime partie nous intéresse. Là encore, cette contrainte sera le prétexte à la mise en oeuvre d'une bibliothèque bien sympathique.

On commence en donnant une alternative à l'emploi de convert pour ce qui est de l'extraction, avec la commande fbext tirée du lot de commandes FBM, Fuzzy Pixmap Manipulation (ftp://nl.cs.cmu.edu/usr/mlm/ftp/fbm1.2.tar.Z).

Le bénéfice ici est de pouvoir utiliser en entrée des formats graphiques compressés, ce que n'autorise pas convert dans le cadre d'une extraction si ce n'est par l'artifice consistant à compresser le fichier RGB avec la commande gzip, ce qui est loin d'être idéal.

Une note en passant pour recommander la modification du Makefile de FBM afin que les variables BIN et MAN pointent respectivement sur /usr/local/bin et /usr/local/man (les créer au besoin ainsi que /usr/local/man/manl).

Les utilitaires fournis sont susceptibles de reconnaître les formats les plus usités, à condition toutefois de disposer des bibliothèques correspondantes et d'en fournir les chemins d'accès via le fichier Makefile (pour les TIFF et JPEG en particulier).

Juste pour montrer à quoi pourrait ressembler un appel à fbext dans notre script (image_seule.pl), je me contente du format GIF pour le codage de l'image source. Par contre, fbext ne connaissant que la version 87a du format GIF, il faut au préalable convertir notre image dans ce format comme ci-dessous :

convert /home/httpd/html/carto/carte.tif gif87:/home/httpd/html/carto/carte.gif87

Ensuite dans le script image_seule.pl, il suffit de modifier la ligne principale pour qu'elle ressemble à ce qui suit :

system ("/usr/local/bin/fbext -G $csg_x $csg_y 200 200 </home/httpd/html/carto/carte.gif87 | /usr/X11R6/bin/convert -draw 'image 90,170 /home/httpd/html/carto/legende.tif' -quality 90 -gamma $gamma gif87:- jpeg:-");

Les remarques maintenant. L'option -G non documentée dans le 'man'uel de fbext correspond à l'indication de format GIF en sortie. Cette option ainsi que celles des autres formats connus sont visibles par 'man fbm'. Le format en entrée est déterminé automatiquement et peut donc être différent du résultat.

Il est évident que pour des images de plus de 16 000 pixels de côté, il faudra recourir au format TIFF en entrée et donc interfacer les commandes FBM avec la libtiff. Enfin, comme on peut le constater l'intérêt global demeure faible car il faut tout de même faire appel à convert pour l'incrustation d'une légende sous forme de vignette graphique. Cela permet toutefois de présenter FBM et la syntaxe pour demander à convert de lire sur l'entrée standard dans un format donné.

Cette petite transition n'était là que pour présenter FBM, un des nombreux outils de manipulation des graphiques bitmap. Il n'en reste pas moins qu'il n'est pas forcément très adapté à des extractions au sein de très gros fichiers si lui aussi charge l'intégralité de ces fichiers avant que d'aller piocher dedans.

Aussi, à défaut de trouver la perle rare (qui pourtant existe, je n'en doute pas), on peut la développer nous même. Le cahier des charges est relativement simple : support de grandes images (jusqu'à 4 Go en l'occurrence), pas vraiment de limitation en nombre de pixels en largeur et hauteur, maximum de 256 couleurs (puisque prévu à priori pour des cartes) et surtout, deux points importants, le stockage d'un index pour connaître l'adresse de chaque début de ligne dans le fichier car, et c'est là le deuxième point et l'aspect le plus intéressant, nous allons compacter chaque ligne à l'aide d'une fonction de la librairie zlib.

En clair, notre document pourra faire jusqu'à 4 Go, MAIS 4 Go compressés.

Vous retrouvez les sources auto-documentés des deux programmes, conversion vers, ET depuis, notre format propriétaire. Et même si ce n'est pas encore la panacée, vous percevez rapidement que nous ne nous préoccupons que des lignes dont une partie des points vont se retrouver dans la portion extraite, grâce à ce fameux index.

De retour dans notre script image_seule.pl, la commande principale devient désormais :

system ("/usr/local/bin/cpii2rgb /home/httpd/html/carto/carte.cpii $csg_x $csg_y 200 200 | /usr/X11R6/bin/convert -draw 'image 90,170 /home/httpd/html/carto/legende.tif' -quality 90 -gamma $gamma -size 200x200 rgb:- jpeg:-");

Vous remarquerez que l'on s'appuie toujours sur convert pour générer le document dans son format définitif. Cela nous évite de développer les routines d'écriture en GIF, JPEG ou autre PNG. On se contente d'envoyer du RGB, ce qui est simpliste, et convert se charge du travail délicat. Il permet aussi et surtout de traiter l'incrustation de notre vignette graphique et la correction gamma.

Au préalable, il aura bien évidemment fallu convertir notre image originale dans notre nouveau format (le CPII) à l'aide de la commande suivante :

/usr/local/bin/rgb2cpii /home/httpd/html/carto/carte.rgb 1000 1000 /home/httpd/html/carto/carte.cpii

Concernant les sources, vous passerez rapidement sur la piètre qualité de leur rédaction pour ne vous focaliser que sur certains détails spécifiques à l'emploi des fonctions compress2 et uncompress de zlib.

Le point probablement le plus important à prendre en considération est la double fonction de la variable contenant la taille du buffer de destination. En effet, si après l'appel aux fonctions compress2 ou uncompress elle contient la longueur résultant du traitement, elle sert aussi à fournir à ces mêmes fonctions en entrée la largeur du buffer dans lequel elles peuvent évoluer. Il est donc indispensable de toujours y placer la valeur appropriée AVANT chaque appel.

La grande diversité de librairies ou d'API graphiques spécialisées (libtiff, API de GIMP, librairies d'ImageMagick, libpng, libjpeg, libungif, etc.) fournies en standard ou téléchargeables depuis Internet offre beaucoup de perspectives pour n'importe quel développement spécifique.

[petit logo]

     Chercher sur ce site

Une remarque, une question ou une suggestion ? Merci de nous écrire à info@kommando.com.

KOMMANDO
Siège social : 3, rue Jacques Daguerre · 95370 MONTIGNY lès CORMEILLES
Tél : 33 (0)6 60 60 10 48 · Fax : 33 (0)6 61 60 10 48 · info@kommando.com



KOMMANDOInternetMatérielsPrestationsNEXTSTEP·OPENSTEPFormationsPartenairesRéférences