Google JPEG XL Desteğini Yeniden Canlandırdı mı?

 (tonisagrista.com)
5 puan yazan GN⁺ 2025-12-03 | 2 yorum | WhatsApp'ta paylaş
  • Chromium motoru JPEG XL desteğini geri yüklemesiyle, bir zamanlar terk edilmiş bir görüntü formatı yeniden gündeme geldi
  • Google, JPEG XL'i 2022 yılında “ekosistemdeki yetersiz ilgi” gerekçesiyle kaldırmıştı; buna rağmen topluluk ve önde gelen şirketlerin sürekli baskısı sürdü
  • Meta, Intel, Adobe, Cloudinary, Krita gibi birçok kuruluş, formatın korunma gerekliliğini açıkça destekledi
  • Son dönemde PDF Association'ın HDR içeriği için temel format olarak JPEG XL'yi benimseme niyetini ilan etmesiyle ivme arttı
  • Chrome'un yeniden ekleme kararı, JPEG XL'in geniş çapta standartlaşma ihtimalini yükselten bir dönüm noktası olarak değerlendirildi

JPEG XL'nin Canlanma Arka Planı

  • 2022'de Chromium ekibi, JPEG XL'i “mevcut formatlara kıyasla yeterli ekosistem ilgisi ve avantaj eksikliği” gerekçeleriyle kodu ve bayrakları kaldırdı
    • O dönemde topluluk, Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips, Krita gibi ana kuruluşların desteğini dile getirdi
    • Takiben bloglar, videolar ve sosyal medya aracılığıyla silinme kararının haksızlığına karşı tepkiler sürdü
  • 2025 sonunda, Chromium ekibi Obsolete durumundaki JPEG XL konusunu Assigned olarak değiştirerek resmi olarak geri getirme sürecine başladı
    • Blink geliştirici grubundan Rick Byers, “performanslı ve bellek güvenli bir JPEG XL kod çözücüsünü memnuniyetle karşılıyoruz” diye belirtti
    • Bu karar, Safari'nin desteği, Firefox'un tutum değişikliği, PDF Association'ın benimseme girişimleri gibi olumlu sinyaller üzerine kuruluydu

Firefox ve Rust Tabanlı Kod Çözücü Geliştirme

  • Firefox ekibi, JPEG XL'in C++ tabanlı libjxl kod çözücüsünün güvenlik riski nedeniyle “bellek güvenli” bir Rust sürümüne ihtiyaç duyulduğunu savundu
    • Bu nedenle Google Research, Rust uygulaması jxl-rs geliştirmeye başladı
    • Bu proje, JPEG XL'in tarayıcı içinde güvenli entegrasyon olasılığını artıran bir etken oldu

PDF Association'ın Benimseme Hamlesi

  • PDF Association CTO Peter Wyatt, JPEG XL'i PDF spesifikasyonunun HDR görüntüleri için standart biçim olarak dâhil etme niyetini duyurdu
    • Bu, belge ve yayıncılık alanında JPEG XL'in standartlaşma potansiyelini güçlendiren bir faktör oldu

JPEG XL'nin Ana Teknik Özellikleri

  • Mevcut JPEG'ten kayıpsız yeniden sıkıştırma ile kalite kaybı olmadan yaklaşık %30 kapasite düşüşü sağlanabiliyor
  • Geniş renk alanı ve HDR desteği, en fazla 32 bit kanal ve 4,099 kanal işleme
  • Maksimum görüntü boyutu 1,073,741,823×1,073,741,824 desteğiyle devasa görselleri işleyebilir
  • Aşamalı kod çözümleme (progressive decoding) desteğiyle web aktarım verimliliği artar
  • Animasyon, alfa saydamlık, derinlik haritası (depth map) özellikleri içerir
  • Tekrar tekrar kodlamaya dayanıklı yapısı sayesinde kuşaklar arası kalite kaybı minimuma iner

Sonuç

  • JPEG XL, bir sonraki nesil görüntü formatı için gerekenleri karşılıyor ve Chrome motorunun geri dönüşü yaygın yayılma için belirleyici bir adım
  • Topluluk baskısının uzun vadeli sonucu olarak yapılan bu geri dönüş, web görüntü ekosisteminin yeni bir standart adayı olarak ortaya çıkıyor
  • Yazar, Chromium'un yeniden değerlendirmesini memnuniyetle karşılarken, bu kararın çok geç alındığını vurguluyor

İlgili okumalar

2 yorum

 
GN⁺ 2025-12-03
Hacker News görüşü

  • JPEG XL'in daha az bilinen harika özelliklerinden biri, JPEG'den kayıpsız transcode yaparken yaklaşık %20 depolama alanı tasarrufu sağlayan bir moda sahip olmasıdır
    Orijinal entropi bit akışını aynen koruduğu için tamamen tersinirdir
    GCP bunu DICOM Store API'ye uyguluyor; böylece JXL'in alan tasarrufundan yararlanırken gerektiğinde anlık olarak JPEG'e dönüştürüp sunabiliyor
    Şirketimiz onlarca PB ölçeğinde veriyi GCP DICOM Store'da saklıyor; bu özelliğin yıllık ücretleri ciddi biçimde düşürmesini bekliyoruz
    Tarayıcıda yerel destek de umuluyor; Chrome ekibinin sonunda destek vereceğine dair şeyler duyduk

    • Ortalama bir JPEG encoder'ı ya da mozjpeg ile karşılaştırıldığında farkın ne olduğunu merak ediyorum
    • Geçmişte GCP DICOM Store'u test etmeye zaman bulamamıştım; pratikte nasıl olduğunu merak ediyorum
      Tam bir PACS mi, bir WADO uygulaması mı, yoksa sadece özel bir API mi olduğunu bilmek isterim
    • Tersinir ise neden doğrudan JPEG XL olarak saklayıp servis sırasında tekrar dönüştürmüyoruz diye merak ediyorum
      Acaba işlem süresi mi çok yüksek?
    • Zaten orijinal DICOM'u saklamak gerekiyorsa transcode etmenin ne anlamı var emin değilim
      Depolama maliyetinin büyük kısmı muhtemelen DICOM'un kendisidir
    • Sonuçta GCP'nin büyük müşterileri bu özellikten ciddi fayda sağlıyor; bu da Chrome'da JXL'i itmelerinin nedeninin dahili müşteriler olduğu düşüncesini uyandırıyor

  • JPEG XL'in rakibi AVIF değil
    AVIF zaten fiili standart haline geldi; neredeyse tüm tarayıcılar destekliyor ve Apple'ın varsayılan görüntü formatı olarak da kullanılıyor
    JXL'in tarayıcı desteği hâlâ zayıf olsa da arşivleme, profesyonel fotoğrafçılık ve tıbbi kullanım gibi niş alanlarda yer edinmeye başlıyor
    10 yıl kadar sonra insanların ona kısaca “JPEG” diyecek kadar yaygınlaşması mümkün
    AVIF açık ve telifsiz bir standarttır; JPEG/WebP'den çok daha iyi sıkıştırma verimi sunar ve JXL'e de yakın bir seviyededir
    JXL'in azami görüntü boyutu daha büyük olsa da gerçek benimsenmede AVIF çok daha ileride
    AV2 çıktığında kalite farkı neredeyse kaybolacak; iki formatın da gelişerek benzer kalite düzeyini koruyacağını düşünüyorum

    • AVIF'in JPEG ya da WebP'den daha verimli olması zaten beklenir ama JXL ile rekabet edemez
      Gerçekçi kalite ayarlarında JXL daha yüksek sıkıştırma oranı ve daha hızlı encode/decode sunuyor
      Ayrıca progressive decoding de destekliyor
      AV2 çıkınca yetişebilir ama şu an JXL'in çok önde olduğunu düşünüyorum
    • Chrome ekibinin JXL desteğini bırakma nedenlerinden biri, AVIF'in zaten yeterince iyi olmasıydı
      Bu yeniden değerlendirme de o zamanki kararla bağlantılı görünüyor
    • “Apple'ın varsayılan görüntü formatı AVIF” sözü yanlış gibi geliyor
      iPhone HEIF kullanıyor
    • libjxl'i doğrudan denedim; bellek kullanımı yüksekti ve kararsızdı
      Yüksek çözünürlüklü görüntüleri encode etmek için terabayt düzeyinde RAM gerekecek kadar kötüydü
      Kod tabanının dağınık olması beni şaşırttı ve birçok seçeneğin düzgün çalışmadığını gördüm
      jxl-rs ile yeniden denenmesi olumlu ama aynı geliştiriciler işin içinde olduğu için temkinliyim

  • Chromium'un JPEG XL işlevi için jxl-rs crate kullanma ihtimali yüksek
    Muhtemelen yeterince kararlı hale gelmesini bekleyip sonra entegre etmeyi planlıyorlar
    İlgili issue'ya buradan bakılabilir

    • Mozilla'nın tutumu da benzerdi ama Google bir süre düşmanca bir tavır sergiledi
      Kullanıcıların itirazına rağmen issue'yu kapattılar, yakın zamanda da yeniden açtılar
      Muhtemelen PR sorunu ya da içerideki hoşnutsuzlukla ilgilidir
    • jxl-rs'de bir buçuk yılı aşkın süre hiç commit olmayan bir dönem vardı
      Şu an iyi gidiyor olması biraz da şanslı bir gelişme olabilir

  • JPEG XL'in referans implementasyonuna (C++) baktım; 2 yıl önce bile kod kalitesi iyi değildi
    Güvenlik sorunu çıkacakmış gibi hissettiriyordu

    • Bu yüzden hem Mozilla hem Google, JXL desteğini bellek güvenli bir implementasyon şartına bağlamış durumda
      Rust sürümü geliştiriliyor ve Google'ın Chromium'daki tüm decoder'ları zamanla Rust ile değiştirme planı var
    • Açıkçası bugünlerde (2025 itibarıyla) C++ ile yazılmış büyük ölçekli görüntü işleme kodu zaten başlı başına bir güvenlik riski
      Bu sadece JPEG XL'e özgü bir sorun değil

  • JPEG XL'in azami çözünürlüğü 1,073,741,823 × 1,073,741,824; yani yüzlerce petabaytlık ultra yüksek çözünürlüklü görüntüleri ifade edebiliyor
    Pratikte sıkıştırmadan sonra bile onlarca ila yüzlerce PB düzeyinden söz ediyoruz

    • 600DPI temel alındığında bir kenar maraton mesafesine denk geliyor
      Böyle devasa görüntülerin çok küçük bir byte alanında tanımlanabilmesi bir DOS saldırı vektörü de olabilir gibi görünüyor
      Bunu A4 kağıda çevirmeye çalıştım ama Gemini hesaplayıcısı birimleri karıştırıp saçma bir sonuç verdi
    • Böyle aşırı büyük görüntülerle başa çıkmanın tek pratik yolu tiling ve piramit yapısı kullanmaktır
    • Muhtemelen tüm Dünya'nın yaklaşık 4 cm çözünürlükle çekilmiş bir görüntüsü kadar büyüktür
    • O çözünürlükte selfie çekseniz süper çözünürlüklü mikroskop seviyesinde olurdu
    • JPEG XL, AVIF'in aksine verimli progressive decoding desteklediği için indirme sürerken bile hızlıca düşük kaliteli önizleme gösterebilir

  • Geçmiş HN tartışmalarının derlemesi
    Chromium Team Re-Opens JPEG XL Feature Ticket
    FSF Slams Google over Dropping JPEG-XL in Chrome
    Google set to deprecate JPEG XL support in Chrome 110
    Chromium jpegxl issue closed as won't fix

  • Birkaç yıldır .avif kullanıyorum
    Mükemmel değil ama .jpg ya da .png'den çok daha iyi olduğunu düşünüyorum
    .webp ve jpeg-xl'i de değerlendirdim ama sonunda .avif'ten memnun kaldım
    Yine de Google'ın web standartlarını fiilen yönlendirmesinden rahatsızım
    Ticari bir şirketin dijital ekosistemi kontrol etmesi sağlıklı değil

    • “.jpg'den .avif daha iyi” cümlesinde .avif'in iki kez tekrar edilmesi kafa karıştırıyor
    • Yüksek kaliteli JPEG'i küçük boyutta istiyorsanız jpegli denemenizi öneririm
      jpegli GitHub
      AVIF'in görsel olarak kayıpsız ayarları iyi seçilirse jpegli'den daha küçük olabilir ama ortalama olarak jpegli daha verimlidir
    • Bu arada İngilizcede “since some years” yerine “for several years” daha doğal durur
    • JPEG XL tekrar tekrar kaydedilse bile kalite kaybı daha az olduğu için web ortamı için avantajlıdır
      İlgili video: YouTube bağlantısı

  • JXL'i kaldıran “Google'ın tamamı” değil, Chrome ekibiydi
    JXL, Google Zürih araştırma laboratuvarından Jyrki Alakuijala tarafından tasarlandı; kendisi Chrome ekibinde değil, Google Research tarafındaydı
    Chrome ekibinin Mountain View merkezli kapalı bir kültürü var

    • Jyrki, Brotli, WebP lossless, WOFF2, jpegli gibi işlerin de arkasındaki çok yetenekli bir mühendistir
      JpegXL rafa kaldırıldıktan sonra jpegli'yi yapması da bir tür tepkiydi
    • Bu durumu Conway’s Law ile açıklamak mümkün olabilir

  • C++ tabanlı ve çok sayıda çok iş parçacıklı bağımlılık içeren yapının güvenlik saldırı yüzeyini büyütebileceği gerekçesiyle JXL gecikmiş gibi görünüyor
    Hem Mozilla hem Google bunu önlemek için Rust implementasyonunu tercih ediyor
    Standardın kendisi ise açıkça mevcut formatlara göre daha iyi

    • 100 milyon satır ifadesi fazla abartılı görünüyor
    • Gerçekte yaklaşık 30 bin satır ve tek iş parçacıklı sürüm yaklaşık 10 bin satır civarında
      AVIF'ten ikili dosya boyutu olarak da çok daha küçük ve spesifikasyonu da çok daha kısa
    • Google JXL geliştirmesine katıldığına göre bellek güvenli bir decoder'ı hızlıca yapmamış olması kendi sorumluluğu
    • Acaba 100 bin satır mı demek istemişti? Bunun önemli bir kısmı muhtemelen test kodudur
    • Gerçek libjxl yaklaşık 112 bin satır; yani 100 milyon satır iddiasından 3 basamak daha düşük

  • iPhone 17 Pro'nun RAW dosyalarının JPEG XL ile sıkıştırıldığı söyleniyor