Inscription : 05 Août 2011, 14:38 Message(s) : 193
Ca fait déja un moment que je me suis lancé dans le compactage de données je crois que j'ai déjà lancé une rubrique dessus mais voila la nouvelle, j'espère que ça donnera et intéressera quelqu'un ou me (lui) donnera des idées ...
Je me suis attaqué pour le moment depuis quelques mois aux écrans 17K image de présentations je vous fait pas un dessin J'ai déja fait quelques études et projets malheureusement pas toujours a la hauteur des derniers compacteurs applib et exomizer. Mes débuts sont prometteurs... Mais le résultat n'est pas encore à la hauteur. J'ai constaté qu'une réorganisation de l'écran en un sprite dont les octets sont en verticales donnait un très bon résultat après un compactage avec les compacteurs de dernières générations la réorganisation horizontale est aussi meilleure qu'un écran 17 K mais moins bonne que le vertical.
J'ai fait quelques compacteurs
1. Chaque fois qu'il voit un octet il compare ce qu'il est après genre (methode RLE) 01 01 01 02 03 04 04 ff ff ff ff ff 03 05 compacte ca fait 01 03 02 01 03 01 04 02 ff 04
pas vraiment ergonomique
Technique 1
Comme je m'attaque qu'aux images en prenant compte que c'est un mode 1 les 4 couleurs primaires correspondent a &00 &0f &f0 &ff encre 0,1,2,3 ce sont les plus utilisées dans une images, statistiquement c'est pas loin des 70 % d'où j'ai fait une version améliorée qui ne prenait compte que des 00 0f 0f f0 donc quand il il y a un 00 ou 0f f0 ff dans le compactage il copie le nombre après c'est déjà beaucoup mieux mais le problème se pose quand il n'y a qu'un 00 ou 0f ou f0 ff ca prend 2 octets a la place d'un. J'ai trouve un solution je scanne les octets de l'écran et dans 99% I il y a des octets non utilise dans un écran. donc je fais un test de tous les octets et je prends des non utilises et je les attribue l' un a &00 l'autre a &0f , l'autre &f0 et &ff par ex pour la compréhension si dans l'écran il n'y a pas de 54 admettons je l'attribue dans mon compactage a 00 comme ça s'il n'y a qu'un 00 je le laisse c'est bien mais pas assez...
Technique 2
En sachant que les 00 ou 0f f0 ou ff sont les plus présent dans un écran mode 1 j'ai pense que je plus pratique serait de les enlever J'ai réalise le compactage qui enlevé par ex tous les 00 ma méthode est que j'ai employé les bits donc par exemple 00 00 00 00 01 44 55 ff (image) ça correspond a 01 44 55 ff (la source sans 00) et l'autre partie du compactage par bits 0 0 0 0 1 1 1 1 =&15 donc pour c'est /8 une image prendra &800 de données et le reste de source c'est bien mais pas assez j'ai fait des tests en passant après par aplib et le résultat donnait mieux si je faisait 1 sur deux c'est a dire que c'est la même méthode mais il compare par 2 octets un exemple 00 ff 44 f0 00 00 00 00 00 00 f0 11 55 00 00 résultat 1 sur 2 1 1 0 0 0 0 1 1 0 c'est mieux mais ça suffit pas comme ca ça fait &400 de donnes octets au lieu de &800 (normal 1/2)
j'ai essayé de faire une autre méthode dans une image toujours mode 1 il y a 4 couleurs donc j'ai fait une routine qui analisait les bits c à d si c'est du rouge on trace du rouge sur la longueur qui faut ça va mais c'est pas aussi concurrentiel que les autres c'est a dire que je scanne ligne par ligne 4 rouge 1 blanc 5 vert 1 blanc 2 gris 1 blanc 25 rouges le problème c'est qu'il y a a 64000 octets par écran a (8*8*40*25) ça compacte mais pas assez
J'ai pensé qu'une image pouvait être affiche dans une autre mode qui ne lui correspondant pas donc quand je l'affiche en mode 2 il n'y a plus que de 2 couleurs ça simplifie les choses il n'est pas compliqué de la réachiffer dans le bon mode avec un call bc0e et ldir mais pas assez concluant
méthode 3
dictionnaire
j'ai pensé que mettre les octets différent de l'image en partant de c000 dans un dico serait intérressant mais un dictionnaire de 16 octets dès qu'il est rempli on commence une autre page, le principe est d'attribuer un chiffre sur 4 bits au nombre pour pouvoir a la fin diminuer de moitie l'image
donc une image 00 ff 44 00 44 22 11 f0 02 03 09 09 11 05
on attribue le premier 00 a 00 ff a 01 44 a 02 22 a 03 etc jusqu'à 0f ensuite les nouveaux. Le principe est que je fusionne les deux octets en un. Ca fait que pour une image c'est la moitie le problème c'est que le dictionnaire prends beaucoup de place car lorsque que les 16 octets sont occupés le suivant fait une nouvelle série. Je sais pas si je suis clair... Le principe est bon mais ...
A vos idées merci
Si quelqu'un veut mes sources pas des soucis je peux les mettre en ligne
la réorganisation verticale ne fonctionne pas sur toutes les images prends le manoir de morte-vieille, ils réorganisaient parfois en vertical, mais pas toujours il faudrait déjà voir quel type d'image tu veux compacter pour gagner face à du applib ou mizoumizeur il faudra faire du spécifique, pas du générique
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 1 invité
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum