[exelvision] utilitaire pc2des, exemples

[kevlar]

Je suis en train de tester l'utilitaire Pic2des de 6502man, merci à lui !
Sur l'exemple ci-dessous, je pars d'une image en 24 bits, convertie en couleurs indexées 8 bits, puis retaillée en 320 pixels de largeur (c'est l'image en haut à gauche de cette copie d'écran).
C'est cette image déjà préparée que j'importe dans Pic2des.
J'obtiens la conversion en 8 couleurs "sans palette" propre à l'EXL 100 sur l'image en bas.


Je pense qu'il doit être possible, en travaillant davantage l'image de départ, d'arriver à une conversion encore meilleure (mais la "non palette" de l'EXL 100 impose ce rendu "rosâtre" pour le gris).

En tout cas, on peut bien s'amuser avec Pic2des, merci !

[jester]

En pratique le rendu est bien plus chouette en partant d'images de type BD, ou en 16/32 couleurs (jeux atari, amstrad, etc.).
A partir de photos les teintes sont toujours assez bizarre et le tramage devient vite de la bouillie.

Tu saurais pas dessiner par hasard ?
Tu sais programmer aussi me semble-t-il... tu programmes toujours ? (pas obligatoirement en langage machine)
C'est parce que je me sens un peu seul parfois

[6502man]

Ca fait plaisir de voir que l'utilitaire sert à quelqu'un

Sinon tu peut directement partir d'une image 32 bits juste redimensionné a la bonne taille (320 x 200), et tu règle directement le niveau RVB de l'image pour obtenir ce que tu veux ( ou du moins le plus approchant).

Comme la signalé Jester les meilleurs résultats sont obtenus a partir d'images 8/16 bits, mais dans certains cas des photos en 32bits peuvent donner un bon résultat.

Amuse toi bien avec l'utilitaire et pense a nous faire un petit diaporama des résultats

[kevlar]

En pratique le rendu est bien plus chouette en partant d'images de type BD, ou en 16/32 couleurs (jeux atari, amstrad, etc.).
A partir de photos les teintes sont toujours assez bizarre et le tramage devient vite de la bouillie.

Tu saurais pas dessiner par hasard ?
Tu sais programmer aussi me semble-t-il... tu programmes toujours ? (pas obligatoirement en langage machine)
C'est parce que je me sens un peu seul parfois

Oui, je programme en C, maintenant.
Dis-moi si tu as des besoins particuliers pour un projet de jeu (pour le dessin).
Actuellement, j'essaye de comprendre comment je vais, dans un premier temps, transférer le fichier .DES vers l'émulateur ...
J'avais de la doc technique interne de 1985, je croyais que le trap 11 servait à charger une image HR, pa-ta-trac, c'est une sorte de routine "logo" de tracé de traits d'après ce que j'ai compris.
Mon objectif étant de faire fonctionner tout çà sur mon EXL 100 physique, de base, avec juste la mémoire livrée avec, et le lecteur de cassettes.
J'ai téléchargé ton DevKit sur le site de Daniel, mais je n'ai pas encore regardé.

[kevlar]

Ca fait plaisir de voir que l'utilitaire sert à quelqu'un
(...)

Oui, je te remercie encore pour ton travail !
A ce sujet, quel langage es-tu utilisé ? Si par hasard c'est en C sans trop de routines spécifiques à Windows, j'aimerais bien voir les sources

[jester]

Au fait Philippe, je ne me souviens plus si ton outil peut exporter dans autre chose que du DES... sinon il faudra que tu me refiles le format afin que j'accepte ce format en entrée de mon outil de compression + visualisation.
Si je me souviens c'était une portion de contenu de la mémoire écran avec des offsets pour la positionner correctement dans la mémoire ?

[6502man]

Pic2Des exporte au format DES et sinon au format RAW (avec entete special) pour le clipping.

Je devait intégrer ton algo de compression mais je n'ai pas eu le temps


Si tu veux tu peux intégré a ton utilitaire le format DES et CLIPPING

[6502man]

L'utilitaire est développé en C avec l'API SDL ( pour permettre d'ouvrir de nombreux formats d'images ).

Ensuite l'algo est vraiment enfantin : chaque pixel est décomposer en RVB ensuite avec le réglage RVB (les boutons rouge vert bleu ) chaque pixel est ajusté dans la fenêtre de destination .

Tout simple.

J'ai choisi le format DES parcequ'au départ j'avais trouvé simple a utiliser avec le BASIC, mais on peut très facilement sortir tout autres formats, il faut juste du temps pour s'y mettre

J'ai aussi intégré l'option CLIPPING pour ne sortir que des portions d'images et la c'est au format RAW exelvision donc codage sur 3 octets pour le rvb de 8 points

[kevlar]

Ok, j'ai vu tes "dll" on a les mêmes sous Linux (libzip, libsdl ...) ;
mais où trouve-t-on la description du format .DES ?
Compte tenu de la taille des fichiers, je pensais naïvement qu'il s'agissait d'un RAW avec le codage 3 octets/8 pixels du VDP ...

[6502man]

Le format DES c'est tout simplement la copie des octets en ram vdp donc 122 octets par ligne 3 octets/ 8pixels

[kevlar]

Voilà, j'ai commencé à faire cet utilitaire pour LInux (la partie interface, le main et le makefile) ; çà donne çà visuellement :


Comme tu le vois, je n'ai pas fait les mêmes choix que toi pour la répartition des widgets.
J'ai compris pour le format .DES.

Mais j'aurais besoin d'une info : comment fais-tu le recodage du 24 bits/pixel (3x8 en fait 3x16 pour mois sous Gtk) vers le 3 bits par pixel de l'EXL 100 ? Une table de correspondances pour les couleurs ?

[6502man]

Pour le codage des couleurs exelvision, regarde les docs, je ne me rappel plus précisément l'ordre precis.

Sinon il faut déterminer la composante RGB de chaque pixel et l'inscrire sur les 3 bits :

Code : Tout sélectionner

    R 00000000              G 00000000             B 00000000
  chaque bits correspond a 1 pixel  =  1 bit de R + 1 bit de G + 1 bit de B 

mon explication n'est pas très clair il se fait tard.

Demain j'essaie de t'expliquer mieux.

[kevlar]

Ok, je compte sur la suite

Sous Linux/gtk; chaque pixel RVB est codé en 8 ou 16 bits selon l'application/routine système.

Par exemple, en prenant un codage 8 bits, un rouge bien intense me donne $FF0000 (R = 255, G = 0, B = 0)
Je n'ose pas penser à une correspondance simple pour l'EXL 100 ...
S'il existe une table de codage des 8 couleurs de l'EXL je serais preneur.
Le blanc vaudrait 7 par exemple ? (0x111 ) ? Avec les 3 bits allumés, correspond aux 3 octets mis à 255 (allumés) pour Gtk ?

Exemple volontairement idiot :
- sous Gtk 24 bits, admettons que j'aie une couleur avec R=1 G=127 B= 127 (vert émeraude très bleuté)
- si je convertis brutalement en considérant que dès qu'un bit est allumé en 24 bits, je le garde pour l'EXL, cela donnerait :
GTK - EXL
R=1 - R=1
G=127 - G=1
B=127 - B=1
Donc l'EXL me sortirait le couleur 7, à mon avis çà va poser problème.

Humm, je crois que je suis un peu confus, et pourtant c'est le matin

[Daniel]

Il y a trois groupes d'algorithmes pour réduire le nombre de couleurs :
- Couleur la plus proche
- Tramage ordonné
- Diffusion d'erreur

Dans chaque groupe il y a de nombreuses méthodes différentes, qui vont donner des résultats plus ou moins heureux en fonction de la nature de l'image et de la palette cible. On ne peut donc pas donner "la méthode" : il y en a des centaines, et c'est un choix artistique plus que technique qui permet d'avoir un résultat intéressant. Voir à ce sujet la discussion sur Skyrim : http://forum.system-cfg.com/viewtopic.php?f=25&t=3622

Voir aussi les travaux de Sam pour les images Thomson :
http://www.logicielsmoto.com/phpBB/viewtopic.php?t=395
http://www.logicielsmoto.com/phpBB/viewtopic.php?t=418
http://www.logicielsmoto.com/phpBB/viewtopic.php?t=383

[kevlar]

merci, je vais lire çà, mais Daniel j'aurais quand même besoin de la liste des couleurs sur Exl bon c'est vrai que je peux les prendre sur l'émulateur par picking ...)