Bagaimana cara kerja kompresi tekstur perangkat keras?

Itu kompres data dibandingkan dengan array pixel jelas.

Tetapi apa yang membuatnya berbeda dari kompresi normal (seperti png, jpeg)?

Seperti komentar Simon disinggung, satu perbedaan utama antara kompresi tekstur perangkat keras dan kompresi gambar yang umum digunakan adalah bahwa yang pertama tidak menggunakan pengkodean entropi. Pengodean entropi adalah penggunaan bit-string yang lebih pendek untuk mewakili pola yang sering terjadi atau berulang dalam data sumber — seperti yang terlihat dalam format wadah seperti ZIP, banyak format gambar umum seperti GIF, JPEG, dan PNG, dan juga dalam banyak audio umum dan format video.

Pengkodean entropi bagus dalam mengompresi semua jenis data, tetapi pada dasarnya menghasilkan rasio kompresi variabel. Beberapa area gambar mungkin memiliki sedikit detail (atau detail diprediksi dengan baik oleh model pengkodean yang Anda gunakan) dan membutuhkan sangat sedikit bit, tetapi area lain mungkin memiliki detail rumit yang membutuhkan lebih banyak bit untuk dikodekan. Ini menyulitkan untuk menerapkan akses acak, karena tidak ada cara langsung untuk menghitung di mana dalam data terkompresi Anda dapat menemukan piksel saat diberikan ( x ,  y) koordinat. Juga, sebagian besar skema pengkodean entropi bersifat stateful, jadi tidak mungkin untuk hanya memulai decoding di tempat sewenang-wenang di aliran; Anda harus mulai dari awal untuk membangun negara yang benar. Namun, akses acak diperlukan untuk pengambilan sampel tekstur, karena shader dapat mengambil sampel dari lokasi mana pun dalam tekstur kapan saja.

Jadi, daripada pengkodean entropi, kompresi perangkat keras menggunakan rasio tetap, skema berbasis blok. Misalnya, dalam kompresi DXT / BCn , tekstur diiris menjadi blok 4 × 4 piksel, yang masing-masing dikodekan dalam 64 atau 128 bit (tergantung pada format yang dipilih); dalam ASTC , format yang berbeda menggunakan ukuran blok dari 4 × 4 hingga 12 × 12, dan semua blok dikodekan dalam 128 bit. Rincian bagaimana bit mewakili data gambar bervariasi antara format (dan bahkan mungkin bervariasi dari satu blok ke yang berikutnya dalam gambar yang sama), tetapi karena rasionya diperbaiki, perangkat keras mudah menghitung di mana dalam memori untuk menemukan blok. mengandung piksel ( x , y ) yang diberikan, dan setiap blok mandiri, sehingga dapat didekodekan secara independen dari blok lainnya.

Pertimbangan lain dalam kompresi tekstur perangkat keras adalah bahwa pendekodean harus dapat diterapkan secara efisien dalam perangkat keras. Ini berarti bahwa operasi matematika yang berat dan aliran data yang kompleks sangat tidak disukai. Format BCn, misalnya, dapat didekodekan dengan melakukan beberapa operasi matematika integer 8-bit per blok untuk mengisi tabel pencarian kecil, kemudian hanya mencari entri tabel yang sesuai per piksel. Ini membutuhkan area on-chip yang sangat sedikit, yang penting karena Anda mungkin ingin mendekode beberapa blok secara paralel, dan karenanya memerlukan beberapa salinan perangkat keras decode.

Sebaliknya, format berbasis DCT seperti JPEG memerlukan jumlah nontrivial matematika per piksel, belum lagi aliran data kompleks yang menukar dan menyiarkan berbagai nilai menengah melintasi piksel dalam satu blok. (Lihat artikel ini untuk beberapa detail berdarah dari decoding DCT.) Ini akan jauh lebih kotor untuk implementasi perangkat keras, yang saya duga adalah alasan mengapa AFAICT, tidak ada perangkat keras GPU yang pernah menerapkan kompresi tekstur berbasis DCT atau berbasis wavelet. .

"Bagaimana kompresi perangkat keras (perangkat keras) bekerja" adalah topik besar. Semoga saya bisa memberikan beberapa wawasan tanpa menduplikasi konten jawaban Nathan .

Persyaratan

Kompresi tekstur biasanya berbeda dari teknik kompresi gambar 'standar' misalnya JPEG / PNG dalam empat cara utama, seperti diuraikan dalam Beers et al's Rendering from Compressed Textures :

1. Kecepatan Decoding : Anda tidak ingin kompresi tekstur menjadi lebih lambat (setidaknya tidak terasa begitu) daripada menggunakan tekstur yang tidak terkompresi. Ini juga harus relatif sederhana untuk didekompresi karena dapat membantu mencapai dekompresi cepat tanpa biaya perangkat keras dan daya yang berlebihan.

2. Akses Acak : Anda tidak dapat dengan mudah memprediksi teks mana yang akan dibutuhkan selama render yang diberikan. Jika beberapa subset, M , dari texels yang diakses berasal dari, katakanlah, di tengah-tengah gambar, penting bahwa Anda tidak perlu men-decode semua garis 'sebelumnya' dari tekstur untuk menentukan M ; dengan JPEG dan PNG ini diperlukan karena decoding piksel tergantung pada data yang sebelumnya didekodekan.
   Catatan, setelah mengatakan ini, hanya karena Anda memiliki akses "acak", tidak berarti Anda harus mencoba sampel sepenuhnya secara sewenang-wenang

3. Tingkat Kompresi dan Kualitas Visual : Beers et al berpendapat (dengan meyakinkan) bahwa kehilangan beberapa kualitas dalam hasil kompresi untuk meningkatkan tingkat kompresi adalah pertukaran yang bermanfaat. Dalam rendering 3D, data mungkin akan dimanipulasi (misalnya difilter & diarsir, dll.) Sehingga hilangnya kualitas mungkin tertutupi.

4. Pengkodean / penguraian asimetris : Meskipun mungkin sedikit lebih kontroversial, mereka berpendapat bahwa proses pengkodean jauh lebih lambat daripada pengodean. Mengingat bahwa decoding harus pada tingkat pengisian HW, ini umumnya dapat diterima. (Saya akui bahwa kompresi PVRTC, ETC2, dan beberapa lainnya dengan kualitas maksimum bisa lebih cepat)

Sejarah Awal & Teknik

Mungkin mengejutkan beberapa orang untuk mengetahui bahwa kompresi tekstur telah ada selama lebih dari tiga dekade. Simulator penerbangan dari tahun 70-an dan 80-an membutuhkan akses ke data tekstur yang relatif besar dan mengingat bahwa 1MB RAM pada 1980 adalah> $ 6.000 , mengurangi jejak tekstur sangat penting. Sebagai contoh lain, pada pertengahan 70-an, bahkan sejumlah kecil memori dan logika berkecepatan tinggi, misalnya cukup untuk penyangga bingkai RGB 512x512 yang sederhana ) dapat membuat Anda mengembalikan harga rumah kecil.

Padahal, AFAIK, tidak secara eksplisit disebut sebagai kompresi tekstur, dalam literatur dan paten Anda dapat menemukan referensi untuk teknik termasuk:
a. bentuk sederhana sintesis tekstur prosedural / matematika,
b. penggunaan tekstur saluran tunggal (misalnya 4bpp) yang kemudian dikalikan dengan nilai RGB per-tekstur,
c. YUV, dan
d. palet (literatur menyarankan penggunaan pendekatan Heckbert untuk melakukan kompresi)

Memodelkan Data Gambar

Seperti disebutkan di atas, kompresi tekstur hampir selalu lossy dan dengan demikian masalahnya menjadi salah satu dari mencoba untuk merepresentasikan data penting dengan cara yang ringkas sambil membuang informasi yang kurang signifikan. Berbagai skema yang akan dijelaskan di bawah ini semua memiliki model 'parameterised' implisit yang mendekati perilaku khas data tekstur dan respons mata.

Lebih lanjut, karena kompresi tekstur cenderung menggunakan pengkodean fixed-rate, proses kompresi biasanya mencakup langkah pencarian untuk menemukan set parameter yang, ketika dimasukkan ke dalam model, akan menghasilkan perkiraan yang baik dari tekstur asli. Namun langkah pencarian itu bisa memakan waktu.
(Dengan kemungkinan pengecualian alat seperti optipng , ini adalah area lain di mana penggunaan khas PNG & JPEG berbeda dari skema kompresi tekstur)

Sebelum maju lebih jauh, untuk membantu dengan pemahaman lebih lanjut tentang TC, ada baiknya kita melihat Principal Component Analysis (PCA) - alat matematika yang sangat berguna untuk kompresi data.

Contoh tekstur

Untuk membandingkan berbagai metode, kami akan menggunakan gambar berikut:

Perhatikan bahwa ini adalah gambar yang cukup sulit, terutama untuk metode palet dan VQTC karena mencakup banyak kubus warna RGB dan hanya 15% dari texel yang menggunakan warna berulang.

Kompresi Tekstur PC dan (pasca pertengahan 90-an)

Untuk mengurangi biaya data, beberapa game PC dan konsol game awal juga memanfaatkan gambar palet, yang merupakan bentuk Vector Quantisation (VQ). Pendekatan berbasis palet membuat asumsi bahwa gambar yang diberikan hanya menggunakan bagian kubus warna RGB (A) yang relatif kecil. Masalah dengan tekstur palet adalah bahwa tingkat kompresi untuk kualitas yang dicapai pada umumnya agak sederhana. Contoh tekstur yang dikompresi menjadi "4bpp" (menggunakan GIMP) menghasilkan Note lagi bahwa ini adalah gambar yang relatif sulit untuk skema VQ.

VQ dengan vektor yang lebih besar (mis. ARGB 2bpp)

Terinspirasi oleh Beers et al, konsol Dreamcast menggunakan VQ untuk menyandikan blok 2x2 atau bahkan 2x4 piksel dengan byte tunggal. Sementara "vektor" dalam tekstur palet adalah 3 atau 4 dimensi, blok 2x2 piksel dapat dianggap sebagai 16 dimensi. Skema kompresi mengasumsikan ada cukup, perkiraan pengulangan vektor-vektor ini.

Meskipun VQ dapat mencapai kualitas yang memuaskan dengan ~ 2bpp, masalah dengan skema ini adalah bahwa ia membutuhkan memori bertuliskan bertuliskan: Pembacaan awal dari peta indeks untuk menentukan kode untuk piksel diikuti oleh sedetik untuk benar-benar mengambil data piksel yang terkait dengan kode itu. Tembolok tambahan dapat membantu mengurangi beberapa latensi yang terjadi, tetapi menambah kompleksitas pada perangkat keras.

Contoh gambar yang dikompres dengan skema Dreamcast 2bpp adalah . Peta indeks adalah:

Kompresi data VQ dapat dilakukan dengan berbagai cara namun, IIRC , di atas dilakukan dengan menggunakan PCA untuk menurunkan dan kemudian mempartisi vektor 16D sepanjang vektor utama menjadi 2 set sehingga dua vektor yang representatif meminimalkan rata-rata kuadrat kesalahan. Proses ini kemudian berulang hingga 256 kandidat vektor diproduksi. Algoritma global k-means / LloydPendekatan kemudian diterapkan untuk meningkatkan perwakilan.

Transformasi Ruang Warna

Transformasi ruang warna juga menggunakan PCA yang mencatat bahwa distribusi warna global sering menyebar sepanjang sumbu utama dengan penyebaran jauh lebih sedikit di sepanjang sumbu lainnya. Untuk representasi YUV, asumsinya adalah bahwa a) sumbu utama sering dalam arah luma dan bahwa b) mata lebih sensitif terhadap perubahan arah ini.

Sistem 3dfx Voodoo menyediakan "YAB" , sistem kompresi 8bpp, "Saluran Sempit" yang membagi setiap 8 bit texel ke dalam format 322, dan menerapkan transformasi warna yang dipilih pengguna ke data tersebut untuk memetakannya ke dalam RGB. Jadi sumbu utama memiliki 8 level dan sumbu yang lebih kecil, masing-masing 4.

Chip S3 Virge memiliki skema 4bpp yang sedikit lebih sederhana, yang memungkinkan pengguna untuk menentukan, untuk seluruh tekstur , dua warna ujung, yang seharusnya terletak pada sumbu utama, bersama dengan tekstur monokrom 4bpp. Nilai per-pixel kemudian memadukan warna akhir dengan bobot yang sesuai untuk menghasilkan hasil RGB.

Skema berbasis BTC

Memutar ulang beberapa tahun, Delp dan Mitchell merancang skema kompresi gambar sederhana (monokrom) yang disebut Block Truncation Coding , (BTC) . Makalah ini juga termasuk algoritma kompresi tetapi, untuk tujuan kami, kami terutama tertarik pada data terkompresi yang dihasilkan dan proses dekompresi.

Dalam skema ini, gambar dipecah menjadi, biasanya, blok piksel 4x4, yang dapat dikompresi secara independen dengan, pada dasarnya, algoritma VQ lokal. Setiap blok diwakili oleh dua "nilai", a dan b , dan satu set bit indeks 4x4, yang mengidentifikasi mana dari dua nilai yang akan digunakan untuk setiap piksel.

S3TC : 4bpp RGB (+ 1bit alpha)
Meskipun beberapa varian warna dari BTC untuk kompresi gambar diusulkan, yang menarik bagi kami adalah Iourcha dkk. S3TC , beberapa di antaranya tampaknya merupakan penemuan kembali dari karya Hoffert dkk yang agak terlupakan. digunakan dalam Quicktime Apple.

S3TC asli, tanpa varian DirectX, mengkompres blok baik RGB atau RGB + 1bit Alpha ke 4bpp. Setiap blok 4x4 dalam tekstur digantikan oleh dua warna ujung, A dan B , yang darinya hingga dua warna lainnya diperoleh dengan campuran linier berbobot tetap. Selanjutnya, setiap texel di blok memiliki indeks 2-bit yang menentukan cara memilih salah satu dari empat warna ini.

Misalnya, berikut ini adalah bagian 4x4 piksel dari gambar uji yang dikompres dengan alat Kompresor AMD / ATI. ( Secara teknis ini diambil dari versi gambar uji 512x512 tapi maafkan saya kekurangan waktu untuk memperbarui contoh ). Ini menggambarkan proses kompresi: Rata-rata dan sumbu utama warna dihitung. Yang paling cocok kemudian dilakukan untuk menemukan dua titik akhir yang 'terletak pada' sumbu yang, bersama dengan dua turunan 1: 2 dan 2: 1 campuran (atau dalam beberapa kasus campuran 50:50) dari titik-titik akhir, yang meminimalkan kesalahan. Setiap piksel asli kemudian dipetakan ke salah satu warna tersebut untuk menghasilkan hasilnya.

Jika, seperti dalam kasus ini, warnanya masuk akal didekati oleh sumbu utama, kesalahan akan relatif rendah. Namun jika, seperti di blok 4x4 tetangga yang ditunjukkan di bawah ini, warnanya lebih beragam, kesalahan akan lebih tinggi.

Contoh gambar, dikompres dengan AMD Compressonator menghasilkan:

Karena warna ditentukan secara independen per-blok, mungkin ada diskontinuitas pada batas blok tetapi, selama resolusinya dijaga cukup tinggi, artefak blok ini mungkin tidak diperhatikan:

ETC1 : 4bpp RGB
Ericsson Texture Compression juga bekerja dengan blok 4x4 texels tetapi membuat asumsi bahwa, seperti YUV, sumbu utama dari set texels lokal seringkali sangat kuat berkorelasi dengan "luma". Seperangkat texels kemudian dapat diwakili oleh hanya warna rata-rata dan 'panjang' skalar, sangat tinggi dari proyeksi dari texels ke sumbu diasumsikan.

Karena ini mengurangi biaya penyimpanan data relatif untuk mengatakan, S3TC, memungkinkan ETC untuk memperkenalkan skema partisi, di mana blok 4x4 dibagi menjadi sepasang sub-blok horisontal 4x2 atau vertikal 2x4. Masing-masing memiliki warna rata-rata sendiri. Contoh gambar menghasilkan: Area di sekitar paruh juga menggambarkan partisi horizontal dan vertikal dari blok 4x4.

Global + Lokal

Ada beberapa sistem kompresi tekstur yang merupakan persilangan antara skema global dan lokal, seperti palet yang didistribusikan dari Ivanov dan Kuzmin atau metode PVRTC .

PVRTC : 4 & 2 bpp RGBA
PVRTC mengasumsikan bahwa (dalam praktiknya, bilinearly) gambar yang ditingkatkan adalah perkiraan yang baik untuk target resolusi penuh dan bahwa perbedaan antara perkiraan dan target, yaitu gambar delta, adalah monokromatik lokal, yaitu memiliki poros utama yang dominan. Lebih lanjut, ini mengasumsikan sumbu utama lokal dapat diinterpolasi melintasi gambar.

(yang harus dilakukan: Tambahkan gambar yang menunjukkan kerusakan)

Contoh tekstur, dikompresi dengan PVRTC1 4bpp menghasilkan: dengan area di sekitar paruh: Dibandingkan dengan skema BTC, artefak blok biasanya dihilangkan tetapi kadang-kadang dapat "melampaui" jika ada diskontinuitas yang kuat dalam gambar sumber, misalnya sekitar bayangan kepala lorikeet.

Varian 2bpp memiliki, secara alami, kesalahan lebih tinggi daripada 4bpp (perhatikan hilangnya presisi di sekitar biru, area frekuensi tinggi di dekat leher) tetapi masih bisa dibilang berkualitas cukup:

Catatan tentang biaya dekompresi

Meskipun algoritma kompresi untuk skema yang dijelaskan di atas memiliki biaya evaluasi sedang hingga tinggi, algoritma dekompresi, terutama untuk implementasi perangkat keras, relatif murah. ETC1, misalnya, membutuhkan sedikit lebih dari beberapa MUX dan adders presisi rendah; S3TC secara efektif sedikit lebih banyak unit tambahan untuk melakukan pencampuran; dan PVRTC, sedikit lagi. Secara teori, skema TC sederhana ini dapat memungkinkan arsitektur GPU untuk menghindari dekompresi sampai sebelum tahap penyaringan, sehingga memaksimalkan efektivitas cache internal.

Skema lain

Mode TC umum lainnya yang harus disebutkan adalah:

• ETC2 - adalah superset (4bpp) dari ETC1 yang meningkatkan penanganan daerah dengan distribusi warna yang tidak selaras dengan 'luma'. Ada juga varian 4bpp yang mendukung 1 bit alpha, dan format 8bpp untuk RGBA.

• ATC - Secara efektif variasi kecil pada S3TC .

• FXT1 (3dfx) adalah varian yang lebih ambisius dari tema S3TC .

• BC6 & BC7: Sistem 8bpp, berbasis blok yang mendukung ARGB. Terlepas dari mode HDR, ini menggunakan sistem partisi yang lebih kompleks daripada ETC untuk mencoba model distribusi warna gambar yang lebih baik.

• PVRTC2: 2 & 4bpp ARGB. Ini memperkenalkan mode tambahan termasuk satu untuk mengatasi keterbatasan dengan batas yang kuat dalam gambar.

• ASTC: Ini juga merupakan sistem berbasis blok tetapi agak lebih rumit karena memiliki sejumlah besar ukuran blok yang mungkin menargetkan berbagai bpp. Ini juga mencakup fitur-fitur seperti hingga 4 wilayah partisi dengan generator partisi pseudo-acak, dan resolusi variabel untuk data indeks dan / atau ketepatan warna dan model warna.