Chromium, JpegXL’i birleştirdi

• JpegXL çözücüsü Chromium kod tabanına entegre edildi ve böylece tarayıcı JXL formatındaki görselleri işleyebilir hale geldi
• Değişiklik, Gerrit kod inceleme sayfasında “Wire up JXL decoder” başlığıyla görülebiliyor
• Bu birleştirme, JpegXL formatı desteği için temel bir adım niteliğinde ve çözücünün bağlanması çalışmasını içeriyor
• Kod incelemesi, Chromium’un src deposundaki değişiklik (7184969) olarak kaydedildi
• Web tarayıcılarında yeni nesil görüntü formatı desteğinin genişlemesi açısından önem taşıyor

---

Chromium’un JpegXL çözücüsünü entegre etmesi

• Gerrit kod inceleme girdisi “Wire up JXL decoder (7184969)”, Chromium projesine JpegXL çözücüsünü bağlayan bir değişikliktir
  • Bu değişiklik, Chromium’un src deposu içinde yapıldı
  • Kod inceleme platformu olarak chromium-review.googlesource.com kullanılıyor
• Başlığın da ifade ettiği gibi bu, JXL (JpegXL) çözücüsünü tarayıcının içine bağlama (wire up) çalışması anlamına geliyor
• Sayfada ek açıklama veya kodun ayrıntıları gösterilmiyor; yalnızca değişiklik başlığı görülebiliyor

Teknik bağlam

• JpegXL, yeni nesil bir görüntü sıkıştırma formatıdır ve mevcut JPEG’e kıyasla daha yüksek verimlilik hedefler (metinde doğrudan belirtilmiyor; yalnızca teknik ad mevcut)
• Çözücünün Chromium’a birleştirilmesiyle birlikte, JXL görsellerini işleme yeteneğinin kod seviyesinde etkinleştirilmesi için temel hazırlanmış oldu
• Bu değişiklik, tarayıcı motorunun medya kod çözme yapısının genişletilmesiyle ilgili teknik bir ilerlemeyi gösteriyor

Belgenin durumu

• Sayfa, Gerrit kod incelemesinin önbelleğe alınmış bir anlık görüntüsü olarak gösteriliyor
• “shadow DOM gizlenmiş” anlamına gelen bir uyarı ifadesi yer alıyor, ancak gerçek kod içeriği gösterilmiyor
• Bu nedenle bu belgede doğrulanabilen bilgiler yalnızca değişiklik başlığı ve inceleme kimliği (7184969) ile sınırlı

[GN⁺]

Hacker News yorumları

• Cloudinary blog yazısına baktım; webp, jpegxl, avif, jpeg vb. karşılaştıran eski ama klasik bir yazı
  Grafikler iyi düzenlenmiş ve AVIF çok yavaş

  • JPEG en düşük kaliteye ayarlandığında burada çok daha iyi görünüyordu
    ilgili bölüm bağlantısı
  • Bu sitenin tam olarak ne yapmaya çalıştığını anlamadım
    ekran görüntüsüne bakın
  • Alıntılanan cümlede dendiği gibi, JPEG XL şu anda hem kayıplı hem kayıpsız için en iyi codec konumunu sağlamlaştırdıysa, JPEG ile PNG'yi tek başına değiştirebilecek büyük bir ilerleme olur
  • Yalnız bu test donanım hızlandırmalı encoder/decoder kullanmıyor

• jxl-rs kütüphanesi, JPEG XL'in Rust implementasyonu
  Nispeten yeni bir proje ama Rust sayesinde güvenlik açısından daha iç rahatlatıcı
  Önceki Chromium tartışmaları sırasında bu kütüphane yoktu

  • Google'ın JPEG XL'i reddetme gerekçesinin “ilgi eksikliği” olduğunu hatırlıyorum. Güvenlik meselesi değildi sanırım
  • “Rust güvenlik kaygılarını azaltıyor” sözüne katılmıyorum. Bellek güvenliği güvenliğin kendisi değildir
    Rust aşırı özgüven yaratabilir ve tehdit modellemesinin atlanmasına yol açabilir
    Hatta dikkatli bir C programcısı daha güvenli olabilir
  • Gerçekte ne kadar unsafe kod olduğunu kontrol ettim
    arama sonucu bağlantısı

• Yakın zamanda WebP ile AVIF'i karşılaştırdım; WebP neredeyse anında encode edilirken AVIF 1MP bir görüntüde 20 saniyeden fazla sürüyor
  JXL'in desteği hâlâ az olduğu için pratikte kullanamıyorum ama WebP seviyesinde hız ve daha iyi kalite bekliyorum

  • rav1e'nin güncellemeleri yıllardır durmuş durumda, bu yüzden aom ya da svt-av1 gibi encoder'ları kullanmak daha iyi deniyor
  • AVIF'te CPU kullanım parametrelerini ayarlamak gerekiyor. Varsayılan ayarlar çok yüksek CPU seviyesi kullandığı için yavaş
    Benim ortamımda 2MP bir AVIF'i yaklaşık 100ms'de üretiyor

• JPEG XL'in açık spesifikasyonuna (spec) serbestçe erişilememesi üzücü

  • Kapalı standartları sürdürmenin utanç verici olduğunu düşünüyorum
  • ISO, IEC gibi kurumların pek çok belgesinin ücret duvarı (paywall) arkasında olması asıl sorun

• Yine yeni bir görsel format daha geldi ama sonunda dönüştürmeden kullanılamayan bir durumun tekrarlanacağından endişeliyim

  • Yine de Microsoft bile bir JPEG XL eklentisi çıkardı ve Google geri adım attığına göre bunun gerçek bir fırsat olduğunu düşünüyorum
    Microsoft Store bağlantısı
  • Aslında zaten pek çok uygulama destekliyor — Affinity, Photoshop, Microsoft Photos, Gimp ve hatta iOS 17+/macOS 12+ ile sistem genelinde destek var
    Chromium ise daha geç kalmış durumda
  • Tabii yeni bir formatın benimsenmesi için her zaman yaklaşık 10 yıllık bir geçiş süresi gerekiyor

• Vikipedi'de JPEG XL'in özellik listesini okuyunca, çok kanallı görüntüler ya da çok sayfalı belgeler gibi ilginç özellikler gördüm
  Güzel yanları var ama giderek TIFF kadar karmaşıklaşıyormuş gibi hissettiriyor

• JPEG ile JPEG-XL arasında hâlâ pek çok ortak nokta var
  Yeni bir implementasyon mevcut JPEG desteğini de birleştirirse kod boyutunda azalma mümkün olur mu diye merak ediyorum

  • Gerçekten de bu özellik için JPEG-XL Rust deposunda bir issue açılmış
    issue #513 bağlantısı

• Kişisel olarak WEBP gibi yeni formatlar yerine mevcut JPEG kullanmaya devam etme eğilimindeyim
  Çoğu program destekliyor ve sıradan kullanıcı için JPEG + PNG yeterli
  Basit animasyonlar için GIF, karmaşık olanlar için video kullanılabilir

  • “JPEG XL” adı öyle düşündürse de sadece JPEG'in uzantısı değil
    PNG'den daha küçük boyutla kayıpsız encoding yapabiliyor ve mevcut JPEG'i %20 daha sıkıştırırken geri döndürülebilir transcoding de destekliyor
    HDR, geniş gamut, aşamalı yükleme gibi çeşitli özelliklere sahip olduğu için web aktarımı için de ideal
    jpegxl.info'ya bakın
  • WebP artık fiilen standart bir format sayılabilir
    Safari 14'ten sonra tüm büyük tarayıcılar destekliyor ve Windows 10 ile macOS Big Sur'dan itibaren varsayılan olarak geliyor
    destek durumu, yazılım listesi
  • GIF artık verimsiz. Video ile değiştirmek 5 ila 10 kat daha verimli
    ilgili yazı

• JPEG XL, WebP ve AVIF tartışmalarını uzun zamandır duyuyordum ama çok bilmiyordum
  Benchmark'lara bakınca JpegXL hem sıkıştırma hızı hem de boyut açısından WebP'den üstün görünüyor; o zaman Chromium neden benimsemekte isteksizdi diye merak ediyorum

  • WebP ve AVIF, VP8/AV1 ile kod paylaşabildiği için tarayıcıya entegrasyonu kolay, buna karşılık JPEG-XL ayrı bir kod tabanı olduğundan implementasyon yükü büyük
    Ayrıca libjxl 100 bin satırı aşan bir C++ kod tabanı olduğu için güvenlik açığı riski taşıyordu
    Rust implementasyonu olgunlaştıkça Chrome'un yeniden değerlendirdiği anlaşılıyor
  • JPEG XL aşamalı decoding destekliyor
    demo videosu
  • Google, “Benzer formatlardan birden fazlası yalnızca güvenlik riskini artırır” diyerek tek başına AVIF'in yeterli olduğunu savunmuştu
  • AVIF düşük bpp'de (düşük kalite) iyi ama kayıpsızda zayıf; buna karşılık JXL yüksek kalite ve kayıpsızda güçlü
  • Geçmişte JPEGXL C++ kütüphanesi bakımsız durumdaydı, ancak Rust sürümü çıkınca tarayıcıların benimsemesi mümkün hâle geldi

• JPEG XL'in animasyon destekleyip desteklemediğini merak ettim

  • Destekliyor ama kareler arası sıkıştırma olmadığı için verimsiz, bu yüzden normal videodan daha büyük oluyor
  • Chrome platform durum sayfasına göre animasyon, HDR ve aşamalı decoding desteği var
    ayrıntılı bağlantı
  • Gerçekten Canary tarayıcısında test ettim ve animasyon sorunsuz çalıştı
  • Birisi şakayla, WebP'nin aslında “video formatı olan bir görsel”, JPEG XL'in ise “görsel formatı olan bir video” olduğunu söylemişti; bu da ironik bir simetri yaratıyor 😄