Hindari kompresi sumber daya ganda

13

Saya menggunakan .pngs untuk tekstur saya dan saya menggunakan sistem file virtual dalam .zipfile untuk proyek game saya. Ini berarti tekstur saya dikompresi dan didekompresi dua kali. Apa solusi untuk masalah kompresi ganda ini? Salah satu solusi yang pernah saya dengar adalah menggunakan .tgas untuk tekstur, tetapi sepertinya sudah lama, sejak saya pernah mendengarnya. Solusi lain adalah menerapkan dekompresi pada GPUdan, karena cepat, lupakan overhead.

textures assets compression

— pengguna1095108
sumber

2

Terkait: jika Anda menggunakan jpegs, maka banyak program zip dengan formatnya sendiri mampu mengompres bahkan mereka yang sebesar 20% sehingga tidak selalu seburuk itu. Apa gunanya kompresi ganda yang paling Anda khawatirkan? Apakah ini terlalu lama? Banyak format bahkan menyimpan data yang sudah dikompresi hanya kata demi kata dan tidak melakukan dekompresi sama sekali.

— PlasmaHH

17

Format zip mendukung beberapa algoritma kompresi yang berbeda. Anda dapat menggunakan algoritma yang berbeda untuk setiap file dalam arsip. Ketika Anda ingin menyimpan file yang sudah dikompresi yang tidak mendapat manfaat dari kompresi tambahan (seperti PNG) dalam arsip zip, Anda dapat menyandikan file-file ini dengan algoritma "tersimpan" yang tidak memampatkan sama sekali. Dialog "Tambahkan ke arsip" dari 7-zip memungkinkan Anda memilih ini di bawah "Kekuatan kompresi".

Tetapi ketika Anda tidak hanya memiliki gambar tetapi juga sumber daya lainnya yang lebih kompresif dalam arsip Anda, mungkin akan sangat membosankan untuk memilih algoritma untuk setiap file. Dalam hal ini Anda mungkin lebih memilih format gambar yang tidak terkompresi dalam arsip kompresi.

Format TGA tahu banyak mode yang berbeda, beberapa di antaranya dikompresi dan beberapa tidak. Ketika Anda tidak ingin menggunakan kompresi, pastikan Anda memilih yang tepat di opsi ekspor editor grafik yang Anda gunakan. Format gambar non-kompresi lainnya adalah BMP (Windows Bitmap).

Inilah tes yang saya buat. Saya menambahkan gambar yang sama (aset dari proyek saya saat ini) dalam format yang berbeda beberapa kali ke arsip zip, beberapa dengan "deflate" -algoritma pada kekuatan normal dan satu dengan "store". Maaf untuk GUI Jerman. Kolom ke-2 adalah ukuran terkompresi, kolom ke-3 adalah algoritma kompresi dan kolom ke-4 adalah ukuran terkompresi.

masukkan deskripsi gambar di sini

Seperti yang Anda lihat, deflate-encoding PNG hanya menyelamatkan sedikit 0,3%, sementara BMP deflate-encoded dikurangi menjadi sepersepuluh dari file asli yang bahkan lebih kecil dari versi PNG. Ini cukup mengejutkan saya. Saya akan mengharapkan PNG menjadi lebih kecil karena metode kompresi PNG harus dioptimalkan untuk gambar-data sementara ZIP tidak. Penjelasan yang mungkin adalah bahwa editor gambar saya (GIMP) menambahkan cukup banyak meta-informasi ke file PNG yang tidak dilakukan untuk BMP.

TGA terkompresi berperilaku mirip dengan BMP mengenai filesize sebelum dan sesudah zip sementara kompresi file TGA terkompresi lebih ditingkatkan oleh ZIP, meskipun tidak sebanyak versi terkompresi.

Mungkin layak untuk bereksperimen dengan algoritma lain selain mengempis dan dengan pengaturan kekuatan kompresi lainnya. Kombinasi mana yang akan memberikan hasil terbaik kemungkinan akan tergantung pada gaya tekstur Anda. Tetapi Anda juga dapat mempertimbangkan untuk melakukan benchmark terhadap pemuatan aset game Anda dan memiliki dekompresi-kinerja memengaruhi keputusan Anda yang pengaturan yang Anda gunakan.

Intinya: Bila Anda ingin menghindari kompresi ganda saat masih memiliki ukuran file yang rendah, gunakan PNGdengan Storealgoritma zip atau BMPdengan algoritma zip kompresi.

— Philipp
sumber

5

Saya melakukannya pada beberapa gambar milik saya dan PNG (level kompresi 9) mengalahkan zip (level kompresi ultra) dari gambar BMP sepanjang waktu sekitar 20%. Jadi itu harus efek seperti meta-informasi.

— Trilarion

3

png memiliki opsi interlacing dengan mengurangi kompresibilitas tetapi memungkinkan gambar beresolusi rendah untuk diekstraksi dari hanya bagian pertama dari file gambar (seperti saat mengunduh melalui koneksi bandwidth rendah), apakah dinding Anda memiliki yang aktif? selain itu png menggunakan deflate untuk kompresi.

— ratchet freak

Sepertinya Anda telah menggunakan kompresor png yang buruk, berikan file Anda jalankan melalui PNGOUT dan Anda harus mendapatkan hasil yang tidak akan dikalahkan oleh file bmp zip.

— aaaaaaaaaaaa

Apakah BMP atau TGA Anda 24-bit atau 32-bit? Dengan BMP khususnya mereka lebih cenderung 24-bit, dan ukuran TGA yang tidak terkompresi menunjukkan itu juga 24-bit. Anda mungkin tidak membandingkan suka-dengan-seperti di sini.

— Maximus Minimus

@ JimmyShelter Baik TGA dan BMP adalah 32bit dengan saluran alpha - saya memastikan.

— Philipp

7

Jangan khawatir tentang itu.

Ketika algoritma "deflate" yang digunakan dalam file .zip menemukan blok data yang sudah terkompresi dengan baik, seperti data piksel dari gambar .png, ia menemukan bahwa itu tidak dapat mengompresnya secara efektif, dan itu akan menyimpannya sebagai literal data tidak terkompresi. Ini membutuhkan sedikit overhead pada akhir dekompresi untuk menyalin.

http://en.wikipedia.org/wiki/DEFLATE

— Russell Borogove
sumber

3

Terkadang sesederhana itu, masalah yang dirasakan tidak selalu merupakan masalah nyata. Bahkan jika sebenarnya ada overhead dekompresi dua kali, deflate yang tidak terkompresi adalah operasi yang sangat cepat, saya kira overhead hanya akan dapat diukur.

— aaaaaaaaaaaa

Apakah kompresi akan membutuhkan waktu lama untuk menyadari bahwa file tersebut tidak dapat dikompres?

— user253751

Relatif ya. Saya tidak tahu heuristik apa yang biasa digunakan oleh kompresor .zip untuk memilih penyandian blok, tetapi mungkin sama mudahnya dengan mencoba semua penyandian dan menjaga hasil terbaik. Selama pengembangan, jika Anda harus memiliki data Anda di .zip, Anda mungkin ingin memaksa semuanya untuk digunakan storealih-alih deflatemenghemat waktu, maka deflatesemuanya untuk rilis build.

— Russell Borogove

2

Sepertinya beberapa jawaban yang sangat baik telah diberikan, tetapi saya pikir saya akan memberikan satu lagi:

What are the solutions to this double compression problem?

Solusi: Jangan Lakukan Apa pun.

Dasar Pemikiran: Tidak ada masalah yang dinyatakan - ya Anda mengompresi informasi dua kali, tetapi mengapa Anda khawatir tentang hal ini? Apakah ukuran data terlalu besar? Apakah dekompresi terlalu lambat? Apakah ini lebih atau kurang penting daripada lusinan fitur yang dapat Anda tambahkan, perbaiki, uji dan / atau debugging pada saat ini?

— NPSF3000
sumber

Melakukan sesuatu dua kali secara tidak perlu adalah masalah itu sendiri. Setidaknya saya sudah merasakannya. Tapi, tentu saja, Anda benar dengan saran Anda juga. Memori dan kecepatan dekompresi dapat menjadi masalah, meskipun tidak dalam kasus ini, karena saya tidak menulis permainan komersial.

— user1095108

Saya seorang pengembang game profesional, dan saya dapat meyakinkan Anda kecuali ada masalah kinerja nyata dan terdokumentasi yang tidak akan kita buang-buang waktu karena mengkhawatirkan hal ini - dibutuhkan banyak pembelian $ 0,99 atau tayangan iklan untuk membayar katakanlah, 8 jam untuk 'memperbaiki' masalah ini dengan benar. Melakukan sesuatu dua kali bukanlah masalah, meskipun bisa jadi tidak efisien. Meskipun dalam hal ini Anda tidak melakukan hal yang sama dua kali - Anda punya data gambar yang disimpan sebagai PNG untuk kompresi dan sejumlah besar file yang sedang diarsipkan bersama.

— NPSF3000

Benar, tetapi setelah selesai itu dilakukan untuk beberapa proyek. Jika Anda merenungkan algoritma DEFLATE - itu tetap sama sejak tahun delapan puluhan. Anda akan menjadi kakek tua, jika Anda memprogramnya nanti, tetapi, jika Anda tahu algoritmenya, Anda bisa, katakanlah, menerapkannya pada GPU dan menikmati kecepatan dekompresi super cepat di berbagai proyek.

— user1095108

Jadi Anda menghabiskan, apa 2 minggu, sebulan menerapkan Deflate pada GPU? Dan kemudian Anda menyadari bahwa Anda baru saja akan menggunakan platform X daripada Y dan menghancurkan algoritma Anda melalui Z. Jika Anda ingin membuat game, FOKUS PADA MEMBUAT GAMES, jangan khawatir tentang hal-hal yang tidak perlu seperti menurunkan kinerja.

— NPSF3000

Setelah Anda mengetahui suatu algoritma (re) mengimplementasikannya harus mudah. A snap, bukan 2 minggu atau sebulan. Itu yang ingin saya katakan. Sudah ada sejak tahun delapan puluhan, menginvestasikan waktu ke dalamnya mungkin bermanfaat.

— user1095108

1

Jika Anda menggunakan format khusus seperti PNG dan OGG, Anda tidak akan memerlukan kompresi ZIP.

PNG, OGG, dan format lain yang sudah dikompresi tidak akan jauh lebih kecil dengan mengompresnya lagi sebagai ZIP. 100MB PNG terkompresi masih ~ 100MB.

Skrip, file Konfigurasi, dan format berbasis teks lainnya sangat diuntungkan oleh kompresi, namun biasanya sangat kecil jika dibandingkan, mereka tidak menyimpan data sebanyak itu. Jika game Anda 100MB, maka file teks mungkin menghasilkan 1MB dari keseluruhan game, bahkan jika Anda bisa membuatnya 100KB melalui kompresi maka Anda hanya memenangkan 900KB, kurang dari 1%, hampir tidak sepadan dengan usaha.

Anda bahkan mungkin ingin menggunakan sistem file secara langsung daripada menggunakan sistem file virtual, berbasis zip. Itu akan membuat penambalan sangat mudah: Anda bisa menukar semua file yang Anda modifikasi.

— API-Beast
sumber

2

Terkadang seseorang tidak punya pilihan, apakah akan menggunakan .zipfile atau tidak. Misalnya, pada platform android, .apkini adalah .zipfile, yang mungkin berisi sumber daya.

— user1095108

3

Plus, ada keuntungan pasti untuk menggunakan arsip , dan file ZIP menyediakan kompresi dan struktur arsip.

— MrCranky

Ya saya tahu, saya hanya mengatakan bahwa menggunakan sistem file asli juga memiliki kelebihan. Saya sedikit pendukung "Keep it simple".

— API-Beast