JPEG Regresif

 (maurycyz.com)
1 poin oleh GN⁺ 21 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Dengan memodifikasi struktur multi-scan pada JPEG progresif, alih-alih kualitas gambar membaik seiring unduhan berlangsung, gambar yang sudah ditampilkan dapat terus berubah menjadi gambar lain
  • Setiap scan menentukan kanal warna, rentang frekuensi DCT, dan presisi; pada JPEG dengan resolusi yang sama, jika beberapa marker dihapus lalu digabung, data rendering yang sudah ada bisa ditimpa
  • Decoder membatasi jumlah scan yang diproses untuk mencegah masalah mirip bom kompresi; Chrome merender hingga sekitar 90 frame, sementara Firefox dan lainnya memproses lebih banyak
  • Jika tiap frame hanya memakai satu scan khusus DC, jumlah frame bisa ditambah sambil menghindari ghosting, tetapi karena sifat blok DCT, resolusi hasil turun menjadi 1/16 dari aslinya
  • Satu JPEG dapat memuat banyak frame seperti video, tetapi karena tidak ada informasi timing, kecepatan pemutaran bergantung pada latensi jaringan; ini lebih cocok untuk eksperimen HTML dan aplikasi halaman tunggal yang memanfaatkan partial rendering daripada video praktis

Cara JPEG progresif menampilkan gambar

  • JPEG menyimpan komponen frekuensi rendah lebih dulu sehingga meski file baru terunduh sebagian, ia bisa menampilkan pratinjau resolusi rendah alih-alih gambar yang terpotong
  • Data terkompresi dibagi menjadi beberapa scan dan setiap scan diawali header
    • FF DA adalah marker awal scan
    • Setelah itu ada field panjang, jumlah dan ID kanal yang disertakan, serta indeks tabel Huffman
    • Lalu ditentukan bin DCT awal/akhir dan presisi, kemudian koefisien DCT yang dikodekan Huffman disimpan
  • Scan pertama memuat bin frekuensi DC terendah dari ketiga kanal warna

YCbCr dan peningkatan kualitas bertahap

  • Tiga kanal warna JPEG memakai YCbCr, bukan RGB biasa
    • Y adalah luminans, jadi butuh kualitas tinggi
    • Cb dan Cr adalah komponen chroma, jadi penurunan kualitasnya tidak terlalu berdampak secara visual
    • Secara sangat kasar, Y = G, Cb = B - G, Cr = R - G
  • JPEG contoh mengisi data secara bertahap dari scan 0 sampai 9
    • Scan 0: Y Cb Cr, menyimpan bin DCT 0–0 dengan setengah presisi untuk memberi pratinjau resolusi sangat rendah
    • Scan 1: Y, menambahkan bin 1–5 dengan presisi 1/4 untuk memperkuat detail luminans
    • Scan 2·3: menambahkan bin 1–63 dari Cb, Cr dengan setengah presisi
    • Scan 4: mengisi bin 6–63 dari Y dengan presisi 1/4 untuk melengkapi rentang yang tersisa dari scan 1
    • Scan 5: meningkatkan bin 1–63 dari Y ke setengah presisi
    • Scan 6–9: menambahkan bit terakhir ke tiap kanal untuk mencapai kualitas penuh
  • Data chroma selesai lebih dulu daripada luminans, tetapi karena chroma disimpan pada setengah resolusi, yaitu 1/4 jumlah piksel, total kapasitas Cr + Cb pun hanya setengah dari luminans

Mengganti gambar saat unduhan berlangsung

  • Karena setiap scan menyatakan rentang frekuensi yang akan diterapkan, kita bisa membuat JPEG yang menimpa data gambar yang sudah dirender dengan scan berikutnya
  • Ini diimplementasikan dengan menyambung beberapa gambar beresolusi sama sambil menyaring marker berikut
    • awal gambar (start-of-image)
    • awal frame (start-of-frame)
    • akhir gambar (end-of-image)
  • Bisa dibuat dengan editor heksadesimal, tetapi untuk pembuatan nyata digunakan program C sederhana
  • Jika file dikirim lewat jaringan lambat, beberapa gambar akan berganti satu per satu selama unduhan berlangsung

Batas scan pada decoder

  • Kebanyakan decoder JPEG berhenti setelah memproses sejumlah scan tertentu
  • Ini diduga sebagai pembatas untuk menghindari masalah mirip bom kompresi, sehingga dengan cara penggabungan sederhana sulit membuat lebih dari 9 frame
  • Untuk membuat animasi lebih panjang, jumlah scan yang dibutuhkan per frame harus diminimalkan

Mengapa Baseline JPEG tidak bisa dipakai

  • Pendekatan yang dimulai dari Baseline JPEG yang hanya memakai satu scan tidak bekerja
  • Dalam mode progresif, satu scan tidak bisa memuat bersama-sama bin 0 yang merupakan data DC dan bin 1 ke atas yang merupakan data AC
  • Mode Baseline tidak punya batasan ini, tetapi decoder Baseline berhenti memproses setelah scan pertama
  • Karena data AC harus datang setelah data DC, frame JPEG progresif terkecil terdiri dari satu scan khusus DC saja

Komposisi dan resolusi frame khusus DC

  • Karena DCT diproses dalam blok 16×16, hanya dengan data DC pun hasilnya bukan warna polos, melainkan gambar dengan resolusi 1/16 dari aslinya
  • Frame minimum hanya memakai satu scan yang menyimpan bin DCT 0–0 dari tiga kanal Y Cb Cr dengan presisi penuh
  • Dalam konfigurasi ini, Chrome merender sekitar 90 frame sebelum berhenti memproses
    • Browser lain seperti Firefox memproses lebih banyak scan
    • Gambar yang terdiri dari 90 scan bekerja di hampir semua browser

Pergantian frame tanpa ghosting

  • Ghosting pada metode penggabungan sederhana muncul karena scan AC dirancang untuk memperhalus data yang sudah ada
  • Pada JPEG progresif biasa, beberapa tahap presisi bisa dimuat tanpa terlalu membesarkan ukuran file, tetapi ini tidak cocok untuk metode penggantian gambar
  • Jika hanya memakai scan khusus DC tanpa peningkatan progresif nyata, tidak ada pemurnian data AC sebelumnya sehingga ghosting bisa dihindari
  • Frame khusus DC adalah gambar JPEG yang sesuai standar, jadi tidak memerlukan encoder khusus
    • Pada spesifikasi scan, hanya bin DC dari tiga kanal yang ditentukan seperti 0,1,2:0-0,0,0;

Batasan video JPEG tunggal

  • Dengan menyambung frame khusus DC, satu file JPEG bisa memuat seluruh video
  • Scan JPEG tidak punya cara untuk menambahkan timing frame, sehingga kecepatan pemutaran sepenuhnya bergantung pada latensi jaringan
  • Selain untuk Rickroll yang tidak biasa atau lelucon, tidak ada bidang aplikasi praktis

Eksperimen yang memperluas partial rendering

Bacaan terkait

1 komentar

 
GN⁺ 21 jam lalu
Opini Hacker News

  • Saya pernah melakukan hal yang sangat mirip dengan PNG interlaced Adam7: https://www.da.vidbuchanan.co.uk/adamation/image.png
    Pemutarannya pada akhirnya memang bergantung pada latensi jaringan, tetapi server dikonfigurasi untuk mengirim tiap frame secara terpisah pada interval tetap. Karena frame-nya kecil, selama jaringan tidak luar biasa lambat, serverlah yang menentukan waktu pemutaran

  • Teknik terkutuk, tetapi jelas cocok di sini

    • Perusahaan teknologi besar sepertinya akan memikirkan cara memanfaatkannya untuk fingerprinting browser

  • Saya penasaran apakah teknik ini memungkinkan steganografi untuk menyembunyikan data di depan mata. Sebagian besar program analisis gambar otomatis kemungkinan hanya memeriksa gambar terakhir, jadi tampaknya bisa dipakai siswa untuk melewati filter konten sekolah

    • Ini bisa dipakai sebagai teknik pengacau AI: pesan untuk manusia dimasukkan ke frame pertama, pesan untuk AI ke frame terakhir. Semacam saling mengirim foto kucing untuk mengalahkan Skynet
    • Sepertinya tidak ada cara yang membuatnya lebih baik daripada steganografi biasa

  • Mungkin ini bisa dipakai sebagai progress bar untuk pekerjaan yang dimuat paralel di jaringan yang sama, agar pengguna bisa memperkirakan sisa waktu tunggu

    • Seingat saya, tempat seperti 4chan memblokir perilaku seperti ini sepenuhnya karena disalahgunakan untuk menyembunyikan gambar yang menjijikkan atau ilegal

  • Jika web server membuat “JPEG” secara langsung dan mengirimkannya ke klien sebagai potongan yang diberi jeda waktu, waktu pemutaran bisa dikendalikan sampai batas tertentu. Jika webcam dijadikan sumber, “JPEG” yang tak berujung juga dimungkinkan

    • Beberapa webcam sudah menerapkan ini dengan teknik MIME bernama multipart/x-mixed-replace. Caranya, server menginstruksikan klien untuk mengganti data yang baru saja dikirim dengan data baru, dan ini bekerja hanya dengan HTTP biasa dan JPEG tanpa JavaScript
    • Banyak kamera IP sudah menerapkannya sebagai https://en.wikipedia.org/wiki/Motion_JPEG
    • Ini juga bisa dilakukan dengan GIF. Saya pernah membuat CGI mainan yang mengirim GIF frame demi frame dan menangani klik dengan image map, sehingga bisa dipakai seperti remote desktop tanpa JavaScript. JPEG mungkin lebih baik, jadi layak dicoba lagi

  • Dengan Service Worker, Anda bisa meniru koneksi lambat untuk mengendalikan kecepatan pemutaran

  • Aneh karena perilakunya berbeda tergantung lingkungan. Di Firefox desktop, pemutarannya benar, tetapi di iOS mobile, “seluruh video di dalam JPEG” hanya tampak seperti tiga frame warna hampir solid dari cokelat→oranye→merah, plus siluet kucing yang buram
    Karena warnanya berubah di tiap frame, jelas ada sesuatu yang berjalan, tetapi sulit menyebutnya video. Di desktop, ia diputar seperti video sungguhan sehingga mengejutkan, dan tampaknya menyentuh kondisi batas yang aneh pada decoder gambar iOS

  • Baru-baru ini saya mengerjakan penayangan gambar cepat dengan OpenGL dan jpeg-turbo, dan ketika mode progresif JPEG diaktifkan, decoding menjadi jauh lebih lambat. Saran lama bahwa progressive JPEG itu bagus mungkin sudah tidak berlaku lagi
    Selama puluhan tahun saya hampir tidak pernah melihat gambar yang bertahap menjadi lebih tajam, jadi nilai praktisnya juga tampak tidak besar

    • Mungkin Anda melewatkan momen ketika gambar sedikit buram segera setelah halaman dimuat lalu menjadi tajam pada tahap berikutnya. Tidak seperti dulu ketika tahap pertama sampai sulit dikenali, tetapi nilai menyediakan pratinjau resolusi rendah hampir gratis hanya dengan sekitar 30% ukuran file masih ada
    • Saya memakai cjpegli sebagai encoder, dan kombinasi default progresif dengan 4:4:4 penuh memberikan rasio kompresi terbaik, jadi ini bukan sekadar fitur tambahan sederhana
    • Foto JPEG yang disimpan secara progresif biasanya sekitar 5% lebih kecil, dan mengonversi JPEG ke format progresif secara lossless juga memungkinkan. Jika dikonversi lossless ke JPEG XL, ruang yang dihemat bisa lebih besar
    • Decoding progresif bukan bertujuan membuat proses decoding itu sendiri lebih cepat, melainkan agar gambar besar tampil lebih cepat, terutama pada koneksi mobile yang lambat
      Contoh: https://youtube.com/watch?v=UphN1_7nP8U

  • Awalnya saya terpikir cara sulit menghitung koefisien frekuensi tinggi dari koefisien “salah” pada gambar pertama, tetapi pendekatan sekadar menggabungkan dua gambar itu cerdas. Hanya dengan menempelkan komponen frekuensi rendah dari satu gambar lalu komponen frekuensi tinggi dari gambar lain, hasilnya mengejutkan bagus

  • Saya penasaran apakah komponen frekuensi rendah juga bisa diperoleh langsung dengan kamera. Ini juga mengingatkan pada MRI yang memperoleh frekuensi rendah terlebih dahulu di k-space