Traitement par bande de l'image binaire -- RAPPORT D'EVOLUTION-- DdB #DS2KI@! M.Deschamps ______________________________________________________________________________________________________ le 23/01/2001 à 01:44 Decision : il faut une liste tampon de Rectangle pour permettre au traitement de fusion de travailler a partir de la mémoire vive (Run-time) Pb : dans le cas de certaine image binaire, ce tampon pourrait-il encombrer trop la mémoire? Solution : TRACE : valid\23#01#2001\Trace.txt . Une exemple sur une petite matrice ______________________________________________________________________________________________________ le 24/01/2001 à 0:57 Decision : Il faut detecter tous les bandes d'une ligne puis de la matrice Pb : Pb mémoire (creation tableau taille raisonnable impossible !!!:(((( ) Solution : Essai sur le compilateur a l'iut & utilisation de Visual c++ v5.00 Pro TRACE : valid\22#01#2001\_bande.cpp ______________________________________________________________________________________________________ le 25/01/2001 à 2:25 Travail effectue : Le traitement detecte toutes les bandes de la matrice (quelques bugs persistent!) Pb : Les bandes non fermees en fin de ligne ne sont pas compatiblise Decision : Codage avec le nouveau compilateur qui semble etre bien plus souple pour la memoire TRACE : valid\25#01#2001 Traitement fonctionne meme sur des matrices de 10000 * 10000. :)) ______________________________________________________________________________________________________ le 26/01/2001 à 1:55 Travail effectue : Le traitement detecte toutes les bandes sur toutes taille de matrice Bug de bande fermante en fin de ligne corrigé. Bug du "bit fou" persiste : des bits de la matrice change d'etat d'une fonction a une autre TRACE : valid\26#01#2001 _______________________________________________________________________________________________________ le 27/01/2001 à 11:45 Travail effectué : Le traitement est presque complet, les bandes sont analysees par une fonction puis optimisee en rectangles plus grands (ce qui sauve de l'espace mémoire) Bug du "bit fou" corrigé : les images de matrice sont mises en constant (const) les fonctions les traitant n'accepte plus que des param par ref. Pb : L'optimisation des rectangles oblige une decoupe des rectangles, pour l'instant les "miettes" de rectangles resultantes ne sont pas prises en compte L'optimisation passe par l'anlyse sequentiel de la liste des rectangles en mémoire. En fin de matrice, celle-ci etant importante, le temps d'execution devient horrifiant -> INACCEPTABLE TRACE : valid\27#01#2001 _______________________________________________________________________________________________________ le 28/01/2001 à 4:30 Decision : Le temps d'exe etant un objectif a atteindre, il faut mettre en place une serie de stats pour permettre de commencer deja a optimiser le code Pb1 : Bug dans la detection des cas & la creation du rectangle fusionne (coord impossible) Soluce : implementation de 6 nouveaux cas encore non pris en charge Pb2 : La creation de rectangle fusionné n'est pas "intelligente", certaines solutions choisies de fusion ne sont pas optimale... Soluce ? : Tester entre plusieurs creations possible avec un critére de selection : l'aire optimal pour un rectangle donné (mais le run-time ! :(((( ) pb3 : Maintenant que les fusions se font plus nombreuses, les parcours de liste des rectangles fusionnés et des bandes encores non fusionnées lourdissent de facon PHENOMENALE le run-time Soluce ? : implementer dans la classe rectangle un drapeau de "derniére modif en ligne " et si aucune modif n'a ete enregistee depuis plus de y+1 alors faire passer le rectangle dans une autre liste (definitive?). Pour eviter de parcourir encore la liste, cette analyse se ferait pendant celle de l'analyseFusion (?) TRACE : valid\28#01#2001 _______________________________________________________________________________________________________ le 1/02/2001 à 21:45 Travail effectue : Mise en place de la gestion du format raw (jusque la, l'algo gerait du fichier texte avec des zero et des un) suite au RdV client du 31/01 (afin que le resultat soit "visible" avec un editeur d'image) TRACE : valid\1#02#2001 Reste a faire : _La gestion des "miettes" de rectanles, il s'agit des "chutes" de la fusion de ces derniers, ils ne sont pas encore pris en compte (ils sont "oubliés"). Le pb C qu'ils sont souvent necessaires a la fusion d' autres rectangles (qui pour l'instant ne fusionnent pas et sont laissé en bande séparées) _L'optimisation de la liste des rectangles enregistrés en mémoire, il faut que les rectangles deja fusionne et qui ne sont plus susceptible de l'etre soit stockés dans une liste finale afin de ne pas alourdir la recherche de recatngles compatible a la fusion (lecture sequentielle de la liste =>long!) ________________________________________________________________________________________________________ le 3/02/2001 à 2:22 Travail effectue : Mise en place de la gestion des "miettes" de rectangles. Tout les cas ont désormais géres de facon complete Remarque : Le run-time s'est ameliore et pourtant les miettes etant gerees cela devrait etre plus lent !!! ________________________________________________________________________________________________________ le 5/02/2001 à 22:15 Travail effectue : Correction du code (certains tests en particulier) sur conseils de Valère Rq: La mise en place de strcmp dans les tests n'a pas ete mise en place car la signature de la methode oblige des conversions de paramatres lourdes et complexes qui pourrait compromettre le bon fonctionnement du prg. ________________________________________________________________________________________________________ le 13/02/2001 à 21:35 Travail effectue : Mise en oeuvre de la libeartion de l'image de la memoire et de l'effacement memoire de la lsite tampon pour assurer un recouvrement memoire total. ________________________________________________________________________________________________________ le 16/02/2001 à 1:10 Travail effectue : Mise en place d'un paramétrage du nom de l'iamge de ses dimension ainsi que d'autre parametre en ligne de commande du main. Commentaire du code finaux. Collecte de trace d'execution. ________________________________________________________________________________________________________ le 20/02/2001 à 19:35 Constat : la simple mise en memoire de l'image .raw la modifie ! Le blanc est transformer en un noir clair et le noir semble rester intact ?!? Solution : Probleme résolu la valeur du blanc sur 8 bits = 255 et non a 0 (C le noir) Nouveau Pb : La lecture du bitmap est mal formatée (le blanc a une valeur decimale de -51) __________________________________________________________________________________________________________ du 20/02/2001 au 24/02/2001 Travail effetué: debut du rapport de synthése sur ce traitement Pb : L'image final.raw (dessin des rectanges en memoire) ne considere, il semblerait, que le premier ou le dernier rectangle de la liste Soluce : L'ecriture disque se fait ligne a ligne et donc l'ecriture doit etre reportée en fin de ce traitement une fois tout les rectangles "ecrit sur l'image" Le pb de formatage a la lecture a aussi ete resolu, la valeur du "blanc" est sous forme entiere il fallait donc pas oublier de le "caster" en char. constat : Le liste des rectangles s'allongent de plus en plus, il reste l'optimasation de celle-ci a effectuer ainsi que le filtrage des rectangles trop petit (critere a definir) TRACE: 24#02#2001 ___________________________________________________________________________________________________________ le 3/02/2001 Travail effectué : poursuite du rapport de synthése. Explication de chaque méthode selon la séquencement du traitement à l'éxécution ________________________________________________________________________________________________________