format d'image bmp - Page 1

J’ai converti une image basse résolution en bmp avec Positive image (1996)
Maintenant je veux l’ouvrir
L’entête avec les octets écrit de droite à gauche et a la palette a l’envers avec les octets dans le bon ordre , j’avoue que je comprends ce qui a pris à Microsoft le jour ou ils ont créé ce format ?
palette dans l'ordre, octets RVB inversé + un octet inutilisé par couleur
Enfin...

Maintenant je veux l’ouvrir

Donc, je comprends bien qu’il y a quatre plans à afficher sur le st, mais je n’ais plus la vivacité d’esprit pour piger rapidement comment convertir ces données image
Poids de l’image ,32118 octets.
Jusqu’à la palette de couleur, c’est bon
Les données de l’image commencent donc pour cette image à l’octet 118 soit 32000 octets de data image (ligne par ligne bas en haut …).
J’ai donc tenté de les afficher dans l’ordre ou elles arrivaient. Big Bug j’ai l’impression d’avoir quatre plans image décalés mais je voie bien que ce n’est pas la solution de les juxtaposer.
Un indice

C'est quoi la taille de l'image ?

C'est du 16 couleurs ton image ?

GT Dans les formats d'image

GT Dans les formats d'image ( je sais )

Poids de l’image 32118 octets.
basse résolution 320*2000 , 16 couleurs

tous mes vœux GT

Sur le pc le plans sont linéaires et sur ST entrelacés, je pense très fortement que cela vient de cela.


GT Entrelacé

J’ai vu cela aujourd’hui
pour simplifier, (je l’espère) j’ai enlevé trois plans de mon image pi1 avant de la reconvertir en Bmp .
Je regarderais cela bientôt.
Avec plusieurs docs contradictoires concernant les octets de l’image….

Je me suis remis au BMP aujourd’hui
Le format que je démonte est codé ainsi :
Chaque quartet des octets images correspondent à un index de la table de couleur.

Pour tester, j'ai fait le plus simplement
Il suffit donc de lire les octets en commençant par le dernier du fichier Bmp.

Pour tester, j'ai fait le plus simplement possible en traçant les point par pbox x, y, 1,1
J’ai obtenu un affichage correct mais très lent. Plus d'une minute rien que pour l'affichage direct sur l'écran.

Mais comme j'ai besoins de la convertir dans un buffer, il me faut évidement une autre solution.

Comment définir les plans d'image celon les couleurs?
Quatre plans, quatre words ok
Mais comment définir les bits???????????????????

Quel langage de programmation ?

la je l'ai fait en Omikron
mais quand j’aurais réussi a obtenir un résultat positif, je le ferait en 680000

Regarde comment est organisé la mémoire écran dans Le livre du développeur Tome 1, page 453 et suivantes (téléchargeable ici)

et comment faire faire des manipulations de bits en Omikron Basic dans Le livre du BASIC Omikron, page 160 et suivantes (téléchargeable ici).

Ok je sais , mais c'est pas page 453. ou c'est pas la même édition.


ça doit être un sacré bordel a entré toute les valeurs.
Et pour compliquer les choses, dans mon convertisseur, quant je converti une image dans le buffer, la résolution écran n'est pas encore forcement celle de l'image.
http://www.mirari.fr/nT1v

j'ai fini FFF de NEO mais pas encore en ligne

C'est page 453 du PDF, pas le numéro qui est indiquée en bas des pages

Autant pour moi j’ai juste ouvert mon livre page 453
Je n'ai jamais utilisé les fonctions Line A seulement AES et VDI.
Je suppose que la fonction $a002 attend un numéro de 0 a 15
Mais dans mon cas, je ne pense qu’elle accepterait un numéro de couleur sans que la résolution écran soit identique à l'image.

Bien sur quatre plans quatre bits par couleur...
Mais la corrélation est elle avec les numéros de couleur ou plutôt avec la valeur de la couleur ?

Ah c'est vrai, je n'ai pas précisé : je parlais de l'explication qui est avant la description des fonctions Line A, pas de ces fonctions proprement dite.

Les 4 bits (issus des 4 plans) donnent le numéro de la couleur, entre 0 et 15. Les valeurs RGB correspondantes se trouvent dans le registre de palette qui a ce même numéro.

Pourquoi je cherche a me compliquer inutilement les choses simple .....
Plus qu'a taper du code..... quand j'aurais un peut de temps et l'envie..

Sinon , Meçi quand même pour l'aide..

J’avais bien été tenté d’utiliser les fonction Line, A, mais comme dans mon convertisseur je n’ai pas utiliser L’Aes et La Vdi, ca m’ennuyer de l’alourdir avec les tableaux intin…..
Mais il faudrait que je teste un jour pour voir la vitesse d'affichage de $A001
Pour faire une fondue d'image peut être...

J’ai refait un test en affichant tous les points écran, (Hier les point à zéro je les affichais pas pour gagner du temps)
Et bien Il manquait le premier octet à toutes les lignes.
J'ai regardé un peut l’organisation des couleurs dans les plans, c’est un vrai bordel.
Il doit y avoir un paquet d ‘opération à faire pour obtenir uniquement 16 bits
Entre toutes les opérations logique et la ligne A, ce serait quoi le plus rapide ?
En basic ,en affichant tous les points ça laisse le temps de rêver…Avant de passer en assembleur

[uhttp://www.mirari.fr/97w7][/u] ce test est uniquement en basse résolution

C'est un problème qui a déjà été bien étudié. Cherche "chunky to planar" sur Google, tu trouveras des algorithmes rapides

merçi je vais regarder

Effectivement c'est une solution que je n’utiliserais pas, imagine sur un écran entier.
Avec une ou plusieurs tables de correspondance et en 680000 pour par s'endormir devant...
la version Basic c'était pour bien comprendre comment est fait ce format.

Encore une insomnie...

Grosse amélioration en basic.
Moins de 30 secondes pour afficher tous les point images..
Mais peut faire mieux...

http://www.mirari.fr/kWOI

HELP
Voici une image moyenne résolution que j'ai converti en BMP.
http://www.mirari.fr/F3mM

La même image , http://www.mirari.fr/Ao6f
même dimensions, même poids. mais les données ont été modifiée par un programme Windows
par simple ouverture et sauvegarde.

Voici un aperçue des entêtes des deux fichiers.

Les détail du format sont là :
https://en.wikipedia.org/wiki/BMP_file_format

Les images ne sont pas strictement identiques, la 2ème a une barre de menu en bas. À part ça la palette a été modifiée (elle a été réorganisée, les couleurs inutilisées supprimées, les 4 bits inférieurs de chaque composante RGB ont été mis à zéro), et quelques valeurs sans importance dans l'en-tête sont différentes.

Ha oui j'ai pas mis les deux même.


Valeurs modifiées dans l'entête
offest 2 taille image
offset 34 taille data image
offset 38 et 42 ???? je craignais que ce soit un pourcentage pour les valeurs RVB
offset 50 : 16 couleurs ??
offset 118 : Data images modifié. Nouvelle indexations des couleurs

Les couleurs inutiles, je les laisse même en haute résolution.
Ça ne dérange pas Windows et ça me simplifies la sauvegarde

rockyone (./24) :
offset 38 et 42 ???? je craignais que ce soit un pourcentage pour les valeurs RVBoffset 50 : 16 couleurs ??

C'est la résolution (en pixels/mètre) et le nombre de couleurs "importantes". Quasiment aucun logiciel n'utilise ces valeurs.

Merçi
C’est valeurs, je dois les enregistré dans les fichiers que je crée ?

C'est casse pieds d'avoir des valeurs qui ne sont pas enregistrées avec tous les logiciels....
Cela complique les vérifications...

Tu peux les mettre à zéro.

Bon la sauvegarde écran Atari en BMP dans les trois résolutions, et le rechargement, c’est bon pour le moment .Mais je n’utile pas encore le mode Chunky….

J’ai un nouveau problème avec la palette de couleur
Voici une image 320*200 produit par Windows, et ce que ça donne quand je la charge.
http://www.mirari.fr/AQNp

Je suppose que dans ce cas, la couleur importante a un rôle.
Ci c’est le cas, comment l’utilisé ?

Je n'ai pas regardé en détail, mais je pense plutôt que tu cherches la palette à la mauvaise adresse dans le fichier. L'en-tête peut avoir plusieurs tailles différentes, donc tu ne peux pas coder une adresse "en dur" pour le début de la palette ; il faut la calculer à partir des tailles données dans le fichier. Regarde ici : https://en.wikipedia.org/wiki/BMP_file_format#Color_table

je lit bien la palette a la bonne adresse, je pense plutôt que mon système de décodage est en cause.
Actuellement, je n'utilise que le poids faible des octets V,B et R pour translaté par ma table de correspondance.
Ce système est valable apparemment uniquement si le poids faible et le poids fort de l'octet sont égaux.
Est ce n'est pas le cas dans cette image.