Version imprimable
:idea:
salut tous
j'ai un petit probleme pour pourvoir afficher une image un turbo pascal.
J'ai compris comment faire marcher blockread mais la seule chose que je ne comprends pas c'est avec l'algorithme : il (192 and) = 192 THEN ...
Je pense su'il s'agit tout simplement du codage parce que quand j'enleve les conditions j'ai une sorte de fouilli de pixels. En fait je voudrais savoir comment exactement sont codées des images .bmp .pcx et si possible .jpg
Merci d'avance
Alors pour les BMP c'est très simple mais comme je vais pas tout reexpliquer une n-ième fois, euh je répondrais qu'il faudrait chercher sur google.fr pas exemple, où il y a de très bons tutoriels. C'est la même chose pour les PCX. Par contre pour les JPEG, là c'est plus compliqué : en effet, il me semble que le codage des JPEG utilise la trigonométrie et en particulier les cosinus ( je me rappèle plus comment ça marche désolé ). Donc la doc doit se trouver sur Internet, mais je pense qu'il doit falloir être callé en maths sinon... ( moi j'ai jamais essayé et ça me tente pas... ).
Pour information, il y a encore les unités de notre cher Haypo ( qui a quitté le navire... ) qui marchent très bien ( euh euh si on est technicien supérieur... voire ingénieur en informatique : enfin elles sont plutôt difficiles à utiliser si on a pas la même pensée qu'haypo ... )
a+
y 'aurait pas ue adresse particulièrement bien?
en ce qui concerne le codage jpeg, il repose sur la transormation de Fourier (TF).
C'est relativement mathematique, mais meme si ca aide, on est pas oblige de comprendre ce qu'il y a derriere.
La transformee de Fourier est une operation pas si complexe que ca, qui est appliquee sur chaque portion d'image (celle-ci est divisee en carres de 32x32).
On obtient des coefficients a placer devant des sinus et cosinus. Le "signal" (ici, l'image, ou plutot la TF de l'image) est la superposition (ponderee par les coef.) de tous ces sinus et cosinus. Si on ne garde que les premiers coefficients, le "signal" (l'image) n'est pas trop degrade.
Si on applique la transformation inverse, on obtient une image qui ressemble pas mal a l'image de depart. Tout depend du nombre de coeff. qu'on garde, et c'est pour ca qu'il est possible de choisir le taux de compression des images jpeg : plus on garde de coeff., plus l'image est precise, mais moins ca compresse.
Pour les details techniques, je ne connais pas trop le formalisme adopte, mais maintenant que tu sais ca, ca doit etre assez facile de trouver des trucs sur le net (il existe des algorithmes performants et assez simples de TF et TF inverse sur le net).
<troll>
wormful : J'ai écrit mes unités pour moi, ou plutôt pour mes programmes. Pas dans le but de les réutiliser comme librairie :-/ Par contre j'ai p'têtre quitté le bateau, mais je suis resté accroché à une corde qui pendait derrière :-p
Le gros défaut de mes unités graphiques : depuis mon programme Affiche, j'utilise l'unité XMS dans l'unité VESA2, et l'unité VESA2 dans toutes les librairies de chargement d'une image ... Au final, pour afficher une image BMP, il faut au moins 3 unités !
</troll>
Le codage PCX (de mémoire) :
1- Lire l'entête ... voir mes unités :-)
2- Si les bits #7 et #6 valent 0 (octet and 192 = 0), alors les bits de poids faible contiennent la couleur d'UN pixel. Sinon, les bits de poids faible contiennent le nombre de répétition, et l'octet suivant contient la couleur.
C'est un peu bête de prendre 2 bits pour le code spécial "répétition". Ex: Le pixel 200 doit être codé {193, 200} : deux octets pour un pixel ... et c'est la même chose pour tous les pixels de couleur >= 64.
Lien : http://www.wotsit.org/
@+ Haypo
un truc beaucoup plus simple c ets l unites de hdd34 qui lit presque toutes les images , y compris les jpeg et les gif , donc , vbe et de plus une des meilleurs ( sans exagerer )
Non Charly, n'en fait pas trop !
Certes, ce sont les meilleures ! :lol: J'ai les chevilles qui gonflent ! :wink:
Pour être plus sérieux, je ne lis pas les Jpeg, car tout ce que j'avais trouvé sur le sujet... Etait horrible !
En fait, les librairies Jpeg sont à 99% basées sur le travail du Jpeg Independant Group. En effet, celui-ci à créé du code C, adaptable à toutes les plateformes. Le codage et le décodage étant absolument fous (une vingtaine d'unités en Pascal), personne ne s'est amusé à le refaire par soi-même.
J'ai volontairement renoncé à intégrer le Jpeg dans mes unités, car je ne pouvais intégré 20 unités en plus, rien que pour ça.
Par contre, mon unité charge : *.bmp, *.ico, *.pcx, *.tga, *.gif, *.raw
Les unités d'Haypo sont, peut-être, compliquées à utiliser (je ne crois pas, enfin...).
Par contre, désolé Haypo, mais elles sont bancales. Elles ne chargent qu'une image sur 10 ! Quelle performance...
Si tu veux mon unité, il faut me contacter. Ici : hdd34_nospam@hotmail.com, et en virant le nospam, évidemment.
Pour répondre à la première question, en passant. Le X and 192 = 192 perrmet de la valeur d'un bit ou plusieurs bits. 192 est un masque.
A+
J ai enfin reussi à remplacer ce que je ne comprenais pas, mais subsiste un bug : pour certaines images, il y a un décalage plus ou moins grand selon les images à la 160 eme ligne (pile poil 320/2). Je ne trouve pas l'erreur et pourtant j'ai respecté ce que disait un tutoriel sur le pcx ( expliquant q'il y avait des coeff à placer...)
Bref voici mes lignes
NOTA : désolé d'avoir crée plusieurs sujets pour un même thème, mais je me suis trompé de boutons ( je n'avais pas beaucoup de temps devant moi et je n'ai pas fait attention sur quoi je cliquais , ce qui bien evidemment ne se reproduira plus)Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
je vous remercie d'avance
d'ailleurs il semblerait que "x" ne depasse pas "32050" puisque lorsque je clos la boucle par "until x= 32051" au lieu de "al=0" le programme continue à tourner et le probleme montré plus haut se remet.
Mikoeur