[HECTOR HRX/MX] de belles images sur vos HRX/MX

[__sam__]

Si je comprends bien la manip, tu te fais sur PC un fichier "data" représentant l'organisation mémoire Hector à partir du fichier BMP converti. Ensuite tu passes exomizer en mode RAW sur ce fichier data. Là tu envoies ces data dans l'Hector dans une zone mémoire différente de la mémoire video, puis tu executes le decompresseur vers la ram video.

C'est bien ca ou est-ce que tu procède différemment ? Il est important de séparer les data de la zone de mémoire où elles se décompressent. Il est aussi important de compresser dans le même mode que le décompresseur. Si le décompresseur est en mode "inverse" (des adresses hautes vers les adresse basses), il faut compresser avec l'option -reverse je crois me souvenir.

Bonux:

[6502man]

Oui le processus que tu décrit est bien celui la !

Je viens d'essayer plusieurs options de compression mais soit ca plante soit c'est pas mieux

Je vais essayer une autre version du décompresseur ...

[6502man]

Je viens de penser que lors de l'assemblage de mon code source il m'avait retourné 2 erreurs car il ne reconnaissait pas les mnémo et j'avais remplacé par ce qu'il me semblait correct pour TASM mais peut être me suis je trompé de ce côté la

voici les 2 lignes en causes :

Code : Tout sélectionner

ld      ixl, c

remplacé par :

Code : Tout sélectionner

LD L,C

et

Code : Tout sélectionner

dec     ixl

remplacé par:

Code : Tout sélectionner

DEC L

Sinon je ne vois pas pourquoi cela ne fonctionne pas sauf à avoir besoin d'un buffer très grand ???

[Markerror]

Bonjour,

Tu es sûr que le registre L n'est pas utilisé ailleur ? Il vaut mieux remplacer ces nmémoniques par leurs équivalents binaires, à savoir.

LD IXL,C : DB &DD,&69

DEC IXL : DB &DD,&2D

Markerror

[Fool-DupleX]

Fais aussi attention à ne pas décompresser dans la même zone mémoire que la source, car tu vas écraser les données comprimées avec les données décomprimées qui se déroulent plus vite que les données comprimées ne sont lues.

Effectivement, je confirme qu'il est très important d'avoir le bon mode de compression. Pour le 6809, j'ai entièrement réécrit l'algorithme de zéro et il n'y a qu'un seul mode qui est supporté, par exemple. Je ne sais pas pour l'algo sur Z80, mais j'ai observé qu'il n'est pas optimal. Peut-être est-il aussi buggé.

A noter que les images en 4 niveaux de gris, 320x200 sur MO6/TO8/TO9+ ou en 4 niveaux de bleu sur MO5 (y'a des contraintes par contre) sont assez bluffantes, surtout en animation.

[6502man]

Super MERCI Markerror

C'était bien la le problème j'avais remplacé ces 2 mnémo par 2 incorrect d’où le problème à la décompression

Du coup j'ai essayé avec le compresseur sous Windows les 2 options en mode RAW avec ou sans -c (disable literal sequence) et dans les 2 cas j'obtiens exactement le même fichier de sortie (même longueur) avec la même image évidemment
J'avais essayé aussi d'assembler la version du source pour utiliser les fichiers compressés avec l'option -c mais il me sort aussi plusieurs mnémo inconnus ???
Pour ma culture personnel ou trouver la correspondance opcode de ces mnémo ?

Code : Tout sélectionner

inc     iyl
ld      iyl, c

Maintenant que j'ai trouver je pense la meilleur compression possible, je vais arranger le programme assembleur pour qu'il récupère la bonne pallette pour chaque image et faire un petit slideshow pour illustrer tout ca

[yo_fr]

Tu pourrais mettre le contexte d'utilisation de ces deux instructions ? Car il il a aussi les registre IX et IY en Z80
et on a des DEC IX et des LD IX,valeur ...(les registres IX / IY sont les registres dit d'indexation)
Le code source est pour quel processeur

[6502man]

Le code source est pour Z80 justement

Je connais les IX et IY mais je n'avais encore jamais vu ces registres pour ma part !!

En fait si l'autre code est plus rapide à la décompression ca peut être intéressant

[Markerror]

Bonsoir,

Pour connaître facilement les valeurs hexadécimales correspondant aux "instructions cachées" du Z80 (bon, pas cachées en fait, mais pas très utilisées et pas documentées partout ni connues des assembleur/moniteurs/désassembleur de l'époque), tu peux utiliser l'assembleur de Winape.

INC IYL donne &FD &2C
LD IYL,C donne &FD,&69

Ces instructions permettent en fait de manipuler les poids fort ou faible des registres IX et IY. C'est pas forcément très utilisé car en temps machine, c'est plus lent que les registres non indexés, mais dans le cas où on a besoin de plein de registres 8 bits, ça peut dépanner .

Markerror

[__sam__]

@Phil: Pour info, en compression "horizontale" tu gagnes combien de ko/image ?

@Fool: En couleur c'est pas mal non plus quand on arrive à choisir le bon sous-ensemble de 4couls. Tu devrais voir les images que j'ai envoyé à Phil.... Je pense qu'il va en garder certaines pour son slideshow. Il pourra peut-être publier le surplus par ici, mais en attendant voici quelques autres images que je viens de produire.

lion-prides-of-our-timbavati-lodge.gif (12.54 Kio) Vu 1186 fois

500231442.gif (6.77 Kio) Vu 1186 fois

3494423190_7c24301b8e_m.gif (11.55 Kio) Vu 1186 fois

[__sam__]

Personne n'a envie de faire un jeu de poker pour HRX ?

dt.streams.StreamServer.jpg.gif (7.65 Kio) Vu 1182 fois

On pourrait gagner une belle voiture...

ford_falcon_lower.gif (7.79 Kio) Vu 1182 fois

[Fool-DupleX]

Ces vieux algos de diffusion d'erreur sont décidément désuets, je ne les supporte plus (artefacts dans les tons medians bien visibles sur les cartes à jouer par exemple), c'est quand que tu passes au moins à la diffusion stochastique ? Ca a 15 ans maintenant, ca devrait être assez vieux non ?

t'as déjà essayé la structure-aware de mon pote Victor ? C'est une de mes préférées. Je pense qu'elle pourrait donner d'excellents résultats en vidéo pour préserver les détails.

http://www.iro.umontreal.ca/~ostrom/pub ... 9_saed.pdf

[__sam__]

t'as déjà essayé la structure-aware de mon pote Victor ? C'est une de mes préférées. Je pense qu'elle pourrait donner d'excellents résultats en vidéo pour préserver les détails.

J'ai essayé l'une des méthodes de Victor (dans laquelle les coefs de diffusion sont variables en fonction du niveau du point considéré).

dt.common.streams.StreamServer.MAP.png (6.66 Kio) Vu 1172 fois

Mais sur un trop grand nombre d'image j'ai trop d'artefacts du type "serpentin" ou "grille": il y a des lignes uniformes verticales ou des serpentins de deux pixels de haut en bas. (regarder dans la pelouse "vert 50%" : il y a pleins de grilles qui rompent le motifs à damier):

1272662374prod_376_19914.MAP.png (5.96 Kio) Vu 1172 fois

Bref, d'un coté avec FS il y a des "worms" et de l'autre des serpentins.

Bon il y a peut être un bug dans l'adaptation de la diffusion de Victor sur des images non N&B ou aux couleurs non orthogonales, je ne sais pas trop. J'ai fait dans le rapide au mieux en utilisant ce que la bibliothèque graphique sous-jacente permettait. Dans le fond la partie sur laquelle j'ai travaillé est le fait de n'utiliser que 4 couls et pourtant avoir des images très colorées (une réduction de couleur classique donne de mauvais résultats dans le cas présent.)

[jester]

Utiliser un algo par diffusion pour des images type cartoon est une erreur de casting majeure... le résultat est lamentable dans la plupart des cas... un dithering sur des trames basiques donnent de bien meilleurs résultats.
Les techniques les plus belles sont celles qui utilisent un maximum de couleurs unies ou bien utilisent un motif simple pour reproduire une couleur à partir d'un mix de deux couleurs primaires... le résultat est visuellement sympatique et ne pique pas les yeux comme la diffusion qui s’apparente d'avantage à une bouillie de pixels qu'il faut regarder à 10m de sa TV cathodique (avec un tube si possible HS pour assurer le maximum d'aliasing).
Disons que la méthode choisie donne des résultats sympa pour des sources photo-réaliste, pour des images issues de jeu vidéo c'est un mauvais algo pour des yeux humains, à moins d'être un fan de ce type d'art... disons moderne.
Perso je ne suis pas client, mais c'est une affaire de goût.

[Fool-DupleX]

Le résultat est visuellement meilleur sur l'image avec les cartes à jouer (que le FS classique). Mais cette variante de FS a coefficients adaptés, toute intéressante qu'elle est, n'est pas ce que Victor a fait de meilleur. D'accord, le stochastique est un classe III compliqué à implémenter en couleur. Le structure-aware est un classe II, donc son algo est similaire à du FS, plus facile à implémenter.

Pour ce qui est des trames régulières, je reste fidèle aux trames à rotation dispersées non-Bayeriennes (http://lspwww.epfl.ch/publications/colo ... dda_95.pdf), également de Victor. Mais au-dela de la trame qu'il a développée, c'est la technique de calcul de la trame qui est intéressante. Je l'ai moi-même utilisée avec succès pour construire des trames spécifiques à certains systèmes d'impression non standard (http://www.thermorewrite.com/eng/).

Ouh, ca me rappelle mes belles années dans la recherche tout ça. Bons souvenirs.

PS. Et le pulse-density d'Eschbach ? Partir du FS puis relaxer les points par recuit simulé ou similaire ? Hmm. ptet pas super facile pour de la couleur.

J'ai du code d'époque, il faudrait que je te le file.