enquèteConvertisseur d'image. - Page 1

Je suis en train de faire un programme qui converti des images couleurs en images en niveaux de gris, avec bien entendu la possibilité d'exporter l'image vers du code.
Je le programme parceque j'en ai besoin, image studio ne permet pas de tramer les images et le programme de dolstouf ne permet pas de changer le contraste et la luminausité (en plus le rendu n'est pas en tps réelle).

Je me suis dis que faire un programme utilisable par tout le monde pourrais être utile, d'où mon enquête pour savoir si c'est une bonne idée, si il y a des trucs que vous trouvez [pas] pratique avec les convertisseurs que vous utilisez, si il y a des features qui pourraient être utiles...

voilà voilà.

Perso, mon image, je la transforme en ndg avec mon Paint Shop Pro, puis je baisse le nombre de couleurs à 16, et enfin je remappe la palette suivant les gris...

Ce qui serait bien de faire dans ton convertisseur, c'est de convertir à la volée, genre tu spécifies des réglages puis un dossier et ça converti tous les fichiers en données avec un nom au début genre Ship_xx...

Pour moi, ce qui est important :
- redécouper l'image
- régler le contraste et la luminosité du sprite
- régler les seuils de conversion à la main
- retoucher à la main quelques détails qui ne vont pas
- créer et éditer un masque
- convertir plusieurs images à la fois
- permettre de concaténer le résultat de la conversion de plusieurs images (faire un tableau de sprites)
- générer un tableau d'offsets dans le cas où la sortie est concaténée
- générer des header C / ASM
- plusieurs formats de sprites possibles (extgraph, genlib, ...)
- possibilité de rajouter de formats par plug-in

J'ai déjà commencé à bosser sur un convertisseur de ce style, avec Qt, il n'y a pas grand chose pour l'instant, mais ce que j'ai fait, je l'ai fait en une semaine à peine, donc je pense qu'on peut avancer vite si on s'y met bien. En fait, pour l'instant le dev et gelé parce que je vais essayer de réfléchir pour évaluer si mon architecture est efficace ou non.
J'ai un screenshot : http://perso.wanadoo.fr/jackiechan68k/images/spriteconv.png

Moi je suis toujours sur la v2 de DoAnyBgs, mais j'ai pas les sources là donc...
effectivement je trouve important de pouvoir faire une floppée de sprites à la fois, et être le plus général possible quant au format du sprite.
J'aurais tendance à crayonner tous les points de Sasume, en rajoutant la possibilité de sauvegarder un "projet" (une liste d'images à convertir quoi, et leur format) et ce genre de trucs... c'est tellement mieux quand on doit convertir des centaines de sprites

Hmm. Plutôt que de faire 3 vapor, on pourrait peut-être essayer de mettre en commun nos efforts pour sortir un soft.
Je trouve que ton idée de sauvegarde est bonne au fait.

Voulez-vous que je vous génère la doc de mon projet pour voir à quoi ressemble ma conception ?

Et au fait, j'ajoute ce point : à long terme, je m'étais dit que ça serait bien aussi d'avoir un outil qui convertit sans avoir besoin de passer par une interface graphique (donc pas de retouche).

En fait DoAnyBGS ne fait pas de retouche/conversion d'image, mais seulement le passage image-> sprite, en présupposant une image en nvg.
Sinon ça serait bien sûr mieux d'avoir un convertisseur universel, je te l'accorde

Pour ce qui est de la génération de la "sortie", je trouve ça assez inutile de générer soit du C (short sprite[12] = {0x1100,0x0011,...}) soit de l'asm. Je ne génère que du binaire directement, ça évite d'avoir à s'embêter avec des options de génération de code (identation, nom des variables, syntaxe a68k ou gnu as, ...).

en fait pour l'instant j'agit par étapes qui permettent de rester le plus général possible et gérer n'importe quel format facilement...
d'abord la création de l'image, et la séparation des plans de gris et du masque
puis la conversion du sprite en binaire brut avec les options voulues
et enfin la mise en forme, et à partir de là passer du C à l'asm n'est qu'une question de changement des paramètres du fprintf (ou assimilé, en l'occurence en C# c'est pas exactement ça)
le format est décrit par quelques variables principales:
- le nombre de plans
- si il y a un masque ou non (et inversé ou non (selon si "1" = transparent ou pas))
- la taille de l'entrelacement (8bits, 16 (ex: genlib), 32, etc, et si ça fait la taille de l'image ça sort un sprite format graphlib du coup)
- l'ordre de l'entrelacement est en fait un champ de texte pour l'instant (peut être en xml à terme qui donne l'odre des champs (par ex: "WHITE, BLACK" ou "GREY1, GREY2, MASK") ce qui permet de rester très souple... j'ai prévu de pouvoir choisir des formats pré enregistrés ou de créer les siens directement (avec un fichier de conf contenant tout ça)
- rajouter ou non la taille de l'image entre les plans, etc, etc

(au passage l'idée à la base était de faire un prog pour convertir les images, mais faire un truc spécifique aux sprites c'est pas mal aussi )

"convertir plusieurs images à la fois "
Moi je ne convertirais jamais plusieurs séries de sprites à la fois; chaque série à besoin d'avoir un contraste et une luminosité propre.

"à long terme, je m'étais dit que ça serait bien aussi d'avoir un outil qui convertit sans avoir besoin de passer par une interface graphique"
Il y a toujours des cas où on a besoin de retoucher: dans un jeu où on utilise un fond noir, les sprites devront être globalement assez clairs. Un programme ne peut prévoir ce qu'on cherche à faire.

"retoucher à la main quelques détails qui ne vont pas"
Vu que je ne converti que des sprites ripé, pas besoin de pouvoir retoucher.


Maintenant qlq questions:
Pour augmenter le contraste, j'ai éloigné les gris de la couleur moyenne, et pour modifier la "brightness", j'ai simplement additioné à toutes les couleurs une constante qu'on fait varier. Est-ce que c'est bon ? Je pose ces questions là parceque mon programme modifie différement le contraste différement que ImageStudio.
Qu'appelle tu "les seuils de conversion" ? C'est la couleur moyenne ?


(pui vlà ce que je comptais faire: http://databob.free.fr/Volume/files/Montruc.PNG. oui, c'est en tout point inférieur au convertisseur de Sasume )

Le tramge c'est bien Si tu réussi a finir ce logiciel moi il m'interesserait

Le tramage ça me fait peur, sur vraie calc, ça donne des résultats mauvais.

ça dépend tramé comment, mais c'est vrai qu'en général l'écran bave un peu trop pour que ça rende vraiment bien

> Je ne génère que du binaire directement, ça évite d'avoir à s'embêter avec des options de génération de code (identation, nom des variables, syntaxe a68k ou gnu as, ...).
Pour le C, il suffit de reprendre le code de ttbin2hex (et de ses dépendances). Rappel: la TIGCC Tools Suite a une licence incompatible GPL, car elle interdit l'utilisation à but commercial.

Sasume :
Le tramage ça me fait peur, sur vraie calc, ça donne des résultats mauvais.

Non c'est faux, ça rend bien. Je peux pas argumenter plus que ça vu qu'il suffit juste de regarder sa calculette pour le constater...

Sasume, Lionel:
Pour moi, il vaut mieux avoir au moins la POSSIBILITE de générer du C ou de l'asm.
Après, si on ne l'a pas dès le début mais qu'on peut faire des plug-ins, pas de problème: on peut toujours la rajouter (même pour les formats persos, comme le format "gros et rapide" d'Alk par exemple...)

Quand j'ai besoin de tramer et apres de changer la luminosite et de compresser en RLE (un ensemble de conditions plutot rarement reunies), je charge mon image avec tipicture de dolstouf, je fais les reglages qui me conviennent, mais je n'exporte pas, pas besoin : imprim ecran et hop, j'enregistre ca en bmp pour reouvrir avec image studio

C'est en effet une solution

au passage, voici les resultats des différents tramages:

à savoir que le tramage "simple" (càd le même que celui qu'on peut obtenir avec le prog de dolstouf) a rendu vraiment plus jolie toutes les images que j'ai testé
Les tramages avec plus de motifs sont parfois plus moches. Quand au dernier tramage (le "random"), il est carement laid la plus part des cas

-

C'est du 4 ndg... Nettoie tes yeux...

Sinon hmm, les meilleurs tramages sont le 3 et le 5 à mon avis ^^
(3 pas très uniforme mais sympa a regarder, et 5 bien uniforme et pas trop moche)

-

Je préfère le 3 au 5. Le 6 est en effet carrément moche !

Y'a pas un niveau qui a sauté, pour le 6?

Non non les 4 gris y sont

-4+2

-2+4
Le blanc et le noir sont des niveaux de gris

GoldenCrystal :
C'est du 4 ndg... Nettoie tes yeux...

Tu devrais utiliser des [cite], dans le cas où les gens à qui tu réponds éditent leur posts après coup... ^^

C'est surtout que c'est pas correcte d'éditer après coup juste pour (essayer) ne pas paraître bête.

Vertyos > Habituellement j'évite de recopier un post qui se trouve juste avant parce que je trouve ça inutile (et je peux pas savoir que la personne ayant posté avant va effacer son post non plus...), mais si tu veux je le ferai à chaque fois :]
(Heu tu comptes effacer ton post ? Parce que si c'est le cas faut que je te cite avant qu'il soit trop tard )