informatique et high-tech (les meilleures news) %) - Page 893

merci.

ceci dit ca a l'air cool ce format, faudrait le voir sur des vraies images et pas sur des images "choisies pour leurs bonnes caractéristiques"

C'est assez impressionnant ce truc.

J'attends des vrai retour indépendant perso

Quelques tests perso:

1) Ça se compile très facilement (un seul fichier c++ 11 à compiler).

2) Fichier png original 960x1263 pixels, 4x8 bits/pixel, RGB+alpha (type dessin)
Taille png (optipng -o7): 1308050 octets
Taille flif: 764955 octets (-41% ) !

3) Temps (cpu: core2 duo @2.1Ghz)
encodage flif: 15s
decodage flif: 1.7s
encode optipng: 4m 52s

4) Pas vu de perte dans l'image.

C'est de la tuerie ces temps d'encodage/décodage !!!

C'est vrai que c'est plutôt impressionnant. Je ne sais pas si cela aura du succès : je n'ai pas l'impression qu'il y ait une grosse demande à ce niveau, comparé à la vidéo (au hasard).

1.7s pour décoder je trouve ca plutot lent perso

Peut-être pour des sondes spatiales ou autres satellites qui font de l'imagerie.

Ou pour des sprites en gray4 décompressés à la volée ?

godzil: c'est progressif et l'image est visible a base resol des le debut du chargement. du coup les thumbnails sont gratos, aussi, et doivent prendre moins de temps.

Ca reste que 1.7s pour décompresser une image sur une machine moderne c'est lent, progressif ou non, je n'ose meme pas imaginer sur un machin portatif.

Mais a vrai dire ça ne m’étonne guère, il y a toujours un trade-off dans un sens ou l'autre, compression/décompression plus lente pour meilleur taux, ou l'inverse, mais avoir le beurre et l'argent du beurre il faut pas rever.

je pense que tu tiens la bonne conclusion. C'est un peu pareil pour gzip/bzip2/lzma.

Oui, ca reste une performance ceci dit, si c'est aussi bon qu'annonce, mais ca reste quelque chose de pas adapte pour des machines a faible puissance de calcul (surtout le C++11 n'aide pas..)

Mais sur des machine portative je ne pense pas qu'il y ai un attrait pour du lossless.
Ce format FLIF se compare à d'autre formats lossless mais qu'en est-il face à du jpeg ? La aussi il y a du trade-off et sur une machine portative on pourrait le substituer facilement à du jpeg sans que l'utilisateur ne voit une différence.

Le PNG est ters utilise pour tout ce qui est element d'interface sur une page web par exemple, il y a tout un tas d'application ou des images en lossless sont indispensable. Je vois mal un OS utiliser du JPEG pour les icones par exemple.

Je me demande ce que ça donnerait comme taux de compression si on remplaçait tout simplement le deflate (zip/gz) par du LZMA 2 (xz) dans le format PNG.

Libre a toi de tester

Kevin Kofler (./26777) :
Je me demande ce que ça donnerait comme taux de compression si on remplaçait tout simplement le deflate (zip/gz) par du LZMA 2 (xz) dans le format PNG.

ça serait intéressant, en effet.

mais un simple gzip < image.bmp > image.gz && xz < image.bmp > image.xz devrait donner une idée du résultat, non ?

Allez pour la peine: http://comments.gmane.org/gmane.comp.graphics.png.devel/6258

https://code.google.com/p/lzmapng/

Godzil (./26776) :
Le PNG est ters utilise pour tout ce qui est element d'interface sur une page web par exemple, il y a tout un tas d'application ou des images en lossless sont indispensable. Je vois mal un OS utiliser du JPEG pour les icones par exemple.

Oui en effet. Mais sur des icones on est rarement dans les centaines de kilo-octets. Faut se faire une idée avec ses propres tests.
En espérant que ce soit un jour supporté par les navigateurs.

Y'a peu de chances. Aucun des formats d'image "alternatifs" (JPEG2000, HD Photo / JPEG XR, WebP...)
n'a vraiment percé.

Apriori ca depends des domaines, il semblerait que le JPEG2000 soit tres utilise par les consomateur de tres tres grosses images parce qu'il permet de ne charger que la zone utile et non l'image entiere quand on zoom (genre images venant de satelites)

Le reste entre brevets et apport reel, c'est certain que ca ne pouvais pas marcher, et le Flif n'apporte pas beaucoup plus, et le lossless est une utilisation marginale, et dans la majorité des cas, tu as besoin de vitesse et non de taille pour les images lossless.

(et du lossless quand les capteurs sont deja eu meme dégradent l'image...)

Je ne dirais pas ça. Il y a des domaines où le lossless est nécessaire et où le temps de décodage est secondaire (archivage, imagerie médicale...). FLIF semble bien placé pour ces utilisations.

Je vois bien par exemple, pour distribuer un logiciel, tu pourrais encoder tes images dans ce format + 2-3 métadonnées, puis à l'installation, convertir les images en PNG ou autre format cible.
Maintenant, oui, 1,7sec c'est énorme, ça ne percera pas dans le web pour l'instant en tout cas.

Ensuite, c'est une version WIP, où l'on ne s'occupe pas des optimisations logicielles.

Sur openpandora le developpeur donne pas mal d'info, rien n'est optimisé pour le moment.

mouai

C'est justement ça qui m'épate le plus : que openpandora puisse délivrer des infos intéressantes #troll#

bah je suis tombé dessus par hasard en cherchant des infos sur FLIF.