Kaynakların iki kez sıkıştırılmasından kaçının


13

.pngDokularım için s kullanıyorum ve .zipoyun projem için bir dosyada sanal dosya sistemi kullanıyorum . Bu, dokularımın iki kez sıkıştırıldığı ve açıldığı anlamına geliyor. Bu çift sıkıştırma probleminin çözümleri nelerdir? Duyduğum bir çözüm, .tgas'yi dokular için kullanmaktır , ancak bunu duyduğumdan yıllar önce görünüyor. Başka bir çözüm de dekompresyon uygulamaktır GPUve bu hızlı olduğu için ek yükü unutun.


2
İlgili: jpegs kullandıysanız, kendi formatına sahip bir çok zip programı% 20 bile bunları sıkıştırabilir, bu yüzden o kadar da kötü değildir. Çift kompresyonda en çok endişe duyduğunuz nokta nedir? Çok mu uzun sürüyor? Birçok format zaten sıkıştırılmış verileri bile kelimesi kelimesine saklar ve üzerlerinde herhangi bir açma işlemi yapmaz.
PlazmaHH

Yanıtlar:


17

Zip formatı birkaç farklı sıkıştırma algoritmasını destekler. Arşivdeki her dosya için farklı bir algoritma kullanabilirsiniz. Ek sıkıştırmadan (PNG gibi) yararlanmayan zaten sıkıştırılmış dosyaları bir zip arşivinde saklamak istediğinizde, bu dosyaları hiç sıkıştırmayan "depolanmış" algoritma ile kodlayabilirsiniz. 7-zip'in "Arşive ekle" iletişim kutusu bunu "Sıkıştırma gücü" altında seçmenizi sağlar.

Ancak arşivlerinizde yalnızca resimleriniz değil, daha sıkıştırılabilir kaynaklarınız da olduğunda, her bir dosya için algoritmayı seçmek oldukça sıkıcı olabilir. Bu durumda, sıkıştırma arşivinde sıkıştırılmamış görüntü biçimini tercih edebilirsiniz.

TGA formatı, bazıları sıkıştırılmış ve bazıları sıkıştırılmamış birçok farklı modu bilir. Sıkıştırma kullanmak istemediğinizde, kullandığınız grafik düzenleyicinin dışa aktarma seçeneklerinde doğru olanı seçtiğinizden emin olun. Sıkışmayan başka bir görüntü formatı BMP'dir (Windows Bitmap).

İşte yaptığım bir test. Aynı görüntüyü (mevcut projemden bir varlık) farklı biçimlerde birden çok kez bir zip arşivine ekledim, bazıları normalde "deflate" -algoritması ve "store" ile bir tane. Alman GUI için üzgünüm. 2. sütun sıkıştırılmamış boyut, 3. sütun sıkıştırılmış algoritma ve 4. sütun sıkıştırılmış boyuttur.

resim açıklamasını buraya girin

Gördüğünüz gibi, PNG'nin deflate kodlaması yalnızca% 0,3'lük bir tasarruf sağladı, deflate kodlu BMP, PNG versiyonundan bile daha küçük olan orijinal dosyanın onda birine indirildi. Bu beni oldukça şaşırttı. ZIP sıkıştırma olmasa da PNG'nin sıkıştırma yönteminin görüntü verileri için optimize edilmesi gerektiğinden PNG'nin daha küçük olmasını beklerdim. Muhtemel bir açıklama, resim düzenleyicimin (GIMP), PNG dosyalarına BMP için yapmadığı oldukça fazla meta bilgi eklediğidir.

Sıkıştırılmamış TGA dosyasının sıkıştırılmamış versiyonları kadar olmasa da sıkıştırılmış TGA dosyasının sıkıştırılması ZIP tarafından daha da geliştirilirken sıkıştırılmamış TGA, sıkıştırmadan önce ve sonra dosya boyutuyla ilgili BMP'ye benzer şekilde davrandı.

Söndürme dışındaki diğer algoritmalarla ve diğer sıkıştırma gücü ayarlarıyla denemeye değer olabilir. Hangi kombinasyonun en iyi sonuçları alacağı muhtemelen dokularınızın stiline bağlı olacaktır. Ancak, oyununuzun varlık yüklemesini karşılaştırmayı ve dekompresyon performansının hangi ayarı kullandığınıza kararınızı etkilemesini de düşünebilirsiniz.

Alt satır: Hala düşük bir dosya boyutuna sahipken çift sıkıştırmayı önlemek istediğinizde PNG, Storezip algoritmasıyla veya BMPsıkıştırma zip algoritmasıyla kullanın.


5
Bazı resimlerimde yaptım ve PNG (sıkıştırma seviyesi 9) BMP görüntülerinin zip (sıkıştırma seviyesi ultra) her zaman yaklaşık% 20 oranında yendi. Bu yüzden meta-bilgi gibi bir etki olmalı.
Trilarion

3
png, sıkıştırılabilirliği azaltan bir geçmeli seçeneğe sahiptir, ancak düşük çözünürlüklü bir görüntünün görüntü dosyasının sadece ilk kısmından çıkarılmasına izin verir (düşük bant genişliği bağlantısı üzerinden indirilirken olduğu gibi), duvarınızda bu etkin miydi? Ayrıca png sıkıştırması için deflate kullanır.
cırcır ucube

Kötü bir png kompresörü kullandığınız, dosyalarınızı PNGOUT aracılığıyla çalıştırdığınız ve sıkıştırılmış bir bmp dosyası tarafından dövülmeyecek bir sonuç almanız gerektiği anlaşılıyor.
aaaaaaaaaaaa

BMP'leriniz veya TGA'larınız 24 bit mi yoksa 32 bit mi? Özellikle BMP ile 24 bit olma olasılıkları daha yüksektir ve sıkıştırılmamış TGA boyutu bunun 24 bit olduğunu göstermektedir. Muhtemelen burada olduğu gibi karşılaştırmıyorsunuzdur.
Maximus Minimus

@JimmyShelter Alfa kanalı ile hem TGA hem de BMP 32bit - Emin oldum.
Philipp

7

Endişelenme.

.Zip dosyalarında kullanılan "deflate" algoritması, bir .png görüntüsünün piksel verileri gibi zaten iyi sıkıştırılmış bir veri bloğuyla karşılaştığında, onu etkili bir şekilde sıkıştıramayacağını bulur ve bunu tam olarak depolar sıkıştırılmamış veri. Bu, kopyalamak için dekompresyon ucunda çok az ek yük gerektirir.

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


3
Bazen bu kadar basittir, algılanan bir sorun mutlaka gerçek bir sorun değildir. Aslında iki kez dekompresyon yükü olsa bile, sıkıştırılmamış söndürme gerçekten hızlı bir işlemdir, sanırım tepegöz sadece ölçülebilir olacaktır.
aaaaaaaaaaaa

Misiniz sıkıştırma sonu dosyası sıkıştırılabilir olmadığını fark etmek uzun zaman alır?
user253751

Nispeten, evet. Tipik .zip kompresörlerin bir blok kodlamasını seçmek için ne kullandığını bilmiyorum, ancak tüm kodlamaları denemek ve en iyi sonucu tutmak kadar basit olabilir. Eğer gelişme sırasında, gereken bir .zip senin bilgi var, muhtemelen kullanmak için her şeyi zorlamak isteyeceksiniz storeyerine deflatekaydetme zaman, o zaman deflateserbest bırakılması için her şey oluşturur.
Russell Borogove

2

Bazı çok iyi yanıtlar verilmiş gibi görünüyor, ama bir tane daha vereceğimi düşündüm:

What are the solutions to this double compression problem?

Çözüm: Hiçbir şey yapmayın.

Gerekçe: Herhangi bir sorun belirtilmedi - evet bilgiyi iki kez sıkıştırıyorsunuz, ama neden bu konuda endişelisiniz? Veri boyutu çok mu büyük? Dekompresyon çok yavaş mı? Bu, şu anda ekleyebileceğiniz, hassaslaştırabileceğiniz, test edebileceğiniz ve / veya hata ayıklayabileceğiniz düzinelerce özellikten daha fazla veya daha az önemli mi?


Gereksiz yere iki kez bir şey yapmak başlı başına bir sorundur. En azından ben böyle algıladım. Ancak, elbette, önerinizde de haklısınız. Hem ticari hem de dekompresyon hızı, bu durumda olmasa da, ticari bir oyun yazmıyorum gibi bir sorun olabilir.
user1095108

Ben profesyonel bir oyun geliştiriciyim ve gerçek, belgelenmiş performans sorunları olmadıkça sizi temin ederim, bu konuda endişe duymayacağım ikinci bir şey - söz için ödemek için 0,99 $ çok fazla satın alma veya reklam gösterimi gerekiyor, 8 bu sorunu 'düzeltmek' için birkaç saat. Bir şeyi iki kez yapmak sorun değildir, ancak verimsiz olabilir. Bu durumda aynı şeyi iki kez yapmamanıza rağmen, sıkıştırma için PNG olarak depolanan görüntü verileriniz ve birlikte arşivlenen bir sürü dosya var.
NPSF3000

Doğru, ama bir kez bittiğinde birden fazla proje için yapılır. DEFLATE algoritması hakkında düşünürseniz - seksenli yıllardan beri aynı kaldı. Daha sonra programladıysanız eski bir gramps olursunuz, ancak algoritmayı biliyorsanız, GPU'ya uygulayabilir ve birden fazla projede süper hızlı açma hızlarının tadını çıkarabilirsiniz.
user1095108

GPU'da Deflate'i uygulamak için bir ayını ne kadar hafta harcıyorsunuz? Ve sonra X platformuna Y'den daha fazla dağıtmak üzere olduğunuzu ve algoritmanızı Z yoluyla kırdığınızı anlıyorsunuz.
NPSF3000

Bir algoritmayı (yeniden) uyguladıktan sonra kolay olmalıdır. Bir çırpıda, 2 hafta veya bir ay değil. Bunu söylemek istedim. Seksenli yıllardan beri var, içine biraz zaman ayırmak faydalı olabilir.
user1095108

1

PNG ve OGG gibi özel biçimler kullanırsanız ZIP sıkıştırmasına ihtiyacınız olmaz.

PNG, OGG ve diğer zaten sıkıştırılmış formatlar, tekrar ZIP olarak sıkıştırılarak çok daha küçük olmayacaktır. Sıkıştırılmış 100 MB PNG'ler hala ~ 100 MB'dir.

Komut dosyaları, Yapılandırma dosyaları ve diğer metin tabanlı formatlar sıkıştırmadan büyük ölçüde yararlanır, ancak genellikle karşılaştırmada küçüktürler, çok fazla veri depolamazlar. Oyununuz 100MB ise, metin dosyaları sıkıştırma yoluyla 100KB yapabilseniz bile, tüm oyunun 1MB'ını yapabilir, ancak sadece% 1'den az, zahmete değmez 900KB kazandınız.

Hatta sanal, zip tabanlı bir dosya sistemi kullanmak yerine dosya sistemini doğrudan kullanmak isteyebilirsiniz. Yamalamayı çok kolay hale getirir: sadece değiştirdiğiniz dosyaları değiştirebilirsiniz.


2
Bazen bir .zipdosyanın kullanılıp kullanılmayacağı konusunda bir seçenek yoktur. Örneğin, android platformunda, kaynaklar içerebilecek .apkbir .zipdosyadır.
user1095108

3
Ayrıca, arşiv kullanmanın kesin avantajları vardır ve ZIP dosyaları hem sıkıştırma hem de arşiv yapısı sağlar.
MrCranky

Evet biliyorum, sadece yerel dosya sistemini kullanmanın da avantajları olduğunu söylüyorum. Biraz "Basit tut" savunucusuyum.
API-Beast
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.