LeanImg

Cum pot redimensiona un JPG la sub 100 KB?

Scara de calitate măsurată pentru o fotografie de 538,6 KB, de ce sliderul se blochează la 131 KB și de ce tăierea pixelilor este levierul care atinge cu adevărat un buget de byte.

· Updated

Un formular de încărcare spune 100 KB maxim. Fotografia ta are 538,6 KB. Reflexul este să iei sliderul de calitate și să-l tragi la stânga, iar pentru o fotografie mare, acel reflex nu te va duce acolo. Am luat un fișier și am parcurs toată scara: texture.jpg la 3840x2160, 538,6 KB pe disc. Chiar și la calitatea 30 ajunge la 131 KB, iar imaginea este vizibil distrusă până atunci.

Numărul care controlează de fapt dimensiunea JPEG este numărul de pixeli. Baseline JPEG codifică imaginea în blocuri de 8x8, așa că împărțirea ambelor dimensiuni lasă un sfert din blocuri pentru stocare. Dacă ai doar sliderul, te vei bloca în jurul valorii de 131 KB pentru un fișier de această dimensiune. Fiecare cifră de mai jos a ieșit din propriul nostru compresor și redimensionator, rulând într-o filă de browser. Nu există un pas de încărcare pe care să aștepți.

De ce sliderul de calitate nu mă duce la 100 KB?

Iată scara, același fișier sursă de fiecare dată, rulat în compresorul de imagini în modul manual. Modul inteligent alege fiecare setare implicită a encoderului, care este 80 pentru JPEG și WebP, 63 pentru AVIF și fără pierderi pentru PNG.

texture.jpg, 3840x2160, 538,6 KB sursă, ieșire JPEG prin MozJPEG.
SetareIeșireSchimbare
Slider 90347,8 KB-35%
Inteligent (slider 80)286,1 KB-47%
Slider 60212,4 KB-61%
Slider 30131 KB-76%

Șaizeci de puncte de slider au adus 216,8 KB. Ultima porțiune, de la 60 la 30, a sacrificat multe detalii vizibile pentru 81,4 KB. O fotografie de 3840x2160 are 8,3 milioane de pixeli de descris, iar există un minim sub care câțiva bytes nu pot descrie aceștia la această dimensiune. Minim este real.

Cardul rezultatului compresorului arătând texture.jpg redus de la 538,6 KB la 131 KB la calitatea 30
Fundul scării: 131 KB, o reducere de 76%, și totuși 31 KB peste limita de 100 KB.

De ce calitatea 30 nu este de fapt 30?

Acesta îi încurcă pe oameni, iar este responsabilitatea noastră să explicăm. Când sursa este un JPEG, compresorul nostru citește tabelele de cuantizare din primele 64 KB ale fișierului și estimează calitatea la care a fost salvat. Sliderul tău apoi scalează acea estimare. O fotografie salvată la calitatea 60, cu sliderul la 80, codifică la 48. Redimensionarea oprește o a doua trecere de a pretinde o calitate pe care pixelii nu o pot livra, deoarece re-codificarea unui fișier de calitate 60 la 90 doar cheltuie bytes descriind daunele care sunt deja integrate. Encoderul de dedesubt este MozJPEG. Un alt lucru demn de știut: comprimarea elimină fiecare bucată de metadate, EXIF, GPS, profil ICC și miniatură încorporată. Orientarea supraviețuiește.

De ce estimarea de lângă slider nu se potrivește cu rezultatul?

Pentru că este o curbă, nu o codificare. Panoul afișează acel număr înainte ca ceva să ruleze, din două lucruri doar: dimensiunea fișierului tău și poziția sliderului. Este bytes originale înmulțite cu sliderul împărțit la 100, ridicat la puterea de 1,8. Nu vede niciun pixel din imaginea ta și nu știe despre redimensionarea de mai sus, așa că în exemplul de calitate 60 afișează o cifră pentru 80 în timp ce encoderul este pe cale să folosească 48.

Pe același fișier de test de 538,6 KB, diferența este mare și își schimbă direcția pe parcurs. La slider 90, panoul a prezis 445,5 KB față de un real 347,8 KB, 28% prea mult. La slider 30, a prezis 61,7 KB față de un real 131 KB, 53% prea puțin. Citește din nou acel al doilea dacă vizezi o limită de 100 KB: estimarea spune că ai depășit-o cu 38 KB în momentul în care encoderul este pe cale să o rateze cu 31. KB de pe cardul rezultat este singurul număr pe care merită să acționezi. În modul PNG din paletă nu există nicio estimare, iar panoul afișează un avertisment în locul ei.

Cum pot obține de fapt un JPG sub 100 KB?

Tăiați pixelii mai întâi, apoi comprimați. Deschideți redimensionatorul și folosiți presetările procentuale, care sunt 25, 50 și 75. Cincizeci la sută reduce 3840x2160 la 1920x1080, un sfert din pixeli. Douăzeci și cinci la sută îl reduce la 960x540, o șaisprezecime. Există, de asemenea, 15 presetări sociale la dimensiuni fixe, de la un pătrat Instagram de 1080x1080 la un banner YouTube de 2560x1440, plus un mod de pixeli-exacti cu moduri de acoperire, conținere și întindere. Acest mod de pixeli-exacti este cum un pătrat de pașaport de 600 x 600 este introdus fără a strivi o față. Dacă vizezi 100 KB dintr-o fotografie 4K, începe de la 25% și lucrează în sus.

Două lucruri despre redimensionator merită să știi mai întâi. Ieșirea PNG rămâne fără pierderi, iar fiecare alt format este re-codificat la calitatea 90 în mod implicit, astfel încât un JPEG care trece prin ambele instrumente este codificat de două ori. Sursele animate ies ca un cadru static. Și când ieșirea compresorului ar fi mai mare decât fișierul pe care l-ai alimentat, îți returnează originalul neatins.

Ar obține WebP sau AVIF mai repede?

Același fișier texture.jpg, 538,6 KB, trei encodere la poziții de slider corespunzătoare.
EncoderSlider 80Slider 63
JPEG286,1 KBnu a fost măsurat
WebP290,3 KB200,6 KB
AVIF312,7 KB186,9 KB

Citește acea tabelă de două ori. La aceeași poziție a sliderului de 80, JPEG a produs cel mai mic fișier și AVIF cel mai mare, ceea ce pare invers până îți amintești redimensionarea de mai sus. 80 al JPEG-ului a fost scalat în raport cu calitatea estimată a sursei, așa că nu a fost de fapt 80, în timp ce WebP și AVIF iau numărul literal. Scade-le la valoarea implicită inteligentă de 63 a AVIF și codec-urile moderne avansează: 200,6 KB pentru WebP, 186,9 KB pentru AVIF. Ambele sunt încă departe de 100 KB la 3840x2160, ceea ce este întregul punct. AVIF a costat, de asemenea, aproximativ 10 până la 11 secunde pe codificare pe această mașină, în timp ce JPEG și WebP au revenit instantaneu, iar suportul browserului este mai tânăr. Calea noastră JPG la WebP este blocată la 4:2:0 chroma, așa că marginile roșii dure se estompează puțin.

Ce se întâmplă dacă fișierul meu este un PNG cu transparență?

Un levier complet diferit. Am rulat alpha.png, 900x606 și 942,4 KB cu un canal alfa real, prin ambele moduri PNG. Opțiunea "Fără compresie" este oxipng la nivelul 3, complet fără pierderi, și a returnat 383,9 KB, o reducere de 59% cu fiecare pixel intact. Opțiunea "Dimensiune fișier mai mică" rulează libimagequant, care reduce imaginea la o paletă, și a returnat 98,3 KB. Asta este 90% reducere și depășește un buget de 100 KB fără a atinge dimensiunile. Paletele bandăază degradele netede, așa că verifică un cer sau o umbră moale înainte de a-l trimite. Transparența supraviețuiește în ambele moduri. Cere ieșire JPEG și canalul alfa dispare, fiind mat pe alb.

Pot să tai pentru a ajunge la 100 KB?

Parțial. Tăierea elimină pixeli, așa că elimină bytes. Cutterul nostru ia un fișier pe rând de până la 10 MB și oferă opt presetări de aspect plus un raport personalizat W:H. Nu există un câmp pentru a introduce o lățime țintă în pixeli, așa că nu poți viza o dimensiune exactă a ieșirii, iar fiecare tăiere a unui format cu pierderi este re-codificată la o calitate fixă de 92. Un GIF revine ca un PNG cu un singur cadru. Pentru a atinge un buget de byte, presetările procentuale ale redimensionatorului îți oferă un control mai direct.

Asta înseamnă că încarcă fotografia mea?

Nu. Această aplicație nu are rute API și nu are acțiuni pe server, iar singurele cereri de rețea pe care le face sunt fetch-uri de aceeași origine pentru activele sale și codec-urile WASM. Fișierul tău este decodat pe un canvas și re-codificat din nou de WASM în aceeași filă. Cele mai multe alte instrumente din această categorie funcționează invers: imaginea ta călătorește la serverul lor și stă în stocarea lor până când un temporizator de retenție se activează. Aceasta este diferența pe care o explică pagina noastră de confidențialitate. De asemenea, este motivul pentru care un lot aici este limitat la 10 fișiere și 50 MB, deoarece propriul tău CPU face munca. Această limitare este motivul pentru care o folder cu 300 de fișiere în el nu este o sarcină pentru browser.