La suite, la suite !...

[Yann]

Je saisis cette occasion pour coucher sur pixel quelques idées.
La question posée : so, what's next ?
Car enfin, on a beau vouloir tout faire, on final, il faut prioriser pour aboutir à quelque résultat aussi mineur soit il.
Le problème est donc de choisir.
Voici les quelques pistes qui me viennent à l'esprit :

Compression PC :

- Second pass BWT :
Le principe de la transformée Burrows-Wheeler a fait ses preuves. Ce tri complet des octets d'un fichier a l'excellente propriété de produire une série de caractères très répétitifs, faciles à compresser ( genre "aaaabaaacaccccccic..." ) et d'être aisément réversible.
Enfin, quand je dis facile...
Il faut quand même réfléchir un peu, les algorithmes ne sont pas du tout les mêmes que pour une compression normale. LZ (ou zip) donnera des résultats très pauvres. Les auteurs de cette transformée conseillent d'enchaîner avec une autre transformée dite MTF (move to front). Bien que ce schéma fonctionne, il est malheureusement très coûteux en performance.
Je pense donc qu'il est possible de fabriquer un compresseur spécifiquement dédié à la sortie d'un fichier BWT, mais très très rapide.
J'ai quelques schémas en tête à tester, et qui restent à éprouver pour valider les hypothèses.
La contre partie ? La compression ne sera pas aussi performante que pour les compresseurs BWT "haut de gamme", qui sont parmi les meilleurs au monde.
De plus, la "deuxième passe" n'est qu'une partie du processus, il reste toujours le tri du fichier à effectuer avant, et cela prend un certain temps. Donc, en additionnant les deux, en aucun cas cela ne peut donner un compresseur rapide (la décompression, en revanche, peut-être très rapide).

Donc bon, c'est la piste la plus prometteuse, mais je manque un peu de motivation pour me décider.


Compression Media :

Image : Malgré mes premières tentatives ratées de compression d'image avec corrélation spatiale, je pense avoir maintenant saisi les principes les plus essentiels, et pouvoir construire un format d'image compétitif avec JPEG. Là encore, l'objectif n'est pas de compresser comme un dieu, mais d'avoir un résultat proche du standard (donc environ un taux de compression de 1:8, en fonction du niveau de qualité bien sûr) avec des temps de compression (et de décompression) très très rapides, et surtout des artéfacts visuels plus attrayants que ceux produits par JPEG, qui sont très moches.
Tout ceci me semble accessible. J'ai aussi l'algorithme en tête, ne resterait plus qu'à le tester.
Mon principal problème, c'est que j'ai perdu les outils de tests qui me permettaient de visualiser les algos de compression d'image. Au fil des mises à jours des middlewares, ils ne fonctionnent plus. Il me faudrait donc les ré-écrire, et c'est plus vite dit que fait.
Un boulot pas trivial, notamment pour s'assurer d'une bonne prise en compte des formats sources, et qui me fait donc reculer.
Mais rien d'impossible, si le résultat peut servir à quelque chose, la motivation reviendra.


Compression HP48 :

Créer un nouveau compresseur :
La récente histoire de Debug4x m'a rappelé qu'il y avait, mine de rien, quelques utilisateurs de BZ2 sur Terre.
D'autres part, la principale demande exprimée est identique à mon besoin initial : un compresseur "de distribution", avec en compression beaucoup de puissance et de temps, pour obtenir un fichier le plus compressé possible, mais de l'autre côté un décompresseur très très rapide.
LZD a été créé spécialement pour ça. Et ça marche très bien.
Toutefois, son taux de compression sur les "gros" objets est inférieur à BZ2. Par conséquent, il n'est pas très employé.

Avec ce que j'ai appris pour PC, il me serait aujourd'hui possible de créer un nouveau compresseur pour HP48, avec un taux de compression probablement très supérieur à BZ2/TNT2, et en s'assurant que la vitesse de décompression reste la plus élevée possible (pas aussi rapide que LZD tout de même...)

Cela aurait un usage pour la création de programmes et librairies compressées.
Toutefois, je pense me heurter aux problèmes suivants :
1) C'est plus vite dit que fait. Développer sur HP48, c'est de l'assembleur, et les capacités de debugging et surtout de statistiques sont assez limitées, ce qui rend le développement assez long, et surtout un peu aveugle. Bref, c'est pas gagné
2) La décompression ne peut pas être aussi rapide que LZD, mais il faudrait qu'elle soit aussi rapide que BZ2. Et même ça, ce n'est pas gagné, loin de là.
3) Il y a aussi un risque que le décompresseur soit trop gros, de par sa complexité.
4) Surtout, il faudrait développer le compresseur pour PC. Malheureusement, Debug4x est développé en Delphi, et ce n'est plus aujourd'hui mon langage de prédilection. Cela me prendrait donc beaucoup de temps.
5) Enfin, il y a une prédilection naturelle des utilisateurs HP4x pour BZ. BZ2 améliore l'original, et est donc accepté facilement. Mais tout autre algorithme non compatible a peu de chance d'être "bien vu". On craindrait sur la stabilité du programme, même si ce n'est pas justifié. BZ inspire confiance...

Finir / améliorer R.O.C :
Je n'ai jamais soumis R.O.C à HPCalc.org. La raison ? je craignais une dispersion. Il y a déjà trop de programmes de compression.
R.O.C a donc besoin d'être sérieusement supérieur pour avoir une raison d'exister.
Mais ce n'est pas suffisamment le cas.
OK, il est très rapide, ok, il utilise très peu de mémoire (2Ko); ok il compresse presque aussi bien que BZ2
mais c'est le "presque" justement qui pose problème.
Pour être pleinement justifié, il faudrait qu'il compresse mieux que BZ2. Et ça, ce n'est pas gagné.

Les bases sont posées, elles sont intéressantes, mais je pense qu'il faudrait travailler davantage l'algorithme pour qu'il soit vraiment intéressant (donc qu'il garde ses propriétés de vitesse et de mémoire, mais il faut améliorer son taux de compression, et si possible aussi sa vitesse de décompression).


Jeux HP48 :

Reprendre Phantasie Conquest

J'avais commencé à ré-écrire Phantasie Conquest, à l'origine conçu avec mes propres outils de compilation, et donc mon propre langage. Evidemment, ça pose quelques problèmes, car c'est pour le moins plus frustre que l'excellent environnement de programmation Debug4x.
J'ai donc commencé à ré-écrire quelques morceaux avec les mnémoniques SysRPL interprétées par Debug4x.
L'objectif serait de tout ré-écrire, rendant le jeux accessible à toutes les calculatrices HP, même les plus modernes (et pas uniquement les HP48).
C'est un énorme boulot, que je n'ai pas terminé. Il faut dire que le jeux ne me semble pas vraiment utilisé, ce qui est normal compte tenu de l'âge du support. Je suis donc peu motivé pour tout reprendre. Mais bon, ça me titille un peu quand même...


Site Web :

Séparer HP48 et Compression :

A l'origine, je n'avais qu'un seul site. J'ai donc regroupé les deux sujets. Mais, bien qu'il y ait une progression chronologique (Jeux HP48 -> Compression HP48 -> Compression PC -> Compression ARM), il faut admettre qu'ils n'ont plus grand chose en commun.
Aujourd'hui, ce choix semble inapproprié.
Il serait donc probablement de meilleur aloi de séparer les deux thèmes sur deux sites distincts.

C'est un peu de boulot, il faudrait de nouveau se plonger sur les offres d'hébergement Internet et choisir le meilleur support disponible pour ce nouveau site. Donc tout simplement du temps.


Y a pas que l'ordinateur dans la vie :

Oui alors ça c'est mon plan actuel, et je dois dire que c'est très sympa
Mais il faut admettre que ça ne fait progresser aucun des sujets mentionnés, alors... où est le juste milieu ?