Afbeeldingscompressor

Er wordt niets geüpload, en dat is te bewijzen

Elk ander resultaat voor "afbeelding comprimeren online" stuurt je bestand naar een server, en daarom hebben die tools een groottelimiet, een wachtrij en een privacyverklaring die je niet gelezen hebt. Deze decodeert en hercodeert in je browser met dezelfde codecs die de browser al gebruikt om afbeeldingen te tonen. Open het netwerktabblad, comprimeer een foto, en kijk hoe het aantal verzoeken blijft staan. Er is geen groottelimiet omdat er geen upload is om te begrenzen.

Het werk draait in een Web Worker met OffscreenCanvas, weg van de thread die de pagina tekent. Dat is geen detail: een JPEG van 20 megapixel decoderen en hercoderen is een paar honderd milliseconde volle CPU, en op de hoofdthread is dat een bevroren tabblad met een spinner die stil is gaan staan.

Van formaat wisselen wint meestal van kwaliteit bijstellen

De vergelijkingsregel onder elk bestand is gemeten en niet geschat: elk alternatief formaat wordt echt op dezelfde kwaliteit gecodeerd, dus de getallen zijn de echte. WebP komt bij gelijke zichtbare kwaliteit meestal 25 tot 35% onder JPEG uit, en AVIF nog eens 20% onder WebP, en dat is een grotere besparing dan welke kwaliteitsschuif ook geeft zonder zichtbare schade.

Het addertje is de ondersteuning, en die is het waard om precies te benoemen. WebP werkt overal waar iets actueel is. AVIF decodeert overal waar iets actueel is, maar het coderen vanaf een canvas bestaat niet in elke browser, dus deze pagina peilt dat door één pixel te coderen en het type terug te lezen. Ontbreekt AVIF in de lijst, dan is dat de reden. Een canvas dat om een formaat gevraagd wordt dat het niet kan schrijven geeft geen foutmelding: het levert stilletjes een PNG, en een tool die zijn eigen verzoek vertrouwt geeft je een bestand dat drie keer zo groot is als waar je mee begon.

Hercoderen vernietigt altijd de metadata

Er is hier geen schakelaar "EXIF behouden" omdat er geen eerlijke kon zijn. De pijplijn decodeert het bestand naar pixels en codeert die pixels opnieuw; EXIF, IPTC, XMP, het kleurprofiel en de GPS-coördinaten wonen in de verpakking om de pixels heen en overleven de reis niet. Voor de meeste toepassingen is dat de juiste standaard en een verbetering voor de privacy: een vakantiefoto die rechtstreeks vanaf een telefoon geplaatst wordt draagt de exacte coördinaten van waar hij genomen is. Wil je zien wat een bestand meedraagt voordat het weggaat, dan leest de EXIF-viewer dat zonder er iets aan te veranderen.

Het kleurprofiel is het deel dat af en toe bijt. Een foto met het label Display P3 komt hier zonder label uit, wat browsers vervolgens als sRGB lezen, en een verzadigd rood kan zichtbaar verschuiven. Comprimeer je fotografie met een breed gamut voor drukwerk, dan is dit niet de tool.

Veelvoorkomende problemen

• Het bestand werd groter. Meestal een PNG-schermafbeelding: PNG is verliesvrij en al efficiënt voor vlakke kleur, en het opnieuw als PNG coderen kan niet winnen van wat een optimalisatie al deed. Zet het in plaats daarvan om naar WebP, waar een schermafbeelding vaak 60% zakt.
• Een HEIC van een iPhone gaat niet open. Alleen Safari kan HEIC decoderen, dus daarbuiten faalt het bestand hier in plaats van te doen alsof. De camera van de telefoon op "Meest compatibel" zetten levert JPEG.
• Een transparante PNG kwam er met een witte achtergrond uit. JPEG heeft geen alfakanaal, dus de transparantie moet iets worden. Hier wordt dat wit in plaats van het zwart waar de meeste canvaspijplijnen standaard op uitkomen. Kies WebP of PNG om het te behouden.
• Een bewegende GIF werd een stilstaand beeld. Een canvas decodeert één frame. Een animatie door deze pagina halen houdt het eerste frame over en verder niets.

Veelgestelde vragen

Welke kwaliteit moet ik gebruiken?

75 voor foto's op het web, en daar zitten JPEG en WebP op de curve net voordat artefacten zichtbaar worden op normale weergavegrootte. Onder 60 zie je de blokjes rond contrastrijke randen. Boven 90 groeit het bestand snel voor een verschil dat niemand op een scherm ziet. Kwaliteit doet helemaal niets voor PNG, dat verliesvrij is, dus de schuif is daar inactief.

Is er een limiet aan de bestandsgrootte?

Geen uploadlimiet, want er is geen upload. De echte grens is het geheugen van je apparaat: een gedecodeerde afbeelding neemt breedte × hoogte × 4 bytes in, hoe klein het bestand ook was, dus een foto van 50 megapixel is 200 MB RAM voordat er iets gecodeerd is. Dertig bestanden tegelijk is daarom de bovengrens van een batch.

Waarom is de ZIP niet gecomprimeerd?

Omdat het zinloos zou zijn. Elk bestand erin is een al gecomprimeerde afbeelding, en een JPEG deflaten scheelt een fractie van een procent voor een volle ronde over de bytes. Het archief wordt in store-modus geschreven, en dat is een geldige ZIP die elk besturingssysteem gewoon opent.

Wordt het kleiner als ik twee keer comprimeer?

Kleiner, en slechter. Verliesgevend hercoderen werkt in generaties: elke ronde kwantiseert de artefacten van de vorige ronde samen met het beeld. Comprimeer altijd vanaf het origineel, nooit vanaf een uitvoer.