dernière mise à jour: 3 janvier 2014
La documentation n'étant jamais à jour, il faut parfois aller lire les sources pour comprendre (parfois) le pourquoi du comment. Moi même, je n'y arrive pas toujours. Cette page me sert d'aide mémoire, donc c'est tout en vrac...
On peut marquer une image. Il existe quelques macros pour abstraire certaines choses, mais ce n'est pas très fini.
Il y en a probablement pas mal, mais dans l'ensemble, c'est assez stable. Peut-être quand même quelques petits 'memory leak' qui trainent dans des recoins obscurs... Exemple:
foo = Image_alloc(bla...);
Image_tripote(foo, bar);
Image_DeAllocate(foo);
free(foo); /* ne pas oublier ça... */
A ce moment, les zones mémoires contenant les pixels de l'image sont rendues au gestionnaire de mémoire, mais l'en-tête du descripteur d'image est encore malloc-é. Il convient donc de rajouter un free(foo).
Xv n'affiche pas les TGA fabriqués par Libimage ? Le bug n'est pas dans libimage, mais dans Xv. D'après les spécifications du format TGA, on peut ajouter un commentaire dans le fichier. Or, Xv ne reconnait plus les TGA comme des TGA si ce commentaire est présent, ce qui est le cas par défaut dans la bib. Le workaround est simple: il faut ajouter Image_set_comment(img, ""); avant d'enregistrer le fichier afin d'enlever le commentaire. Je pense même qu'il y a un truc dans le Makefile.
le flag 'modified' du descripteur d'image est mal géré. Oui, en effet, il n'est parfois pas positionné par les fonctions qui le devrait. Une revue complète de tout le code pour corriger ce souci est programmée pour 2012.
Par contre, le fait que certaines fonctions ne semblent pas finies n'est pas un bug. C'est un 'undocumented feature'. Et qu'il manque la documentation, c'est le lazzy effect.
Début 2007, j'ai découvert que le compilateur g77 était un produit en fin de vie, et que les Linux récents avaient de plus en plus tendance à préférer gfortran. Il est donc probable que l'interface actuelle soit mise à l'écart et remplacée par un équivalent plus moderne.
Merci au généreur donateur d'une Sun U5 grace auquel j'ai enfin pu finaliser l'adaptation du machin à une autre architecture que le trop commun i386 sous Linux, en l'occurence un processeur UltraSparc, tournant sous OpenBSD 4.4. Et ça a été plus facile que je ne le pensait, les soucis de boutisme ayant déja été réglés dans une vie antérieure. D'autre part, ça a été une bonne occasion de nettoyer le code d'un certain nombre de warnings assez génants.
Je dois d'abord préciser que la fidèle machine sur laquelle je fabrique le kluge est une très vieille Debian (une SID d'il y a cinq ans, c'est dire si je suis un dino), et que le Gcc est également *vieux* : gcc version 4.0.3 (Debian 4.0.3-1). C'est un peu génant, mais pas plus que si j'avais un Unixware 1.x :) Donc, en avant... Voyons, dans un ordre approximatif, les problèmes que j'ai rencontré:
Bon, j'ai gruiké ça rapidement un dimanche pluvieux, ça marche mais ça n'est peut-être pas orthodoxe. Je vais consulter les experts en fromages pour savoir si j'ai pris le bon chemin.
À priori, il reste pas mal de choses à faire, surtout pour rendre les boucles X-Y plus cache-friendly. Les buffers contenants les images étant organisés en tableaux de lignes, il y a probablement quelques hit/mess à grapiller. D'un autre coté, pour le moment, juste ça marche...
Bah, fatigué de devoir recopier mes fichiers .MAP de palette à droite et à gauche, j'ai ajouté une func qui cherche dans quelques endroits. Donc, j'essaye en série:
La première chose à faire (comme d'hab) c'est d'aller lire le Makefile. Vous y découvrirez quelques options à positionner selon vos gouts. Et un de ces jours, je vais passer au tandem infernal automake/autoconf, si jamais j'arrive à comprendre comment ça marche.
En attendant, les variables à positionner pour l'install sont:
A la compilation, on peut aussi utiliser quelques -DMACHIN=42 pour modifier le comportement de la bib. En phase de mise au point de la bibliothèque, il est capital de détecter les conditions anormales: eg: plotter en dehors de l'image. Donc, avec un -DABORT=1, les conditions anormales génererons un COREDUMP analysable avec gdb, si vous n'avez pas oublié de régler votre ulimit -c à une valeur raisonnable.
alloca.h oui, là, il y a un léger souci. je suis en ce moment en train de tenter d'installer ma libimage dans un OpenBSD, et je ne sais pas quoi faire pour les alloca. (2007-12-30) investigations en cours. Sans compter que le problème va se poser aussi avec NetBSD.
Bien que tout ce fatras soit codé à la gruik, j'essaye d'introduire un peu de rigueur dans la chose. En particulier, certains noms de paramètres de fonctions vont être normalisés. Ce qui, en fait, ne sert à rien, parce que c'est le codeur qu'il faudrait normaliser.
Les hackeurs trouveront dans le fichier imprime.c une fonction : Image_print_sizeof_structs, qui affiche les tailles des diverses structures utilisées par les rouages internes.
Il faut regarder les #define dans tthimage.h et la fonction Image_err2str dans msglib.c. Je préfère ne rien mettre ici, parce que j'aurais la flemme de le mettre à jour quand il faudrait le faire... En particulier pour classer les codes d'erreur en fonction de leur gravité.
Elles sont habilement dissimulées dans le fichier tthimage.h, mais je ne leur porte qu'une confiance limitée.
Deux dumpeurs de pixels dans dumppix.c. Le premier affiche des trucs en hexadécimal, et le second en ascii. Ne m'en demandez pas plus, je ne suis au courant de rien. Heureusement, il y a un autre package qui contient quelques tools assez performants.
Il manque plein de choses dans cette bibliothèque de fonctions, ou dans les outils qui tournent autour. En Octobre 2003, je suis en train de travailler sur un éditeur de fontes 16x24, mais il ne sortira que quand il sera prèt. Nous sommes le 1er janvier 2014, et ça n'a pas avancé d'un pas.