Mozilla introduceert efficiëntere jpeg-encoder

Mozilla heeft een efficiëntere encoder voor jpeg-afbeeldingen geïntroduceerd. De encoder is compatibel met bestaande decoders en zou afbeeldingen gemiddeld vijf procent kleiner kunnen maken. Facebook voert al proeven uit met de nieuwe encoder.

Zowel afbeeldingen die volgens het baseline- als via het progressive-jpeg-formaat zijn opgeslagen, zijn gemiddeld vijf procent kleiner, belooft Mozilla. Veel afbeeldingen zullen volgens de browsermaker dankzij de Mozjpeg 2.0-encoder zelfs nog kleiner zijn. De opensource-encoder is compatibel met bestaande jpeg-decoders, waardoor bijvoorbeeld browsers niet hoeven te worden bijgewerkt om de nieuwe, kleinere jpegs te kunnen laden. De verbetering is vooral te danken aan trellis quantization, een algoritme dat vooral geschikt is voor de compressie van beelden en dat ook in onder meer Xvid en h.264 wordt gebruikt.

Facebook is al begonnen met de eerste tests van het nieuwe formaat. Bovendien heeft het sociale netwerk 60.000 dollar gedoneerd om de ontwikkeling van Mozjpeg 3.0 mogelijk te maken. Vorig jaar verzocht Facebook Mozilla juist om ondersteuning voor webp, een relatief nieuw formaat voor afbeeldingen van Google. Vooralsnog heeft Mozilla daar nog geen gehoor aan gegeven, al is het verzoek wel in overweging genomen. In 2011 zei Mozilla nog geen plannen voor ondersteuning te hebben.

Uit onderzoek dat Mozilla zelf heeft verricht, zou blijken dat jpeg in sommige gevallen efficiënter is dan webp wanneer wordt gekeken naar het aantal bits dat nodig is per pixel. De nieuwe standaard high efficiency video coding, die onder meer wordt gebruikt in de opvolger van h.264, is in alle gevallen het efficiëntst, maar ondersteuning voor stilstaande afbeeldingen met hevc-compressie is nog minimaal.

Reacties (79)

[Juris LLM.]

Bedoel je deze? https://xkcd.com/927/
Ontopic: Het is inderdaad goed dat er weer eens gekeken wordt naar de oude standaarden. Toch vraag ik me af of het niet eens tijd word voor een nieuw afbeeldingsformaat. Het zou mooi zijn als er een lossless raw formaat komt.

[Yggdrasil]

Raw is per definitie de ruwe data rechtstreeks van de sensor van je camera. Die moet eerst geïnterpreteerd worden door een algoritme om er een afbeelding van te maken.

Aangezien het cameraspecifiek is heb je er weinig aan als formaat voor internetafbeeldingen, tenzij je in elke browser een volledige lijst van alle camera's wilt bouwen zodat de browser de ruwe data kan interpreteren en renderen.

Een goed losless formaat is PNG en daar zal best nog wat aan verbeterd kunnen worden.

[Anoniem: 80466]

Toch vraag ik me af of het niet eens tijd word voor een nieuw afbeeldingsformaat.

Dat formaat wordt hevc (ISO/IEC CD 23008-12 Image File Format )
Er moet echter nog hardwareaccelleratie voor hevc (met name voor video) worden uitgerold voordat browsers het massaal gaan ondersteunen.

[Reactie gewijzigd door Anoniem: 80466 op 22 juli 2024 23:18]

[skatebiker]

Ik zie eerlijk gezegd liever een 16 bits JPEG / PNG formaat. Deze hebben nog altijd de beperking van 8 bits per R,G of B.
Maar misschien is dat gewoon TIFF ? Ik snap ook niet waarom camera's dat niet gebruiken naast RAW en JPEG.

[84hannes]

Omdat TIFF een niet-bestaand gat opvult. TIFF heeft kleurinformatie voor 3 a 4 kleuren per pixel, RAW heeft (doorgaans) maar 1 kleur per pixel. TIFF is groot, waarschijnlijk zelfs groter dan RAW vanwege de informatie (2 kleuren per pixel) die je toe moet voegen ten opzichte van RAW. Je hebt dus een bewerkte afbeelding (nadeel van JPG) in heel veel bits (nadeel van RAW): er is geen winnaar in jouw voorstel.

[MSalters]

RAW heeft 1 kleur per sensor-element. Dat is omdat camera's zo werken, en "RAW" leterlijk de ruwe cameradata is. Maar je hebt dan wel meerdere sensoren (typisch twee G, 1 R en 1 per pixel.

TIFF staat zo ongeveer alles toe. 40 kleuren? Als jij een sensor hebt die dat produceert, dan kan TIFF het opslaan. Maar juist die flexibiliteit maakt het nauwelijks tot een verbetering over RAW.

Het idee van "twee kleuren toevoegen per pixel" is dus volkomen onzin. Zelfs in RAW zijn er geen ongebruikte bits.

[84hannes]

Volgens mij vergis jij je. Eén sensorelement staat voor één pixel. Iedere pixel in RAW heeft dust maar één kleur. Aldus een artikel dat ik hierover vond:

So a 10MP camera has 2.5 Million green pixels, 2.5 million blue ones and 5 million green ones. The job of the RAW processor in the camera or in the computer software if you shoot RAW is to interpolate between the single colors to generate the missing color values at all pixel locations.

De eerste "green" moet, gezien de context, "blue" zijn.

[PPie]

De eerste "green" moet, gezien de context, "blue" zijn.

Red?

[84hannes]

Red!

[Orion84]

Wat bedoel je met een lossless RAW formaat? Die bestaan er al genoeg, lijkt me? Elke camerafabrikant heeft een dergelijk formaat en als je graag een open standaard gebruikt is er DNG.

[djunicron]

Inderdaad, maar uiteindelijk gebruikt volgens vrijwel niemand DNG...
En waarom zou je, PNG is vaak al goed genoeg als je wilt uitwisselen, maar mensen die zich ermee bezig houden kunnen vaak met iedere andere "fabrikanten-RAW" ook wel overweg.

Een Raw-oplossing met de grote van een flinke Jpeg als standaard zou misschien nog leuk zijn, maar ook daarvan betwijfel ik of het er gaat komen en of er dan wel behoefte aan is. Ik verwacht eigenlijk van niet.

[Reactie gewijzigd door djunicron op 22 juli 2024 23:18]

[Orion84]

Zou misschien leuk zijn, maar gewoon theoretisch onmogelijk. Jpeg behaalt dergelijke compressie alleen door een heleboel informatie weg te gooien. Dat is prima voor waar jpeg voor gebruikt wordt, maar het idee van RAW is juist om zoveel mogelijk van de originele sensordata te behouden zodat je in de nabewerking het maximale uit je foto kan halen.

Twee verschillende doelen, twee verschillende formaten, elk met hun eigen voor en nadelen die niet verenigbaar zijn.

[Adion]

Een deel van de compressie van JPEG is wel degelijk te wijten aan het om een andere manier representeren van de data (in frequentiedomein, gesorteerd op frequentie en vervolgens een lossless compressie gelijkaardig aan zip toegepast)
Slechts een deel van de compressie is te wijten aan de (lossy) quantizatie-stap.
JPEG-XR, wat een potentiele opvolger voor JPEG had kunnen zijn heeft bijvoorbeeld voorzieningen om een zeer gelijkaardig algoritme voor lossless compressie ook toe te passen.

[JAVE]

Lossy vergelijken met lossless gaat altijd in het voordeel van lossy zijn wat betreft grootte van het bestand. Dat is namelijk het hele idee van lossy :-)

[Anoniem: 120693]

Het zou mooi zijn als er een lossless raw formaat komt.

Maar die zijn er toch al? Waarom zou je er een bij willen hebben? Wat zou die moeten doen wat nu nog niet kan?

Voor het internet is lossless gewoon nog geen optie. Bijvoorbeeld bij de sites en shops waar ik mee verantwoordelijk voor ben zou dat een paar duizend Euro per jaar meer aan datakosten met zich meebrengen voor iets wat 95% van de mensen nooit zou zien en waar de resterende 5% best mee kan leven.

[mae-t.net]

Correctie: lossless is geen optie voor foto's. Voor lijn- en rastertekeningen zijn natuurlijk uitstekende lossless formaten, die zowel in kwaliteit als afmetingen even goed of beter zijn.

[Reactie gewijzigd door mae-t.net op 22 juli 2024 23:18]

[Junketsu]

Waarom is lossless geen optie voor foto's? De sensordata (RAW formaat) kan als lossless als een PNG worden opgeslagen waarbij van elke pixel informatie wordt bijgehouden.

[Adion]

Hangt er vanaf wat je lossless noemt. Wil je echt de rauwe sensordata van een camera is het native-formaat, of eventueel DNG vermoedelijk de enige oplossing.
Bij een PNG moet je het Bayer-patroon dat gebruikt word in de sensor al omzetten in een RGB-formaat per pixel. Dit is een stap waarvoor niet 1 uniek algoritme voor bestaat, maar verschillende algoritmes verschillende resultaten geven.
Zelfs die stap kan dus al verlies op leveren ten opzichte van de rauwe data.

[Junketsu]

De sensor is met jouw definitie ook lossy door de hardware die bepaalde keuzen maakt en niet precies het origineel na kan bootsen. Zo kunnen we eeuwig dorogaan.

Met de definitie die jij stelt komen we geen steek verder, want dan is alles lossy.

Wat is dus de toegevoegde waarde?

[mae-t.net]

Lossless is absoluut een optie voor foto's, maar niet voor "het internet" dat in de posting waarop ik reageerde werd genoemd. Ik neem tenminste aan dat hij het www bedoelde, en bij het laden van pagina's telt nog steeds elke kilobyte (temeer als je met je mobieltje of pad surft).

[Junketsu]

Je hebt helemaal gelijk. Ik reageerde zonder de context te begrijpen. Mijn excuses.

[hackerhater]

Correctie: lossless is geen optie voor foto's. Voor lijn- en rastertekeningen zijn natuurlijk uitstekende lossless formaten, die zowel in kwaliteit als afmetingen even goed of beter zijn.

Correctie: lossless is geen optie voor foto's. Voor lijn- en rastertekeningen zijn natuurlijk uitstekende lossless formaten, die zowel in kwaliteit als afmetingen even goed of beter zijn.

Voor zo'n tekeningen, waarom daarvoor geen SVG gebruiken?
Kan je het schalen wat je wilt zonder kwaliteitsverlies

[NovapaX]

Dat bedoelt hij dus ook
SVG, PDF etc. Allemaal lossless.

[mae-t.net]

PDF is niet per definitie lossless, er kan JPEG-compressie gebruikt zijn.

Maar ik bedoel dus inderdaad formaten als SVG en PNG, en PDF afhankelijk van het intern toegepaste formaat.

[Anoniem: 420148]

PDF is inderdaad meer een container van bepaalde objecten. Je kunt XML, JPEG, PNG, PSK etc. allemaal in een PDF gooien.

[NovapaX]

Nee, PDF per definitie is wel lossless.
Wat je erin stopt komt er ook weer uit.
Dat je daar lossy-encoded dingen bij stopt kan de PDF niets aan doen.

Let op, het ging hier ook over lijn- en rastertekeningen.

Maar als je het strikt bekijkt is PDF inderdaad geen codec, maar een container, of meer een markup-language.

[Anoniem: 420148]

SVG is niet lossless, dat is een dataset zonder compressie. Dit is gewoon een XML-bestandje die door de viewer uitgelezen word als plaatje of tekstdata.

Lossless heeft nog steeds een compressiealgoritme waarbij enkel geen data verloren gaat. Daar voldoet SVG bijvoorbeeld dus niet aan. PDF zal ongeveer hetzelfde te werk gaan, aangezien dit gewoon gevectoriseerde tekst is.

[Anoniem: 136725]

nog niet eerder gezien, maar slaat wel de spijker op de kop ;-) thanx

[Soldaatje]

5% is mooi maar niet echt om wakker van te liggen.
Ben benieuwd of de decoders langer bezig zijn of het meer processorkracht/batterij kost.

[Orion84]

Op de schaal van Facebook is het natuurlijk bijzonder fijn om 5% te besparen op storage en dataverkeer aan plaatjes. En plaatjes zullen denk ik een zeer substantieel deel uitmaken van de data die omgaat in Facebook.

[Anoniem: 126717]

Yep! Mooi artikel om te lezen:
https://m.facebook.com/note.php?note_id=76191543919

The Photos application is one of Facebook’s most popular features. Up to date, users have uploaded over 15 billion photos which makes Facebook the biggest photo sharing website. For each uploaded photo, Facebook generates and stores four images of different sizes, which translates to a total of 60 billion images and 1.5PB of storage. The current growth rate is 220 million new photos per week, which translates to 25TB of additional storage consumed weekly. At the peak there are 550,000 images served per second. These numbers pose a significant challenge for the Facebook photo storage infrastructure.

En vervolgens de meer technische kant. Het artikel is al uit 2009, dus de getallen zullen nu veel hoger zijn.

Waarom wordt jpeg2000 nergens gebruikt?

[juniordiscart]

JPEG2000 wordt voornamelijk gebruikt in digitale cinema. Het wordt weinig gebruikt op het web omdat JPEG2000 velen malen complexer voor het encoden naar JPEG2000 en ik geloof decoden ook.

Hier teer ik even op mijn geheugen, kan zo niet direct een bron vinden. JPEG werd ontwikkeld door verschillende organisaties. Één van die organisaties had een hele reeks aan patenten op technieken die ook verwerkt werden in JPEG. Deze organisatie werd later opgekocht, en de patentent gebruikt om patentinbreuken mee aan te vechten. Hierdoor zijn vele nu een beetje terughoudend om zulk een scenario te vermijden, en later problemen te krijgen op een web waarin toch voornamelijk wordt gepredikt om open standaarden te gebruiken.

[MSalters]

JPEG2000 gebruikt wavelets in plaats van de iDCT. Dat is inderdaad complexer.

[Anoniem: 457607]

Eens, op Facebook schaal en op wereldschaal zet 5% zoden aan de dijk.

Daarbuiten, huis, tuin- en keukengebruik is het weinig interessant, temeer omdat het bereiken van de besparing zo enorm veel voeten in de aarde heeft. Zowel software als hardware ondersteunen het niet.

In die context (op kleine schaal) vind ik ook webp niet interessant. Ik ben niet onder de indruk van 20% besparing. Maak me maar wakker wanneer er een formaat is wat 2 x - 10 x kleiner is, dat zou een motivatie zijn om alles aan te passen (hardware, software, workflow).

[84hannes]

dat zou een motivatie zijn om alles aan te passen (hardware, software, workflow)

Daar is het mooie nieuws: je hoeft niet alles aan te passen. Die SD-kaart in je digitale fotolijstje hoef je nog een paar weken niet te vervangen omdat er nieuwe foto's bij moeten passen. Je google photos/drive account hoef je nog geen upgrade tegeven omdat je met 20% effectieve uitbreiding nog maanden vooruit kan, je gaat niet langer elke maand 50MB over je mobiele datalimiet heen doordat alle plaatjes 20% kleiner zijn en plaatjes 90% van je datagebruik uitmaken. En dat zonder dat je jouw telefoon, browser of image viewer hoeft te upgraden, er hoeft alleen aan de encodeerkant iets te veranderen.

[TrekVogel]

Facebook is voor de Android app daarom al webp gaan gebruiken.

[hendymen]

Precies wat ik al dacht!

Elk voordeel heeft zijn nadeel, het is leuk dat die afbeeldingen 5% kleiner in bestandsgrootte zijn maar ik zit er niet op te wachten dat ik door het bekijken van alles wat ik doe op facebook, en later op ook streamings diensten 5% verlies van mijn batterij..

Ik heb nu al het gevoel als ik de itvonline van KPN of de horizon van UPC bekijk dat ik een kachel op mijn schoot heb, ik zie bij dat silverlight materiaal streaming een cpu van 60~80% op een macbook air 2012 en ~40% op een hp zbook 17...

Hierdoor is al merkbaar dat de accutijd van 12 uur ineens naar 3 uur geschaald wordt op de macbook en de zbook moet blij zijn met een 1,5uur..

Deze techniek is inderdaad leuk voor de capaciteit van de opslag en voor het snellere streaming voor mensen met een 54k modem.. Tegenwoordig leven we op 4g met bijna 50/50 en onbeperkte databundels ik zit echt niet te wachten op 5% minder accutijd..

[Anoniem: 544923]

Waarom zou je batterij 5% minder lang mee gaan als de plaatjes 5% kleiner worden. En als tv via je tablet gaat gaat die natuurlijk sneller leeg omdat het beeldscherm de hele tijd aanstaat.

[hendymen]

Omdat de afbeelding meer gecomprimeerd wordt, je hebt dus meer rekencapaciteit nodig om een afbeelding te de-comprimeren, meer rekencapaciteit is meer belasting van de cpu, een hogere cpu belasting lijdt weer tot een hogere accu gebruik,

Als voorbeeld pak een 1080 filmpje van 5gb welke opnieuw gecodeerd is of pak de originele blu-ray van 60gb, je zult zien dat je cpu veel zwaarder belast wordt met de opnieuw gecodeerde versie van 5gb dan de versie van 60gb.

Een film op een dvd-tje is 4,7gb maar dezelfde film van het internet kan al 700mb zijn (natuurlijk wel met minimale kwaliteitsverlies ~5%, echter speelt je simpele dvd speler deze 700mb versie niet af, deze codex (codering) is niet ondersteund omdat je dvd speler te weinig rekencapaciteit heeft om deze terug te coderen..

Bron; jarenlange ervaring op het echte HDbits.org forum.

[dusty-2011]

Een internet-film van 700 MB ziet er echt heel anders uit dan een originele DVD van 4,7 GB. Er is geen sprake van minimaal kwaliteitsverlies, er is sprake van GROOT kwaliteitsverlies. De DVD-rips van 700 MB hebben echt een heel slecht beeld vol met artefacten.

[OddesE]

Zeker een tijdje niet meer gekeken? Op 700 MB download je tegenwoordig een BluRay rip op 720p. Die ziet er veel beter uit dan de DVD ooit was. De enige reden dat DVD's 4,7 GB nodig hebben om een SD beeld te encoden is dat DVD spelers vroegah super trage processors hadden en geen meer geavanceerde algoritmes aankonden. Zometeen komt er h265 en die belooft bij gelijke kwaliteit nog maar iets meer dan de helft van de ruimte nodig te hebben. Die 720p rip past zometeen in 400MB.

[dusty-2011]

Ik had het in mijn reactie duidelijk over DVD-rips, niet over de Bluray-rips die jij aanhaalt. Maar ik heb natuurlijk ook wel eens een 720p release van 700 MB gekeken. Ik ben het helemaal niet met je eens dat dit betere kwaliteit zou zijn dan een originele DVD. Een originele DVD ziet er best mooi uit als je hem op een fatsoenlijke DVD speler afspeelt op een fatsoenlijke TV. De 700 MB 720p releases hebben een veel te lage bitrate voor 720 beeldlijnen en zien er daarom een stuk minder goed uit, ze zitten vol met pixelation en artefacten. Bekijk dit op dezelfde TV vanaf dezelfde afstand en het ziet er echt niet beter uit dan een originele DVD.

Voor een 720p release houd ik altijd als vuistregel aan dat de release zo'n 2 GB per uur film groot moet zijn (uitzondering: cartoons e.d. die op een lage bitrate er nog fatsoenlijk uitzien). Voor een 1080p release houd ik altijd als vuistregel aan de release zo'n 3,5 GB tot 4 GB per uur film groot moet zijn. Deze vuistregels gelden voor moderne codecs zoals h264 of x264. Als je deze vuistregels naleeft dan krijg je echt veel betere kwaliteit video te zien dan een originele DVD.

Ik gruwel van de YIFI releases. Bah, een hele 720p film proppen in 700 MB, met geluid van abominabele kwaliteit, kleuren die sterk afwijken van de originele Bluray, regelmatig pixelation en artefacten in beeld.

[hendymen]

Ik ben het helemaal met je eens, letterlijk het 'verkrachten' van mooie films om ze zo klein mogelijk te maken..

Als je een 720 tv hebt wil je gewoon kunnen genieten van 720 films, idemdito bij 1080 films en tv's.

Als ik een oude beeldbuis tv zou hebben zou ik genoegen nemen met een YiFi release.

Maar goed we raken off-topic

[skatebiker]

De DVD-rips van 700 MB hebben echt een heel slecht beeld vol met artefacten.

Kom, kom, overdrijven is ook een kunst. Zelf heb ik het meermalen gedaan maar het valt best mee. Natuurlijk is de originele DVD beter maar zo'n 700MB rip is prima te bekijken. Maar al die pixelpeepers tegenwoordig die nemen geen genoegen meer met foto's van minder dan 12MP of smartphoneschermpjes van minder dan 1920x1080. En met die foto's van 12MP ipv 6MP gaat het voordeel van 5% met betere JPEG compressie ruimschoots verloren.
Beetje hetzelfde als 'de auto's van tegenwoordig zijn veel zuiniger' (wat dus per auto geldt) waarbij vergeten wordt dat er zoveel meer auto's zijn dat de totale vervuiling en lawaai veel groter is dan bijv. 20 jaar geleden.

[halofreak1990]

Natuurlijk is de originele DVD beter maar zo'n 700MB rip is prima te bekijken.

Op 'n computerscherm? No way. Ik heb menig 700MB DivX gehad en die hadden stuk voor stuk baggerbeeld. Een DVD van minder dan 4.3GB komt er bij mij dus niet in.

[hendymen]

Ik krijg nachtmerries van DivX rips maar, als je het verschil tussen die dvd en de rip kunt zien dan zie je het volgende ook wel.

Voorbeeldje als je het echt wilt weten;

Originele Need for Speed Blu-ray, TayTo release, Sparks
-------------
http://imgbox.com/g/sxJ3hwSQYf

Eerste 6 fotos zijn Origineel bluray
Tweede 6 fotos zijn TayTo release 11.50 GB
Derde 6 fotos zijn Scene(sparks) release 13.58 GB
-------------
x264 iNFO
x264 [info]: frame I:1280 Avg QP:15.56 size:254542
x264 [info]: frame P:47745 Avg QP:16.85 size:103119
x264 [info]: frame B:139009 Avg QP:18.29 size: 55481
x264 [info]: consecutive B-frames: 4.0% 7.1% 12.3% 16.2% 15.8% 38.2% 4.3% 0.7% 0.7% 0.7%

encoded 188034 frames, 2.36 fps, 13221.75 kb/s, duration 22:09:12.99

[dusty-2011]

Moet ik verschil zien tussen die foto's? Sorry hoor, maar ze zien er allemaal bijna identiek uit. De verschillen die er zijn zijn zeer minimaal. De verschillen zijn net zichtbaar op 30 cm afstand van m'n monitor. Ga ik op een meter afstand van m'n monitor zitten dan zijn er helemaal geen verschillen meer. De TayTo release en de Sparks release zijn beide prima rips gebaseerd op deze foto's.

De verschillen tussen een 700 MB DVD rip en een originele DVD zijn véle malen groter.

[hendymen]

Dat bedoel ik te zeggen!

Maar in verhouding moet het mogelijk zijn om een dvd te coderen naar ~700mb ook met deze kwaliteit-behouding, als je zelfs wilt kan je een dvd van 4,7gb naar bijvoorbeeld 500mb brengen zonder verlies. Maar ik zou het niet prettig vinden als mijn laptop op schoot of een tablet in de hand een verwarming wordt doordat deze dan constant zit te blazen, wat ook ten koste gaat van de accu.

Wat ik liever zou zien is dat ze een extra server (figuurlijk een stuk) inzetten om alle fotos die geupload worden te coderen/inpakken en zodra jij die foto oproept je de normale (geuploade) versie krijgt van de foto door deze op een andere server wordt ge-decodeerd/uitgepakt en aan je wordt aangeboden. Hierdoor merk jij zelf niets als gebruiker, fotos blijven zoals ze zijn en de accu ook, en heeft facebook minder opslag nodig doordat de bestanden nog maar de helft van de originele grote zijn,

Kortom gezegt, ieder voordeel heeft ook zijn nadeel en we raken off-topic!

[dusty-2011]

Een DVD van 4,7 GB naar 500 MB brengen kan alleen als je een codec gebruikt die maar liefst negen keer zo efficiënt is. De beste codecs van het moment zijn volgens mij ongeveer 2,5 keer zo efficiënt.
Verder zijn originele DVD's altijd double-layer en zijn de filmbestanden vaak wel 7 of 8 GB groot. Als je dit dan terug zou willen brengen naar 700 MB heb je een 10 keer zo efficiënte codec nodig en die bestaan gewoonweg niet. Dit gaat altijd gepaard met groot kwaliteitsverlies.

[Mitsuko]

De verbeteringen hier zijn allemaal mogelijk binnen de huidige JPEG standaard, er worden dus geen nieuwe algoritmes gebruikt tijdens het decoderen. Natuurlijk is het mogelijk dat bepaalde algoritmes die langzamer werken nu meer worden gebruikt, maar het decoderen zou net zo goed ook sneller kunnen zijn.

Daarnaast hoeft je netwerk wel 5% minder lang data binnen te halen en duurt het inlezen van je harde schijf ook 5% minder lang.

[MSalters]

De belangrijkere oorzaak van batterijverbruik is de data-transfer - radio's vreten meer batterijen dan je ARM CPU. Dus de eerste energiewinst is dat je download snelelr is.

Verder verandert dit compressie-algoritme niets aan je decompressie-algoritme. Dat produceert hetzelfde resultaat op basis van minder input data. En gezien de werking van JPEG decompressie (gebruikte coëfficienten op de goede plek zetten, iDCT runnen) wordt decompressie sneller als je minder coëfficienten hoeft te gebruiken voor hetzelfde resultaat.
(JPEG compressie werkt doordat de meeste coëfficienten na de DCT onbelangrijk zijn en dus niet verzonden worden).

Kortom, er zijn 2 redenen waarom dit batterijen spaart.

[Anoniem: 528441]

Wel als 80% van de sitebezoekers je mobiel bezoeken (en nee 4g is nog lang niet overal)
of wanneer mensen nog inbellen (ja buiten de vs en europa komt dat nog best vaak voor)

[bonus]

Instagram zou die 5% dankbaar kunnen gebruiken met de hoeveelheden die zij hebben Of Dropbox... Dan heb je het niet over een paar plaatjes maar een paar miljoen denk ik.

[Forsakeneyes]

Mwuah, ~10KB of meer besparing op een paar miljard afbeeldingen tikt toch wel aardig aan hoor. Je moet groot denken bij dit soort dingen.

[Maurits van Baerle]

Hopelijk heeft hij ook minder last van die lelijke compressieartefacten waar JPEG berucht om is. Ik weet alleen niet of dat mogelijk is binnen de standaard.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 23:18]

[juniordiscart]

Dat is nou net eigen an JPEG. Soms wil je gewoon dat je afbeelding er wat "slechter" uitziet zodat je kan besparen op file size, omdat niet iedereen nood heeft aan alle details in de foto. Je kan bij JPEG voor het encoderen van een RAW afbeelding kiezen wat de kwaliteitsfactor is van je afbeelding. Hoe "slechter" de kwaliteit, hoe kleiner de bestandsgrootte. Indien je geen artefacten wil moet je kijken naar PNG, maar PNG afbeeldingen zijn over het algemeen wat groter dan een zelfde JPEG afbeelding.

Wat in het artikel wordt gezegd is eigenlijk: we hebben de bestandsgrootte 5% kunnen verkleinen met een gelijke graad van kwaliteit. En dat is best wel interessant, hoe klein die 5% ook mogen wezen.

[Reactie gewijzigd door juniordiscart op 22 juli 2024 23:18]

[lezzmeister]

Het is voor bedrijven als Facebook juist reuze-interessant. Die 5% over een miljard afbeeldingen, dat tikt wel aan. Dat scheelt enorm in de kosten voor opslag en bandbreedte.

[Anoniem: 80466]

Dat scheelt enorm in de kosten voor opslag en bandbreedte

Initieel kost het juist VEEL VEEL meer opslagruimte omdat je twee versie van alle images moet opslaan.
Je hebt dan dus 95% meer opslagruimte nodig voor images.

[EraYaN]

Lezen...

> De encoder is compatibel met bestaande decoders en zou afbeeldingen gemiddeld vijf procent kleiner kunnen maken.

[dmantione]

Het gevolg van 5% kleinere bestandsgrootte is dat je er ook voor kunt kiezen om het bestand even groot te houden en zo minder arctefacten te zien.

[Alex3]

Merkwaardig dat Mozilla zich met een propiëtair formaat bezighoudt en niet b.v. met png, dat ook nog eens efficiënter is en ook bewegende plaatjes kan opslaan.

[gjmi]

png is niet efficiënter voor foto's, wel voor grafische plaatjes, simpele kleuren, lijnen, text. en dan ook nog losless, dus geen artefacten

[supersnathan94]

Vergeet de transparantie niet. Erg belangrijke eigenschap van PNG waar ik gretig gebruik van maak.

[CyBeR]

png kan geen bewegende plaatjes opslaan; althans niet vanuit de spec van png zelf.

[i7x]

Webp is een beetje nutteloos. Het zijn toch maar wat plaatjes, en die zijn meestal niet zo groot. Desondanks denk ik dat het een kleine moeite zou zijn om het te ondersteunen, al zou gewoon jpeg blijven gebruiken natuurlijk handiger zijn als het echt even grote afbeeldingen oplevert.

Webm is wel echt een uitkomst. Heel handig om te gebruiken in plaats van gifs bijvoorbeeld. Gelukkig heeft Firefox daar wel ondersteuning voor.

[Reactie gewijzigd door i7x op 22 juli 2024 23:18]

[Hans van Eijsden]

Dat webp nutteloos is ben ik niet met je eens. Sinds ik op http://www.weblogzwolle.nl webp toe pas voor Chrome-bezoekers, zijn we per dag tussen de 4 en 6 GB aan data minder kwijt. Nou is data gratis voor ons, maar toch is het mooi meegenomen.
Meer informatie over het automatisch comprimeren naar bijvoorbeeld webp voor Chrome-bezoekers vind je hier: https://developers.google...lter-image-optimize?hl=nl

[Jazco2nd]

"toch maar wat plaatjes"
Ben je net opgestaan ofzo? Leed bijvoorbeeld wat voor een bizarre load het is voor Facebook, staat een paar reacties boven je.

[EraYaN]

Webm wordt nu eigenlijk misbruikt on gif te vervangen eigenlijk zouden we daar de nieuwe webp voor moeten gebruiken...
Webm is voor filmpjes... Webp met animatie support is de echte vervanger voor gif.

Ze hebben het ook ooit geprobeerd met apng nar dat is nooit echt van de grond gekomen.

[Anoniem: 136725]

Blij om te zien dat men zich met oude formaten bezig houden.

Een quote die me nog steeds doet heugen luid als volgt: We need to make a new codec that will make other ones unnecessary so we need lesser codecs. Poof! Another codec has been born.

[player-x]

Een quote die me nog steeds doet heugen luid als volgt: We need to make a new codec that will make other ones unnecessary so we need lesser codecs. Poof! Another codec has been born.

Dat geld in dit geval natuurlijk niet, het is de nog steeds zelfde codec, alleen wordt er meer efficiënt gecodeerd.

Het is alleen wachten op dat deze encoder overal word integreert, want bv niet alleen Photoshop moet er gebruik van gaan maken maar ook bv Windows Paint en al andere tekenprogramma's die daar tussen zitten.

[Anoniem: 136725]

Vandaar ook dat ik ook zei: Blij om te zien dat men zich met oude formaten bezig houden.

Compatebility die behouden blijft en wel kleinere bestands groote.

[wkleunen]

Het is geen nieuwe standaard, het is een andere manier van encoderen binnen dezelfde standaard.

"De opensource-encoder is compatibel met bestaande jpeg-decoders, waardoor bijvoorbeeld browsers niet hoeven te worden bijgewerkt om de nieuwe, kleinere jpegs te kunnen laden. ''

[codebeat]

Gebruik meestal https://tinypng.com/ voor png plaatjes met behoudt van transparantie, kan een hoop bytes besparen. Tevens http://www.digitalconfidence.com/downloads.html doet het ook goed, haalt een hoop extra info uit plaatjes. Bijvoorbeeld adobe Fireworks heeft daar wel een handje van om allerlei zut in de header te plaatsen van afbeeldingen.

Zeker omdat tegenwoordig alles flat is en je wellicht plaatjes gebruikt (wanneer je plaatjes gebruikt) kun je ook de kleurdiepte terugbrengen. Soms kan het zelfs in 16 kleuren. Dat scheelt echt een hoop bytes, let wel, opslaan als png anders wordt het plaatje qua omvang veel groter. Voordeel is dan dat je het plaatje groter kan maken (formaat) en iets schalen op de website. Dat is wanneer de site responsive is weer erg handig, ziet het er toch nog scherp uit.

[Reactie gewijzigd door codebeat op 22 juli 2024 23:18]

[vssr]

Voor dat soort werk is https://kraken.io ook een prachtige tool, deze kan zowel png, jpg als gif 'minimizen' met keuze uit lossy of lossless. Via de api kun je grote aantallen draaien. Ik geef hier tegenwoordig de voorkeur aan t.o.v. grafische programma's. Kraken bedenkt voor mij wat acceptabel is, en 99% van de tijd klopt 't. Geen reclame, gewoon echt een goede tool

[codebeat]

@vssr: Bedankt voor de tip! Ga het eens proberen. Weet je ook wie hier achter zit, van wie of wat is het eigenlijk? Zie ik nergens staan dus vandaar de vraag.

[vssr]

Kennelijk is het van 'Nekkra', te Berlijn gevestigd, de firma zegt me verder niets. Zie: https://kraken.io/about/impressum

[Anoniem: 175233]

Het zou veel beter zijn als de JPG encoders een ingebouwde kwaliteits controle hadden, waarbij de codec een zo goed mogelijke compressie kiest, zonder teveel aan de kwaliteit in te boeten.

Want wat doet iemand die momenteel iets in Photoshop opslaat? Die kiest 100% kwaliteit... omdat het hem niet uitmaakt of het plaatjes daardoor 30% groter wordt.... of zelfs dubbel zo groot. In principe kan je bij het opslaan kiezen tot hogere compressie, maar dan moet je per plaatje gaan controleren of je artefacten ziet. Dat doet natuurlijk niemand. (En niemand die weet dat die 100% ook maar gewoon een willekeurige compressie is...)

Wat je zou willen is een opslag methode die een systeem heeft waarbij automatische de laagste compressie kiest, waarbij er nog geen zichtbare artefacten ontstaan. Dát zou pas echt zoden aan de dijk zetten!

[Fairy]

Ik vind 't jammer dat er nog steeds geen algemeen ondersteunde opvolger van jpeg is. We hebben jpeg2000 gehad, werd niets wegens rechtenproblemen. Later kwam JPEG XR, maar dat is intussen ook alweer 7 jaar oud en nog steeds bijna nergens te vinden, praktisch geen enkel programma kan JPEG XR bestanden maken.

Ik zou graag een formaat zien dat in staat is om veel beter te comprimeren, inclusief lossless optie, kleurprofielen, 8 of 16 bits per kleur, transparantie in gradaties.

Als je dan ook nog kunt kiezen tussen snelle codering en decodering en trage complexe voor extra kwaliteit dan zou dat echt een perfecte oplossing zijn, met name voor fotografie vind ik JPG echt een no-go. Ik doe alles in raw, maar als ik iets moet laten printen dan moet ik het sturen in JPG en dat vind ik zonde omdat je hiermee veel kwaliteit verliest, bijvoorbeeld ProPhotoRGB is met JPG niet mogelijk.