Ontwikkelaar komt met bpg-compressieformaat als 'jpeg-vervanger'

Ontwikkelaar Fabrice Bellard, onder andere verantwoordelijk voor de ffmpeg-bibliotheek, heeft op basis van de hevc-videocodec een nieuw compressieformaat voor afbeeldingen gebouwd. Het bpg-formaat zou afbeeldingen tot de helft kleiner kunnen maken dan het jpeg-formaat.

Bellards bpg-formaat gebruikt onderdelen van de hevc-encoder in ffmpeg. Daarmee kunnen afbeeldingen met een vergelijkbare kwaliteit de helft kleiner worden gemaakt dan bij het gebruik van de jpeg-standaard. Het bpg-formaat, ofwel better portable graphics, biedt dezelfde kleurformaten als jpeg en biedt daarbovenop ook ondersteuning voor een alfa-kanaal. Ook rgb-, ycgco- en cmyk-kleurmodellen worden ondersteund en kleurdieptes tussen de 8 en 14bit zijn mogelijk.

Door middel van een javascript-decoder kunnen bestaande browsers afbeeldingen die met bpg zijn gecomprimeerd decoderen. Ook lossless-compressie is mogelijk en metadata als exif en icc-profielen kunnen embedded worden in de bpg-container. Volgens Bellard is bpg zelfs nog iets sneller dan afbeeldingen die met de hevc-codec compacter zijn gemaakt, doordat de header kleiner is. Voor Windows en Linux is de broncode van het nieuwe compressieformaat vrij beschikbaar.

Of het formaat breed ondersteund gaat worden, is nog onduidelijk. Google kwam in 2010 met het webp-formaat, maar het gebruik op met name het web blijft nog achter. Andere formaten die gemiddeld beter comprimeren dan jpeg zijn jpeg 2000 en re-jpeg.

Reacties (115)

Helemaal geen comments over de maker??

Fabrice Bellard is degene die o.a. FFMPEG heeft gemaakt en ge-opensourced. Die gast verdient een standbeeld in de open source goeroe gallerij!

Hij heeft ook ffe het qemu project gestart, nieuwe formules gevonden voor het berekenen van arbitrare digits van Pi, en zo op zijn desktop het record verbeterd voor het vinden van digits van pi, iets wat eerder enkel op een supercomputer gepresteerd was,
Hij heeft ook een x68 emulator geschreven in javascript, die at runtime de linux kernel compileert met een een snelle kleine c compiler die hij ook geschreven heeft, en zo (snel!!) linux kan booten in uw browser.
Verder implementeerd hij ook een 4G basisstation volledig in software, die op een eenvoudige pc kan lopen, iets waar je normaal enkele duizenden euro's aan hardware voor nodig hebt, en nog enkele andere kleine tools, amper iets om over naar huis te schrijven toch?

bron: http://bellard.org/

FB is de oppergod van alle techneuten. Buig allen voor hem!
Die gozer heeft zoveel mooie dingen gemaakt, ffmpeg, qemu, javascript implementaties, etc. etc.
Hij verdient inderdaad een standbeeld.

Maar even on-topic: kunnen we niet hetzelfde truukje doen maar dan op basis van WebM? Dus de image encoder baseren op de compressie algoritmes van WebM? Dan krijg een echt open source alternatief dat overal patentvrij te gebruiken is.

Edit: voor Bulkzooi link naar Wikipedia toegevoegd

[Reactie gewijzigd door [Yellow] op 12 december 2014 15:52]

Interessant, maar... het is heel moeilijk om serieus te concurreren met de bekende standaardformaten zoals JPEG die overal en door iedereen worden gebruikt en die overal in ingebouwd zitten, o.a. in vrijwel alle digitale camera's.

Technisch superieur zijn is niet genoeg om het te winnen van een populair de-facto standaardformaat zoals JPEG. (In de geschiedenis van de technologie heeft een technisch beter formaat / betere standaard het al vaker afgelegd tegen de concurrentie).

GIF was vroeger een veelgebruikt formaat maar tegenwoordig nog zeer beperkt. Ik denk wel dat het nodig is dat apparatuur zoals fotocamera's, smartphones, tablets dit standaard moeten ondersteunen en dat het ook als standaardformaat voor opslag worden gebruikt.

GIF had het probleem dat het maximaal 256 kleuren kon gebruiken en daardoor is het obsolete geworden voor foto's. JPEG heeft zo'n beperking niet. Het is wellicht wat groter en het kent geen alfa-channels, maar dat zijn meestal niet al te grote problemen.

Het enige bestaansrecht van GIF is nu nog animated GIF. Voor de rest kun je beter PNG of JPEG gebruiken.

Er bestaat ook wel animated PNG, maar dat wordt alleen door Firefox ondersteund.

Er bestaan zelfs 2 varianten: MNG en APNG, waarvan APNG beter ondersteund wordt door webbrowsers dan MNG.

GIF tegenwoordig beperkt? Dan kom je denk ik niet vaak op sites als redddit. Daar worden animated GIF's nog steeds vrij veel gebruikt, hoewel er op dit moment een verschuiving is naar HTML5 video.

Inderdaad, toch wel jammer want ik kan me zoveel voordelen bedenken..
Meer foto's op je camera/telefoon.
Sneller laden van websites met veel foto's/plaatjes en vooral ook minder data verbruik.

Neem bijvoorbeeld facebook/twitter/instagram/snapchat filmpjes en foto's zijn de boosdoeners in verbruik.
Eigenlijk zouden hun of 1 van hun de grote stap moeten maken.

Edit: typo

[Reactie gewijzigd door Fhristi op 11 december 2014 20:37]

Op telefoons etc zal dit formaat voorlopig waarschijnlijk enkel maar zorgen voor meer bandbreedte ipv minder.
Want op mobile is de caching beperkt en je moet wel de js-viewer code ook meeleveren (die in principe niet lang gecached blijft)

Als het aanslaat en native gemaakt wordt dan kunnen die sites ermee besparen, maar voorlopig zullen het enkel extra kosten zijn.

Wat helaas niet vermeld wordt, maar ik veel interessanter vindt:
- Hoeveel kleiner is een BPG met (voor het oog) dezelfde kwaliteit als een JPEG? Als dit in de buurt van de 50%-40% komt, dan denk ik dat het een mooie stap voorwaarts is, die binnenkort opgepakt gaat worden door meerdere concurrerende standaarden.

50% zeker wel, ja.

Veel moderne camera's kunnen in RAW schieten, bovendien ook alle spiegelreflex cameras, dan bied dit zeker voordelen

Ik vind de vergelijking hier http://xooyoozoo.github.io/yolo-octo-bugfixes/ duidelijker.
Je ziet er verschil .. vooral de lucht als subtiel gradient .. en het vervagen van de kabels aan de kruizen. Bij de "tennis" foto zie je ook duidelijk verschillen tussen de verschillende formaten.

[Reactie gewijzigd door gekkie op 11 december 2014 20:35]

Verdorie, da's zeker een mooie vergelijking! De grootste uitdaging zal helaas zijn om dit formaat mainstream te krijgen.

Mooi om te zien zeg. Maar in vergelijk met het origineel vs bpg 'medium' nog een wereld van verschil in textuur. Nu ben ik wel benieuwd wanneer bpg kwalitief in de buurt komt, wat doet 100kb bijvoorbeeld?

Op de gelinkte site ( http://xooyoozoo.github.io/yolo-octo-bugfixes/ ) kan je ook de vergelijking maken met webp, en dat verschil is wel niet groot.

Ik zie toch wel duidelijk een verschil. Het eerste wat me opviel was de banding in de lucht bij de webp versie. Ook zijn er veel meer artifacts te zien in webp. Google's webp is 'met dit voorbeeld' zeker het mindere formaat.

Dat wilde ik subtiel linken. Opvalllende verschilen, mooie tech.

Transparantie en animatie, zodat we ook van .gif verlost zijn.

he BPG decoding library excluding the FFmpeg code is released under the BSD license.
The BPG encoder is released under the BSD license

bron: http://bellard.org/bpg/


Qua licentie zit het wel snor.

Maar acceptatie is alles.

Kan zijn dat ik het fout hen, maar was er al niet een gif"vervanger"in een soort van PNG form?
Weet het formaat niet meer uit men hooft maar kwam er op neer dat het met PNG vergeleken kon worden.

APNG maar dat is amper ondersteund, verder heb je ook nog webm die doet het al wat beter, en geluid support.

“Gemiddelde webpagina is 1.8MB, 56% afbeeldingen” http://www.webperformance...00-web-page-1795-kb-size/

Zou betekenen dat je ‘gemiddeld’ inclusief js-decoder van 1.8 naar 1.3 gaat.

[Reactie gewijzigd door n8n op 12 december 2014 13:13]

Of het formaat breed ondersteund gaat worden, is nog onduidelijk. Google kwam in 2010 met het webp-formaat, maar het gebruik op met name het web blijf nog achter. Andere formaten die gemiddeld beter comprimeren dan jpeg zijn jpeg 2000 en re-jpeg.

Native ondersteuning is niet nodig door het gebruik van de geleverde javascript decoder.

Supported by most Web browsers with a small Javascript decoder (gzipped size: 71 KB).

Nadeel daarvan is dat je die gzipped decoder eerst moet inladen, dus weer wat verlies. Maar op websites met veel afbeeldingen waarschijnlijk wel lonend.

Wacht even, je schrijft zelf in het artikel dat dat ook voor het bpg-script geldt:

Door middel van een javascript-decoder kunnen bestaande browsers afbeeldingen die met bpg zijn gecomprimeerd decoderen.

Ik heb net even gekeken en bpgdec.js is ook 300 kB groot, daar heb ik een bpgdec.js.tar.gz van gemaakt en kom ik op 81,1 kB.

[Reactie gewijzigd door Soldaatje op 11 december 2014 20:56]

Test it. Dit is hoogst experimentele stuff.

De snelheid is op een groot deel van de devices geen probleem al zou native (hardware) ondersteuning wel beter zijn. Moet ook geen probleem zijn gezien het in essentie hevc is.

Scheelt wel een hoop opslag en bied betere kwaliteit niet te vergeten. Hoewel 8+ bit voor consumenten geen enkel voordeel zal bieden is de mogelijkheid er toe zeer welkom vind ik. Zeker met de blik op de toekomst waar de gamut steeds groter wordt en we later eindelijk wel een keer van 8bit afstappen.

Ik ga er eens mee spelen

Juist daar zie ik de toepassing. Veel posts hier zeggen dat dit formaat JPG niet gaat vervangen. Dat zal inderdaad zo wezen, maar als je zelf een drukke website hebt waar gebruikers foto's kunnen uploaden, dan is het al gauw heel lonend deze clientside naar bpg te converteren en dan zo op je server op te slaan. Ik ga dit zeker wel gebruiken.

71kB aan decoder is niet veel, maar die 200MB aan Java kan voor somige platformen toch wel een klein obstakeltje vormen.

Even een Public Service Announcement: Javascript en Java zijn 2 verschillende dingen. Javascript is de programmeertaal voor browsers. Java is de programmeertaal die alleen gebruikt word door Mojang (om Minecraft te maken).

Als alle browserbouwers dan ook gelijk even webp, JPEG XR en JPEG2000 support in kunnen bouwen dan ben ik ook weer blij. Vooral webp is wel relaxed. Jammer dat er nog zo weinig support is.

WebP is ook nog geen standaard. Het is een verzinsel van Google, en werkt dus alleen op Chrome (En Chropera, want dat is gewoon Chrome, en andere Chrome-klonen).

Op dezelfde manier zie je ook nog bijna geen support voor APNG (Firefox), JPEG XR (MSIE), en full-colour fonts (dat is écht een klerezooi).

[Reactie gewijzigd door _Thanatos_ op 12 december 2014 00:04]

In dit voorbeeld kun je wel heel duidelijk het verschil zien zeg.

Het ziet er een heel stuk beter uit en is zelfs iets kleiner, ik vraag me echt af hoe hem dat gelukt is en waarom niet eerder. Dat jpeg zag er nooit echt fraai uit, tenzij je de compressie veel lager koos.

JPEG is van de generatie MPEG2. Intussen hebben we h.264/AVC gehad, en BPG is gebaseerd op de nieuwe video codec h.265/HEVC. Het kost gewoon tijd om de details van het menselijke zicht te begrijpen, en hoe je dat slim kan coderen.

Niet echt, het begrip van het menselijk zicht is al vrij lang begrepen en is nu niet heel veel beter dan in de tijd van JPEG en MPEG2: in die tijd werd YUV (en YCbCr) en 4:2:2 subsampling al geïntroduceerd, wat de voornaamste tactieken zijn om de eigenschappen van het menselijk oog uit te buiten om lossy compressie er zo goed mogelijk te doen uitzien.

De vooruitgang in videocompressie komt er voor 95% door de vooruitgang in hardware: hardware wordt krachtiger en goedkoper, dus het wordt doenbaar om ongeveer dezelfde technieken uitgebreider toe te passen.

Voorbeelden:
1. In HEVC/H.265 wordt het gebruik van B-frames aangeraden, in AVC/H.264 was dat niet het geval. B-frames zijn frames die informatie uit zowel het vorige als het volgende frame gebruiken: enkel het residu tegenover de twee omliggende beelden wordt opgeslagen. In MPEG2 en H.264 werden er voornamelijk P-frames gebruikt: frames die informatie uit het vorige frame gebruiken (maar niet het volgende). B-frames waren toen al deel van de spec, maar in MPEG2 zijn er amper gebruikte profielen die B-frames gebruiken, bij AVC was dat al meer het geval, bij HEVC bevatten de meest gangbare profielen B-frames.
---> edit: geen nieuw inzicht dus, gewoon een bredere toepassing die nu mogelijk is door krachtigere hardware.

2. HEVC verdeelt het beeld in coding units (in een boomstructuur genaamd Coding Tree Units), blokken van variabele grootte (8x8/16x16/32x32/64x64 pixels). Grote blokken zijn erg efficiënt voor stukken beeld waar weinig detail in zit, zoals blauwe lucht of een kale muur. Door slechts een klein deel van het gehele beeld -de delen met veel detail (zoals een vliegtuig dat door die blauwe lucht vliegt, of een poster op die kale muur)- met kleinere blokgroottes te encoderen, en de andere delen met grotere blokken, wordt er echt enorm veel bandbreedte bespaard. De prediction units (een onderdeel van de blokstructuur) kunnen zelfs vierkant of rechthoekig zijn.
Deze techniek werd al zeer beperkt gebruikt in AVC/H.264: daar hebben de prediction blocks een variabele grootte van 4x4 tem 16x16 pixels. Maar de macroblock grootte was vast (16x16).
---> Toen wist men echt al dat variabele blokgroottes erg efficiënt waren, maar men kon ze nog niet toepassen omdat dit simpelweg te duur was in termen van complexiteit: de variabele blokgrootte maakt het werk van de decoder ingewikkelder, en de encoder heeft het al helemaal moeilijk want die moet uitzoeken voor elk deel van eht beeld of het nu met een klein of een groot blok moet worden gecodeerd.

Verdere verbeteringen komen van in-loop fikters: filters die de beeldkwaliteit subjectief verbeteren maken nu deel uit van het encoding process: de encoder kijkt welke parameters voor een bepaalde filter subjectief het best zijn en geeft die parameters mee in de stream. Enkele van deze filters zijn nieuw en dus wel gebaseerd op recent onderzoek naar subejctieve/onbjectieve beeldkwaliteit, maar de meeste (zoals de belangrijkste: de deblocking filter die randen van macroblokken vervaagt) bestonden al. Wederom: ze worden nu in de spec gebruikt omdat de hardware tegenwoordig krachtig genoeg is, niet omdat we erg veel nieuwe dingen ontdekt hebben.


Kortom: de vooruitgang is echt niet een resultaat van een beter begrip van het menselijk zicht, maar van de grotere hoeveelheid beschikbare rekenkracht en lagere kost van hardware (de lagere kost maakt het betaalbaar een complexere encoder/decoder chip te maken).

De volgende standaard, H.266, zal denk ik dezelfde trend volgen: dezelfde principes, breder toegepast. Zo is de kans reeel, met de komst van 8K en 16K beelden, dat de variabele blokgrootte wordt uitgebreid tot 128x128 en zelfs 256x256 pixels. En nog een veelbelovende optie is het gebruik van niet-rechthoekige blokstructuren, waarbij blokken in bepaalde gevallen driehoekig kunnen zijn.


Meer over I/P/B frames

Meer over de blokstructuur van HEVC.

[Reactie gewijzigd door kiang op 12 december 2014 15:54]

Goed verhaal. Echter, B frames worden ook in MPEG2 ondersteund. Ik denk dat het verschil zit in verhouding I/P/B frames. In MPEG2 worden relatief veel I en P frames gebruikt. In h264 en 265 worden veel meer B frames gebruikt.

Je hebt gelijk: de techniek bestond al, ik bedoelde inderdaad dat B-frames nu meer aangeraden worden (meer HEVC profielen bevatten B-frames dan bij AVC het geval was, en hun verhouding ligt hoger).

Er zijn daarnaast ook veel gecertificeerde H.264 decoders die alsnog geen B-slices ondersteunen. Bij HEVC zal dat, doordat meer profielen B-frames bevatten, minder vaak het geval zijn (enkel voor ultra low power en zeer gespecialiseerde hardware (zoals een encoder die enkel voor live broedcasts gebruikt wordt: daar kun je geen B-frames gebruiken) toepassingen vermoed ik).

JPEG is nog ouder dan dat, MPEG-2 is van 1996 JPeg van 1992.

http://en.wikipedia.org/wiki/JPEG
http://en.wikipedia.org/wiki/MPEG-2

En raad eens van wanneer het veel betere JPEG2000 was? Ik zou dan ook graag een vergelijking zien tussen JPEG2000 en dit nieuwe formaat.

Het probleem is niet om een nieuw en beter formaat dan JPEG te maken, het probleem is hoe krijg je het tot een standaard die iedereen gaat gebruiken.

Die vergelijking kan je hier zien (zoals hieronder ook al door @gekkie vermeld):
http://xooyoozoo.github.io/yolo-octo-bugfixes/

als ik de verschillen zo bekijk ben ik wel benieuwd of die smoothe transitie tussen kleuren van BPG niet te veel ten koste gaat van de scherpte.

Nee hoor, kijk maar eens naar het plaatje Fruits: scherper EN smoother

Weet je wat de grootste grap is? Ik kijk elke keer tegen J2000 aan zodra ik welk willekeurig document vanuit Photoshop ga opslaan, maar ik heb me nooit er toe kunnen zetten om het te gebruiken. Beetje "wat de boer nie ken da vreet ie nie"... Ik weet wel dat praktisch elke computer het kan openen, ik doe er gewoon niets mee... Iets wat ik overigens wel deed toen ik vanaf GIF inene kon kiezen voor PNG. Die keuze was om de een of andere reden zo gemaakt...

Zo geweldig is de ondersteuning van jpeg2000 anders niet. Stuur iemand een jpeg, gif of png en dat gaat altijd wel goed. Bij .jp2 heb je echter groot kans dat je bericht terug krijgt dat het bestand niet geopend kan worden. Voor jpeg2000 moet je namelijk vaak speciaal een image viewer of plugin installeren, want brede ondersteuning door OS-en en browsers is er niet echt, Apple uitgezonderd.

GIF had dan ook nogal zijn beperkingen. JPEG heeft daar veel minder last van, efficiëntie is misschien niet wereldschokkend maar best ok en het gemis aan alpha-channel voelt ook niet zo zwaar als het in GIF deed.

Die paar keren dat ik J2000 heb uitgeprobeerd, was het nut maar heel erg beperkt. Misschien 10% kleiner dan normale JPG. Dat is het dan gewoon niet waard. Bij deze BPG zie ik wel grote verschillen, én levert het extra opties zoals een alfa kanaal. Dát wordt dan wel interessant.

Denk ook niet dat JPEG snel vervangen gaat worden. De 2000 versie staat ook alweer 14 jaar te wachten op erkenning

Kunnen we geen open codec krijgen die meeontwikkelt in de tijd? Ik ben absoluut géén fan van jpeg, zeker niet in grafische zin. Het is lossy en kent geen doorzichtigheid. Helaas wel idioot veel gebruikt (camera's bijvoorbeeld)

[Reactie gewijzigd door Nas T op 12 december 2014 05:52]

Ik ben absoluut géén fan van jpeg [...] Het is lossy [...]

Net als veel andere formaten (waaronder BPG dus ook); de kunst is alleen om de verhouding "lossy" t.o.v. "compressie" goed te vinden. Je ziet in 't voorbeeld dat BPG bij eenzelfde (+/- paar bytes) compressie een stuk beter z'n werk doet en dus minder "lossy" is. Maar het is net zo goed ook lossy. (Tenzij je "lossless mode", wat ook ondersteund wordt, inschakelt, maar dat zal de compressie niet ten goede komen).

Voor audio en videomateriaal maakt 't vaak ook helemaal niet (veel) uit om (een bepaalde mate van) verlies te hebben omdat 't menselijk oog/oor maar details oppikt tot op bepaalde hoogte. Alle andere "details" kun je (in meer/mindere mate) 'weggooien' omdat 't oor/oog dat toch niet oppikt en daar zit je compressie (grotendeels).

Bij andere vormen van compressie kun je helemaal geen verlies hebben (denk aan een ZIP/RAR van een document/executable; daar mogen niet zomaar "bits/bytes" weggegooid worden, na de-compressie zul je 100% het origineel willen kunnen reproduceren).

tl;dr: elk formaat heeft z'n voor- en nadelen, met daarbijbehorende compressie(mogelijkheden) en, ja, sommige formaten beginnen langzaamaan 'outdated' te worden en beginnen langzaamaan marktaandeel te verliezen van nieuwe(re) / betere formaten.

[Reactie gewijzigd door RobIII op 11 december 2014 22:57]

Wellicht even melden dat je alleen reageert op het lossy deel, gezien BPG wel degelijk transparantie ondersteund (alfa kanaal).

Lossy is sowieso al lastig overigens. Het maken van een foto/film met welk formaat dan ook levert per definitie al verlies op. Er zijn minder pixels/sensors dan licht signalen .

En wie gaat daar zijn tijd en energie in steken als er vervolgens niet gecasht kan worden dmv licentiegelden?

Als browsers het ondersteunen wordt het zeker een interessant formaat voor hosters om te gebruiken. Het scheelt bandbreedte en dus vaak ook geld.

Ik denk dat die bandbreedte niet echt het probleem is.

Misschien ben ik te ouderwets, maar nog opgegroeid in het inbelmodemtijdperk, heb ik altijd de tic gehouden om afbeeldingen te verkleinen voordat ik ze online slinger, in een document plak of via de mail verstuur.

Tegenwoordig resized bijna niemand meer iets. Als de filesize écht verschil zou maken, zou iedereen toch bandbreedte-gerelateerde problemen met die grote files moeten ervaren?

Tijd is geld, en als mensen liever 10 euro voor een grotere internetbundel betalen (ook op mobieltjes wordt er veel groot spul verstuurd) dan is dat hun keuze. Onwetendheid kan ook zoiets opleveren, veel mensen hebben geen flauw idee hoe je uberhaupt iets resized

maar het gaat juist om de bedrijven achter de websites, waarom denk je dat google met webp is gekomen?

De Chrome Web Store draait inmiddels geheel op WebP-afbeeldingen, met een gemiddelde besparing van 30% t.o.v. JPEG-afbeeldingen.[3] Facebook gebruikt het formaat op grote schaal om dataverkeer te besparen en de snelheid te vergroten in zijn mobiele applicaties.

30% minder dataverkeer op images heeft een behoorlijke impact op de dagelijkse trafic en dus kosten

We gaan te snel uit van onze eigen situatie waarbij bandbreedte van secundair belang is. Landen in Afrika en Azië hebben die luxe niet altijd.
Een bijkomend probleem is dat je bepaalde afgelegen gebieden nooit optimaal kunt bedienen ivm de kosten. Met een softwarematige upgrade kun je relatief simpel de kwaliteit verbeteren.

..veel mensen hebben geen flauw idee hoe je uberhaupt iets resized

Heerlijk van die websites met width=300 height=200 en dan een 14 MB JPEG er achter.. 'even snel uploaden van de camera'.

Op gathering of tweakers zijn ook heel veel mensen die niet weten hoe je en thumbnail kan maken. Om de haverklap zie je daar afbeeldingen met notabele een dikke rode rand van Tweakers dat dit niet de bedoeling is en een link naar hoe het moet. Helpt niets, zelfs gebruikers waar je beter van zou verwachten vinden het blijkbaar allemaal te moeilijk...

Ik heb dit zelf ook al meegemaakt, ik post niet super veel op fora, en al zeker geen foto's. Ik verwachtte dat dit automatisch gebeurde.

OT: Zo zoek ik ook al enige tijd naar een instelling waarmee ik op Youtube standaard 240p kan selecteren en wanneer ik wil een hogere resolutie. Als je een paar seconden van een film bekijkt in 1080p op een GSM ben je met 4G al snel veel data kwijt, terwijl je enkel de inhoud van het filmpje wou weten. Zo wordt er vééél data onnodig verbruikt volgens mij, en CO2 geproduceerd...

Klopt, het enige wat ze tegenwoordig kunnen is een van ons tweakers bellen als hun outlook zich heeft opgeknoopt op een powerpoint vol met ruwe 15 megapixel foto's...

Om vervolgens je heel wazig aan te kijken als je ze uitlegt dat een bijlage van ruim 500mb ook wel erg idioot is...

Hang gewoon van je volume af. Als jij toevallig miljoenen afbeeldingen met tijdseenheid moet leveren wordt het allemaal heel interessant.

Als de afbeelding voor een website gebruikt wordt is het fijn als deze zo klein mogelijk is. Dit heeft namelijk grote invloed op de gebruikservaring. Hoe eerder alle content gedownload is, hoe eerder deze getoond kan worden.

Zeker met de verschuiving naar "nieuwe" devices, met vaak (nu nog) minder bandbreedte, wordt dit weer belangrijker.

Bandbreedte is wel degelijk een groot probleem. Een website betaald voor iedere MB die hij doorstuurd. Een standaard hosting pakket is gemiddeld 3 tot 5 gb per maand.

Als je de afbeeldingen met 50% kunt verkleinen zonder kwaliteitsverlies tegenover de huidige situatie scheelt je dit én bandbreedte én wordt je site sneller geladen. Dus de gebruikerservaring gaat ook omhoog.

Ik zie deze als webdeveloper heel graag verschijnen.

- Heeft lossless
- Exif
- ICC profielen
- Transparantie
- De helft van de grootte van jpeg
- RGB, CMYK en YCGCO kleurprofielen
- broncode vrij beschikbaar
- Nu al toepasbaar door javascript decoder

Ik zie deze ook wel een kans hebben om een nieuw standaard binnen browsers te worden. We kunnen hem immers nu al gebruiken waardoor we geen kip en ei verhaal hoeven te hebben. Plus de broncode is vrij beschikbaar.

Fout niet resizen ids de grote fout die veel webbouwers maken.

google kijkt toch naar de snelheid van jou website. Laatst een voorbeeld van iemand, pagina 2,5mb, na compressie van de afbeeldingen ging er 1,2 mb af.
Gevolg website wat bijna 1 sec sneller geworden, zie daar betere rankings in google, mensen die pagina sneller krijgen.

Grote van het bestand is zeker nog belangrijk op het web alleen onderschatten veel mensen dat.

Het scheelt bandbreedte en dus vaak ook geld.

Dus minder inkomen voor hosters? Nee die zullen dit niet willen finacieren...

Denk aan Imgur, zij hosten afbeeldingen.

Ah ja inderdaad die hosters kunnen zo idd wel besparen, het is inderdaad net welke hoster of website je bent (tweakers zou er ook profijt van hebben)...

Het is voor bijvoorbeeld camera's juist een geweldige codec. Het is op z'n minst 'best wel goed' (afhankelijk van de implentatie van de camera) voor ongeveer 95% van de gebruikers (Mensen die meer nodig hebben kunnen altijd nog RAW werken) en transparantie voor een camera zie ik niet echt een meerwaarde van in

Voor een camera niet, maar voor grafische zaken werk ik nu met PNG, want losless compressie. Alleen het meest gangbare is jpeg en met verschillende standaarden werken is ook niet handig.
Transparantie voor een camera is in zoverre handig, dat je in een grafisch programma bijvoorbeeld gezichten kan knippen en de rest transparant maakt. Dat kan nu ook, maar dan moet je je bestand wel volgens een ander formaat opslaan. Dat is niet fijn voor workflow. Plus: theoretisch en praktisch is het mogelijk, dus ik zeg: hoe meer mogelijkheden, hoe beter.

Vooral belangrijk is dat de standaard open en dynamisch is, zodat alles mee kan groeien. Camera's kunnen dan oudere type's blijven maken, want op nieuwere software is dat ook uit te lezen.

Met de tijd wordt denk ik een beetje lastig. Tenzij je kan verplichten dat het ge-update wordt wat een hoop moeilijkheden met zich mee brengt.

Zoals WebM & WebP? Of het werk van Xiph?

Pas als de camerafabrikanten ondersteuning voor dit soort formaten zouden gaan inbouwen in hun camera's zou het wel eens flink kunnen aanslaan. En ik denk dat de wat kritischer fotograaf graag een betere beeldkwaliteit zal zien. Vooral ook een lossless compressieformaat zal bij de meeste DSL(R) gebruikers zeer goed ontvangen worden.

Het wordt ook hoog tijd dat er in die brache op dit punt eens wat vernieuwing doorgevoerd wordt om e.e.a. weer wat meer bij de tijd te brengen. Zolang men maar 'downward compatible' blijft en dus ook JPEG zal blijven bieden als bestandsformaat is er niet echt een rationeel nadeel te bedenken waarom ze dit niet zouden doen. Het is eigenlijk verbazend dat er op dat punt zo weinig beweging is geweest in de camerawereld sinds de digitale camera de analoge heeft verdrongen. Alleen in de RAW formaten zijn ontwikkelingen geweest maar in de 'ready-to-view' formaten is er niet echt wat gebeurd.

Dit werkt natuurlijk alleen goed als de camerafabrikanten gezamenlijk een nieuwe standard afspreken en gaan gebruiken. Dit formaat lijkt zeker een kandidaat te zijn.

HOOGSTE tijd voor veranderingen imho.

En ik denk dat de wat kritischer fotograaf graag een betere beeldkwaliteit zal zien.

Precies de reden dat RAW bestaat. Helaas is dit ook flink versplinterd en niet standaard. Noch open.

Oftewel zwaarder om in en uit te pakken maar kleiner. Dus voor browsers iets meer werk om plaatjes "uit te pakken"

H.265/HEVC is leuk voor filmen maar daar ook, leuk 2x zoveel kwaliteit in dezelfde opslag maar wel de extra tijd die nodig is om de video om te zetten. Moet je rekening mee houden.

Zeker aangezien behoorlijk wat GPU"s nu H.264 kunnen decoderen. H.265? Nog niet dus dat gaat weer naar de CPU.

Dat komt snel genoeg: bepaalde nieuwe fotocamera's hebben al een een chip voor hardwarematige encode/decode. Komt snel genoeg uit op GPUs. Maar daarnaast: op een moderne CPU (een Core 2 Duo of nieuwer) valt die load voor het decoden echt wel mee hoor.

Ik denk meer aan de tablets en super kleine laptops. Het type dat het met een Intel Atom moet doen.

Tuurlijk kan die het plaatje decoderen. Maar het gaat ietsje langer duren en op bepaalde pagina's kan dat behoorlijk uitpakken.

Totdat inderdaad ze standaard komen met verbeterde hardware ondersteuning voor H.265

Er is altijd een compromis nodig tussen grootte, kwaliteit en benodigde rekenkracht.
JPEG is nog een oud formaat van toen CPU's vele malen minder krachtig waren. Nu zelfs de CPU van een telefoon vele malen krachtiger is dan een computer van 10 jaar geleden, kan in de balans de benodigde rekenkracht omhoog waardoor de kwaliteit omhoog kan bij eenzelfde bestandsgrootte.

Maar het speelveld is omgekeerd ook wel weer veranderd waardoor het weer veel en veel moeilijker is om een nieuwe standaard te creeeren.

In 1992 had je 1 of 2 mainstream plaatjes toon-progs en daar moest jpeg ingebouwd worden en dan was je er grofweg.

Tegenwoordig moet je het bijna minimaal door MS gedragen krijgen (voor explorer-thumbnails) idem voor Apple / Linux. En dan als je het ook nog als echte vervanger wilt hebben voor jpg door alle browsers (inclusief backwards compatibilty voor bijv ie8).
En dan heb je nog het hele mobile stuk waar je het ook nog moet introduceren.

Dus technisch gezien is het veel en veel makkelijker geworden om betere kwaliteit te krijgen, alleen praktisch is het veel en veel moeilijker geworden om het uit de kip-ei fase te krijgen

Het voorbeeld is zelf een jpeg, is dat wel representatief??
http://ic.tweakimg.net/ext/i/imagenormal/2000567201.jpeg

Aangezien het voorbeeld veel groter(bestand) is lijkt me dat wel.

hoe wil je het anders zien in je browser
(al had een .png beter geweest)

PNG ja

Ja mooi, vroeger had je op VHS-video's trailer reclame voor dvd's. Kon je op je VHS-band zien hoe mooi dvd was. En nu loopt er een Samsung-televisiereclame waar ze het verschil laten zien tussen Amoled en gewoon led. Die zie ik dan op mijn gewone led-tv en toch is er verschil :-)

De zoveelste JPEG vervanger.... en als je je bedenkt dat veel muziek nog steeds in het MP3 formaat uit de jaren 90 van de vorige eeuw staat... sommige dataformaten uit een, voor computerbegrippen, ver verleden, lijken niet uit te willen sterven.... en JPEG is daar waarschijnlijk ook een voorbeeld van.

Ik denk dat dit vooral te maken heeft met noodzaak, voor video is het formaat er van een veel groter probleem met steeds hoger wordende resoluties en dergelijke. MP3'tjes bijvoorbeeld kan je er toch al een hoop op je device a 320kbit hebben dus is een efficienter formaat niet zo nodig. Met een goede breedbandverbinding laad ook een hoge resolutie jpg van toch wel prima kwaliteit ook gewoon snel genoeg in dus ook daar is er minder druk om te veranderen. Zonder die druk gebeurt het gewoon weg niet.

De mp3 encoders zijn jarenlang doorontwikkeld. En de laatste lame-versie bijvoorbeeld produceert muziekbestanden van zeer goede kwaliteit.

Zoals je kunt zien heeft de ontwikkeling niet stilgestaan op mp3-gebied: http://lame.cvs.sourcefor...istory.html?revision=HEAD

Totally agree. eigenlijk zou er een verbod op dergelijke ancient formaten moeten komen.

voorbeeldje van iets wat ook na 15 jaar nog steeds geen grond aan de voeten van de zoden zet:
http://en.wikipedia.org/wiki/Musepack

en toch lopen we met z'n allen MP3's af te spelen.... :*(

FLAC

Flac is lossless, dus nog steeds heel wat groter dan musepack...

MP3 is ook gewoon goed genoeg.
Op een telefoon of draagbare mediaspeler met oordopjes is elke verbetering t.o.v. MP3 volledig overbodig. Zelfs de tegenwoordig veel gebruikte bitrate van 320 kb/s is met standaardapparatuur/ luidsprekers/ oortjes van betaalbare draagbare apparatuur niet hoorbaar beter dan 160 kb/s (of zelfs 128 kb/s of 96 kb/s wanneer je de standaard meegeleverde oortjes gebruikt).