Bir tarayıcı görseli sıkıştırırken neler olur

Sıkıştırılmış dosya yeniden bir piksel ızgarasına dönüştürülür. Tarayıcılar bunu yerel kodla, platformun sunduğu yerlerde donanım hızlandırmasıyla yapar; JPEG, PNG, WebP ve AVIF’i işlerler — Apple platformlarında ayrıca HEIC’i, çünkü çözücü zaten işletim sistemiyle geliyor.

Çözme, dosyaya göre kayıpsızdır: dosyanın tarif ettiği piksellerin tam olarak kendisini alırsın. Kayıp çoktan yaşanmıştır — o dosyayı üreten şey onu kodlarken.

Telefon kameraları sensörün ham yönünü ve bunun nasıl döndürüleceğini söyleyen ayrı bir EXIF etiketini birlikte kaydeder. Bu etiketi görmezden gelen yazılım yan yatmış fotoğraflar üretir. Etiketi uygulamak, başka hiçbir şey dokunmadan önce piksel ızgarasının kendisini döndürmek demektir — ondan sonra etiket gereksizleşir; yeniden kodlamanın üst verileri düşürmesinin bir nedeni de budur.

Hedef boyuta tam çözünürlükte ulaşılamıyorsa görsel küçültülür. Algılanan kalitenin büyük bölümü sessizce burada kazanılır ya da kaybedilir. Ucuz bir kutu filtresi komşu pikselleri ortalar ve her şeyi yumuşatır; bir Lanczos filtresi daha geniş bir komşuluğu ağırlıklandırır ve kenarları diri tutar.

Yeniden örnekleme gerçekten yıkıcıdır — atılan pikseller geri gelmez — ama küçük bir hedefe ulaşmanın çoğu zaman en az yıkıcı yoludur, çünkü kodlayıcının bütün bütçesini anlatmaya çalışıp başaramayacağı ayrıntıyı baştan ortadan kaldırır.

Kayıplı olan kısım. JPEG görseli parlaklık artı renk gösterimine çevirir, renk çözünürlüğünün bir bölümünü atar (göz bunu zar zor fark eder), görseli 8×8’lik bloklara böler, her bloğu frekans bileşenlerine dönüştürür ve ardından nicemler — yani yüksek frekanslı ayrıntıyı yuvarlayarak siler. Kalite parametresi, bu yuvarlamanın kabalığıdır. Ondan sonrası kayıpsız entropi kodlamasıdır; iyileştirilmiş bir Huffman tablosunun ya da aşamalı bir taramanın bedavaya bayt kazandırmasının nedeni de budur.

Tarayıcının yerleşik kodlayıcısı bir kara kutudur: bir kalite sayısı isteyebilirsin, başka bir şey değil. İyileştirilmiş entropi tabloları yok, temel mi aşamalı mı seçimi yok, yeniden örnekleme filtresi üzerinde denetim yok ve bir ayarın kaç bayt üreteceğini denemeden öğrenmenin yolu yok.

WebAssembly’ye derlenmiş bir kodek bunların hepsini geri verir; bedeli, indirmesi için harcadığın baytlardır. ToolZool bütün hattı bu şekilde çalıştırır — çözme, yönlendirme, yeniden örnekleme ve kodlama, hepsi WebAssembly’ye derlenmiş Rust, arka planda bir işçide — çözmeyi tarayıcıya bırakmak yerine. Üç nedeni var ve hepsi pratik:

• Arama çok sayıda kodlama ister. Tam bir boyuta ulaşmak, aynı görseli beş altı kez kodlamak demektir. Bunu ucuz ve tekrarlanabilir kılan şey, kodlayıcının senin olmasıdır.
• Bir çözücünün hayır diyebilmesi gerekir. 60.000 × 60.000 piksel olduğunu bildiren bir dosya, bellek ayrılmadan önce geri çevrilmelidir; kesik bir dosya da yarım görsel döndürmek yerine hata vermelidir. Tarayıcının çözücüsü bu kararları kendi verir; bizimki sınırları açıkça söyler ve uygular.
• Aynı girdinin aynı çıktıyı vermesi gerekir. Tarayıcı çözücüleri renk işleme konusunda ve bozuk dosyalara davranışta birbirinden ayrılır. İki ucu da elinde tutan bir hat, her cihazda aynı baytları üretir — bir sonucu denetleyebilir kılan şey de budur.

Bedeli dürüstçe söyleyelim: o motor bir indirmedir. Yalnızca bir dosya seçtiğinde getirilir, yani bunun gibi bir sayfayı okumak onun bedelini asla ödemez.

Bir hedef dosya boyutu verildiğinde, iyi bir kodlayıcıyla harika bir kodlayıcı arasındaki fark yüzde birkaçtır. Kalite kaydırıcısını tahmin etmekle doğrusunu aramak arasındaki fark çok daha büyüktür, çünkü hakkının %60’ında kalan bir tahmin, hak ettiğin kalitenin üçte birini çöpe atmıştır. Tam boyuta sıkıştırmanın bütün fikri budur; 50 KB sınırını tutturmak ise aramanın en zorlu uçta sana ne kazandırdığını gösteriyor.