Autor Wątek: BPG przyszłość gier i internetu?  (Przeczytany 3711 razy)

Offline timus

  • Użytkownik

  • +6
# Maj 04, 2015, 17:11:47
BPG (Better Portable Graphics) to format grafiki stratnej i bezstratnej o wysokim stopniu kompresji który ma być następca jpeg(jak dla mnie to również idealny następca png). Kilka ważniejszych jego cech:
  • Znacznie mniejsze pliki niż jpeg przy zbliżonej jakości
  • Wsparcie kanału alpha(przeźroczystość)
  • Wsparcie animacji
  • Możliwość osadzenia metadanych np. EXIF
  • Dzięki obecności dekodera w JS, już teraz jest obsługiwany przez większość przeglądarek
  • open-source
  • oparty na kompresorze video HEVC

Posiada jednakże jeden bardzo duży problem, HEVC jest opatentowany w USA, nie jestem prawnikiem ale wydaje mi się, że może to być spora przeszkoda.

Przykłady:

Więcej informacji i szczegółowy na stronie libbpg.org.

Co o tym formacie sądzicie? Czy nadaje się na następce JPEG? Czy nadaje się do użycia w grach? Czy ktoś obeznany z prawem może powiedzieć coś na temat problemu z patentem?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

  • +6
# Maj 04, 2015, 19:11:37
Cytuj
Czy nadaje się do użycia w grach?
A co ma format pliku do gier? Nie sądzę, żeby kiedykolwiek karty graficzne pozwalały na trzymanie tekstur skompresowanych jako BPG, więc co najwyżej zmniejszy to samą paczkę z grą, ale na samo działanie nie wpłynie kompletnie.

Offline koirat

  • Użytkownik

  • +2
# Maj 04, 2015, 21:30:21
Animacja może się przydać.

Offline Xion

  • Redaktor
    • xion.log

  • +2
# Maj 04, 2015, 22:40:49
Hah, przeczytałem ten wątek jako "BGP, przyszłość Internetu" i myślę sobie "Jaka przyszłość? Przecież na BGP Internet działa od dekad!" :) Następnym razem dodaj, że chodzi o grafikę w grach i Internecie.

A co do samego BPG, to zamiast porównań z formatem z zeszłego stulecia, chętniej bym zobaczył, jak się sprawuje w starciu z wynalazkami bliższymi teraźniejszości, jak WebP.

Offline aphity

  • Użytkownik

# Maj 04, 2015, 23:02:19
A co ma format pliku do gier?
Dla AAA pewnie nie zrobi to wielkiej różnicy (bo co to za problem dorzucić do pudełka jeszcze jednego Blu-raya ;) ), ale w grach mobilnych i online objętość paczki tudzież czas downloadu assetów to dość istotne czynniki

Hah, przeczytałem ten wątek jako "BGP, przyszłość Internetu" i myślę sobie "Jaka przyszłość? Przecież na BGP Internet działa od dekad!" :) Następnym razem dodaj, że chodzi o grafikę w grach i Internecie.
To samo. Tyle że ja pomyślałem, że to jakiś news dotyczący odejścia od BGP na rzecz czegoś lepszego :P

edit: Aha, odnośnie patentów: jeżeli faktycznie jest tak jak piszesz, tzn. ta firma ma patent na rozwiązania użyte w tym formacie (i nie da się tych fragmentów zmienić tak by nie naruszać patentów), to, o ile format się spopularyzuje, pewnie skończy się na tym że każdy producent browserów tudzież eksporterów do tego formatu będzie odprowadzać opłatę licencyjną. Tak było z mp3 - tylko że tam posiadacz patentu (Fraunhofer Institut?) zażyczył sobie opłat tylko od enkoderów - więc w cenie produktów umiejących tworzyć mp3 zawarte było bodaj ok. $1 tej opłaty licencyjnej.
« Ostatnia zmiana: Maj 04, 2015, 23:09:14 wysłana przez aphity »

Offline timus

  • Użytkownik

# Maj 04, 2015, 23:31:09
A co do samego BPG, to zamiast porównań z formatem z zeszłego stulecia, chętniej bym zobaczył, jak się sprawuje w starciu z wynalazkami bliższymi teraźniejszości, jak WebP.
Proszę bardzo, mozilla zrobiła takie porównanie(patrz HEVC): http://people.mozilla.org/~josh/lossy_compressed_image_study_july_2014/(jasno widać, że WebP jest na przegranej pozycji)

Hah, przeczytałem ten wątek jako "BGP, przyszłość Internetu" i myślę sobie "Jaka przyszłość? Przecież na BGP Internet działa od dekad!" :) Następnym razem dodaj, że chodzi o grafikę w grach i Internecie.
Wydawało mi się, że umieszczenie tego tematu w dziale Grafika 2D wystarczy, widać duża ilość osób nie zwraca na ten szczegół uwagi, w przyszłości postaram się zawierać tego typu informacje w tytule.

więc co najwyżej zmniejszy to samą paczkę z grą, ale na samo działanie nie wpłynie kompletnie.
Po to właśnie używa się coraz to lepszych algorytmów kompresji w nowych formatach.

Nie sądzę, żeby kiedykolwiek karty graficzne pozwalały na trzymanie tekstur skompresowanych jako BPG
Nie wydaje mi się aby gpu pozwalana na używanie jakiegokolwiek formatu z kompresja(? ktoś ma jakieś informacje, ze tak można ?) chociażby na wzgląd na wydajność. Z drugiej strony nie wszystkie gry muszą używać GPU, ba nawet nie muszą mieć grafiki!
« Ostatnia zmiana: Maj 04, 2015, 23:50:08 wysłana przez timus »

Offline Xender

  • Użytkownik

  • +1
# Maj 05, 2015, 14:21:08
Nie wydaje mi się aby gpu pozwalana na używanie jakiegokolwiek formatu z kompresja(? ktoś ma jakieś informacje, ze tak można ?) chociażby na wzgląd na wydajność.
Są specjalne formaty do kompresji tekstur.
Taka kompresja jest lokalna (tekstura dzielona jest na prostokątne bloki o stałej wielkości) i ma stały współczynnik, co pozwala zachować dostęp swobodny do dowolnego fragmentu w O(1).

https://en.wikipedia.org/wiki/Texture_compression
https://www.opengl.org/wiki/S3_Texture_Compression

Ta klasa algorytmów AFAIK nie ma zastosowania do kompresji plików/strumieni - czy to obrazków, czy wideo.
Chociaż kompresja wideo to temat-rzeka, więc może się mylę i tam też znalazła jakąś niszę.

Z drugiej strony nie wszystkie gry muszą używać GPU, ba nawet nie muszą mieć grafiki!
Grze bez grafiki BPG ani żadna inna jej kompresja niepotrzebna.
Chcesz wykoleić własny temat? :P
« Ostatnia zmiana: Maj 05, 2015, 14:25:51 wysłana przez Xender »

Offline timus

  • Użytkownik

# Maj 05, 2015, 15:32:22
Grze bez grafiki BPG ani żadna inna jej kompresja niepotrzebna.
Chcesz wykoleić własny temat? :P
BPG bezstratny można przecież użyć jako formatu mapy 2D dla gry tekstowej. Przy bardzo dużych mapa pewnie sporo okroił by rozmiar w porównaniu np do mapy w formacie txt.

Offline Xirdus

  • Redaktor

  • +1
# Maj 05, 2015, 20:23:29
@timus: a nie lepiej do kompresji tekstu zastosować format do kompresji tekstu?

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Maj 05, 2015, 20:48:52
Cytuj
Nie wydaje mi się aby gpu pozwalana na używanie jakiegokolwiek formatu z kompresja(? ktoś ma jakieś informacje, ze tak można ?) chociażby na wzgląd na wydajność.
Tekstury trzyma się skompresowane na GPU właśnie ze względu na wydajność. Dekompresję GPU robi całkowicie sprzętowo, więc dekompresja nie boli, a zysk wydajnościowy jest, bo mniej danych do przeciągnięcia z pamięci do GPU.

Cytuj
@timus: a nie lepiej do kompresji tekstu zastosować format do kompresji tekstu?
Jeśli masz zapisaną mapę 2D jako plik tekstowy, to nie zmienia to faktu że nadal są to dane 2D. Inna kwestia, że danych mapy raczej nie będzie tak wiele, żeby sobie tym głowę zawracać.

Offline Xirdus

  • Redaktor

# Maj 06, 2015, 01:56:11
Jeśli masz zapisaną mapę 2D jako plik tekstowy, to nie zmienia to faktu że nadal są to dane 2D.
Ale inne dane. Specyfika plików graficznych i plików tekstowych jest na tyle różna, że wątpię by algorytm zoptymalizowany pod grafikę pokonał na tym polu algorytm zoptymalizowany pod tekst. Inna sprawa, że ASCII Art tak naprawdę tekstem nie jest (chodzi o dystrybucję poszczególnych liter na przestrzeni tekstu), więc i algorytmy inaczej zadziałają. Oczywiście pomijając to, że jak już wspomniałeś, dużo tego nie ma, a jak trzeba to ZIP starczy aż nadto.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Maj 06, 2015, 03:29:41
Cytuj
Ale inne dane. Specyfika plików graficznych i plików tekstowych jest na tyle różna, że wątpię by algorytm zoptymalizowany pod grafikę pokonał na tym polu algorytm zoptymalizowany pod tekst.
Algorytm kompresji plików graficznych ma tę przewagę, że robi predykcję na podstawie sąsiadów w dwóch wymiarach.

Cytuj
Inna sprawa, że ASCII Art tak naprawdę tekstem nie jest (chodzi o dystrybucję poszczególnych liter na przestrzeni tekstu), więc i algorytmy inaczej zadziałają.
Właśnie o to mi chodzi. Poza tym nie widziałem generalnie żadnego algorytmu do kompresji typowo tekstu, który był by w szerszym użyciu - zwykle używa się zipa i tyle.

Offline Xion

  • Redaktor
    • xion.log

# Maj 06, 2015, 06:22:05
Cytuj
Właśnie o to mi chodzi. Poza tym nie widziałem generalnie żadnego algorytmu do kompresji typowo tekstu, który był by w szerszym użyciu - zwykle używa się zipa i tyle.
Przy obecnych rozmiarach pamięci i szybkościach transferu, zwykły tekst nie osiąga po prostu rozmiarów na tyle kłopotliwych, żeby jakaś specjalna kompresja się opłacała. Wyjątkiem może być kompresja tekstu o pewnej strukturze, czyli np.:
  • kodu w VCS-ach przy dużych projektach (>1MLOC) -- tutaj można by zobaczyć, czego używają np. Git albo Perforce
  • danych przesyłanych po HTTP -- tutaj powszechny jest gzip (inna sprawa, że np. zminifikowany JavaScript pod względem entropii ma niewiele wspólnego z kodem, o prozie nie wspominając, a o wiele więcej z binarnymi blobami)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Maj 06, 2015, 12:15:20
Cytuj
(inna sprawa, że np. zminifikowany JavaScript pod względem entropii ma niewiele wspólnego z kodem, o prozie nie wspominając, a o wiele więcej z binarnymi blobami)
Byś się zdziwił. Zminifikowane źródła bardzo często kompresują się lepiej od binarek (gdzie "a+b" bardzo rzadko da się zakodować w trzech bajtach), a także oryginalnych źródeł (brak spacji i  długich identyfikatorów).

Offline Xender

  • Użytkownik

# Maj 06, 2015, 16:15:50
Wyjątkiem może być kompresja tekstu o pewnej strukturze, czyli np.:
  • kodu w VCS-ach przy dużych projektach (>1MLOC) -- tutaj można by zobaczyć, czego używają np. Git albo Perforce
Nie wiem, co siedzi w P4.

W Gicie luźne obiekty to zwykłe, generyczne zlib.deflate.
Packfile chyba tym samym, tylko przedtem robi się delty pomiędzy różnymi obiektami w packfile (korzystając z heurystyki, że bloby odpowiadające plikom o tej samem nazwie i pozycji w drzewie w kolejnych commitach (czyli po prostu kolejno zacommitowane wersje jednego pliku) prawdopodobnie są podobne i delty między nimi będą małe).
Delty są tutaj chyba binarne.

Hg z kolei leci na diffach, chyba tekstowych, pewnie też kompresowanych, ale nie wiem.