Regresif JPEG

 (maurycyz.com)
1 puan yazan GN⁺ 21 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • İlerlemeli JPEG'in çoklu tarama yapısı değiştirilerek, indirme ilerledikçe görüntü kalitesinin artması yerine, ekranda gösterilen görüntünün sürekli başka bir görüntüyle değişmesi sağlanabilir
  • Her tarama; renk kanallarını, DCT frekans aralığını ve hassasiyeti belirtir; aynı çözünürlükteki JPEG'lerde bazı işaretleyiciler kaldırılıp art arda eklendiğinde mevcut işleme verisinin üzerine yazılabilir
  • Kod çözücüler, sıkıştırma bombasına benzer sorunları önlemek için işleyecekleri tarama sayısını sınırlar; Chrome yaklaşık 90 kareye kadar işler, Firefox vb. ise daha fazlasını işler
  • Her karede yalnızca DC'ye özel tek bir tarama kullanılırsa kare sayısı artırılıp izler önlenebilir, ancak DCT blok yapısı nedeniyle ortaya çıkan çözünürlük özgünün 1/16'sına düşer
  • Tek bir JPEG içinde video gibi birden fazla kare taşınabilir, ancak zamanlama bilgisi olmadığından oynatma hızı ağ gecikmesine bağlıdır; pratik videodan çok kısmi işleme kullanan HTML ve tek sayfalı uygulama deneyleri için uygundur

İlerlemeli JPEG görüntüyü nasıl gösterir

  • JPEG, düşük frekans bileşenlerini önce sakladığı için dosya kısmen indirilmişken kırpılmış bir görüntü yerine düşük çözünürlüklü bir önizleme gösterebilir
  • Sıkıştırılmış veri birden çok tarama (scan) bölümüne ayrılır ve her taramanın önünde bir başlık bulunur
    • FF DA, tarama başlangıç işaretleyicisidir
    • Ardından uzunluk alanı, dahil edilen kanal sayısı ve kimlikleri ile Huffman tablo indeksleri gelir
    • Başlangıç ve bitiş DCT bin'leri ile hassasiyet belirtildikten sonra Huffman ile kodlanmış DCT katsayıları saklanır
  • İlk tarama, üç renk kanalındaki en düşük DC frekans bin değerini içerir

YCbCr ve aşamalı kalite iyileştirmesi

  • JPEG'in üç renk kanalı, yaygın RGB yerine YCbCr kullanır
    • Y, parlaklık bileşenidir ve yüksek kalite gerektirir
    • Cb, Cr renk farkı bileşenleridir; kalite düşse de görsel etkisi sınırlıdır
    • Çok kabaca ifade edilirse Y = G, Cb = B - G, Cr = R - G olur
  • Örnek JPEG, 0'dan 9'a kadar taramalarda veriyi aşamalı olarak doldurur
    • Tarama 0: Y Cb Cr, DCT bin 0–0 değerini yarım hassasiyetle saklayarak çok düşük çözünürlüklü bir önizleme sağlar
    • Tarama 1: Y, 1–5 bin'lerini 1/4 hassasiyetle ekleyerek parlaklık ayrıntısını güçlendirir
    • Tarama 2·3: Cb, Cr için 1–63 bin'lerini yarım hassasiyetle ekler
    • Tarama 4: Y için 6–63 bin'lerini 1/4 hassasiyetle doldurarak Tarama 1'in bıraktığı aralığı tamamlar
    • Tarama 5: Y için 1–63 bin'lerini yarım hassasiyetle iyileştirir
    • Tarama 6–9: Her kanala son bitleri ekleyerek tam kaliteye ulaşır
  • Renk farkı verisi parlaklıktan önce tamamlansa da renk farkı yarım çözünürlükte, yani 1/4 piksel sayısıyla saklandığından Cr + Cb toplam kapasitesi de parlaklığın yalnızca yarısıdır

İndirme sırasında görüntüyü değiştirmek

  • Her tarama uygulanacak frekans aralığını belirttiği için, sonraki taramalarla daha önce işlenmiş görüntü verisinin üzerine yazan JPEG'ler oluşturulabilir
  • Aynı çözünürlükte birden fazla görüntü art arda eklenir ve sonraki işaretleyiciler filtrelenerek uygulanır
    • image start (start-of-image)
    • frame start (start-of-frame)
    • image end (end-of-image)
  • Bir hex editörüyle de yapılabilir, ancak gerçek üretimde basit bir C programı kullanılır
  • Dosya yavaş bir ağ üzerinden aktarılırsa, indirme sırasında birden çok görüntü sırayla değişir

Kod çözücülerin tarama sınırı

  • JPEG kod çözücülerin çoğu belirli sayıda tarama işledikten sonra durur
  • Bunun, sıkıştırma bombasına benzer sorunları önlemek için konmuş bir sınır olduğu düşünülüyor; basit birleştirme yöntemiyle 9 kareden fazlasını uygulamak zordur
  • Daha uzun animasyonlar yapmak için kare başına gereken tarama sayısını en aza indirmek gerekir

Neden Baseline JPEG kullanılamıyor

  • Tek taramalı Baseline JPEG ile başlama yaklaşımı çalışmaz
  • İlerlemeli modda, tek bir taramaya DC verisi olan bin 0 ile AC verisi olan bin 1 ve üzeri birlikte konulamaz
  • Baseline modunda bu kısıt yoktur, ancak Baseline kod çözücü ilk taramadan sonra işlemeyi durdurur
  • AC verisi DC verisinden sonra gelmek zorunda olduğundan, en küçük ilerlemeli JPEG karesi yalnızca DC'ye özel tek bir taramadan oluşur

Yalnızca DC içeren karelerin yapısı ve çözünürlüğü

  • DCT, 16×16 bloklar halinde işlendiği için yalnızca DC verisi bulunsa bile tek renk yerine, özgün görüntünün 1/16 çözünürlüğünde bir görüntü elde edilebilir
  • En küçük kare, Y Cb Cr üç kanalının DCT bin 0–0 değerini tam hassasiyetle saklayan tek bir tarama kullanır
  • Bu yapıda Chrome, işlemeyi durdurmadan önce yaklaşık 90 kare işler
    • Firefox gibi diğer tarayıcılar daha fazla tarama işler
    • 90 taramadan oluşan görüntüler neredeyse tüm tarayıcılarda çalışır

İz bırakmayan kare geçişleri

  • Basit birleştirme yöntemindeki izlenim, AC taramalarının mevcut veriyi daha hassas hale getirmek için tasarlanmış olmasından kaynaklanır
  • Normal bir ilerlemeli JPEG'de, dosya boyutunu çok artırmadan birden fazla hassasiyet aşaması taşınabilir; ancak bu, görüntü değiştirme yaklaşımına uygun değildir
  • Gerçek bir ilerlemeli iyileştirme olmadan yalnızca DC taramaları kullanılırsa, önceki AC verisinin hassaslaştırılması gerçekleşmez ve izler önlenebilir
  • Yalnızca DC içeren kareler standart uyumlu JPEG görüntüleridir, bu yüzden özel bir kodlayıcı gerekmez
    • Tarama tanımı, üç kanalın yalnızca DC bin'lerini belirten 0,1,2:0-0,0,0; biçiminde olabilir

Tek bir JPEG videonun sınırları

  • Yalnızca DC içeren kareler art arda eklenirse, tek bir JPEG dosyasında tam bir video taşınabilir
  • JPEG taramalarına kare zamanlaması eklemenin bir yolu olmadığından, oynatma hızı tamamen ağ gecikmesine bağlıdır
  • Alışılmadık Rickroll'lar veya şakalar dışında pratik bir kullanım alanı yoktur

Kısmi işlemeyi genişleten deneyler

İlgili okumalar

1 yorum

 
GN⁺ 21 시간 전
Hacker News yorumları

  • Adam7 interlace PNG ile çok benzer bir şey denemiştim: https://www.da.vidbuchanan.co.uk/adamation/image.png
    Oynatma eninde sonunda ağ gecikmesine bağlı olsa da, sunucuyu her kareyi belirli aralıklarla ayrı ayrı gönderecek şekilde yapılandırmıştım. Kareler küçük olduğundan, ağ olağanüstü yavaş değilse oynatma zamanını sunucu belirliyor.

    • HTTP sunucusunu kontrol edebiliyorsanız, yanıt başlıklarında Refresh ayarlayarak istemcinin yeni animasyon karesini periyodik olarak almasını da sağlayabilirsiniz[1]. 2013 IOCCC başvurusu da PNG olarak render edilmiş bir saati sürekli güncellemek için bu tekniği kullanıyor[2]
      [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
      [2] https://www.ioccc.org/2013/mills/index.html
      Sonraki satırda Refresh başlığı tersine kodlanmış: https://github.com/ioccc-src/winner/blob/619f554bbdb19e5003a...
    • Sonsuz GIF ile canlı video stream etmeye yönelik benzer bir şey de denemiştim: https://github.com/jbochi/gifstreaming#live-video-streaming-...
    • PNG’yi animasyona dönüştürmek için dolambaçlı yollar kullanılırken, APNG kenardan “Ben de varım!” diye bağırıyor gibi.
    • 20 yıl önce çalıştığım yerdeki harita uygulamasına gerçek zamanlı bir hava kalitesi katmanı eklemek için animasyonlu GIF ile aynı şeyi yapmıştım. Görüntüler Java2D ile render ediliyordu; nokta bulutu yerine gradyan kümeleri oluşturmak için bir JOGL sürümü de geliştirmiştim ama sunucu yöneticisi OpenGL sürücüsü kurulumuna izin vermediği için tamamlayamadım.

  • Lanetli bir teknik ama kesinlikle buraya yakışıyor.

    • Büyük teknoloji şirketleri bunu tarayıcı parmak izi alma için nasıl kullanabileceklerini düşünüyor olmalı.

  • Bu teknikle veriyi göz önünde saklayan steganografi yapılıp yapılamayacağını merak ediyorum. Otomatik görüntü analiz programlarının çoğu muhtemelen yalnızca son görüntüyü kontrol eder; bu yüzden öğrencilerin okulun içerik filtrelerini aşmak için kullanabileceği bir şey gibi görünüyor.

    • İnsanlara gönderilecek mesajı ilk kareye, yapay zekaya gönderilecek mesajı son kareye koyan bir yapay zeka yanıltma tekniği olarak kullanılabilir. Birbirimize kedi fotoğrafları göndererek Skynet’i yenmek gibi.
    • Sıradan steganografiden daha iyi olacağı bir yol görünmüyor.

  • Aynı ağda paralel yüklenen işlerin ilerleme çubuğu olarak kullanılıp kullanıcıların kalan gecikmeyi tahmin etmesi sağlanamaz mı diye düşünüyorum.

    • 4chan gibi yerlerde rahatsız edici veya yasa dışı görselleri saklamak için kötüye kullanıldığı ve bu davranışın tamamen engellendiği aklımda kalmış.

  • Web sunucusu anında “JPEG” üretip bunu istemciye zaman aralıklı parçalar halinde gönderirse, oynatma zamanını bir ölçüde kontrol edebilir. Kaynak olarak web kamerası kullanılırsa hiç bitmeyen bir “JPEG” de mümkün.

    • Bazı web kameraları bunu zaten multipart/x-mixed-replace adlı MIME tekniğiyle uyguluyor. Sunucunun, az önce gönderdiği veriyi yeni veriyle değiştirmesini istemciye söylemesi şeklinde çalışıyor; JavaScript olmadan, yalnızca sıradan HTTP ve JPEG ile işliyor.
    • Birçok IP kamera bunu zaten https://en.wikipedia.org/wiki/Motion_JPEG ile uyguluyor.
    • GIF ile de mümkün. Bir keresinde GIF’i kare kare gönderip tıklamaları image map ile işleyerek, JavaScript olmadan uzak masaüstü gibi kullanılabilen oyuncak bir CGI yapmıştım. JPEG daha iyi olabilirdi, yeniden denemeye değer.

  • Service Worker ile yavaş bağlantı taklidi yaparsanız oynatma hızını kontrol edebilirsiniz.

  • Ortama göre davranışın farklı olması tuhaf. Masaüstü Firefox’ta düzgün oynuyor ama iOS mobilde “JPEG içindeki tüm video” neredeyse tek renkli kahverengi→turuncu→kırmızı 3 kare ve bulanık bir kedi silüetinden ibaret görünüyor.
    Renk kareden kareye değiştiği için çalıştığı anlaşılıyor ama buna video demek zor. Masaüstünde gerçek video gibi oynadığı için şaşırdım; iOS görüntü kod çözücüsünün tuhaf bir sınır durumuna dokunuyor gibi.

  • Yakın zamanda OpenGL ve jpeg-turbo ile görüntüleri hızlı göstermeye çalıştım; JPEG’in progressive modunu açınca kod çözme ciddi biçimde yavaşladı. Progressive JPEG’in iyi olduğu yönündeki eski tavsiyenin artık geçerli olmama ihtimali yüksek.
    On yıllardır görüntülerin aşamalı olarak netleştiğini neredeyse hiç görmediğim için pratik değeri de yok gibi.

    • Sayfa yüklendikten hemen sonra görüntünün biraz bulanık olup sonraki aşamada netleşmesini kaçırmış olabilirsiniz. Eskisi gibi ilk aşama tanınmayacak kadar kötü değil ama toplam dosya boyutunun yaklaşık %30’u ile düşük çözünürlüklü önizlemeyi neredeyse bedavaya sunmanın değeri hâlâ var.
    • Kodlayıcı olarak cjpegli kullanıyorum; varsayılan progressive ve tam 4:4:4 kombinasyonunda sıkıştırma oranı en iyi, yani basit bir ek özellikten ibaret değil.
    • Progressive olarak kaydedilen JPEG fotoğraflar genelde yaklaşık %5 daha küçük olur; JPEG’i progressive biçime kayıpsız dönüştürmek de mümkündür. JPEG XL’e kayıpsız dönüştürmek daha da fazla alan kazandırabilir.
    • Progressive kod çözme, kod çözmenin kendisini hızlandırmaya değil; özellikle yavaş mobil bağlantılarda büyük görüntülerin daha erken gösterilmesini sağlamaya yönelik bir özellik.
      Örnek: https://youtube.com/watch?v=UphN1_7nP8U

  • İlk görüntünün “yanlış” katsayılarından yüksek frekans katsayılarını zor yoldan hesaplama fikri aklıma gelmişti; ama sadece iki görüntüyü birleştirme yöntemi zekice. Bir görüntünün düşük frekans bileşenlerinin arkasına başka bir görüntünün yüksek frekans bileşenlerini eklemek bile şaşırtıcı derecede iyi çalışıyor.

  • Kamerayla düşük frekans bileşenlerini doğrudan elde etmenin de mümkün olup olmadığını merak ediyorum. k-uzayında düşük frekansları önce alan MRI yöntemi de aklıma geliyor.