Posté le 26/07/2003 à 22:35 Membre depuis le 12/05/2003, 795 messages
c une question comme une autre embarrassedops:
Posté le 27/07/2003 à 00:04 Membre depuis le 17/08/2002, 1036 messages
Le probleme va etre sur l'algo de decompression. Avec nos methode propose precedemment a part la premiere (vectorielle) la voix est fermé. Il faudrait utilisé des mathematique avance. Je rentre en Terminale S SI spe Math, peut etre que je verra ca pendant l'année. Pour l'instant c'est wait ant see.

Avec des fichiers aussi petit, ca va etre dur, compresser des truc lourd ok, mais compresser que des 1 et des 0, un peu plus dur.
Posté le 27/07/2003 à 23:06 Membre depuis le 17/08/2002, 1036 messages
Suite tres rapide en fait d'année.... :cry:

Comment veux tu mettre l'image sous forme de suite avec la méthode que tu as propose ? Car dans tous les cas avec la méthode du pi tu vas obtenir un alternance de un et de zero !

Donc pas possible !!!!!
Posté le 30/07/2003 à 17:07 Membre depuis le 17/08/2002, 1036 messages
Des qu'il y a compression, il y a mathematiques.

Ok pour l'alternance des pixels.

Deus si tu code l'algo comme dit precedemment tu vas avoir un probleme pour les retour a la lignes. Il faut que tu indique la taille de la sprites au debut.
Posté le 30/07/2003 à 21:39 Membre depuis le 21/10/2001, 1421 messages
A mon avis, la vectorisation d'image n'est pas adaptée à la puissance du z80, et à la petite taille de l'écran, dès que l'image est complexe, ça ne fonctionne pas... pour compresser des images, il faut utiliser les algos de compression classiques:
RLE:le plus simple, il supprime les suites de plusieurs octets identiques (1,1,1,1,1,1 remplacé par un truc du genre 3,*,1)

LZW:adaptation du RLE, il recherche en gros des suites identiques d'octets (et non suites d'octets identiques) pour supprimer une redondance de ce genre 1,2,3,4,1,2,3,4,1,2,3,4 Plus compliqué que le RLE, mais beaucoup plus performant. (c'est surement le plus adapté à la calculette)

HUFFMAN:là ça se complique, on fait un checksum des 256 octets possibles présents dans l'image, l'octet le plus fréquent sera remplacé par un seul bit, le secont par 2 bits...le moins fréquent sera alors une suite de bits assez longue.... enfin c'est assez compliqué à faire, surtout en asm Z80... donc vautm mieux pas trop chercher par là...


le mieux serait de faire une combinaison de RLE et de LZW (et autres algos pourquoi pas!) c'est d'ailleurs ce que font les formats ZIP,GZIP,RAR,......
Posté le 31/07/2003 à 10:53 Membre depuis le 18/07/2004, 335 messages
en fait ces algos compressent plusieurs fois un même fichier en utilisant deux algos, c'est ça ?
Posté le 01/08/2003 à 12:01 Membre depuis le 21/10/2001, 1421 messages
enfin on travaille sur des suites d'octets et non de pixels, donc faut pas compter le nombre de pixels alumés, mais le nombre d'octets identiques, ce qui est beaucoup plus facile à faire, pour le RLE en fait il faut avoir 2 octets de controle,si possible, les octets les moins fréquents dans la suite d'octets à compresser.

si on a comme octets de controle A et B (A pour indiquer une suite redondante, et B pour indiquer un A ou un B)la suite en dessous va etre compressée comme ça:

E E E F A R R R R R R R R R R B I O
->A 4 E B A A A 10 R B B I O (5 octets de gagné)

on gagne pas grand chose comme ça, on doit pouvoir améliorer légerement la compression en faisant un checksum de chaque octet de la liste, et utiliser comme octet de controle les 2 moins fréquents... d'ailleurs, si les octets de controle sont mal choisis, la suite compressée peut etre plus grosse que la suite non compressée! l'idéal est de disposer d'un octet jamais présent dans la liste qui peut servir d'unique octet de controle vu que dans ce cas, y a pas de confusuion possible....
Posté le 02/08/2003 à 11:56 Membre depuis le 21/10/2001, 1421 messages
bah la boucle de décompression est pourtant assez simple,
on recopie betement tous les octets sauf les A et B. si on rencontre un A, on va recopier autant de fois l'octet qui se trouve après le nombre de fois à recopier (si c pas très clair, si on a A 5 D, on va recopier D 5 fois...)
Et si on rencontre un B, on recopie l'octet suivant qui est un A ou un B ici

évidemment, ce n'est qu'un exemple, et on pourait mettre A D 5 pour une suite de 5*D au lieu de A 5 D, c'est juste un principe...

pour la boucle de compression, c'est pas plus compliqué, il faut compter le nombre de fois qu'un octet est présent à la suite, si il est présent plus de 2 fois (en dessous, ça va faire grossir au lieu de compresser), on va remplacer la suite par A XX YY (avec XX et YY l'octet et le nombre d'occurences) on regarde si l'octet à recopier est un A ou un B, dans ce cas on doit mettre un B devant...
Posté le 05/08/2003 à 11:24 Membre depuis le 21/10/2001, 1421 messages
Bon, ce topic m'a donné envie de reprendre un petit projet de routines de compression/décompression en un genre de LZW smile

si j'ai assez de courage, ça va pouvoir compresser et décompresser n'importe quelle suite de données, et pourquoi pas des fichiers entiers...mais on n'y est pas encore!
Posté le 05/08/2003 à 11:39 Membre depuis le 18/07/2004, 335 messages
il existe déjà une routine de décompression RLE, c'est fait par qui ? par David Phillips:

;Input:
;HL = Compress From
;DE = Compress To
;BC = Bytes to Decompress

Decompress:
ld a, (hl)
cp $91
jr z, DispRLERun
ldi
DispRLEC:
ret po
jr Decompress
DispRLERun:
inc hl
inc hl
ld a, (hl)
DispRLERunL:
dec hl
dec a
ldi
jr nz, DispRLERunL
inc hl
jr DispRLEC




et j'ai moi même fait une routine de compression RLE qui marche très bien sur la calculatrice, il ne reste plus qu'à l'adapter à un programme.
elle est disponible ici :
http://paxl.no-ip.org/~nibbles/temp/rle.txt

par contre il reste quelques adaptations à faire pour que les 2 routines proposées dans ce post soient compatibles, ça n'a pas marché du premier coup.
Posté le 07/08/2003 à 19:38 Membre depuis le 19/12/2002, 480 messages
La routine de David Phillips a été optimisée par Clem V. et Aaron Curtis. (voir site Void Productions).

;Input:
;HL = Compress From
;DE = Compress To
;BC = Bytes to Decompress

Decompress:
ld a, (hl)
cp $91
jr z,DispRLERun
ldi
DispRLEC:
ret po
jr Decompress
DispRLERun:
inc hl
inc hl
ld a,(hl)
DispRLERunL:
dec hl
dec a
ldi
jr nz, DispRLERunL
inc hl
jr DispRLEC
Posté le 07/08/2003 à 21:49 Membre depuis le 18/07/2004, 335 messages
je l'ai pris au même endroit smile
Posté le 09/08/2003 à 17:30 Membre depuis le 21/10/2001, 1421 messages
Mais à première vue, cette routine a un problème: l'octet de controle choisi pour indiquer une suite de n octets identiques est $91, ça me pose pas de problème, mais le cas où un $91 est présent dans la chaine à décompresser en tant qu'octet "normal" et non octet de controle n'est pas pris en compte, il faut pour éviter ce bug (qui arrive une fois tous les 256 octets en moyenne, c'est ennorme..) avoir un second octet de controle,par exemple $92 qui indique que le prochain octet de la chaine est soit un $91, soit un $92.....
Posté le 09/08/2003 à 18:12 Membre depuis le 18/07/2004, 335 messages
mais ce problème est pris en compte lors de la compression:
si on doit compresser l'octet $91, on écrit alors
$91 $91 $01
ce qui veut dire qu'on a recontré 1 fois l'octet $91. seulement dans ce cas, ça ne compresse plus grand chose. mais ça n'arrive que lorsq'on rencontre l'octet $91