JPEG XL ve Pareto cephesi
(cloudinary.com)- Büyük görüntüleri tek seferde işleyen JPEG XL kodlamasındaki darboğazı libjxl 0.10, akışlı kodlama API’si ile azaltıyor; kayıpsız sıkıştırmada bellek kullanımını ve hızı büyük ölçüde iyileştiriyor
- 13500×6750 NASA gece Dünya görüntüsünün kayıpsız kodlaması, libjxl 0.9’daki yaklaşık 8GB RAM ve 2 dakikadan fazla seviyesinden libjxl 0.10’da 0.7GB RAM, tek iş parçacığında 30 saniye, 8 iş parçacığında 5 saniyeye düşüyor
- Sıkıştırma yöntemlerini karşılaştırmak için yalnızca dosya boyutuna bakmak yeterli değil; kodlama hızı ve sıkıştırma yoğunluğunu birlikte değerlendiren Pareto cephesi, zaman bütçesine göre en iyi ayarları belirleyen ölçüt haline geliyor
- Kayıplı sıkıştırmada sıkıştırma oranı, hız ve görüntü kalitesi birlikte ele alınmalı; SSIMULACRA2 60~90 aralığında JPEG XL özellikle yüksek kalite ile görsel olarak kayıpsız bölgede güçlü sonuçlar gösteriyor
- jpegli gibi yeni JPEG kodlayıcıları çok hızlı kodlama aralıklarında hâlâ rekabetçi olsa da JPEG XL, geniş bir hız aralığında hem kayıpsız hem de kayıplı sıkıştırmanın temel seçeneklerinden biri konumuna yerleşiyor
libjxl 0.10’daki temel değişiklik
- libjxl 0.10, JPEG XL referans uygulamasının yeni sürümüdür; en büyük değişiklik akışlı kodlama API’sinin eksiksiz uygulanmasıdır
- Bu API, büyük görüntüleri tek seferde işlemek yerine parçalar halinde kodlar
- Tüm görüntüyü belleğe alırken oluşan RAM yükü azalır
- Kodlama hızı da iyileşir
- Etki özellikle büyük görüntülerin kayıpsız sıkıştırmasında belirgindir
Kayıpsız sıkıştırmada azalan bellek ve süre
- libjxl 0.10 öncesinde kayıpsız JPEG XL kodlamasında yüksek bellek kullanımı ve uzun işlem süreleri sorun olabiliyordu
- Örnek görüntü, NASA’nın 13500×6750 gece Dünya görüntüsüdür
- TIFF dosyası 64MB
- Sıkıştırma öncesi boyut 273MB
- Aynı görüntüyü varsayılan effort ayarı e7 ile sıkıştırmanın sonuçları:
- libjxl 0.9 yaklaşık 8GB RAM kullandı ve 2 dakikadan uzun sürdü; çıktı dosyası 33.7MB oldu
- Tek iş parçacığında 2 dakika 40 saniye, 8 iş parçacığında 2 dakika 6 saniye sürdü; iş parçacığı sayısını artırmanın etkisi büyük değildi
- Ölçüm ortamı, 12 çekirdekli Apple M3 Pro CPU ve 36GB RAM’e sahip Kasım 2023 MacBook Pro’ydu
- libjxl 0.10’da aynı görüntüyü sıkıştırmak için yalnızca 0.7GB RAM gerekiyor
- Tek iş parçacığında 30 saniye
- 8 iş parçacığında 5 saniye
- Çıktı dosyası 33.2MB
- effort değeri yükseldikçe sıkıştırma oranı iyileşir, ancak CPU süresine kıyasla kazanım giderek azalır
- e1’den e2’ye geçerken 0.1 saniye yerine 1 saniye harcayarak 22MB azaltmak mümkün oldu
- e2’den e7’ye geçerken 1 saniye yerine 5 saniye harcayarak ek 11MB azaltıldı
- e7’den e9’a geçip 1MB daha azaltmak için neredeyse 2 dakika beklemek gerekti
effort ayarının pratik dengesi
- Sıkıştırma ayarı, zaman ve dosya boyutu arasında bir denge problemidir
- Görüntü düzenleme sırasında yerel kaydetme yapılan üretim iş akışlarında güçlü sıkıştırma şart olmayabilir; bu yüzden düşük effort ile kodlama mantıklı olabilir
- Birden çoğa dağıtım senaryolarında veya uzun süreli arşivlemede, birkaç MB azaltmak için daha fazla CPU zamanı harcamak değerli olabilir
Sıkıştırma yöntemlerini Pareto cephesiyle karşılaştırmak
- Sıkıştırma tekniklerini karşılaştırırken yalnızca dosya boyutuna bakmak, gerçek seçim için gereken bilgileri kaçırmaya yol açabilir
-
Karşılaştırma eksenleri ve grafiği yorumlama
- Temel eksenler sıkıştırma yoğunluğu ve kodlama hızıdır
- Bir yöntemin Pareto optimal olması, aynı veya daha iyi sıkıştırma yoğunluğunu daha kısa sürede sağlayan başka bir yöntem olmadığı anlamına gelir
- Pareto optimal yöntemlerin kümesi Pareto cephesidir
- Grafikte dikey eksen kodlama hızı, yatay eksen ise sıkıştırılmış görüntünün ortalama bits per pixel değeridir
- Dikey eksen megapixels per second birimindedir ve geniş hız aralığını kapsamak için logaritmik ölçek kullanır
- Sıkıştırma öncesi 8 bit RGB 24bpp’dir
- Yukarı çıktıkça hız artar, sola gittikçe sıkıştırma oranı iyileşir
Kayıpsız sıkıştırma karşılaştırma sonuçları
- Önceki libjxl de tüm hız aralıklarında Pareto optimal sonuçlar üretiyor ve PNG, kayıpsız AVIF, kayıpsız WebP’den daha küçük dosyalar oluşturuyordu
- libjxl 0.10, önceki sürüme göre kayda değer farkla daha iyi sonuçlar gösteriyor
- QOI grafikte gösterilmedi ancak 154Mpx/s hızda 17bpp kaydetti
- libjxl’in en düşük effort ayarı 427Mpx/s hızda 11.5bpp’ye kadar sıkıştırdı
- libjxl tarafı 2.7 kat daha hızlıydı ve sonuç dosyası %32.5 daha küçüktü
Fotoğraf dışı görüntülerde kayıpsız sıkıştırma
- Fotoğraflar doğal gürültü açısından zengin olduğundan kayıpsız sıkıştırma genelde zordur; fotoğraf dışı görüntülerde sonuçlar değişir
- Çeşitli çizim tarzlarına sahip 41 manga görüntüsüyle yapılan testte ortalama boyut 7.3 megapikseldi
- Bu görüntüler yaklaşık 4bpp seviyesine kadar sıkıştırıldı; bu, fotoğraf görüntülerindeki yaklaşık 10bpp’den çok daha iyi bir sıkıştırmadır
- Kayıpsız AVIF bu görüntü türünde kullanışlı değildi
- PNG’den daha düşük sıkıştırma oranı verdi
- QOI’ye benzer yoğunluğa ulaştı ama çok daha yavaştı
- Kayıpsız WebP bu tür görüntülerde çok iyi sıkıştırma oranı gösterdi
- QOI, hız ve basitlik düşünüldüğünde fena değil, ancak Pareto optimal olmaktan uzak
- Düşük effort JPEG XL kodlaması QOI’den 2 kat hızlı ve %31 daha küçüktü
- libjxl 0.10, fotoğraf dışı görüntülerde de 0.9’a kıyasla büyük ölçüde iyileşti
- WebP varsayılan effort: 4.30bpp, 2.3Mpx/s
- libjxl 0.9 effort 5: 4.27bpp, 2.6Mpx/s
- libjxl 0.10 effort 5: 4.25bpp, 12.2Mpx/s
- libjxl 0.10 effort 7: 4.04bpp, 5.9Mpx/s
Kayıplı sıkıştırmaya kalite ekseni eklenir
- Kayıpsız sıkıştırmada yalnızca sıkıştırılmış boyut ve hıza bakmak yeterlidir; kayıplı sıkıştırmada buna görüntü kalitesi eklenir
- Kayıplı görüntü codec’leri ve kodlayıcıları, kalite noktasına göre farklı performans gösterebilir
- Yüksek kaliteli kodlamada iyi olan bir kodlayıcının düşük kalitede de iyi olduğu söylenemez
- Tersi de geçerlidir
- Yalnızca sıkıştırma oranı ve kaliteye bakan bitrate-distortion grafikleri, kodlama effort’u ile sıkıştırma performansı arasındaki dengeyi değerlendirmeyi zorlaştırır
- Kayıplı sıkıştırmanın Pareto cephesini görmek için sıkıştırma, hız ve kaliteden oluşan 3 boyutlu uzayı farklı kalite noktalarında kesitlere ayırmak gerekir
Kalite ölçümü ve toplama yöntemi
- Görüntü kalitesi özneldir ve kişiden kişiye değişebilir
- En iyi ölçüm yöntemi, onlarca veya daha fazla insanın katı bir test protokolüne göre görüntüleri karşılaştırdığı ya da puanladığı deneylerdir
- Bu tür deneyler zaman ve maliyet açısından pahalı olduğundan tüm kodlayıcı ayarlarını test etmek zordur; bu yüzden nesnel metrikler kullanılır
- Açık metrikler arasında iyi olanlar SSIMULACRA2, Butteraugli ve DSSIM olarak gösterilir
- Bunlar insan görsel sistemini modellemeye çalışır ve öznel değerlendirmelerle korelasyonları iyidir
- PSNR veya SSIM gibi eski ve basit metrikler, insanların görüntü kalitesi yargılarıyla iyi örtüşmez
- Bir kodlayıcıyı, kendi içinde optimize ettiği metrikle değerlendirirseniz sonuçlar o kodlayıcı lehine çarpıtılabilir
- Yüksek effort libjxl Butteraugli’yi optimize eder
- libavif PSNR veya SSIM’i optimize edebilir
- SSIMULACRA2, test edilen kodlayıcılar tarafından dahili optimizasyonda kullanılmadığı için güvenli bir metrik olarak kabul edilir
- Testte, her ayar tüm görüntü kümesine uygulandığında ortalama SSIMULACRA2 puanı belirli bir değere yakın olacak şekilde kodlayıcı ayarları seçildi
- Ortalama puana göre hizalama, WebP ve AVIF lehine bir yöntemdir
- Önceki araştırmalarda AVIF ve WebP’nin JPEG ve HEIC’e göre daha az tutarlı olduğu, JPEG XL’in ise en tutarlı kodlayıcı olduğu görülmüştü
- Gerçek kullanımda en kötü puanı veya gerçek en kötü görsel kaliteyi eşitlemek isteyebilirsiniz
Gerçek kullanıma yakın kalite aralığı
- Kayıplı sıkıştırmada 50:1 veya 200:1 gibi yüksek sıkıştırma oranları mümkündür, ancak sıkıştırma artefaktları oluşur
- Gerçek kullanımda en ilgili aralık SSIMULACRA2 60~90 aralığıdır
- Kalite noktalarına göre özellikler:
- SSIMULACRA2 90: görsel olarak kayıpsız kalite; AVIF ve JPEG XL gibi modern codec’ler buna yaklaşık 8:1 sıkıştırma oranıyla, yani 3bpp ile ulaşabilir
- SSIMULACRA2 80: yüksek kalite; yaklaşık 16:1 sıkıştırma oranıyla, yani 1.5bpp ile ulaşılabilir
- SSIMULACRA2 70: orta-üst kalite; yaklaşık 30:1 sıkıştırma oranıyla, yani 0.8bpp ile ulaşılabilir
- SSIMULACRA2 60: orta kalite; yaklaşık 40:1 sıkıştırma oranıyla, yani 0.6bpp ile ulaşılabilir
- SSIMULACRA2 60’ın altındaki kalite bant genişliğini daha da azaltabilir, ancak görüntüyü bozma riski taşır
- 2024 web’inde orta ile yüksek kalite aralığı daha ilgilidir
- HTTP Archive’a göre web’de AVIF medyanı 1bpp’dir ve orta-üst kaliteye karşılık gelir
- JPEG medyanı 2.1bpp’dir ve yüksek kaliteye karşılık gelir
- Kamera gibi web dışı kullanım durumlarında yüksek kalite ile görsel olarak kayıpsız aralık daha ilgilidir
Kayıplı sıkıştırma Pareto cephesi sonuçları
- Kayıplı sıkıştırma testi, Şubat 2024 sonu itibarıyla her kodlayıcının en güncel sürümüyle yapıldı
- Kodlama hızı, Apple M3 Pro tabanlı Kasım 2023 MacBook Pro’da 8 iş parçacığıyla ölçüldü
- AVIF hem tile ayarıyla hem de tile’sız ayarla test edildi
- Tile ayarı çoklu iş parçacığı kullanımından daha iyi yararlandığı için daha hızlıdır
- Buna karşılık sıkıştırma yoğunluğu kaybı vardır
Orta kalite: SSIMULACRA2 60
- Aynı format içinde bile kodlayıcı ve effort ayarlarına göre sonuçlar büyük farklılık gösterdi
- Tarihsel olarak yaygın kullanılan JPEG kodlayıcısı libjpeg-turbo’nun varsayılan ayarı, grafikte en hızlıdır ancak sıkıştırma yoğunluğu düşük tarafta yer alır
- WebP, libjpeg-turbo’dan daha iyi sıkıştırma yoğunluğu sundu
- mozjpeg, libjpeg-turbo’dan daha yavaş olsa da daha iyi sıkıştırma sonuçları sağlar; bu görüntü kümesi ve kalite noktasında WebP’den Pareto açısından daha verimliydi
- Google’ın JPEG XL ekibi tarafından geliştirilen jpegli, mozjpeg’den daha hızlıydı ve sıkıştırma oranı da daha iyiydi
- guetzli ve libjxl’den alınan derslere dayanır
- WebP ve yüksek hızlı AVIF’ten daha iyi sıkıştırırken mevcut JPEG dosyaları üretir
- AVIF ve HEIC, JPEG ve WebP’den daha iyi sıkıştırma yoğunluğu elde edebilir ancak kodlama daha yavaştı
- JPEG XL, benzer sıkıştırma yoğunluğuna ulaşırken çok daha hızlı kodlama yaptı
- Bu kalite noktasında Pareto cephesi, makul hız aralıklarında JPEG XL ve çeşitli JPEG kodlayıcılarından, daha yavaş aralıklarda ise AVIF’ten oluştu
Orta-üst ve yüksek kalite sonuçları
- SSIMULACRA2 70 orta-üst kalite düzeyinde genel sonuçlar orta kaliteye benzerdi
- Web ile ilgili en yüksek kalite noktası olarak ortalama SSIMULACRA2 85 kullanıldı; ayarlar, görüntülerin çoğu 80 ve üzerini yakalayacak şekilde yapıldı
- Bu yüksek kalite noktasında farklar daha belirgin hale geldi
- mozjpeg artık WebP’yi geçemedi
- jpegli hâlâ WebP’yi geçti
- Pareto cephesinin büyük bölümünü JPEG XL kapladı
- Çok hızlı kodlamada mevcut JPEG hâlâ iyiydi
- Bu kalite noktasında AVIF Pareto cephesinde yer almadı
- En yavaş ayarında, 0.5Mpx/s altındaki hızla, ikinci en hızlı libjxl ayarıyla aynı sıkıştırma yoğunluğunu yakaladı
- İlgili libjxl ayarı 52Mpx/s hızla 100 kattan fazla daha hızlıydı
Kod çözme hızı
- Şimdiye kadarki karşılaştırma sıkıştırma yoğunluğu ve kodlama hızı odaklıydı
- Modern bilgisayarlarda kod çözme hızı büyük bir sorun değildir, ancak ölçümler de karşılaştırıldı
- Sıralı JPEG, kod çözme hızında en güçlü seçenektir
- mozjpeg ve varsayılan jpegli’nin ürettiği progresif JPEG daha yavaştır, ancak makul boyuttaki görüntüleri çok hızlı yüklemek için yeterince hızlıdır
- JPEG XL, sıralı JPEG ile progresif JPEG arasında yer alır
- AVIF’in kod çözme hızı kodlama biçimine göre değişir
- Daha hızlı ama biraz daha kötü olan çoklu tile kodlaması kullanılırsa kod çözme de daha hızlı olur
- Varsayılan tek tile kodlama daha yavaştır
- Ölçülen en yavaş kod çözme hızı bile kodlama hızıyla karşılaştırıldığında yeterince hızlı sayılır
Görsel olarak kayıpsız kalite ve büyük görüntüler
- Görsel olarak kayıpsız kalite grafiğine WebP dahil edilmedi
- Kayıplı modda bu kalite noktasına ulaşamadı
- Çünkü WebP’de 4:2:0 chroma subsampling zorunludur
- mozjpeg de bu kalite noktası için tasarlanmadığından libjpeg-turbo’dan hem sıkıştırma hem de hız açısından daha kötüydü
- Varsayılan hız ayarında libavif, libjpeg-turbo’dan %20 daha küçüktü ancak kodlama bir basamak daha uzun sürdü
- Aynı kalite noktasında libjxl, libavif’ten %20 daha küçük ve 2.5 kat daha hızlıydı
- Görsel olarak kayıpsız kalite Pareto cephesinin büyük bölümünü JPEG XL kapladı; en hızlı hız aralığında JPEG de yer aldı
- Yaklaşık 1 megapiksellik web boyutu görüntü testinden farklı olarak, daha büyük görüntü testinde sonuçlar büyük ölçüde değişti
- Yüksek kalite noktasında WebP, mozjpeg ve AVIF, libjpeg-turbo’dan daha kötüydü
- HEIC, libjpeg-turbo’ya kıyasla kayda değer tasarruf sağladı
- jpegli de daha iyi hızla kayda değer tasarruf sağladı
- JPEG XL görüntüyü 1.3bpp’nin altına sıkıştırdı; AVIF, libjpeg-turbo ve WebP ise 2bpp üzerinde değere ihtiyaç duydu
libjxl 0.10’un son konumu
- libjxl 0.10, hem kayıpsız hem de kayıplı sıkıştırmada bellek kullanımını bir basamak azaltıyor
- Hız da iyileşti; özellikle çok iş parçacıklı kayıpsız kodlamanın varsayılan effort ayarı bir basamak hızlandı
- JPEG XL, hem kayıpsız hem kayıplı sıkıştırmada, özellikle yüksek kalite ile görsel olarak kayıpsız kalite aralığında güçlü bir görüntü codec’i olarak öne çıkıyor
- Geniş hız ayarı aralığında JPEG XL, Pareto optimale yakın bir seçenek olmaya devam ediyor
- Mevcut JPEG de yeni kodlayıcılar sayesinde hâlâ çekici
- jpegli, mozjpeg’e göre hem hız hem de sıkıştırmada büyük iyileşme sağlıyor
- Aşırı hızlı kodlama gerektiğinde mevcut JPEG hâlâ en iyi seçenek olabilir
2 yorum
jpeglikodlayıcısı,mozjpeg'in ardından bir kez daha JPG'nin ömrünü uzatıyor gibi görünüyor...JXL tarafında yapılmış olsa da ironik biçimde JXL'in yayılmasını engelleyebilir gibi duruyor...
Hacker News yorumları
Kayıpsız WebP’nin ne kadar iyi olduğuna da dikkat etmek gerek
WebP’nin MozJPEG ile kodlamaya kıyasla belirgin bir avantajının olmadığı ya da daha kötü olduğu konuşmalarının arasında çoğu zaman kayboluyor ama kayıpsız WebP performans ve hız açısından gerçekten çok iyi
PNG ya da OptiPNG’den çok daha iyi, çevrim içi destek de yeterince olgunlaştı ve berbat kayıpsız AVIF’i de elbette açık ara geçiyor
SDR görüntüler için sorun değil, fakat HDR için GIF’in 256 renkle sınırlı olması kadar temel bir kısıta dönüşüyor
Tüm bir çizgi romanı sıkıştırıyorsanız PNG hâlâ doğru tercih; bu durumda da fiilen terk edilmiş optipng yerine oxipng kullanmak daha iyi
Ayrıca burada atlanan bir nokta da şu: kayıpsız JPEG2000 fotoğraf içeriklerinde şaşırtıcı derecede iyi ve hızlı olabiliyor
Çoğu kullanım için gerçek kayıpsızdan daha tercih edilebilir ve çoğu zaman görünür bir kayıp olmadan boyutu ayrıca yarıya indiriyor
Çok düşük kalite ayarlarında JPEG’in, belirgin artefaktlar yüzünden yakından bakınca kübist bir tablo gibi darmadağın görünse bile, görüntünün genel kalitesini daha iyi koruyan keskin detay yaklaşımını sürdürmesi şaşırtıcı
Aslında görüntüyü bir tür soyut sanat stiline dönüştürüyor; JXL ve AVIF ise sadece bulanıklaşıyor
Bu görüntüler aynı sıkıştırma oranına değil, aynı bozulma düzeyine göre eşlenmeye çalışılıyor; piksel başına bit sayısı da görüntünün yanında gösteriliyor
Gerçek internette kalite 65 kullanımı nadirdir ve ancak en düşük kaliteli sitelerde görülür; kalite 75 yaygın düşük kalite, kalite 85 ise ortalamaya yakın sayılır
Sıkıştırma gerektiğinde kalite 94 yuv444 veya üzeri kullanırım
Bit hızı sol sütunda; düşük kaliteli JPG, JXL/AVIF’in orta-düşük kalitesi olan 0.4bpp ile aynı boyutta, dolayısıyla sol alttaki görseli üstteki orta ve sağdaki görsellerle karşılaştırmak gerekiyor
Yanlış bir karşılaştırmaya kapılmamak gerek; JXL ve AVIF’e de dosya boyutunu iki katına çıkarma hakkı verilirse çok daha iyi görünürler
SSIMULACRA2 blok artefaktlarını ağır cezalandırıyor ama bulanıklığı pek umursamıyor gibi; aynı SSIMULACRA2 puanında JPEG sürümünün daha iyi göründüğüne katılıyorum
Bu yazının neden kodlama hızına bu kadar odaklanıp, web bağlantısı ortamında kullanımın %99’una karşılık geldiğini düşündüğüm kod çözmeyi üstünkörü ele aldığını anlamıyorum
“Kod çözme hızı modern bilgisayarlarda büyük bir sorun değil, ama sayılara hızlıca bakmak ilginç” gibi geçiştiriyor
Çünkü o noktadan sonra darboğaz artık kod çözme değil
Modern sıkıştırma algoritmalarının çoğu asimetrik olduğundan, sıkıştırmaya çok daha fazla zaman harcansa bile sıkıştırma açma performansına büyük etkisi olmuyor; temel performansa ulaşıldığında daha az önemli hâle geliyor
Mümkünse, mevcut donanımda tamamı yazılımla çözülmek zorunda olan JPEG XL yerine bunları tercih etmek için güçlü bir neden olabilir
H264 çözme her yerde var; AV1 çözme de istikrarlı biçimde standart bir özellik hâline geliyor
İstemci sayfadaki birkaç görseli insanın fark edemeyeceği kadar hızlı çözebiliyorsa bu yeterlidir; buna karşılık kodlamada birkaç puanlık bile iyileşme gerçek maliyet tasarrufu sağlayabilir
Gerçekten de görüntü kodlamaya milyonlarca dolar harcıyorlar
Kayıpsız benchmark’a QOI’nin dahil edildiğini görünce güldüm
Genel kullanıcıya yönelik yazılımlarda varsayılan olarak desteklenmeyen, iyi olmaktan ziyade sadece fena olmayan bir şeyi hedefleyen fiilen alakasız bir format olmasına rağmen, fotoğraf dışı kodlama grafiğinde bir yer kaplaması ilginç
Bu yüzden GameMaker Studio ve son iki yıl civarında yapılmış oyunlar gerçekten de içeride QOI kullanıyor
Tüketicinin bilinçli olarak kullandığı bir şey değil, ama tamamen alakasız demek de zor
Geriye dönüp bakınca bu beklenen bir şey; QOI çözme doğası gereği sıralı, bu yüzden kolayca paralelleştirilemiyor
JXL’in harikalığının formatın kendisinden mi yoksa encoder’dan mı kaynaklandığını merak ediyorum
Yalnızca
-d 1.0ile yüksek kaliteli, küçük görüntüler üretebilmesi tuhaf denecek kadar etkileyici; diğer codec’lerde benzer sonuçlar almak için görüntü türüne göre kalite ayarını farklı vermek gerekiyorduBu geliştirme hızıyla libjxl’in görüntü encoder’ları dünyasının x264’ü olmasına şaşırmam
Buna karşılık libvpx her zaman sıradan bir encoder’dı ve vp8/vp9 formatlarının hayal kırıklığı yaratan performansının, yalnızca hızın değil genel performansın da nedeni bu olabilir diye düşünüyorum
Bu kaçınılmaz olarak kayıplı WebP performansını da etkiledi; Dark Shikari de x264 ile vp8’in durağan görüntü performansını karşılaştırmıştı [0]
[0] https://web.archive.org/web/20150419071902/http://x264dev.mu...
Görsel olarak kayıpsıza yoğun biçimde odaklanmayı sürdürdü ve yüksek kalite ayarlarına yardımcı olmayan, yalnızca karmaşıklığı artıran format özellikleri eklemek istemedik
Modelleme özelliklerinin yanı sıra bağlam modelleme ve entropi kodlama verimliliği yüksek kalitede çok önemli
AVIF’in entropi kodlamasının yüksek kaliteli veya kayıpsız fotoğraflara pek uygun olmadığını düşünüyorum
-d 1.0arayüzüne sahip JPEG encoder’ı cjpegli de yaptıkJPEG XL çalışmasından Highway adlı harika yeni bir paralelleştirme kütüphanesinin de çıktığını belirtmeye değer
Bu kütüphane yalnızca JPEG XL’de değil, Google’ın en yeni Gemma AI modellerinde de kullanılıyor
[1]’de de ele alınıyor; başlangıcı şöyle: “Bugün, sayı dizilerini C++
std::sort’tan yaklaşık 10 kat daha hızlı sıralayan, tüm modern CPU mimarilerinde taşınabilirliği korurken en yeni mimariye özel algoritmalardan da hızlı olan açık kaynak kodunu paylaşıyoruz. Aşağıda bunu nasıl başardığımızı tartışıyoruz.”[0] https://github.com/google/highway
[1] https://opensource.googleblog.com/2022/06/Vectorized%20and%2..., ilgili makale: https://arxiv.org/pdf/2205.05982.pdf
C++’ta taşınabilir SIMD elde etmenin en iyi yolu gibi görünüyor
JPEG XL’in kendi başına ne kadar parladığından bağımsız olarak, sırf şunu yapabilmesi bile kesinlikle harika
a.jpg615504 bayt ve SHA-1’i716744d950ecf9e5757c565041143775a810e10fcjxl a.jpg a.jxlçalıştırıldığında 615504 baytlık JPEG’i okuyup konteyner dahil 537339 bayta sıkıştırıyorAma
djxl a.jxl b.jpgçalıştırıldığında 537339 baytlık sıkıştırılmış veriyi okuyup JPEG olarak yeniden oluşturuyor;b.jpgde 615504 bayt ve SHA-1’i tamamen aynıDünyada korunmak istenen milyarlarca JPEG dosyası olduğunu düşünürsek, mevcut JPEG’i kayıplı bir formata yeniden sıkıştırmak kaliteyi düşürür
Ama JPEG XL, %15–30 tasarruf sağlarken isterseniz özgün JPG’yi bit düzeyinde %100 aynı şekilde geri getirebiliyor
Gerçekten müthiş
Ne yazık ki Debian stable 12 Bookworm kullanıyorum ve ImageMagick 6.9 var; bildiğim kadarıyla Emacs görüntüleri gösterirken muhtemelen ImageMagick kullanıyor
JPEG XL desteği ancak ImageMagick 7’de eklendi; henüz daha fazla kurcalamadım
Kayıplı yeniden kodlama olmadan dijital mirası eksiksiz korumaya yardımcı olacağını düşünüyorum
libjxl’in yeni sürümünün hem kayıplı hem kayıpsız sıkıştırmada bellek kullanımını tek haneli kat mertebesinde azaltması ve hızı da iyileştirmesi çok etkileyici
Özellikle çok iş parçacıklı kayıpsız encoding için varsayılan effort ayarının artık tek haneli kat mertebesinde daha hızlı olması kısmını beğendim; yazı da iyi yazılmış
JPEG XL formatının her adımını ayrıntılı açıklayan bir web sitesi var mı merak ediyorum
Geleneksel JPEG’in aksine ilgili adımları net biçimde anlatan belge bulmak zordu; bu formatta pek çok ilginç yeniliğin bir araya geldiği açık, o yüzden bu eksiklik üzücü
Tek tek bileşenler de kendi başlarına faydalı olabilir gibi görünüyor
Özünde 128x128’e kadar değişken boyutlu DCT, ANS entropi tahmini ve parlaklık tabanlı renk farkı tahmini var
https://github.com/libjxl/libjxl/blob/main/doc/encode_effort... de effort düzeylerine göre özellik ayrımını iyi gösteriyor
Yazıda AV1’i, dolayısıyla AVIF’i encode eden rav1e eksik
rav1e, referans uygulama olan aom’dan çok daha hızlı; aom’un 1 dakika beklemeye rağmen görüntü dönüşümünü bitiremediği durumda rav1e’nin 10 saniyeden kısa sürdüğü olmuştu
Hızlı rav1e’nin yüksek encoding hızlarında jpegli’den daha iyi görünüp görünmediğini de merak ediyorum
Benzer hızlarda ikisi arasında sıkıştırma performansı açısından büyük bir fark görmedim