dernière mise à jour: 2 Juin 2008
La doc 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.
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.
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.
Il faut regarder les #define dans image.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...
Elles sont habilement dissimulées dans le fichier image.h.
Deux dumpeurs de pixels dans dumppix.c. Le premier
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 18x24, mais il ne sortira que quand il sera prèt.
vous pouvez me contacter:
oulala@chez.com
Si votre diff est lisible, je patche --force :)
haut de page