Bij het exporteren van afbeeldingen: gebruik je die JPEG-kwaliteitsschuif altijd als een percentage? Je sleept hem naar 80 en denkt: “ik heb tachtig procent van de beeldkwaliteit behouden”; je zet hem op 100 en denkt: “nu is er niets verloren.”
Dat idee moet volledig op de schop: het getal op de schuif heeft niets te maken met “hoeveel procent beeldkwaliteit”, en kwaliteit 100 is ook niet verliesvrij. Eerst de conclusies die je direct kunt gebruiken: wil je foto’s met een gerust hart opslaan, gebruik dan 85–92; voor web en social media is 75–82 genoeg; zet 100 niet als standaard, het maakt bestanden alleen maar twee tot vier keer zo groot, zonder dat de beeldkwaliteit erop vooruitgaat. Hieronder leg ik in gewone taal uit hoe die schuif in elkaar zit.
In één zin: de JPEG-kwaliteitsschuif bepaalt niet “hoeveel beeldkwaliteit behouden blijft”, maar hoe agressief de delers in de kwantisatietabel zijn — hoe groter de deler, hoe harder er wordt afgerond, hoe meer er verloren gaat. Hij heeft geen lineaire relatie met beeldkwaliteit of bestandsgrootte; de verandering van 100 naar 90 is niet gelijk aan die van 20 naar 10.
Eerst één uitgangspunt: JPEG is een lossy formaat; vanaf het moment dat je op opslaan drukt, gaat er informatie verloren. De schuif bepaalt alleen “hoeveel verlies”, niet “of er verlies is”. Het verlies volgt een vast proces, en de schuif is de laatste sluis in die productielijn.
Bij het opslaan wordt de afbeelding eerst van RGB naar YCbCr omgezet, waarbij helderheid en kleur in twee kanalen worden gesplitst. Dat gebeurt omdat het menselijk oog veel gevoeliger is voor helderheidsverschillen dan voor kleurverschillen; door ze eerst te scheiden, kun je later de helderheid beter beschermen.
Daarna wordt de hele afbeelding in blokjes van 8×8 pixels verdeeld, en op elk blok wordt een discrete cosinustransformatie (DCT) toegepast, die pixelkleuren omzet in een reeks frequentiewaarden. Je kunt het vergelijken met een akkoord opsplitsen in afzonderlijke noten: laagfrequente componenten zijn de ondergrond en gradiënten van het beeld, hoogfrequente componenten zijn scherpe randen en fijne texturen. Het volledige proces staat uitgebreid beschreven op de Wikipedia-pagina over JPEG.
De echte genadeslag komt in de laatste stap: elke frequentiewaarde wordt gedeeld door een getal uit de kwantisatietabel (Quantization Table) en daarna afgerond op een heel getal. Afronden is de plek waar informatie permanent sterft — alles wat bij de deling niet opgaat — de rest — wordt weggegooid en komt nooit meer terug. Wat de kwaliteitsschuif regelt, is hoe agressief die delers zijn: een hoge waarde op de schuif betekent kleine delers, waardoor afronden bijna geen data beschadigt; een lage waarde betekent grote delers, waardoor afronden details wegvaagt. De delers voor hoogfrequente componenten groeien sneller, dus randen en fijne texturen sneuvelen altijd als eerste.
Daarom kan het geen percentage zijn. Van 100 naar 90 en van 20 naar 10 zijn de veranderingen in delers totaal verschillend, en de sprong in beeldkwaliteit en bestandsgrootte ook. In de buurt van 90 merk je één stapje op de schuif misschien niet; in de buurt van 20 is één stapje genoeg om de afbeelding te verpesten. Dit als percentage zien is de meest voorkomende en duurste misvatting over deze instelling.
Eerst het antwoord: voordat je bij 100 van verliesvrij kunt spreken, zijn er nog twee fundamentele tekortkomingen: het ene trekt zich niets van de schuif aan, het andere is zelfs met de schuif niet te verhelpen.
Het eerste is chroma subsampling. Nadat RGB naar YCbCr is omgezet en voordat de compressie echt begint, gooien de meeste encoders al ongeveer 75% van de kleurdetails weg, opnieuw omdat het menselijk oog veel minder gevoelig is voor kleur en het verlies daardoor niet opmerkt. Deze stap valt helemaal niet onder de schuif; hij wordt ook uitgevoerd als je 100 instelt.
Het tweede is dat de wiskunde zelf niet helemaal zuiver is. Zelfs als de delers in de kwantisatietabel zo klein mogelijk zijn, blijven er bij “pixels naar frequenties en frequenties weer naar pixels” kleine afrondingsfouten bestaan. Als je het opgeslagen bestand weer opent, zijn het niet meer dezelfde pixels als toen je op opslaan drukte.
Wil je echt geen bit verliezen, neem dan een verliesvrije route: PNG, TIFF of WebP in verliesvrije modus. Lossy is een eenrichtingsweg; elke instelling van JPEG is dat, ook die ogenschijnlijk “perfecte” 100.
Uit veel praktijktests en pixelvergelijkingen komt steeds een heel duidelijke grens naar voren: twee bereiken dekken bijna alle scenario’s.
85–92 is het bewaarniveau. Portfolio’s, werk dat naar klanten gaat, originelen die je liever niet (opnieuw) laat comprimeren: zet die hier. Een bestand dat met kwaliteit 90 is opgeslagen, is ongeveer 1/8 tot 1/12 van het ongecomprimeerde bestand, terwijl het verschil met het blote oog niet te zien is — je moet al naar 400% inzoomen en op een klein stukje staren om een verandering te vinden.
75–82 is het webniveau. Afbeeldingen voor websites, uploads naar social media: zet die hier. Bestanden zijn nog eens 40%–60% kleiner dan op het bewaarniveau; de prijs is vooral dat complexe texturen licht zachter worden, wat bij normaal kijken nauwelijks opvalt.
Als je het eerdere artikel “Met en zonder kwaliteitsverlies” hebt gelezen, dan spreken de sweet spot van 80–85 en deze twee niveaus elkaar niet tegen: rond 80 zit je al op het webniveau, en 85 valt precies op het bewaarniveau. Afbeeldingen die je al met 80–85 hebt opgeslagen, hoef je niet opnieuw te comprimeren.
De drie niveaus in één zin: dingen die je wilt bewaren zet je op 85–92, dingen die je de deur uit doet op 75–82, en onder 60 is het een mijnenveld — blijf er weg.
De exportstandaard op 100 zetten is angst, geen strategie. Een bestand met kwaliteit 85 is 60%–75% kleiner dan met kwaliteit 100, terwijl je geen enkel verschil in beeldkwaliteit ziet; voor het web betekent het simpelweg dat de laadtijd onnodig wordt opgerekt — die rekening van websiteafbeeldingen heb ik in het artikel over het versnellen van webafbeeldingen uitgebreid doorgerekend.
Zodra de schuif onder 60 komt, valt de beeldkwaliteit niet langzaam af, maar stort hij van een klif.
De oorzaak is nog steeds afronden. Bij te lage waarden worden de delers voor hoogfrequente componenten absurd groot; een frequentiewaarde wordt na deling en afronding gewoon nul — dat detail is dan niet opgeslagen. Zo verdwijnen hele categorieën visuele informatie in bulk: haren, weefselstructuren van stof, de uiteinden van de streken van schreefletters — dat zijn de eerste dingen die sneuvelen.
Wat overblijft, zijn de standaard JPEG-artefacten: 8×8-blokvorming, kleurbanden in gradiënten, ringing-artefacten (golvende randjes naast scherpe randen) en mosquito noise. De grove vormen zijn er nog, maar dit is geen afbeelding meer die bedoeld is om naar te kijken. Over hoe elk type artefact ontstaat, heb ik een aparte geïllustreerde uitleg geschreven.
Daarom is mijn conclusie: 60 is de praktische ondergrens voor normale afbeeldingen. De paar KB die je daaronder nog bespaart, leveren iets op dat er in één oogopslag nep uitziet; dat is het niet waard.
“Kwaliteit 90” is geen universele valuta. De JPEG-specificatie geeft een reeks aanbevolen kwantisatietabellen (Annex K), maar welke tabel elk programma gebruikt en hoe die wordt geschaald, bepaalt elke softwareontwikkelaar zelf. Voor hetzelfde “hoge kwaliteit” zien de getallen bij vier veelvoorkomende tools er totaal anders uit: Photoshop gebruikt een schaal van 0–12, waarbij zijn 10 ongeveer overeenkomt met 90 in de referentie-implementatie libjpeg; GIMP en ImageMagick gebruiken beide een schaal van 1–100, waarbij GIMP bij “hoge kwaliteit” 85 gebruikt en ImageMagick 92; libjpeg gebruikt als referentie-implementatie zelf 90.
Zelfs als je in twee tools “kwaliteit 85” instelt, zijn de geëxporteerde bestanden niet hetzelfde. Onthoud dus niet één getal in één programma en neem dat niet klakkeloos over in een ander. Voor vergelijkingen tussen programma’s en tussen projecten zijn er maar twee betrouwbare manieren: kijk naar de werkelijke bestandsgrootte en naar het werkelijke beeldresultaat.
De schuif is niet betrouwbaar, en het blote oog wordt beïnvloed door scherm en toestand. Kun je “geen verschil zien” dan nog kwantificeren? Ja, en een veel betrouwbaardere aanpak is een andere maatstaf gebruiken: de structurele gelijkenisindex (SSIM, Structural Similarity Index Measure).
Hij vergelijkt niet pixel voor pixel, maar kijkt hoeveel structuur, helderheid en contrast zijn veranderd; dat ligt dichter bij hoe het menselijk oog afbeeldingen beoordeelt dan “tel hoeveel pixels verschillen”. De score loopt van 0 tot 1, waarbij 1 betekent dat twee afbeeldingen volledig identiek zijn. De formule en achtergrond staan duidelijk op de Wikipedia-pagina over SSIM.
Voor de gebruikelijke kwaliteitsniveaus ziet SSIM er ongeveer zo uit: een bestand met kwaliteit 85 haalt meestal een score boven 0,97 en is visueel niet te onderscheiden van het origineel; bij 60 zakt de score naar 0,90–0,93, licht zachter, alleen zichtbaar bij inzoomen; bij 40 blijft er nog maar 0,82–0,87 over, en zijn artefacten met het blote oog zichtbaar.
Deze cijfers zijn veel eerlijker dan de schuif. Als je kwaliteit niet op goed geluk wilt bepalen, kun je met het commando compare van ImageMagick direct de SSIM van twee afbeeldingen berekenen en het punt vinden waar “de bestandsgrootte maximaal is verkleind zonder onder de perceptiegrens van 0,85 te zakken”. Over het gebruik van deze maatstaf heb ik een aparte diepgaande uitleg over SSIM geschreven.
Het kleine gereedschap hieronder werkt volledig in je browser – afbeeldingen worden nooit geüpload. Kies een afbeelding (of klik op “Proefafbeelding gebruiken”), sleep de schuif en kijk hoe de gecomprimeerde grootte en de SSIM veranderen; je kunt ook automatisch de instelling met de kleinste bestandsgrootte bij SSIM ≥ 0,85 zoeken. De SSIM-waarde wordt realtime berekend op de zojuist gecomprimeerde afbeelding – precies de maatstaf uit de vorige sectie.
Let op: de ingebouwde JPEG-encoders van browsers leggen chroma subsampling en kwantisatietabellen niet bloot. Daarom laat dit gereedschap het echte effect van de schuif zien en kwantificeert het het verschil met SSIM, in plaats van de binnenkant van de encoder aanpasbaar te maken – en het bevestigt precies wat dit artikel zegt: kwaliteit 100 is niet verliesvrij, en hetzelfde getal betekent niet hetzelfde in verschillende programma’s.
In de overgrote meerderheid van de gevallen is rond 80 genoeg; 100 zou niet de standaard moeten zijn. Een bestand met kwaliteit 85 is 60%–75% kleiner dan met kwaliteit 100, terwijl het blote oog geen verschil ziet; voor foto’s die je wilt bewaren kun je 85–92 gebruiken, voor web en social media is 75–82 genoeg, en onder 60 ontstaan duidelijke artefacten.
Nee. Zelfs bij 100 gooit JPEG meestal eerst via chroma subsampling ongeveer 75% van de kleurdetails weg, en daarna zorgen kwantisatie en afronding voor onomkeerbaar verlies. Wil je verliesvrij, gebruik dan PNG, TIFF of verliesvrije WebP.
Photoshop gebruikt voor JPEG-kwaliteit een schaal van 0–12, niet 1–100; zijn 10 komt ongeveer overeen met 90 in de referentie-implementatie libjpeg. Elk programma geeft hetzelfde getal een andere betekenis, dus neem getallen niet klakkeloos over tussen programma’s; kijk naar de werkelijke bestandsgrootte en het werkelijke beeldresultaat.
Inzoomen en met het origineel vergelijken is het meest direct; voor een objectieve maatstaf gebruik je SSIM. Een JPEG met kwaliteit 85 heeft meestal een SSIM boven 0,97 en is visueel niet te onderscheiden van het origineel; rond 40 zakt die naar 0,82–0,87, en zijn artefacten met het blote oog zichtbaar. Het compare-commando van ImageMagick kan deze score direct berekenen.
Dat getal op de schuif is een delingsparameter — geen percentage voor beeldkwaliteit; 100 is niet verliesvrij, en onder 60 is het een klif. Als je één ezelsbruggetje wilt: sla foto’s op met 85, sla spullen voor het web op met 80, en gebruik 100 nergens — het bestand wordt twee tot vier keer zo groot, terwijl de beeldkwaliteit er geen greintje op vooruitgaat.
Wil je van het kiezen van een formaat en het aanpassen van afmetingen soepel doorgaan naar kwaliteitsinstelling en het versnellen van webpagina’s, lees dan de complete gids voor beeldcompressie; de hele keten staat in dat artikel.