Google komt met jpeg-compressie die foto's tot een derde kleiner moet maken

Google heeft een nieuwe manier van compressie op jpeg-bestanden voorgesteld die afbeeldingen op het web tot een derde kleiner moet maken zonder zichtbaar verlies aan kwaliteit. Door de kleinere bestanden moeten websites sneller laden.

Google noemt de nieuwe compressie Guetzli en onderzoekers van het bedrijf hebben de techniek voorgesteld in een paper op Arxiv. De bestandsgrootte kan omlaag door gebruik van Googles eigen techniek .butteraugli, dat de 'psychische zichtbaarheid' van verschillen tussen afbeeldingen vergelijkt.

Door gebruik te maken van die techniek kan Guetzli informatie in de afbeelding weghalen waarvan .butteraugli verwacht dat mensen het niet gaan zien. Daardoor zouden naast het kleinere bestandsformaat de jpegs van Guetzli er beter uit moeten zien dan huidige jpegs, die bijvoorbeeld met libjpeg zijn gecomprimeerd.

Het is niet voor het eerst dat het zoekbedrijf probeert om de grootte van afbeeldingen op het web te verminderen. Enkele jaren geleden kwam het met een nieuw bestandsformaat, webp, dat Google zelf gebruikt voor bijvoorbeeld screenshots in de Play Store en thumbnails op YouTube. Google heeft groot belang bij kleinere afbeeldingen, omdat het op zijn servers veel afbeeldingen bewaart.

Links: de niet-gecomprimeerde afbeelding. Midden: gecomprimeerd met andere jpeg-compressie. Rechts: jpeg van Guetzli

Reacties (105)

[blackSP]

Rechts oogt veel beter dan de middelste. Super ontwikkeling dit, hopen dat dit snel breed wordt ingevoerd, geaccepteerd en mainstream wordt. Totdat er weer wat beters komt.

Vrij gebruik lijkt me geen probleem :

https://research.googlebl...new-open-source-jpeg.html

It is our hope that webmasters and graphic designers will find Guetzli useful and apply it to their photographic content, making users’ experience smoother on image-heavy websites in addition to reducing load times and bandwidth costs for mobile users. Last, we hope that the new explicitly psychovisual approach in Guetzli will inspire further image and video compression research.

[totaalgeenhard]

From the practical viewpoint this is very similar to our Zopfli algorithm, which produces smaller PNG and gzip files without needing to introduce a new format, and different than the techniques used in RNN-based image compression, RAISR, and WebP, which all need client and ecosystem changes for compression gains at internet scale.

Dus het is lijkt erop dat het downwards compatible.

Alleen comprimerende toepassing (je photoshop) zal het moeten ondersteunen.

[bbob]

Ik gebruik zelf riot om foto's voor webpagina's kleiner te maken.

Bij voorkeur gebruik je eerst een raw foto zonder compressie c.q die sla ik als jpg op met minimale c.q geen compressie.
Dan in riot om meer compressie te geven.

Wat ik zie is dat het helemaal afhangt van het type foto, kleuren enz. De ene foto kan ik zonder verlies extreem veel meer compressie geven met voor het oog hetzelfde resultaat, de andere foto stukken minder compressie.

Ik vraag me dan ook af hoe ze dit kunnen automatiseren want feit blijft de ene foto kan zonder verlies voor het menselijk oog meer compressie krijgen dan de andere.

update, meteen even test gedaan, compressie is extreem langzaam. Heb jpg 600kb (zonder compressie) met riot kwam ik op 60k, met Guetzli op 175k.
Denk ik kijk of ik de 60kb file door Guetzli te jagen maar deze wordt idd niet geaccepteerd, kwaliteit was al te laag.
Simpele conclusie voor mij, handmatig met riot de compressie wijzigen met je eigen oog lijkt tot nu toe het beste.

[Reactie gewijzigd door bbob op 23 juli 2024 13:36]

[watercoolertje]

Simpele conclusie voor mij, handmatig met riot de compressie wijzigen met je eigen oog lijkt tot nu toe het beste.

Het beste voor je bandbreedte/HDD ruimte, maar daar houdt het meteen op, mijn werkgever gaat het niet leuk vinden als ik plaatjes met de hand ga nalopen om die enkele KB te besparen, dan zijn de kosten om mij te betalen veel hoger dan de baten. Oftewel dit is voor ons wel veel beter, want het bespaard voor ons gratis (theoretisch) 33% van de kosten aan bandbreedte en opslag!

Anyway, ik ga nu wel een keer naar Riot kijken, ben namelijk wel nieuwsgierig

[Reactie gewijzigd door watercoolertje op 23 juli 2024 13:36]

[bbob]

Riot kun je trouwens ook gewoon hele directory laten comprimeren. Gaat dus ook automatisch en snel

Net als bij Guetzli liefst jpg png of iets anders dat niet gecomprimeerd is. Daar zit een groot deel van de winst al in.

[EraYaN]

jpg is altijd lossy gecomprimeerd, png is wel lossless.

[Roel911]

bbob1970 bedoelt met "iets anders dat niet gecomprimeerd is" bijvoorbeeld een .bmp volgens mij

[watercoolertje]

Ah okee, dat is dan wel weer een voordeel, maar dan heb je waarschijnlijk niet meer de winst die jij haalde met het 'maatwerk'.

Thanks in ieder geval, vind het wel interessant om naar te kijken!

[bbob]

In mijn geval werk ik met foto's van kleuren van textiel materiaal, hoog laag die een bepaalde structuur hebben.
In riot kan je van 100 naar 0 (beste) gaan. Bij sommige kleuren kan ik gewoon minder compressie toepassen dan andere kleuren. Het betreft dan foto's met specifiek 1 of 2 kleuren, bijv rood met wat verschillende kleuren rood of donkergrijs.
In mijn geval gaat het om presentatie van kleuren die zo nauwkeurig moeten overkomen omdat koper daar een keuze uit maken.

Heb je gewoon productfoto van pc, vakantie foto dan is een specieike kleur minder belangrijk. Bij foto's waar je vaak met een veelheid aan kleuren te maken hebt kun je goed werken met een vaste compressie factor. Die moet je voor jezelf vinden wat nog acceptabel is.

Zelf dan kun je met riot veel besparen. Meeste dus als het origineel niet gecomprimeerd is.

[MSalters]

Ik vraag me dan ook af hoe ze dit kunnen automatiseren want feit blijft de ene foto kan zonder verlies voor het menselijk oog meer compressie krijgen dan de andere.

Op dezelfde manier waarop MP3 werkt. Dat is waarom het artikel verwijst naar een psycho-visueel model. Zo'n model kan bepalen hoe opvallend elk artifact is.

JPEG wordt in blokjes van 8x8 pixels gecomprimeerd. Met een 1 mpix image heb je dus 65K van die blokjes. Je kunt niet realistisch met de hand parameters per blok instellen, laat staan dat je rekening kunt houden met de 65K * 4 buren. Zo'n algoritme is dus best handig.

[bbob]

Klinkt leuk en zal voor veel zaken werken. Maar net als met jpg heb je mensen met goede oren die het verschil kunnen horen.

Ik besteed zelf veel aandacht aan compressie met foto's van kleurmonster die ik maak. Daar zie ik met riot hele grote verschillen qua compressie tussen sommige foto's. De ene kleur extreem veel meer dan de andere. Tot zelf een punt waar een antraciet in een warme kleur omkiept.

Het deze compressie nu vandaag gedownload en getest maar compressie was niet echt spectaculair te nomen, viel eerder tegen met wat ik nu doe.

[bartvb]

Voor nu nog niet heel bruikbaar. Er is inderdaad een open source implementatie:

https://github.com/google/guetzli

Maar:

Guetzli's computation is currently extremely slow, which limits its applicability to compressing static content and serving as a proof- of-concept that we can achieve significant reductions in size by combining advanced psychovisual models with lossy compression techniques.

en

Guetzli uses a large amount of memory. You should provide 300MB of memory per 1MPix of the input image.

Heb het nog niet geprobeerd, weet niet wat ze met 'extremely slow' bedoelen, maar het lijkt erop dat ze het plaatje comprimeren, daarna door .butteraugli halen om te kijken of er grote perceptuele verschillen zijn, daarna weer comprimeren, vergelijken, etc, etc. Dat kost nogal wat tijd en geheugen inderdaad.

Wat mij betreft vooral nog een proof of concept. Kan op zich wel aardig zijn om b.v. afbeeldingen op een homepage te comprimeren die echt heel vaak worden bekeken. Maar voor m'n eigen gebruik wacht ik nog even tot het allemaal wat efficienter is geworden aan de serverkant

[wizzkizz]

Valid point wanneer het gaat om dynamisch on-the-fly comprimeren van afbeeldingen.

Bij eenmalig comprimeren voorafgaand aan het uploaden zie ik niet waarom je lang zou moeten wachten. Als het bewerkingsprogramma dat je gebruikt het ondersteunt en je computer kan het handlen, dan waarom niet. De client kan het prima weergeven en het scheelt meteen in bandbreedte en tijd.

[Yggdrasil]

Ja, maar de term "extremely slow" geeft mij de indruk dat de web developer of designer zijn computer al vrij snel uit het raam gooit zodra je een dozijn afbeeldingen toevoegt.

[Gamrin]

Dit zou eventueel op een renderfarm moeten kunnen. Bewerkte image saven naar een map die alle images erin gaat comprimeren.

[Yggdrasil]

Klopt, technisch voldoende mogelijkheden, maar voor wie? Maar als je een renderfarm nodig hebt om je afbeeldingen te comprimeren dan moeten de besparingen wel dermate groot zijn dat zich dit terugbetaald. Lijkt mij alleen geschikt voor de grootste bedrijven.

De kleine en middelgrote developers en designers (ik werk in die branche) bewerkt zijn afbeeldingen op zijn iMac of laptop en doet zijn builds lokaal (via Gulp e.d.) of op een CI server. Ik denk niet dat die doelgroep hier de moeite voor kan of wil opbrengen. Zodra het algoritme versneld is (indien mogelijk) of er een variant gevonden wordt die beter is dan wat we nu hebben voor een redelijke performance-prijs gaat het vast wel toegepast worden. Zie bijv. dit artikel over Brotli-compressie in je asset-pipeline.

[SkyStreaker]

Ik zie voordeel bij gigantisch grote image-bibliotheken. Die paar procenten winst gaat cumulatief gezien, lijkt mij, veel winst opleveren in opslagruimte-gebruik. Dit kan toch voordelen hebben voor je omzet als je minder hoeft te betalen voor, potentieel, meer ruimte?

[DaVince21]

"Als het bewerkingsprogramma dat je gebruikt het ondersteunt"

Maar op dat punt zijn we nog niet, en daar ging dit ook niet over. Het is deze eerste implementatie die traag is. Dat hoeft natuurlijk helemaal niet het geval te zijn bij verdere ontwikkeling en optimalisatie, of herimplementatie op een andere manier.

[bbob]

Het is idd heel traag. Zelf werk ik al jaar op 2 met Riot. Doe alles handmatig.
Origineel liefst een niet gecomprimeerd bestand, bijv raw foto die wel als jpg zonder compressie bewaard is of gescande iets.
Daarna op het oog compressie realtime wijzigen in riot.
Test die ik hierboven gedaan heb met Guetzli en Riot betekend voor mij handmatig met riot en zelf compressie bepalen werkt nog steeds beter.
Zie bijv dat is de ene foto tot 35% kan reduceren de andere maar tot 65%.

Het is natuurlijk handwerk, kost tijd maar voorlopig werkt dit nog het beste voor kleine web bestanden.

[Alfa1970]

Ik snap niet waar al die kleur artefacten vandaan komen in beide compressie methodes.
Ik snap dat je detail verlies kan hebben, maar het is een egaal grijs vlak boven en onder de "lijn" hoe komt het toch dat in beide compressie methodes dit wordt vertaald naar witte en veel donkerder grijze vlakken of zelfs individuele pixels?
De rechter methode heeft dat veel minder, maar boven de lijn zitten die artefacten ook daar.

[PageFault]

Met JPEG2000 kun je meer winnen, maar ik vermoed dat dit backwards compatible is met het weergeven van JPEGs.

[Jack Flushell]

Dit voorbeeld is beter. Tenminste iets herkenbaars (kattenoog). Volgorde is hetzelfde met links orgineel, rechts Guetzli en midden oude jpeg.

Ziet er veelbelovend uit.

[cracking cloud]

In dat voorbeeld is de kleur in het rechter plaatje gewijzigd, terwil die in het middelste plaatje nog hetzelfde is ...

[JAVE]

Dan lijkt het erop dat ze minder kleurinformatie opslaan. Het rechter plaatje is inderdaad fletser.

[CrazyJoe]

Ik heb even met ImageJ (een freeware image processing pakket) difference images gemaakt van het origineel met beide gecomprimeerde varianten en de verschillen tussen de oude Jpeg en de Guetzli images t.o.v het origineel zijn helemaal niet zo drastisch.

JPG:
Mean: 3.434
StdDev: 2.200
Min: 0
Max: 11

Guetzli:
Mean: 3.458
StdDev: 2.853
Min: 0
Max: 19

In het grijze vlak buiten het oog zie je bij beide een afwijking van ongeveer 2 kleurwaarden t.o.v het origineel, dus dat het rechtse plaatje fletser zou zijn is niet waar. Misschien dat je in de war gebracht wordt door het feit de oude Jpeg implementatie meer last heeft van quantizatieruis (kijk naar het gebied boven het oog in alle drie de varianten) terwijl dat stukken minder is bij de Guetzli implementatie.

Als je kijkt naar de groene rand aan de linkerkant van de Iris dan zie je in beide gevallen een grote afwijking t.o.v. het origineel. Echter de afwijking is in beide gevallen anders. De oude Jpeg implementatie maakt hier een aantal pixels duidelijk helderer en een aantal pixels juiste fletser zodat je een vreemd kleur contrast krijgt t.o.v. het origineel. De Guetzli versie is inderdaad over het algemeen fletser, maar is in ieder geval consequent fletser waardoor die groene "band" in ieder geval consequenter oogt.

[koelpasta]

Eerlijk gezegd is het redelijk onzinnig om dit soort cijfers te gebruiken voor het bepalen van de kwalieit van een codec.
Ik denk dat je dit soort dingen per definitie in een psychovisuele eenheid moet doen. Of in ieder geval iets met een model van het menselijk oog of iets dergelijks.

Verder ben ik het wel eens met je persoonlijke psychovisuele vaststellingen (die je dus met je eigen ogen hebt gemaakt). Dat is ook gelijk veelzeggender dan die gemiddeldes.

[lukjah]

Dat is dus wat ze bedoelen met "de gebruiker ziet het waarschijnlijk toch niet". Als je ze naast elkaar legt zie je elk lossy compressie algoritme. Maar met die afbeelding alleenstaand was het jou nooit opgevallen.

[koelpasta]

In dat voorbeeld is de kleur in het rechter plaatje gewijzigd, terwil die in het middelste plaatje nog hetzelfde is ...

Nou, in het midden issie ook al best wel anders die kleur.

[ro8in]

Een compressie welke dingen weg haalt waarvan verwacht wordt dat we er niet naar kijken. Vind dat toch wat tricky hoor..

Google wil gewoon meer compressie want een derde minder data scheelt hun al 100.000 harddisks. Heeft niks meer met snellere sites te maken. Een gemiddelde site zou er misschien 1 tiende van een seconde sneller op worden. Dat merk je als gebruiker echt totaal niet.

[Reactie gewijzigd door ro8in op 23 juli 2024 13:36]

[84hannes]

Ik denk dat je er ook rekening mee moet houden dat computerschermen langzaamaan hogere resoluties krijgen. Het is dus een kwestie van tijd totdat alle websites afbeeldingen gebruiken die vier keer zoveel pixels hebben als nu. Het is niet alleen in Googles belang als deze 30% minder groot zijn, het scheelt bandbreedte, opslag, wellicht werkgeheugen (ik weet niet of deze afbeeldingen altijd gedecomprimeerd in het werkgeheugen staan, of bijvoorbeeld voor webpagina's in de achtergrond gecomprimeerd), cache etc.

[dwarfangel]

De ontwikkeling mbt pixels heeft meer baat bij een snellere invoer van ondersteuning voor svg(z) bestanden. Dan hoef je ook niet meer 3 versies van je logo te gebruiken, maar gewoon 1 bestand van enkele kb's.

De compressie van jpg is zeker welkom, maar wel iets minder noodzakelijk dan Google doet voorstellen. Ze helpen vooral zichzelf ermee. 'De markt' verzint wel iets voor de snelheid: bepaalde kleurfilters of gewoon slim gebruik van visuele elementen zoals kleuren en fonts.

[bbob]

1 Bestand van enkele kb werkt voor een vector bestand, dat kan idd logo of iets anders zijn dat je dan onbeperkt kan vergroten.

En foto bestaat nu eenmaal uit pixels geen vectors en dus kun je dat niet onbeperkt vergroten. De 1024x768 foto met factor 4 vergroten betekend verlies aan informatie en onscherpte.

Ik kom heel vaak websites tegen die afbeeldingen niet comprimeren, 1 pagina is dan 2-3 mb terwijl het 1 tot 1.5 mb kan zijn. Je pagina is dus langzamer en zie daar dat maakt weer uit voor je google rankings.

[84hannes]

Ik kom heel vaak websites tegen die afbeeldingen niet comprimeren

Volgens mij ondersteunen browsers alleen gecomprimeerde formaten. Wellicht kan MSIE met BMP omgaan, maar die zijn al heel snel groter dan 3MB. De winst bij JPEG ligt eerder in de orde van 80% dan de 50% die jij suggereert.

edit:
Je maakt hieronder een vergelijking tussen verschillende niveaus van compressie, dat is een heel andere vergelijking dat tussen ongecomprimeerde bestanden en gecomprimeerde afbeeldingen

[Reactie gewijzigd door 84hannes op 23 juli 2024 13:36]

[bbob]

De winst van jpg ligt helemaal aan welke bestand je comprimeert. Ik heb het vaak over websites die wel al een compressie gebruiken maar niet maximaal. Dan kun je er wel stukken meer uithalen.

De maximale compressie werkt pas als je uitgaat van een niet gecomprimeerd origineel. Neem ik bijv een jpg met minimale of geen compressie als uitgangspunt, bijv 600kb, dan kan ik dit met riot (software programma) reduceren tot zeg 60k zonder zichtbaar verschil.
De winst is dan nog meer dan 80%.

Neem ik hetzelfde bestand maar al gecomprimeerd naar zeg 120kb dan kan ik dat verder comprimeren maar kom nooit tot deze 60kb omdat het origineel van 120kb al compressie had. Zonder zichtbaar verlies kom ik dan misschien tot 80-90kb.

[Caelorum]

Daar schiet je alleen totaal niet mee op als je ook daadwerkelijk foto's moet tonen. Een derde minder bestandsformaten kan makkelijk 40MB schelen op de sites waar ik aan werk

[totaalgeenhard]

Ruwe schatting is dat Google 2 miljoen servers heeft en ze gebruik(t)en mirror dus laten we aannemen 4 miljoen schijven in gebruik (op zijn minst).

Dan is 35% minder al snel 1.4 miljoen schijven minder. Het scheelt ze honderden miljoenen.

Bovendien zijn images vrij statische data.

Met betrekking tot snelheid van presenteren van data vanuit bezoeker gezien zal een milliseconde meer of minder niet veel uitmaken. Maar vanuit Google uit gezien is het 35% minder bandbreedte en tot 35% minder energie verbruik dus daarmee zullen ze ook miljoenen kunnen besparen.

Bovendien voor mobiele toepassingen heb je tot minder 35% geheugen/opslag nodig mbt images.

Als ze tot 35% reductie kunnen halen op dynamisch content (met name video) dan zullen ze miljarden besparen.

Text opslag is niet zo interessant, immers factor 100 verkleinen is al makkelijk haalbaar.

Bovendien minder data opslag = minder risico data corruptie & verlies.

Interessant artikel over hoe Google over harddisk denkt:
http://www.zdnet.com/arti...n-if-they-lose-more-data/

bronnen voor aannames:
http://www.artificialbrains.com/google/datacenters
https://en.wikipedia.org/wiki/Google_Data_Centers

[TWyk]

Dan is 35% minder al snel 1.4 miljoen schijven minder. Het scheelt ze honderden miljoenen.

Je vergeet de stap waarbij 98%-99% van die server opslag ruimte niet is gevuld met foto's maar met video en muziek of andere zooi.

[Jack Flushell]

Dat maakt niks uit in dit voorbeeld. Het gaat even om de besparing van deze methode... dat heeft met muziek en video helemaal niets te maken.

[TWyk]

Het maakt wel veel uit want hij rekent een besparing van 1,4 miljoen schijven uit maar als je bedenkt dat de meeste data op die shijven geen jpeg plaatjes zijn is de besparing slecht een miniscule fractie daarvan.

[Jogai]

Nou een site met foto-albums kan hier best van profiteren...

[3raser]

Een fotocamera waarschijnlijk ook. De meeste camera's produceren gewoon JPG afbeeldingen en met die hoge resoluties vandaag de dag worden dat als snel bestanden van ~2-3MB groot. Als je dat kan reduceren dan scheelt het opslag op je SD kaartje en als de foto's er ook nog een betere kwaliteit van krijgen lijkt het me een win-win situatie.

[bbob]

Het huidige algortime is super traag en realtime foto maken wegschrijven naar jpg op je camera zal niet gaan.

Je kan beter als raw opslaan, daarna kun je het beeld trouwens ook nog beter optimaliseren, witbalans, en andere parameters. Daarna kun je het lokaal als jpg opslaan en gebruiken.

Jaren terug maakte ik idd ook foto's en sloeg ze als jpg op. Doe je raw op je camera krijg je meer mogelijkheden om achteraf zaken te wijzigen. Je wil dan niet meer zonder raw.

[3raser]

Ik ben bekend met RAW maar 90% van de mensen zal dit nooit gebruiken. Henk en Ingrid hebben echt niet de kennis of de software om achteraf RAW bestanden te bewerken en naar JPG te converteren. Die willen gewoon direct plaatjes zien.

Wat betreft het trage algoritme, als camera's dit protocol gaan ondersteunen zullen ze ongetwijfeld de chips in de camera erop aanpassen zodat dit vlot genoeg zal werken.

[bbob]

Guetzli is denk ik ook niet bedoeld voor henk en ingrid.
Daarnaast werkt guetzli ook het beste en zelfs alleen met niet gecomprimeerde foto's en dat is dus tocvh meestal raw.

[Anoniem: 602501]

op de achtergrond in de camera zou toch ook een conversie kunnen plaatsvinden? als de camera idled, niet in foto modus zich bevind bijv.

[Xyfi]

Voor veel bedrijven die online diensten aanbieden is bandbreedte hun grootste kostenpost, zo ook bij mijn vorige werkgever.

Dus om nou te zeggen dat Google dit puur eigenbelang vind ik wat kort door de bocht.

[bbob]

Bandbreedte kost geld maar laten video's nu tig keer meer bandbreedte nodig hebben dan een foto.

Kleinere foto's is echter veel belangrijker voor iets anders. Je pagina zal kleiner worden, sneller laden en daardoor krijg je van google meer punten in de zoekmachine en kun je dus iets hoger komen. Optimalisatie van jpg beelden is en moet onderdeel zijn van je het seo verhaal.

[KoalaBear84]

Is ongeveer hetzelfde als MP3 werkt, de niet hoorbare frequenties weghalen. Zo zal dit ook werken, de niet met het oog zienbare details 'optimaliseren'. En zeker als het er beter uitziet als de huidige libjpeg, kan ik het alleen maar aanmoedigen.

[ro8in]

In dit geval gaat het om tonen weg halen die toch niet hoorbaar zijn. In dit geval heeft Google het volgens mij toch echt meer over zichtbare delen weg halen waar we waarschijnlijk toch niet naar kijken. Extreem voorbeeld een wolk in de achtergrond..

[KeesAlderlieste]

Dat doet MP3 voor audio toch net zo goed? Vinden we allemaal normaal.

[BarôZZa]

Een compressie welke dingen weg haalt waarvan verwacht wordt dat we er niet naar kijken. Vind dat toch wat tricky hoor..

Dat is dus wat al gebeurt bij praktisch alle jpg-bestanden op het internet. Dat heet lossy compression en zorgt voor bestanden die vele malen kleiner zijn dan met lossless compression mogelijk is.

Google wil gewoon meer compressie want een derde minder data scheelt hun al 100.000 harddisks. Heeft niks meer met snellere sites te maken. Een gemiddelde site zou er misschien 1 tiende van een seconde sneller op worden. Dat merk je als gebruiker echt totaal niet.

Afbeeldingen zijn voor veel websites verreweg het grootste deel van het verkeer. Als je dat met 35% kan verminderen, dan scheelt dat enorm. Zeker op mobiel. Overigens merk je het uiteraard meestal niet als een site .1s sneller is, maar als het .1s trager is, dan merk je dat wel.
Sommige developers (waaronder ik zelf) richten zich enorm op snelheid. .1s/100ms is enorm voor een pagina die zo snel mogelijk gerenderd moet worden.

[jj71]

Een compressie welke dingen weg haalt waarvan verwacht wordt dat we er niet naar kijken. Vind dat toch wat tricky hoor..

Daar is helemaal niets raars of nieuws aan, en dat is hoe JPEG altijd al heeft gewerkt, al sinds het is uitgevonden in de jaren '90. Lossy compression wordt heel veel toegepast, ook bij bijvoorbeeld video en geluid (MP3 en andere formaten).

[Atomsk]

Google is meer dan alleen maar opslag. Snelle websites zijn ook van belang voor hun zoekmachine. Krijgt iemand allemaal trage sites via een zoekresultaat dan haakt die persoon eerder af en hebben ze minder advertentie-inkomsten. Trage sites worden daarom gestraft door het page ranking algoritme van Google.

[sympa]

Het weghalen van dingen die je niet ziet is de hele gedachte achter lossy compression. Je ziet hetzelfde, maar het kost minder informatie

Dat begon al met analoge TV. Bij zwart-wit had je interlacing (hoge resolutie voor stilstaand beeld, lagere voor beweging). Bij kleur had de kleur een lagere resolutie (want dat zie je toch niet) dan de helderheid. En ga zo maar door.
Dt is dan een hele subtiele: comprimeer zo, dat de storende randjes en blokjes minder zichbaar zijn.

[koelpasta]

foutje., mod me down!

[Reactie gewijzigd door koelpasta op 23 juli 2024 13:36]

[dakathefox]

Google wil gewoon meer compressie want een derde minder data scheelt hun al 100.000 harddisks. Heeft niks meer met snellere sites te maken. Een gemiddelde site zou er misschien 1 tiende van een seconde sneller op worden. Dat merk je als gebruiker echt totaal niet.

Ik vind dit wel erg negatief over komen ten aanzien van Google. Iedereen heeft hier ontzettend belang bij: niet alleen een zoekmachine als Google, maar ook de eigenaar van een webshop of website. Ook jij als consument hebt er een belang bij, want die 1-tiende van een seconde mis je waarschijnlijk niet (vaak is het overigens wel meer dan dat), maar denk ook aan je databundel op je mobiel. Al die beetjes bij elkaar schelen weer.

[Defspace]

@ro8in Het hele idee achter jpeg is precies hetzelfde. Dingen weghalen waarvan verwacht wordt dat je het niet opmerkt. Hetzelfde geldt voor MP3, daarom zijn het ook lossy compressie formaten.
Oeps, deze tab stond al wat langer open, beetje dubbelop reactie.

[Reactie gewijzigd door Defspace op 23 juli 2024 13:36]

[MadEgg]

Natuurlijk gooien ze het op de ervaring van de gebruikers die sneller laden en minder data gebruiken maar dat is onzin natuurlijk. Als ze de gebruiker echt willen helpen op die fronten moeten ze geen nieuw afbeeldingsformaat maken maar iets doen aan hun advertenties, die slobberen pas data.

Het is, zoals het aftikel aanstipt, puur eigenbelang. Opslag en bandbreedte die ze kunnen besparen aan niet-advertentie-materiaal (en dus voor hun niet winstgevend), dat is belangrijk voor Google. Hun eigen kosten omlaag brengen, dat is het doel.

Op zich verder een leuke ontwikkeling natuurlijk. Maar het zal wel eerst gestandaardiseerd moeten worden en ondergebracht in een neutrale instelling (de referentie-implementatie dus) voordat ik het ga overwegen. Aan Google gelieerde software vertrouw ik niet. Voor hetzelfde geld verzamelt de encoder / decoder nog net even wat extra informatie over je.

[The Zep Man]

Natuurlijk gooien ze het op de ervaring van de gebruikers die sneller laden en minder data gebruiken maar dat is onzin natuurlijk. Als ze de gebruiker echt willen helpen op die fronten moeten ze geen nieuw afbeeldingsformaat maken maar iets doen aan hun advertenties, die slobberen pas data.

Niet alleen data. Denk ook aan het energieverbruik.

Een langdurige instantie van uBlock Origin die ik heb draaien blokkeert 18% van alle webverzoeken ooit gemaakt. Let op dat de 18% 'eerstelijns' webverzoeken zijn die ook weer andere content kan verzoeken. Je merkt dan ook een enorm snelheidsverschil bij surfen zonder en surfen met bescherming.

Het is jammer dat T.net niet het verschil tussen surfen zonder en met adblocker heeft getest in hun recente accuduur test. Ik denk dat een beter milieu in je browser begint.

[mae-t.net]

En een test met surfen met en zonder SSL. Google pusht SSL, maar ik heb een vaag vermoeden dat het ook nog wel wat stroom kost, dus dat je het alsnog neit moet willen gebruiken waar het niet nodig is.

[Reactie gewijzigd door mae-t.net op 23 juli 2024 13:36]

[batjes]

CPU overhead van SSL is vrij minimaal. Het ergste is de eerste initiele connectie naar een website/server. Tenzij je nonstop nieuwe verbindingen met nieuwe sessies opstart, zal het een niet meetbaar effect hebben.

[dakathefox]

Aan Google gelieerde software vertrouw ik niet. Voor hetzelfde geld verzamelt de encoder / decoder nog net even wat extra informatie over je.

Lekker aluhoedje. Gelukkig kun je zelf op zoek gaan naar de bevestiging van je stelling, want het is gewoon open-source. Zie ook: https://github.com/google/guetzli.

[dakathefox]

We hebben het hier wel over het bedrijf die "per ongeluk" overal wifi-communicatie had onderschept en opgeslagen he... Er is niets alu-hoedje aan, Google heeft keer op keer laten zien gewoon zoveel mogelijk data te verzamelen op alle mogelijke manieren.

Het staat je vrij om kritisch te zijn ten opzichte van Google. Wel ben ik erg benieuwd wat het risico is van het gecomprimeerd opslaan van een JPG. Bij het opslaan van de afbeelding zie ik namelijk geen risico's. Bij het openen van de afbeelding evenmin, aangezien het gewoon een JPG is waar je geen aparte encoder voor nodig hebt.

[Prysm Software]

Goede ontwikeling.
Volgens mij heeft het rechter plaatje zelfs iets minder verlies dan de linker.
Beter kwaliteit kleiner formaat. Goede zaak.

Typo aanpassing: verlies

[Reactie gewijzigd door Prysm Software op 23 juli 2024 13:36]

[Limbids]

Het linker plaatje is ongecomprimeerd, dus het rechter plaatje kan nooit minder compressie hebben

[BasZer]

hij bedoelt met linker natuurlijk het middelste plaatje (van de drie).

[MadEgg]

Dit plaatje is verre van representatief. Ik denk dat je dit plaatje nog beter als PNG kunt opslaan, lossless en bij dermate weinig variatie net zo klein.

Ik zeg niet dat Guetzli slecht is maar deze plaatjes zeggen gewoon helemaal niets erover.

[totaalgeenhard]

Het is dan ook indicatief.

Ze hadden betere 3 highresh foto's kunnen plaatsen zodat je zelf kunt inzoomen.

[Theo.H]

Hoe vrij mag deze gebruikt worden? Zijn er kosten aan verbonden voor bedrijven zoals Adobe of Corel als ze die lib van google gaan gebruiken?

[Mavamaarten]

Google will natuurlijk dat dit formaat ondersteund wordt door zo veel mogelijk browsers en apparaten. Geld vragen lijkt mij daarom ook echt onwaarschijnlijk

[Timo002]

Het is geen ander formaat, het is een andere manier van compressie. Dus dit zal gewoon op alle browsers werken!

[Mavamaarten]

Excuses, je hebt volledig gelijk. Ik was ervan overtuigd dat browsers deze nieuwe compressie moesten ondersteunen, maar na het bronartikel te hebben gelezen is inderdaad duidelijk dat het gewone jpeg-formaat gebruikt wordt en dit dus backwards compatible is.

[Anoniem: 602501]

echt?
denk dat elke browser nog wel moet begrijpen hoe ze die google compressed jpeg weer kunnen uncompressen

of blijft het gewoon jpeg en is alleen de pixeldata weghalen/veranderen anders

[Reactie gewijzigd door Anoniem: 602501 op 23 juli 2024 13:36]

[Neko Koneko]

Het comprimeren van JPEG gebeurt volgens een algoritme, Google heeft een beter algoritme gevonden om dezelfde compressie beter te maken.

[dakathefox]

of blijft het gewoon jpeg en is alleen de pixeldata weghalen/veranderen anders

Het blijft gewoon een JPEG, alleen de manier waarop de JPEG tot stand is gekomen is dus anders .

[RVervuurt]

Ik hoop eigenlijk dat Facebook deze techniek toe gaat passen, want als je een beetje mooie foto's op Facebook uploadt, worden ze totaal verkracht door de compressie daar.

[MajorMuff]

Je kan bij je opties echter wel 'upload high quality images' of iets in die strekking aanvinken. Dat verbetert het al iets, al laat het inderdaad te wensen over.

[RVervuurt]

De enige foto's die ik upload naar Facebook, zijn via Instagram en daar upload ik voornamelijk mooie foto's of bordspellen, geen stomme selfies in een bar ofzo.

Het is gewoon heel jammer dat de compressie die Facebook toepast, de foto's zodanig aanpast dat mooi kleurverloop verpest wordt, details verdwijnen en meer van dat soort ongein.

[MajorMuff]

Helemaal mee eens, al kan ik ergens ook wel begrijpen dat FB dusdanig veel foto's/afbeeldingen moet verwerken en opslaan dat enige compressie wel noodzakelijk is.

[Anjerlaan]

De groene reflectie in de pupil is weggevallen bij Guetzli

[litebyte]

Idd ....Maar als je dat niet weet als bezoeker
Een soort van 'fastfood' compressie.

[Myliobatis]

Google had al een tijd onbeperkte opslag van afbeeldingen, als je hun compressie gebruikte.
Lijkt me dat dit dan het resultaat is?

[dakathefox]

Ik ben geneigd om JA te zeggen. Het zou niet de eerste keer zijn dat Google een dergelijk voor zichzelf ontwikkelde oplossing publiekelijk beschikbaar zal stellen.

[TWyk]

Is dit formaat beter/efficienter dan jpeg XR dat ook hoge compressie ondersteunt maar ook lossless compressie.

[MSalters]

't Is anders. Directe vergelijkingen liggen niet voor de hand.

OVerigens is het geen ander formaat, het blijft JPEG. Dat in tegenstelling tot JPEG-XR, wat alleen maar in naam JPEG is. Elke browser ondersteunt JPEG, ook als de compressie door Google's nieuwe algoritme is gedaan.

[TWyk]

Dan nog zou het beter zijn als browsermakers zich zouden focussen op het ondersteunen van een duidelijk beter foto opslag formaat dan priegelen aan het bestaande formaat

Als de 4 grote browsermakers zouden afspreken om een efficienter foto formaat te gebruiken dan volgen de sites vanzelf wel
Die sites kunnen dan namelijk makkelijk traffic besparen door hun foto's te verkleinen.

[Reactie gewijzigd door TWyk op 23 juli 2024 13:36]