Unikaj podwójnej kompresji zasobów


13

Używam .pngs dla moich tekstur i używam wirtualnego systemu plików w .zippliku dla mojego projektu gry. Oznacza to, że moje tekstury są dwukrotnie kompresowane i dekompresowane. Jakie są rozwiązania tego problemu podwójnej kompresji? Jednym z rozwiązań, o których słyszałem, jest użycie .tgas do tekstur, ale wydaje się, że wieki temu, odkąd to słyszałem. Innym rozwiązaniem jest wdrożenie dekompresji na, GPUa ponieważ jest to szybkie, zapomnij o kosztach ogólnych.


2
Powiązane: jeśli używałeś plików JPEG, wiele programów zip z własnym formatem jest w stanie skompresować nawet te o 20%, więc niekoniecznie jest tak źle. Jaki jest sens podwójnej kompresji, o którą najbardziej się martwisz? Czy to trwa zbyt długo? Wiele formatów przechowuje nawet skompresowane dane tylko dosłownie i nie robi na nich żadnej dekompresji.
PlasmaHH

Odpowiedzi:


17

Format zip obsługuje kilka różnych algorytmów kompresji. Możesz użyć innego algorytmu dla każdego pliku w archiwum. Jeśli chcesz przechowywać skompresowane pliki, które nie korzystają z dodatkowej kompresji (np. PNG) w archiwum zip, możesz zakodować te pliki za pomocą algorytmu „zapisanego”, który w ogóle się nie kompresuje. Okno dialogowe „Dodaj do archiwum” 7-zip pozwala wybrać to w „Siła kompresji”.

Ale gdy w archiwach masz nie tylko obrazy, ale także inne, bardziej kompresowalne zasoby, wybranie algorytmu dla każdego pliku może być dość nużące. W takim przypadku możesz raczej wybrać nieskompresowany format obrazu w archiwum kompresującym.

Format TGA zna wiele różnych trybów, z których niektóre są skompresowane, a niektóre nie. Jeśli nie chcesz używać kompresji, upewnij się, że wybrałeś właściwą w opcjach eksportu edytora graficznego, którego używasz. Innym nieskompresowanym formatem obrazu jest BMP (Windows Bitmap).

Oto test, który zrobiłem. Wielokrotnie dodawałem ten sam obraz (zasób z mojego obecnego projektu) w różnych formatach do archiwum zip, niektóre z algorytmem „deflate” na normalnej sile, a drugie z „store”. Przepraszamy za niemiecki GUI. Druga kolumna ma nieskompresowany rozmiar, trzecia kolumna jest algorytmem kompresji, a czwarta kolumna ma rozmiar skompresowany.

wprowadź opis zdjęcia tutaj

Jak widać, kodowanie deflate PNG pozwoliło zaoszczędzić zaledwie 0,3%, podczas gdy BMP kodowany deflate jest redukowany do jednej dziesiątej oryginalnego pliku, który jest nawet mniejszy niż wersja PNG. To mnie zaskoczyło. Spodziewałbym się, że PNG będzie mniejszy, ponieważ metoda kompresji PNG powinna być zoptymalizowana dla danych obrazu, podczas gdy ZIP nie jest. Prawdopodobnym wyjaśnieniem jest to, że mój edytor obrazów (GIMP) dodał całkiem sporo meta-informacji do plików PNG, czego nie robi w przypadku BMP.

Nieskompresowany TGA zachowywał się podobnie do BMP w zakresie rozmiaru pliku przed i po skompresowaniu, podczas gdy kompresja skompresowanego pliku TGA została dodatkowo poprawiona przez ZIP, chociaż nie tak bardzo, jak wersje nieskompresowane.

Warto eksperymentować z innymi algorytmami niż deflacja i innymi ustawieniami siły kompresji. Która kombinacja przyniesie najlepsze rezultaty, prawdopodobnie zależy od stylu twoich tekstur. Możesz również rozważyć porównanie obciążenia gry i mieć wpływ na wydajność dekompresyjną w podejmowaniu decyzji o używanym ustawieniu.

Dolna linia: Jeśli chcesz uniknąć podwójnej kompresji przy zachowaniu niskiej rozmiar pliku, można użyć PNGz Storealgorytmem zip lub BMPz algorytmem kompresji zip.


5
Zrobiłem to na niektórych moich zdjęciach, a PNG (poziom kompresji 9) pokonał zip (poziom kompresji ultra) obrazów BMP przez cały czas o około 20%. Powinien to być efekt podobny do meta-informacji.
Trilarion

3
png ma opcję przeplotu ze zmniejszoną ściśliwością, ale pozwala na wyodrębnienie obrazu o niskiej rozdzielczości tylko z pierwszej części pliku obrazu (np. podczas pobierania przez połączenie o niskiej przepustowości), czy twoja ściana ma to aktywne? poza tym png już używa deflate do kompresji.
maniak zapadkowy

Wygląda na to, że użyłeś słabej kompresora png, uruchom swoje pliki przez PNGOUT i powinieneś otrzymać wynik, który nie zostanie pobity przez spakowany plik bmp.
aaaaaaaaaaaa

Czy Twoje BMP lub TGA są 24-bitowe czy 32-bitowe? W szczególności w przypadku BMP są one bardziej prawdopodobne w wersji 24-bitowej, a nieskompresowany rozmiar TGA sugeruje, że jest to również 24-bit. Prawdopodobnie nie porównujesz tego z podobnym.
Maximus Minimus

@ JimmyShelter Zarówno TGA, jak i BMP są 32-bitowe z kanałem alfa - upewniłem się.
Philipp

7

Nie martw się o to.

Kiedy algorytm „deflacji” zastosowany w plikach .zip napotka blok danych, który jest już dobrze skompresowany, na przykład dane pikselowe obrazu .png, stwierdza, że ​​nie może go skutecznie skompresować i zapisze go jako dosłowny nieskompresowane dane. Kopiowanie tego wymaga bardzo małego obciążenia po zakończeniu dekompresji.

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


3
Czasami jest to takie proste, postrzegany problem niekoniecznie jest prawdziwym problemem. Nawet jeśli faktycznie byłby narzut związany z dwukrotną dekompresją, rozpakowywanie deflatu jest naprawdę szybką operacją, myślę, że narzut byłby po prostu mierzalny.
aaaaaaaaaaaa

Czy zakończenie kompresji zajęłoby dużo czasu, aby zrozumieć, że plik nie jest kompresowalny?
user253751

Stosunkowo tak. Nie wiem, jakich typowych heurystyk używają kompresory .zip, aby wybrać kodowanie bloku, ale może to być tak proste, jak wypróbowanie wszystkich kodowań i zachowanie najlepszego wyniku. Podczas programowania, jeśli musisz mieć swoje dane w formacie .zip, prawdopodobnie będziesz chciał zmusić wszystko do użycia storezamiast deflateoszczędzać czas, a następnie deflatewszystko do kompilacji wersji.
Russell Borogove

2

Wygląda na to, że podano już bardzo dobre odpowiedzi, ale pomyślałem, że dam jeszcze jedną:

What are the solutions to this double compression problem?

Rozwiązanie: Nic nie rób.

Uzasadnienie: Nie stwierdzono problemu - tak, kompresujesz informacje dwukrotnie, ale dlaczego się o to martwisz? Czy rozmiar danych jest zbyt duży? Czy dekompresja jest zbyt wolna? Czy jest to mniej lub bardziej ważne niż dziesiątki funkcji, które możesz dodawać, udoskonalać, testować i / lub debugować w tym momencie?


Robienie czegoś dwa razy niepotrzebnie stanowi problem sam w sobie. Przynajmniej tak to postrzegałem. Ale oczywiście masz rację także ze swoją sugestią. Problemem może być zarówno pamięć, jak i szybkość dekompresji, choć nie w tym przypadku, ponieważ nie piszę gry komercyjnej.
user1095108

Jestem profesjonalnym twórcą gier i zapewniam cię, chyba że wystąpią prawdziwe, udokumentowane problemy z wydajnością, nie będziemy tracić ani sekundy na martwienie się o to - trzeba zapłacić 0,99 USD na zakupy lub wyświetlenia reklam, aby zapłacić, powiedzmy, 8 godziny, aby poprawnie „naprawić” ten problem. Robienie czegoś dwa razy nie jest problemem, choć może być nieefektywne. Chociaż w tym przypadku nie robisz tego samego dwa razy - masz dane obrazu przechowywane w formacie PNG do kompresji i całą masę plików, które są archiwizowane razem.
NPSF3000

To prawda, ale kiedy to się stanie, zrobione jest dla wielu projektów. Jeśli zastanowisz się nad algorytmem DEFLATE - pozostał taki sam od lat osiemdziesiątych. Bylibyście starymi grampami, gdybyście wtedy zaprogramowali, ale gdybyście znali algorytm, moglibyście, powiedzmy, zaimplementować go na GPU i cieszyć się superszybkimi prędkościami dekompresji w wielu projektach.
user1095108

Więc spędzasz, co 2 tygodnie, miesiąc wdrażając Deflate na GPU? A potem zdajesz sobie sprawę, że właśnie wdrażasz na platformie X niż Y i łamie algorytm przez Z. Jeśli chcesz tworzyć gry, skup się na tworzeniu gier, nie martw się o niepotrzebne rzeczy, takie jak obniżenie wydajności.
NPSF3000

Gdy poznasz (ponownie) algorytm, jego wdrożenie powinno być łatwe. Błyskawicznie, nie 2 tygodnie lub miesiąc. Tak chciałem powiedzieć. Istnieje już od lat osiemdziesiątych, warto zainwestować w to trochę czasu.
user1095108

1

Jeśli używasz specjalistycznych formatów, takich jak PNG i OGG, nie potrzebujesz kompresji ZIP.

PNG, OGG i inne już skompresowane formaty nie zmniejszą się znacznie, kompresując je ponownie jako ZIP. 100 MB skompresowanych plików PNG to nadal ~ 100 MB.

Skrypty, pliki konfiguracyjne i inne formaty tekstowe znacznie korzystają z kompresji, jednak zazwyczaj są one niewielkie w porównaniu, nie przechowują tak dużej ilości danych. Jeśli twoja gra ma 100 MB, to pliki tekstowe mogą stanowić 1 MB całej gry, nawet jeśli możesz zrobić to 100 KB poprzez kompresję, wygrałeś tylko 900 KB, mniej niż 1%, nie warte wysiłku.

Możesz nawet chcieć użyć systemu plików bezpośrednio zamiast wirtualnego systemu plików opartego na zipie. Ułatwiłoby to łatanie: możesz po prostu zamienić zmodyfikowane pliki.


2
Czasami nie ma wyboru, czy użyć .zippliku, czy nie. Na przykład na platformie Android .apkjest to .zipplik, który może zawierać zasoby.
user1095108

3
Ponadto istnieją pewne zalety korzystania z archiwum , a pliki ZIP zapewniają zarówno kompresję, jak i strukturę archiwum.
MrCranky

Tak, wiem, mówię tylko, że korzystanie z natywnego systemu plików ma również zalety. Jestem trochę zwolennikiem „upraszczania”.
API-Beast
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.