Yeni PNG spesifikasyonu yayımlandı

 (programmax.net)
9 puan yazan GN⁺ 2025-06-26 | 2 yorum | WhatsApp'ta paylaş
  • PNG dosya formatı, 20 yıl sonra yeniden revize edilerek eski konumuna geri dönüyor
  • Bu spesifikasyonda HDR desteği, APNG (animasyon), Exif verisi için resmi destek gibi birçok modern teknoloji yer alıyor
  • Geliştirme sürecine Adobe, Apple, Google gibi büyük BT şirketleri ve yayıncılık kuruluşları ortak olarak katıldı
  • En güncel spesifikasyon, Chrome, Safari, Photoshop gibi çeşitli programlarda zaten destekleniyor
  • İleride daha iyi sıkıştırma teknolojileri ve paralel kodlama/kod çözme gibi ek güncellemeler planlanıyor

Giriş: PNG'nin dönüşü ve önemi

  • Son dönemde PNG dosya formatı, yaklaşık 20 yıllık durgunluğun ardından yeni bir spesifikasyonla güncellendi
  • ABD Kongre Kütüphanesi, Kanada Kütüphane ve Arşivleri, Avustralya Ulusal Arşivi gibi önemli kurumlar PNG'yi resmi olarak önerilen format olarak benimsiyor
  • Yeni spesifikasyon sayesinde PNG, pazarda rekabet gücünü yeniden kazanıyor ve yenilikçiliğini ortaya koyuyor

Yeni özellikler ve öne çıkan noktalar

Uygun HDR desteği ve geleceğe dönük uyumluluk

  • Yeni PNG, HDR (High Dynamic Range) desteği sunuyor
  • Rec. 2020 ve Rec. 709 renk gamı karşılaştırma görseli, daha geniş alanın (dış üçgen) HDR görüntünün ifade ettiği renkleri gösterdiğini ortaya koyuyor
  • Bu HDR bilgisi yalnızca ek 4 bayt (ve mevcut PNG chunk ek yükü) gerektiriyor
  • Chris Lilley gibi ilk yazarlar ve önemli teknik uzmanlar sürece katılarak yeni teknolojiyi açık biçimde açıklıyor

APNG'nin (animasyonlu PNG) resmi olarak tanınması

  • İlk olarak Mozilla tarafından önerilen ve Firefox tarafından desteklenen animasyonlu PNG (APNG) de artık resmi spesifikasyona dahil edildi
  • Daha önce yalnızca bazı yazılımlar tarafından desteklenirken, artık çeşitli programlarda yaygın biçimde benimsendi

Exif verisi için resmi destek

  • Exif sayesinde telif hakkı, kamera bilgisi, GPS bilgisi gibi meta veriler saklanabiliyor
  • Görsel üretimi ve arşivleme, telif yönetimi gibi alanlarda yüksek fayda sağlıyor

Genel iyileştirmeler ve hata düzeltmeleri

  • Mevcut spesifikasyondaki hatalar (errata) için düzeltmeler ve açıklamalar da birlikte yapıldı

Arka plan ve geliştirme süreci

  • Son PNG spesifikasyonu yaklaşık 20 yıl önce yayımlanmıştı (iPhone'un çıkışından 3,5 yıl önce)
  • W3C Timed Text Working Group (altyazı teknolojisi standardizasyonu), PNG'de HDR desteği ihtiyacını gündeme getirince geliştirme yeniden başladı
  • Öneri ortaya çıktıktan sonra Adobe, Apple, BBC, Google, MovieLabs, W3C gibi büyük teknoloji kuruluşları ortak çalışmaya katıldı
  • Güçlü bir konsorsiyum kurularak format yeni nesil bir görüntü biçimine dönüştürüldü
  • Şu anda iki takip güncellemesi de zaten hazırlanıyor

Zaten geniş ölçekte uygulanmış durumda

  • Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer gibi çok sayıda program en güncel PNG spesifikasyonunu destekliyor
  • Yayıncılık şirketleri ile ilgili donanım ve araçlarda da destek genişliyor
  • Haber akış yazıları, spor skor bantları gibi yayın görselleri yeni HDR PNG kullanım örnekleri arasında yer alıyor

Gelecek planları

  • Bir sonraki sürümde HDR & SDR uyumluluğunun daha da iyileştirilmesi planlanıyor
  • Buna ek olarak daha gelişmiş sıkıştırma yöntemleri, paralel kodlama/kod çözme de gündemde
  • Dördüncü edisyonun nispeten kısa bir güncelleme olması, ardından sıkıştırma teknolojisi araştırmalarına dayanarak beşinci edisyonun geliştirilmesi planlanıyor

İlgili okumalar

2 yorum

 
carnoxen 2025-06-26

Başta kuruluş, Apng'yi görüntü için bir standart olmadığı gerekçesiyle reddetmişti; ancak şimdi nihayet kabul etmişler.
 
GN⁺ 2025-06-26
Hacker News görüşleri

  • Yazar olduğunu belirtiyor ve sorusu olan herkesi her zaman memnuniyetle karşılayacağını söylüyor

    • Bu PNG’nin tamamen yeni bir format değil, mevcut formatın güncellenmiş bir sürümü olduğunu vurguluyor

    • Çok yüksek düzeyde geriye dönük uyumluluk sunduğunu belirtiyor

    • Eski programların da yeni PNG dosyalarını mümkün olduğunca iyi okuyabildiğini, örneğin bunun kırmızı bir elma fotoğrafı olduğunu hâlâ anlayabildiğini açıklıyor

    • PNG’nin iç işleyişi konusunda karışıklık olabileceğini söyleyip temel noktaları özetliyor

      • PNG dosyası çeşitli veri parçalarından (chunks) oluşur
      • Her parçanın bir adı vardır; bu sayede programlar bilmedikleri veya ihtiyaç duymadıkları parçaları kolayca atlayabilir
      • Görüntü akışının yalnızca bir tane olduğunu açıkça belirtiyor

    • Yeni PNG spesifikasyonunun özelliklerini kullanan örnek dosyalar olup olmadığını, özellikle animasyonlu veya HDR görselleri doğrudan indirip program uyumluluğunu test etmeye yarayan bir demo sayfası olsa iyi olacağını söylüyor

    • Meta formatları ve genel amaçlı araç ekosistemini desteklediğini belirtiyor

      • Office Open XML veya ePub gibi, yalnızca zip ve XML kütüphaneleriyle ayrıştırılabilen yapıları örnek veriyor
      • PNG’nin de neredeyse Interchange File Format (IFF) ile aynı yapıya sahip olduğunu, ancak eskiden standartta küçük farklar bulunduğu için gerçekten genel amaçlı bir IFF ayrıştırıcısıyla hem PNG hem de IFF türevi dosyaları birlikte ayrıştırmanın mümkün olmadığını kendi deneyimiyle anlatıyor
      • IFF’nin kolay uygulanabildiğini ve veri sıkıştırma açısından güçlü olduğunu, ancak bugüne kadar daha çok eski oyun verileri, AIFF·RIFF ses dosyaları gibi sınırlı alanlarda kullanıldığını; genel amaçlı araçların gelişmemesinin nedenlerinden birinin PNG ile IFF arasındaki uyumsuzluk olduğunu söylüyor
      • PNGv3 ile PNG dosyaları resmen IFF dosyası hâline gelirse, PNG’nin yaygınlığını kullanarak genel amaçlı bir IFF ekosisteminin (ör. libiff gibi) büyümesini ve yeni format tanımları için de kullanılmasını umduğunu belirtiyor
      • Gerçekten kendi PNG/IFF ayrıştırıcısını yazdığını, sadece PNG’yi biraz değiştirerek IFF uyumluluğu kazandırmanın zor olduğunu ve geriye dönük uyumluluğun, özellikle donanım ayrıştırıcılarında, korunması gerektiğini söylüyor
      • PNG’nin kullandığı değiştirilmiş IFF yapısının yeni bir meta format standardı olarak (IFF 2.0) ayrı biçimde belgelenmesini öneriyor
      • IFF 2.0 içinde PNGv2 ile uyumlu bir profilin ve AIFF/RIFF gibi IFFv1’i de kapsayan profillerin resmileştirilmesini, böylece genel amaçlı IFF araçlarının geliştirilebilmesini istiyor
      • Hatta yeni bir greenfield profilinde (modern ortamlara uygun yeni bir formatta), örneğin CRC yerine modern hash’lerle bütünlük kontrolü, parça adları için genişletilmiş karakter kümesi ve her parçanın nitelik bilgisini verimli biçimde taşıyan yapılar getirilebileceğini söylüyor
      • Bu yapıların hem IFFv1’i hem PNGv2’yi dönüştürülebilir (transcode) kılması gerektiğini, tıpkı HTML5’in HTML4 ve XHTML ile birlikte çalışmasına benzer stratejik profil tanımlarının doğru yaklaşım olacağını düşünüyor
      • Sonuç olarak ayrıntılardan çok tasarım hedeflerine, yani eski ve yeni formatlar arasındaki yabancılığı en aza indirmeye ve araç ekosistemini büyütmeye odaklandığını vurguluyor

  • Web tabanlı çizim aracımda belgenin JSON gösterimini PNG’nin yorum alanına kaydetme numarası kullanıyorum

    • Böylece kaydedilen dosya doğrudan görsel olarak da kullanılabiliyor, editöre geri de yüklenebiliyor

    • İndirilenler klasöründe ne olduğu anlaşılmayan JSON dosyalarının birikmemesi gibi bir avantajı var

    • Eğlenceli ama kullanıcıya dosyanın neden .png olarak kaydedildiğini ya da Paint gibi bir programda açıp yeniden kaydedince verinin neden kaybolduğunu anlatmak zor olabiliyor

    • Krita da fırça ayarlarını bu şekilde kaydediyor, fakat veri çok büyük olduğunda beklenmedik sorunlara yol açabiliyor

    • Macromedia Fireworks 20 yıl önce de PNG’yi varsayılan kayıt formatı olarak kullanıyordu

      • Elbette o zaman içine JSON koymuyordu

    • Birçok yapay zeka görsel üretim arayüzü de benzer şekilde kullanıyor

      • Görsel yorumuna (comment) prompt veya ayarları kaydedip sadece görseli açarak yapılandırmayı geri yüklemek ya da ComfyUI gibi tüm iş akışını çağırmak mümkün oluyor
      • Aslında görselle çalışan araçlarda bu yaklaşımın oldukça yaygın olduğunu düşünüyor

    • Macromedia Fireworks, Fireworks dosyasını PNG içine kaydediyordu ve

      • Adobe’nin Illustrator (AI) dosyaları aslında PDF’dir
      • Photoshop’un PSD dosyaları da TIFF içine gömülebilir
      • Bu yüzden Photoshop’ta birden çok katman görünürken başka yazılımlarda sadece tek katman görünebilir

  • Bu spesifikasyon zaten yaygın biçimde uygulanmış şeylerin resmileştirilmesine daha yakın

    • Eğer “yeni nesil PNG” denip gerçekten yeni bir çözücü gerekecekse buna PNG2 denebilirdi diye düşünüyor

    • JPEG-XL zaten çoğu kişinin istediği kayıpsız kodek özelliklerini büyük ölçüde sağlıyor

      • Sorun kodlama/çözme hızı ve kaynak kullanımı

    • Şu anda kayıpsız görsel kodeklerde en iyisinin HALIC olduğunu söylüyor

    • HALIC tartışma başlığına göre gerçekte LEA 0.5 daha iyiymiş

    • Dürüst olmak gerekirse bir süre JPEG XL’i sadece “çok büyük görseller” için sanıp görmezden geldiğini söylüyor

    • Bilgisayarlı görü için görsel anotasyon aracı olan XLabel’da png kullandığını söylüyor

      • Sınıf etiketlerini doğrudan görsel meta verisine kaydettiği için ayrı metin dosyalarına gerek kalmıyor
      • Gelecekte bu kullanım türüne uygun genişletilmiş bir format yapmak istiyor

    • WebP’nin kayıpsız sıkıştırması sektörün en iyileri arasında olsa da yaygın kullanılmıyor

      • Buradan, kayıpsız sıkıştırmada en iyi sonuca ulaşmanın tek başına önemli olmadığı, ekosistem tarafından benimsenmenin asıl mesele olduğu sonucu çıkıyor

    • Kodlama/çözme hızı konusu zamanla iyileşebilir

      • Bu, geçmişte jpg ekosisteminde gerçekten yaşanmış bir değişimdi

  • Exif verisinin resmî olarak desteklenmesi en iyi haber

    • Daha önce de başlık kısmına özel veri yazılabiliyordu ama Exif desteği çok sevindirici

    • Bu arada Exif içinde jiroskop (dönüş) ya da ivmeölçer (yerçekimi) ile ilgili alanlar olup olmadığını merak ediyor

      • Google Kamera uygulamasıyla çekilen fotoğraflarda bu bilgiler olmadığından, sonradan otomatik düzeltme veya panorama birleştirme yaparken eksikliği hissediliyordu

    • İvme alanı (Exif.Photo.Acceleration) ve yükseklik için bir alan (Exif.Photo.CameraElevationAngle) var,

      • ancak üç eksenin tamamını desteklemiyor
      • Ortam sensörleriyle ilgili alanlar mevcut ama sadece standart yazarlarının belirlediği belirli maddeler destekleniyor
      • Exif.Photo.MakerNote, üreticilerin istedikleri bilgiyi kaydedebildikleri serbest bir alan ve 9 eksenli verileri bile yazmaya yetecek kadar geniş bir boyut sınırına sahip

    • Exif, görselin işlenmesinde dönüşün nasıl ele alınacağı konusunda karışıklık yaratabiliyor

      • Eski ve yeni çözücüler, Exif dönüşünü uygulayıp uygulamamaya göre aynı görseli farklı gösterebilir
      • Exif dönüşü için somut çözücü tavsiyeleri olmadığından, çift dönüş (ör. masaüstü ortamı ve kütüphane ayrı ayrı uyguladığında) gibi hatalar da sık görülüyor
      • Sadece “çözücü Exif verisinin güvenilir olup olmadığını ayrıca bilemiyorsa, Exif verisi sadece tarihsel kayıt değeri taşıyor kabul edilmelidir” gibi muğlak bir tavsiye var
      • Tam geriye dönük uyumluluk için “asla döndürme uygulama” gibi net bir yönerge gerektiğini düşünüyor

    • Kameranın ivmeölçer veya ataletsel navigasyon birimi verisini kaydetmek için standart bir alan yok

    • Gerçekte birçok web sitesi yükleme sırasında Exif verisinin çoğunu siliyor

      • Çünkü bazı alanlar gizlilik ihlali veya konum takibi için kötüye kullanılabiliyor

    • Kişisel olarak insanların Exif yerine XMP kullanmasını tercih ettiğini söylüyor

      • Exif’nin yapısı tuhaf ve özünde TIFF görselini PNG içine gömmek gibi bir şey

  • Bu PNG spesifikasyonu zaten yaygın kullanılan uygulamaları resmen kodlaştırıyor

    • En iyi kodek her yerde, her uygulamada, OS kabuğunda, API’de ve Linux’ta da çalışmalıdır

    • HEIC veya AV1 gibi formatlar, işletim sistemi seviyesinde destek yoksa dosyayı önizlemek için bile sorun çıkarabiliyor

    • Düzgün şekilde dolaşıma girmemiş formatlar platform varsayılanı olmamalı

    • Birçok görsel formatıyla, özellikle de yalnızca belirli alanlarda kullanılan nadir formatlarla çalışan biri olduğunu söylüyor

      • Farklı formatları gerçekten desteklemek çok büyük bir meydan okuma
      • Kütüphaneler yüzeyde jpg/tif/heic desteği yazsa da, örneğin 30 GB’lık bir jpeg’i ya da tüm meta veriyi gerçekten sorunsuz işleyip işlemedikleri bambaşka mesele

    • Bu yeni spesifikasyon aslında HEIC veya AV1’den bile daha kafa karıştırıcı olabilir

      • PNG’nin içinde hangi kodeğin bulunduğunu dosyayı açmadan hiç bilemezsiniz

  • HDR’nin şimdiye kadar ilk kez açıkça parlaklık/kontrast aralığı genişlemesi değil de “daha geniş renk uzayı” anlamında kullanıldığını gördüğünü söylüyor

  • Bunun çok geç kalmış olup olmadığını sorguluyor

    • Ayrıca JPEG XL’in zaten tüm özellikleri (kayıplı/kayıpsız sıkıştırma, animasyon, HDR, Exif vb.) ve gelişmiş sıkıştırma tekniklerini (finite state entropy, ZStandard vb.) sunduğunu söylüyor

    • Ayrı bir PNG güncellemesine gerek olmadığını, doğrudan JPEG XL kullanılması gerektiğini düşünüyor

    • Ama “sadece benimseyelim” demek pratikte işe yaramıyor

      • JPEG XL browser support status: 5 yıl geçmesine rağmen destekleyen yalnızca tek bir tarayıcı var
      • Tarayıcı üreticileri uygulamazsa geliştiriciler ve kullanıcılar yeni formatları kullanamıyor

    • “Gelişmiş sıkıştırma teknikleri (ZStandard vb.)” ifadesi hakkında

      • ZStandard, sabit değişim aralığına sahip sayıları (ör. gradyanlar) sıkıştırmada aslında iyi olmayabilir
      • Bzip2 bu tür durumlarda daha iyi olabilir; örnekteki gibi iki değişkenin (iç, dış tekrarlar) renk kanallarına denk geldiği senaryolarda daha uygun olabilir
      • Gerçek veride gürültü olduğu için durum bu kadar basit değil ama bu tür algoritma karşılaştırmaları yine de pratikten kopuk kalabiliyor

    • “PNG güncellemesine gerek yok, JPEG XL’i benimseyelim”

      • O zaman bunu Google’a söylemek gerekir
      • Nitekim Google, Chrome’da JPEG XL desteğinden vazgeçti (ilgili sorun) ve bu da ekosistemin büyümesini fiilen engelledi

    • Neden bir standart daha (bir türev daha) üretildiğini anlamadığını söylüyor

      • Zaten yeterince karışıklık varken, kendine özgü net bir avantajı olmayan yeni standartların çoğalmasından yakınıyor

  • Artık GIF’i APNG (alfa harmanlama + şeffaf arka plan + kayıpsız sıkıştırma) ile değiştirmek mümkün olabileceği için 2000’ler web havası geri gelebilir

    • Animated SVG diye bir standart olup olmadığını merak ediyor

      • Eskiden JavaScript tabanlı SVG animasyonlarını (ör. chatbot avatarları gibi) gördüğünü ama standart bir çerçeve olup olmadığını bilmediğini söylüyor

    • Animated SVG var

      • Başlıca SVG animasyon öğeleri: set, animate, animateTransform, animateMotion
      • Ayrıntılar: SVG animation reference

    • Bugünlerde GIF yerine sessiz videoların (ör. mp4) daha iyi sıkıştırıldığı için daha çok kullanıldığını bildiğini söylüyor

      • Animated PNG’nin AV1 gibi video formatlarına göre ne kadar rekabetçi olduğunu merak ediyor

    • GIF yüklemeyi destekleyen hizmetlerin çoğunda APNG veya animated WEBP desteği neredeyse hiç yok

      • Backend desteği pratikte sıfıra yakın olduğu için bunu çok can sıkıcı buluyor

    • Kısa videoları animasyonlu grafiğe dönüştürürken WEBP zaten baştan beri APNG’den daha iyiydi

      • GIF ara format olarak kullanıldığında APNG ancak biraz rekabet edebiliyor
      • Günümüzde en iyi seçenek AVIF

    • Birkaç yıl önce Lottie (Bodymovin) kütüphanesini kullandığını söylüyor

      • Adobe After Effects’te animasyon hazırlayıp svg ve json olarak dışa aktardıktan sonra lottie JS ile web’de kolayca animasyon uygulayabiliyordu
      • Vektör tabanlı web animasyonlarında düzgün araçlar ve DX’in (geliştirici deneyimi) yetersiz olduğunu hissettiğini söylüyor
      • Animated PNG tarafındaki araçlar ve DX hakkında da bilgi istiyor

  • PR’de yer alan “birçok program yeni PNG spesifikasyonunu zaten destekliyor” iddiası konusunda

    • Photoshop’un APNG desteklediği yönündeki ifade yanlış

      • APNG tanımanın What’s new listesindeki ikinci madde olmasına rağmen, Photoshop’ta gerçekte destek olmaması hayal kırıklığı yaratmış

    • Photoshop HDR kısmını destekliyor ama APNG kısmını desteklemiyor

  • Birisi, insanların tarih/saat belirsizliğini yazılımsal olarak tutarlı şekilde yönetebilmesi gerektiğini söylemiş

    • “Fotoğraf 2025’te tarandı, içeriği Paskalya civarı, 1920 ile 1940 arası” gibi belirsiz zaman bilgisinin yönetilmesine ihtiyaç olduğunu belirtiyor

    • EXIF’te DateTimeDigitized alanı var

    • Google Photos ve Apple Photos içinde tarih doğrudan atanabiliyor ama bu bilgi gerçekte EXIF’e yazılmıyor

      • Platform değiştirildiğinde, EXIF olmayan görsellerde tarih bilgisinin de birlikte kaybolması sorunu ortaya çıkıyor