Après l'échec insupportable de l'utilisation du jpeg2000 par le grand public un nouveau format peu ouvrir la fameuse brèche.

Il s'agit du format BPG.  
C'est l'algo qui génère les images clés dans le format HEVC. L'intérêt est évident, en plus d'être extrêmement performant il sera très facilement décodable en hard par les futures puces qui décoderons le HEVC.

http://www.macg.co/ailleurs/2014/1 [...] ages-86249

http://bellard.org/bpg/

Les performances sont assez démentielles, même face au jpeg2000  

http://xooyoozoo.github.io/yolo-oc [...] pg=t&bpg=t

Le HEVC va s'imposer de fait par ses performances et ses brevets

Il n'y a rien à l'horizon et les premières puces qui encoderont en hard du HEVC vont pouvoir à faible coût encoder très vite ce format d'image.
Actuellement on est plus de l'ordre de la dixaine de seconde en encodage.
Je ferai des tests.

J'éditerai la first page avec les infos pour encoder et décoder ce nouveau format.

Les plugin et logiciels compatibles :

- Un GUI (windows) pour encoder du BPG: http://www.romeolight.com/products/bpgconv/
- Le logiciel XnView version windows décode maintenant le BPG \o/ http://download3.xnview.com/XnView-win-full.exe

- Un plugin pour Gimp: http://www.mikropunto.org/?p=71
- VLC 3 décode le BPG (même si je n'ai pas réussi à l'utiliser) http://www.phoronix.com/scan.php?p [...] px=MTg4NDI
- Simple BPG image viewer for windows https://github.com/asimba/pybpgviewer/releases

Les articles :

- http://www.macplus.net/chronique-8 [...] son-format
- http://www.macg.co/ailleurs/2014/1 [...] ages-86249
- http://phototrend.fr/2014/12/bpg-u [...] ign=buffer
- https://lwn.net/Articles/625535/
- http://www.wikiwand.com/en/Better_Portable_Graphics

Les concurrents potentiels :

Daala est un format vidéo avancé ayant pour objectif de concurrencer en libre le format HEVC bardé de brevets.
https://people.xiph.org/~xiphmont/d [...] ate1.shtml

Une étude comparative de mozilla
http://people.mozilla.org/~josh/lo [...] july_2014/
http://people.xiph.org/~xiphmont/d [...] ate1.shtml

On peu imaginer un format d'image basé sur le x264, étonnamment jamais créé ou sur daala.

Un site permet de comparer les images entre le daala et le x265/bgp:
https://people.xiph.org/~xiphmont/d [...] ol2b.shtml

En attendant le format jpeg2000 a fait ses preuves et peu être utilisé afin de stocker avec un bon ratio taille/qualité de grandes quantités d'images.
À défaut, utilisez la dernière librairie mozjpeg qui encode toujours mieux en jpeg: http://calendar.perfplanet.com/2014/mozjpeg-3-0/

Une petite indication sur le gain en compression d'image texte:
http://calendar.perfplanet.com/2014/mozjpeg-3-0/

Le topic sur le fameux forum doom9 spécialisé en encodage vidéo:
http://forum.doom9.org/showthread.php?t=171505

super interessant
tu a vu, lorsque tu passe de jpeg <> x265 avec l'image "crepuscular rays" cad ceci:
https://people.xiph.org/~xiphmont/d [...] ol2b.shtml
 
si tu regarde bien on perds bcp de petits details (dans le ciel) et aussi dans les paquets d'herbe et l'arbuste presque au centre il perds presque tout ses details dans les branchages fins.
 
En contrepartie il n'y a plus ces dégradés désagréables (du au jpeg)
 
merci en tt cas pour ce post tres complet  
Pour le jpeg2000, ca à pas fonctionné a cause de ses licences trop restrictives, ca me rapelle un peu (le jpeg2000) le mp3pro de thomson, a force de limiter, personne ne l'utilise et ca part a la poubelle.

En attendant on peu utiliser le nouvel encodeur MOZJPEG qui permet d'encoder avec de bien meilleur résultats et réduire les artefacts visuels:

https://www.progville.com/frontend/ [...] s-mozjpeg/
http://albertogasparin.it/articles [...] s-mozjpeg/

Pour mac:

Un petit comparo: http://blog.suumitsu.eu/2015/03/12 [...] n-dimages/

Autres liens: http://www.webpagetest.org/forums/ [...] ?tid=13526

Merci
Dommage, je ne peut pas tester (MOZJPEG )
c'est que pour mac et visiblement pour linux.
 
mais à la lecture du comparo:
"...Passons aux champions issus du monde de la vidéo: WebP et BPG. Le premier utilise les techniques d’encodage du VP8 développé par Google, le second les techniques du H.265 et est crée par Fabrice Bellard. Oui, LE Fabrice Bellard.
 
La principale amélioration de ces formats de compression est leur filtre de deblocking. Visuellement, ça rend beaucoup mieux. Voici ce que ça donne en WebP via plugin GIMP:"
 
Le cauchemar sur BPG, c'est le temps que prends l'encodage
Je ne sait pas si tu à essayé ?
Il faut quoi pour aller vite avec ce truc un i8 en sextuple coeurs cadencé a 300Ghz ????
 
Si tu à des infos fraiches, je suis évidemment preneur, c'est interessant, n'hésites pas à me mp des que tu mets ce topic à jour, merci
 

Tu peux encoder sur windows sans problème:
http://mozjpeg.codelove.de/binaries.html
 
En fait l'intérêt du BGP ça sera quand les puces intègreront le décodage et encodage hardware du h265.
A partir de là on pourrai avoir un encodage hyper rapide et c'est tout l'intérêt. Nous somme résigné à se dire que les futures puces auront cette gestion hardware du HEVC.
 
Actuelle c'est une horreur oui
Mais il n'y a pas de miracle, quand on cherche a encoder avec une qualité n'importe quelle donnée numérique, les meilleurs codes sont très gourmands.

@raysar:
Alors j'ai tésté, mes 1eres impressions:
1) Ca va immensément (incomparable) plus vite à encoder que bgp (*1)
 
2) C'est contrairement à bgp compatible avec les navigateurs internet et les visionneuses
 
3) il n'y à pas trop de pertes en fontion du taux (ratio) de compression, je trouve ca mieux que le jeg2000 qui de plus n'est pas supporté nativement par les browsers.
 
les moins:
j'ai pas reussi à lui faire digérer du tiff (un de 64mo), ca c'est dommage de ne pas l'avoir en format d'entrée le tiff 16 bitsq, le tiff 8bits c'est pareil, il me l'a rechaché
C'est peut etre ? à cause de l'appli du type 32 bits (et pas 64 pour windows) du à la taille trop grande du tiff ?
 
(*1) Concerenant BGP et une telle lenteur
Amha, a ce niveau la ce n'est PLUS du au type d'encodage (ou méthode d'encodage si tu préfère) mais:
Soit à l'algo utilisé
Soit l'optimlisation du code et/ou à la gestion de la mémoire, c'est pas possible autrement
 
Surtout que en plus les apis cuda ont été mises à jour il y a peu de temps, lorsque t'enclenche un cuda avec une bonne carte vidéo, les possibilitées de calcul ca explose tout.
 
Pareil pour la ram, j'ai 8gb embarqué, je ne voit pas 8gb 16, 32, ...de ram dans les caméscopes plus tard et encore moins des super calculateurs, non pas pour une question de cout (parce que la, à la limite)...,  
MAIS surtout pour une question de consommation electrique.
(sauf un cam relié direct au 230v, mais ca limite son champ d'action )
 
Ca me rapelle le début des encodeurs mp3 si tu à connu ca ?
Sans changer de hware, juste le code on a fait un bond de 10 ou 20x en termes de perfs.
 

C'est pareil avec le H265, l'encodage n'est pas lent à faire avec un pc puissant, c'est ULTRA lent.
Le décodage est aussi très difficile.
 
La méthode employée est de construire une puce qui effectue exclusivement cet enchainement de calcul.
C'est pour ça qu'on a des téléphones qui encodent ou décodent du h264 depuis longtemps et qui consomme de l'ordre du watt, ils possèdent une partie de leur processeur exclusivement dédié à ces calculs.
 
Dans chaque processeur on intègre ou intègrera un ASIC http://www.wikiwand.com/fr/Applica [...] ed_circuit qui sera purement dédié a décodage ou encodage du H265. (en plus du h264 actuel)
Ca permet en général de faire un décodage et encodage en temps réel avec un consommation électrique vraiment ridicule.
 
Ca fait des années que tous les processeurs graphique, même de téléphone savent décoder le h264, même si les processeurs et processeurs graphiques sont peu puissants.
 
C'est bien pour cela que le BGP pourra se développer, on pourra faire appel à ces composants des futurs processeurs pour faire les encore ultra rapidement.
 
Evidement tous les encodeurs peuvent s'améliorer, un codec doit respecter certaines contraintes de lectures et rien d'autres.
On peu donc imaginer comme pour le h264 des encodeurs très rapide de BPG qui produisent une qualité déplorable
 
En attendant on garde nos bon vieux jpeg encodé avec mozjpeg à partir d'une source de qualité.

@Raysar:  
Pour la consommation electrique, je pense que tu est assez optimiste (ou c'est moi qui suis pessimite), il suffit de voir les progres des asics depuis plusieurs années (exemple les prime chez pentax), rien que pour de la photo, ca consomme tpoujours bcp (meme si on arrive a /4 sur le dernier milbeaut je crois), alors de la compression video tres complexe, faudra voir
Le h264 des téléphones est nettement moins gourmand, et déja en h264 on voit tres vite les limites de la consommation electrique  
(temps d'enregistrement vs etat de la batterie)
 
Pour ma question tu a testé d'essayer de lui faire digerer (en entrée) du tiff ?
Chez moi j'y arrive pas
Ca fonctionne chez toi ? (ou un format non destructeur en entrée) parce que recompresser du jpeg, c'est un peu limite comme approche
 
J'ai cherché la liste des formats d'entrées et je n'ai pas trouvé.
 
ce qui fonctionne (en entrée) que j'ai pu tester:
Le jpeg, le bmp.
 

Il faut utiliser un convertisseur, par contre on perd les exifs:
Comme ça on peu faire passer du JPG BMG PNG GIF TIF

Et si on veux convertir tous les tiff d'un dossier en jpg dans le dossier "export", puis les supprimer automatiquement, il suffit de faire:

Pour en revenir au format BPG, si l'on veux encoder et supprimer tous les jpg d'un dossier:

Je sais que je suis tout seul dans mon délire, mais il y a des news

• Un GUI (windows) pour encoder du BPG: http://www.romeolight.com/products/bpgconv/

• Le logiciel XnView version windows décode maintenant le BPG \o/

http://download3.xnview.com/XnView-win-full.exe

Je m'intéresse aussi au BPG parce que je ne supporte plus les artefacts de compression JPEG sur des screenshot, même avec une très bonne qualité et le dernier encodeur mozilla ils sont visible. Avec le BPG on arrive à quelque chose bon avec peu de volume.
Parfait pour faire des screen complet de site web. (les archives web sont une catastrophe et prennent beaucoup trop de place)

Je n'ai pas fait de test poussé mais l'encodage d'images de 2100 * 32000 pixels est possible, on est pas limité au 4K ou 8K vidéo.

@Raysar: pour tes supers infos et de mettre ceci à dispo de tous
Super cette version, ca va bien plus vite chez moi à encoder (va comprendre pourquoi d'ailleurs ??) surttout lorsque j'ai regardé un peu les dlls  vs exe  du mode portable
 
Je n'ai trouvé que un bug, c'est lorsque que on pousse le curseur compression à max (cad à 9) il me renvoie un  bpg de 0 octets
 
Ca fait pareil chez toi lorsque tu regle à 9 dans les préférences ?
 
Dans les trucs dommage, c'est de ne pas pouvoir choisir ou le bpg sera écrit (par défaut le bureau)
Lorsqu'on chopisit un Bpg (dans décodage) que ca n'affiche pas une petite vignette (par exemple) ou un popup d'une miniature lorsqu'on passe sur le nom avec la souris, et pas de viewer si on double clic dessus (par exemple)
 
"... même avec une très bonne qualité et le dernier encodeur mozilla ils sont visible. Avec le BPG on arrive à quelque chose bon avec peu de volume."
+1000 exactement le meme avis !

Drap

@raysar: et hop je contribue un ptit coup, ca risque de t'interesser raysar (et merci d'avoir ouvert ce sujet)
http://www.developpez.com/actu/907 [...] ceptables/
 
ca va t'interesser fortement je penses
 
ah un truc, tu reste sur le format bpg ou tu ouvrirait ce topic sur d'autres codecs de ce style interessant ?
Je penses (p'tere a tord va savoir ? )
que ca serait bien de garder les NOUVEAUX modes dans le meme topic pour pouvoir les comparer entre eux, un peu comme t'a fait avec le jpeg optimisé.
Sinon ca risque d'éparpiller les infos interessantes pour ceux qui suivent ce topik (et on est pas trop ...nombreux )
 
Enfin c'est toi l'chef de ce topik, donc c'est toi qui doit décider

Tu me prends pour qui, bien sur que j'ai déjà vu la publication du Flif
Je ne suis juste pas encore repassé ici.

En effet, vu la faible activité sur les codecs, on va parler ici de tous les systèmes
d'encodage d'image performant ici.

J'aimerai aussi parler ici des codecs (qui n'existent pas encore en format d'image), les images clés du VP9 et du daala qui sont des algos concurrents mais intéressants à étudier.
Le Flif est aussi encore à l‘état d'algo mathématique, il faut voir ce que les gros du
web vont faire, mais ça peut être LE format qui leur fera gagner un espace disque
énorme tout en permettant d'améliorer l'expérience utilisateur sur les site web.

Actuellement beaucoup de site ont facile 5 versions différentes pour la même photo.

Je vais essayer d'améliorer le premier post.

Edit:
Il est possible d'utiliser quickview sur macos pour décoder tout un tas de format d'image dont le BPG.
Avec ce plugin: https://github.com/Nyx0uf/qlImageSize

Je regardais tranquillou la WWDC17 d'apple et là que vois-je?
Ils veulent implémenter le BPG (enfin leur sauce) sur leur iphone !
Donc c'est parti Apple va encore réussir à imposer un bon format alors que tous les autres acteurs incompétents ne font pas le boulot.

Ils sont quand même incapable de reprendre le bpg pour l'intégrer mais se sentent obligé de faire leur sauce propriétaire.

https://www.focus-numerique.com/new [...] 20311.html

C'est acté, c'est ça qui va remplacer le gif et le jpeg si chrome l'intègre à sa compatiblité.

Sinon pour info le logiciel Xnview (qui supporte la lecture du BPG) est depuis quelques mois enfin vraiment compatible avec les résolution retina sur macbook. #enfin

edit:
Quelques liens heif:
du code source: https://github.com/nokiatech/heif
un article scientifique: https://dspace.cc.tut.fi/dpub/bitst [...] sequence=1
apple: http://alex4d.com/notes/item/notes [...] rom-wwdc17
tuto conversion heif: http://jpgtoheif.com/

Intéressant ce sujet

je decouvre