Salt la conținut

Cum funcționează oCompress

Ce se întâmplă când plasați un fișier, cum puteți verifica faptul că nu se încarcă nimic și ce înseamnă de fapt compresia fără pierderi și cea cu pierderi.

Pe scurt

Când deschideți pagina unui instrument, browserul descarcă pagina și un mic program, compresorul. Când adăugați un fișier, browserul îl citește, compresorul îl procesează pe propriul procesor, iar rezultatul vă este dat înapoi ca descărcare. Fișierul nu este trimis prin rețea în niciun moment. Întregul proces arată așa:

  1. Încărcarea. Mai întâi se încarcă pagina și interfața instrumentului. Motorul pentru un tip de fișier (imagini, video și audio sau documente) este descărcat doar când adăugați un fișier potrivit, așa că nu descărcați niciodată cod pe care nu îl folosiți.
  2. Citirea. Browserul îi dă paginii acces exact la fișierele pe care le-ați ales, la nimic altceva de pe dispozitiv.
  3. Compresia. Lucrul rulează într-un Web Worker, un fir de execuție de fundal al browserului, așa că pagina rămâne receptivă și puteți anula oricând.
  4. Salvarea. Fișierul comprimat este creat în memorie (videoclipurile mari, în spațiul de stocare privat al browserului) și salvat prin descărcarea obișnuită a browserului, pe rând sau ca arhivă ZIP.

Ce rulează în browser

Browserele moderne pot rula cod compilat la o viteză apropiată de cea nativă prin WebAssembly și le oferă paginilor web acces la encoderele video hardware ale dispozitivului printr-o interfață numită WebCodecs. oCompress le folosește pe amândouă:

  • Imagini: MozJPEG pentru JPEG, OxiPNG și un cuantizator de paletă pentru PNG, encoderul WebP din libwebp de la Google, libavif pentru AVIF, SVGO pentru SVG și decodoare și encodere dedicate pentru GIF și TIFF. Codecurile JPEG, PNG, WebP și AVIF sunt compilate în WebAssembly.
  • Video și audio: WebCodecs, cu biblioteca Mediabunny pentru citirea și scrierea containerelor precum MP4 și WebM. Codificarea folosește encoderul hardware al plăcii grafice, acolo unde există, motiv pentru care poate fi rapidă chiar și într-un browser. Fișierele MP3 sunt scrise de encoderul LAME, iar fișierele FLAC de libFLAC, ambele compilate în WebAssembly și încărcate doar când este nevoie.
  • Documente: codul nostru, construit pe biblioteci open-source pentru PDF și ZIP, deschide PDF-urile și fișierele Office, recomprimă imaginile din interior cu codecurile de imagine și scrie un fișier nou.

Fiecare bibliotecă pe care o livrăm este open-source: majoritatea sub licențe permisive precum MIT, BSD și Apache 2.0, Mediabunny sub MPL 2.0, iar encoderul MP3 LAME sub LGPL, ca fișier separat, înlocuibil. Vedeți lista bibliotecilor, cu versiuni și licențe.

Cum puteți verifica că nu se încarcă nimic

Nu trebuie să ne credeți pe cuvânt. Două teste simple:

  • Treceți offline. Deschideți pagina unui instrument, comprimați un fișier ca să se încarce motorul, apoi opriți Wi-Fi-ul sau datele mobile și comprimați alt fișier de același tip. Funcționează, pentru că nimic nu are nevoie de rețea.
  • Urmăriți rețeaua. În Chrome, Edge sau Firefox, apăsați F12, deschideți fila Network (Rețea) și comprimați un fișier. Veți vedea codul compresorului încărcându-se de pe site-ul nostru și cereri de la serviciile de analiză și de reclame, dar nicio cerere care să conțină fișierul. O fotografie de 10 MB ar apărea ca o încărcare de 10 MB; nu există așa ceva.

Pagina trimite către Google Analytics evenimente anonime de utilizare, de tipul „a fost comprimat un JPG de câțiva megaocteți”. Aceste evenimente conțin instrumentul, tipul fișierului și, ca intervale aproximative, dimensiunea, economia și timpul de procesare, niciodată numele fișierului sau conținutul lui.

Compresia fără pierderi: același conținut, mai puțini octeți

Compresia fără pierderi găsește redundanța, adică lucrurile stocate de mai multe ori sau care pot fi prezise, și le scrie mai compact. Decodarea inversează exact procesul. Trei idei apar în aproape orice format fără pierderi:

  • Predicția. Pixelii vecini dintr-o imagine sau eșantioanele consecutive dintr-un sunet sunt de obicei asemănătoare. Stocarea micii diferențe față de o predicție, în locul valorii complete, lasă numere în mare parte apropiate de zero. Filtrele PNG și predictorul liniar al FLAC funcționează așa.
  • Repetiția. Secvențele repetate sunt înlocuite cu o referință scurtă la copia anterioară. Aceasta este partea LZ77 din DEFLATE, folosit în ZIP, PNG și fișierele Office.
  • Codificarea entropică. Valorile frecvente primesc coduri scurte, iar cele rare coduri lungi (codificare Huffman sau aritmetică).

Compresia fără pierderi are o limită naturală: zgomotul aleatoriu nu poate fi prezis, așa că o fotografie cu granulație sau o înregistrare zgomotoasă nu se micșorează niciodată mult fără pierderi. Tot de aceea, comprimarea unui fișier deja comprimat, cum ar fi un JPEG într-un ZIP, nu economisește aproape nimic.

Compresia cu pierderi: eliminarea a ceea ce nu vă va lipsi

Codecurile cu pierderi merg mai departe, renunțând la informațiile pe care ochii și urechile oamenilor abia le percep. JPEG și WebP stochează culoarea la o rezoluție mai mică decât luminozitatea și elimină prin rotunjire detaliile fine de frecvență înaltă. MP3, AAC și Opus renunță la sunetele mascate de altele mai puternice. Codecurile video precum H.264 stochează din când în când o imagine completă, iar între ele mai ales mișcarea și modificările.

Setarea de calitate sau de rată de biți decide cât se elimină. La setări moderate, pierderea se observă foarte greu; dacă forțați prea mult, apar artefactele tipice: blocuri și halouri în imagini, un sunet metalic sau ca „sub apă” la audio, imagini mânjite în scenele video rapide.

Ce promit instrumentele și ce nu

  • Nu primiți niciodată un fișier mai mare. Dacă rezultatul nu este mai mic, instrumentul returnează originalul și vă spune că este deja optim.
  • Documentele și fișierele audio dau octeți identici pentru același fișier și aceleași setări; encoderele video hardware pot da diferențe de câțiva octeți de la o rulare la alta.
  • Textul din documente rămâne text; paginile nu sunt niciodată transformate în imagini.
  • Metadatele imaginilor, precum locația GPS, sunt eliminate implicit, iar profilul de culoare și rotația sunt păstrate. Metadatele video, precum locația, dispozitivul și datele, sunt și ele eliminate implicit; fișierele audio își păstrează etichetele și coperta, dacă nu dezactivați această opțiune.

Ce nu putem promite este un anumit procent. Economia depinde în întregime de felul în care a fost creat fișierul: o fotografie de telefon sau un PDF scanat au de obicei mult loc de câștig, un fișier deja optimizat are puțin. Instrumentul afișează pentru fiecare fișier dimensiunile exacte înainte și după.

Limitele compresiei în browser

O filă de browser este un mediu izolat cu memorie limitată, iar asta stabilește granițele a ceea ce este practic. Instrumentul acceptă imagini de până la 200 MB și 100 de megapixeli, fișiere PDF și Office de până la 300 MB și video și audio de până la 4 GB pe un calculator (1 GB pe telefoane), deși videoclipurile 4K lungi s-ar putea totuși să nu încapă în memoria unei file. Viteza depinde de hardware: în testele noastre pe un PC rapid cu Windows, în Chrome, un minut de video 1080p a durat circa 20 de secunde, iar o fotografie de 24 de megapixeli circa 2,5 secunde; telefoanele pot fi mult mai lente. Video și majoritatea conversiilor audio au nevoie de WebCodecs, oferit de versiunile actuale de Chrome, Edge și Opera, de Firefox 130+ și de Safari 26+; WAV și AIFF pot deveni MP3, FLAC sau WAV și fără el.

Câteva formate nu au deloc decodor în browsere, precum WMA, AVI și WMV, iar fișierele Office binare vechi nu pot fi rescrise în siguranță. Pentru acestea, instrumentul explică opțiunile în loc să producă un fișier care ar putea fi deteriorat. Când o sarcină este prea mare pentru un browser, un program desktop precum HandBrake pentru video sau LibreOffice pentru documente este recomandarea onestă.