Reprise du message précédent :
W3C Compliant> En tout cas ça m'aura bien bien fait rigoler la certitude avec laquelle tu AFFIRMES "nan nana le JPeg dégrade *TOUJOURS* l'information" et finalement... bah t'avais tout faux C'est pas méchant ni dirigé contre toi, c plutôt le soulagement de savoir que j'ai pas fumé en disant que ça dégrade pas tout le temps.
 

W3C Compliant a écrit a écrit :     Je l'ai déjà fait. En fait, j'avais surtout fait ça pour les algos MPeg (1 et 4), mais le JPeg marche pareil, à la base... et la compression temporelle en moins faudra que je zieute.   Enfin bon, dans l'ordre, il faut se documenter sur : - la colorimétrie (modèles RVB vs. modèles YUV) - la compression spatiale en mode YUV (YUV411, YV12 etc.) -> responsable d'une bonne part de la dégradation visuelle (bavures, flou...) du JPeg - qu'est-ce que la Transformée Discrète en Cosinus (DCT) et son opération inverse (iDCT) (responsable de l'altération des valeurs absolues de luminance/chrominance etc., pas obligatoirement perceptibles)

Par vulgarisation, j'entends vulgarisation, comme tu expliquerais ça à un enfant de 6 ans quoi, les notions de base de la compression mais de façon imagée tu vois

W3C Compliant a écrit a écrit :       Y a toujours perte d'information, même si "subjectivement" tu peux en gagner.   Ton information tu peux la quantifier d'après la différence entre image source et image finale. Avec un delta = 0 correspondant à 100% d'information. Toute altération de ce delta (déviation) amène une perte de l'information *initiale* (à savoir : tel pixel est de telle couleur, avec telle saturation, telle teinte) même si visuellement c plus complexe "subjectivement".   Or le JPeg, en dégradant la source, approxime, et donc fait perdre de l'information. Sinon, si ça rajoutait de l'information, tu pourrais recréer la photo d'origine à partir d'une image dégueulasse.

Vouala. Donc en fait plutôt que de parler de "perte" d'information il vaudrait mieux parler de "modification" de l'information.
 
Pasqu'en effet dans certains cas, on "rajoute" de l'information, par exemple dans le cas d'une image bicolore compressée en jpeg, la frontière entre les deux couleurs n'est plus nette et on voit apparaître un dégradé de couleurs différentes qu'il n'y avait pas au départ (il y a augmentation du nombre de couleur et donc de l'information.)
 
Seulement pour le jpeg, cette information, pourtant plus importante et a priori plus complexe, est plus simple à mémoriser.
 
Un peu comme un humain qui mémorise plus facilement la suite 01234567891011121314151617181920 que la suite 548515059872 qui pourtant comporte moins de chiffres.
 
 
Donc ça c'est "faux" :

Parfois on "rajoute" de l'information pour que ce soit plus léger.
 
Attention à la signification des mots entre guillemets !

Hypothèse : au bout d'un nombre fini de compression jpeg successives on tombe sur une image qui n'évoluera plus.
 

 
i5 est alors une image réversible.
 
Faudrait tester, mais le problème, c'est que tu peux aussi tomber sur un cycle et là ça marchera pas :
 

 
Sinon s'il est possible de trouver des images réversibles à trois couleurs, il est ptet possible de trouvers des images à n couleurs réversibles : avec un système de pavage correctement choisi. Mais là ça devient compliqué (les couleurs + pavage ouille).
 

Bah tiens, une question avant d'aller faire dodo :
 
Est-il possible d'avoir un pixel rouge pur sur une image jpg ?
 
Et plus généralement, toutes les couleurs (sur 24 bits) sont-elles trouvables sur un fichier JPEG ?

j'allais le demander  tout à l'heure, si on prends un carré tout blanc, avec un point rouge au milieu, et on compresse...qu'est ce qui se passe aavec une forte compression
 
avec des images aux limites en générale ?

Bah je vais essayer pour voir.

Le résultat est assez marrant.

En fait il faut tenir compte de la position du pixel dans le découpage de l'image en carré de 8 pixels. Les résultats sont donc pas toujours les mêmes.
 
Alors grosso modo le pixel rouge est dilué dans le carré de 8 pixels, et le blanc "l'emporte" complétement : y a plus du tout de rouge, mais des teintes de gris. Bizarrement il y a plusieurs paquets de gris.

Je ne fais pas de graphisme si ce n est pour faire des Logos mais si qqn est capable de compresser un BMP->JPG sans perte ca m interesse meme si ca ne concerne que 128 couleurs (euh pour les couleurs sans pertes - de 256 je suppose non?cf post + haut)
 

si c'est pour du sans perte vaut mieux du PNG que du JPG...

trolleur
le XHTML est moins bien supporté que le PNG

Un jpg ça compresse nécessairement, ça dépends ce que tu entends par "sans perte", et pour le choix jpg ou png, ça dépends du nombre de couleurs. À quoi sont destiné ces bmp?

bhen non ça dépend pas du nombre de couleurs, les deux sont en 24 bits. L'un est avec perte et plus adapté aux photos, l'autre sans perte et plus adapté aux images où y a des zones unies (que ce soit en carré ou en lignes)

Si tu veux  
 
 
 
 
 
 
 
 
 
 

bon, ben je vois que vous êtes partis dans le trip jpeg, mais c'est juste pour en revenir au gif. Y a moyen d'afficher plus de 256 couleurs avec un gif dans un browser.

nope, un gif animé avec un interval entre les différentes images de 0. Y a une société qui vend un soft qui permet de le faire automatiquement.

bah j'ai même pas besoin de détailler. En essayant de retrouver la société qui fait le programme, je suis tombé sur un autre soft qui fait mieux et qui est gratuit:
 
http://phil.ipal.org/tc.html

j'ai retrouvé la société, au cas où, mais c'est moins intéressant.
 
http://www.peda.com/iag/Welcome.html

pfff... y a déjà le makefile de fait, y a plus qu'a compiler pour que ca fonctionne sous ton OS. C'est ca la portabilité.

prend celui de la firme
 
On compile avec Gcc, c'est marqué dans les fichier d'install. Ca te fais une librairie graphique que tu peux incorporer dans un autre logiciel.
 
C'est vraiment dommage que cet aspect du gif n'aie pas eu plus de succès. Les sites persos auraient peut-être été moins moches. Quoique...

Bon, c'est bien joli tout ça mais ça ne change rien au fait que :
 
 - Le GIF n'est pas un format libre
 - Ça reste de la bidouille
 - Le PNG existe et fait la même chose en mieux.

 
j'allais le dire, mais Chello est tombé en panne au moment où je voulais poster

 
ha ? t'as des liens ? j'ai jamais rien vu à ce sujet

bah ne serait-ve que le premier lien que j'ai mis. Mais je peux essayer de retrouver les autres si tu y tiens...

Ça m'intéresse. URL pour ces générateurs libres ?
 
Ce que je sais c'est que The Gimp et ImageMagick ne produisent que des GIF non compressés
 
En revanche je m'interroge sur la capacité des navigateurs à reconnaitre ces GIF compressés avec autre chose que LZW.

Pour les animations OK, mais pour les images fixes (sans alpha) je ne vois pas pourquoi on utiliserait pas le PNG.
 
 
De toute façon en juillet 2003, le brevet d'Unisys expirera, donc antp pourra fermer son site

Dans ton premier lien ils disent qu'ils n'utilisent pas de compression pas qu'ils utilisent un algorithme alternatif à LZW.

gm_superstar a écrit a écrit :   De toute façon en juillet 2003, le brevet d'Unisys expirera, donc antp pourra fermer son site

 
mon site c'est surtout contre les screenshots en JPEG
j'aurai juste à faire quelques modifs donc
 
le PNG ça compresse quand même mieux que le GIF, quand on utilise des softs qui savent sauver un fichier comme il faut

C'est intéressant st'histoire de GIF en plus de 256 couleurs...

ayé! me revoila. Pour ce qui est des gif libre de droits, tu ne peux pas les compresser, exactement comme le fait gimp. Car le brevet stipule bien que si un gif est compressé il tombe sous les conditions de celui-ci. Mais quand on voit la taille des images gif non compressées si elles sont bien construites, ca n'est pas trop pénalisant.
 
Pour ce qui est de la capacité des browser à lire des gif compressés avec autre chose que du lzw, ca je n'en sais rien, faudrait que qq'un aie le courage de tester, on pourrait peut-être trouver un meilleur rapport qualité/poids.