Online-Abo
  • Login
  • Registrieren
Games World
      • Von ruyven_macaran Trockeneisprofi (m/w)
        Bezüglich der Texturen: Filterung kostet Rechenleistung (und zwar dann, wenn man sie am dringensten braucht), vorberechnete Texturen nicht. Die Gesamtkapazität des RAM würde natürlich auch zum Problem werden, wenn die Szene eine große Sichtweite mit vielfältigen Objekten besitzt. (nicht aber in Szenen mit geringer Sichtweite, denn da muss die Textur dann eh auch in den kleinen Auflösungen vorliegen)


        Jo, ist verständlich.
        Wenn das für die anderen Kanäle genauso gemacht wird (und auf geichem Maßstab), sollte es in der Tat kein Problem sein, das Bild mit einem 8x8tel der Auflösung darzustellen.
      • Von Masochist Komplett-PC-Käufer(in)
        Zitat von ruyven_macaran
        Mit Texturen kenne ich mich n bissl besser aus da werdene explizit niedriger aufgelöste Mip-Maps erstellt, die zusätzlich gespeichert werden. Sinn der Sache ist auch nicht so sehr die Einsparung von Bandbreite (dafür gibt es zusätzlich reine Komprimierungsmechanismen), sondern Vereinfachung der Berechnung bzw. Verhinderung von Unterabtastatung. (Aliasing&Flimmern, wenn eine hochaufgelöste Textur auf wenigen Pixeln wiedergegeben werden müsste. Da ist es sinnvoller, eine niederaufgelöste Variante zu erzeugen)

        Das mit dem Koeffizienten - kannst du mal erklären, was der in der Komprimierung macht?
        Ok, hauptsächlich geht es bei den Texturen sicherlich um das vermeiden von Flimmern, aber das könnte man zur not ja bestimmt auch durch antialiasing und anisotrope Filterung verhindern. Nur wenn man jede in einer 3D-Szene verwendete Textur hochaufgelöst darstellen würde, würde sicherlich auch der Texturspeicher bei zeiten überlaufen. Is also nich ganz vernachlässigbar denk ich mal.
        Das die jetzt tatsächlich immer mehrere Detailstufen einer Textur speichern hätt ich nich gedacht, aber gut dann war mein Beispiel etwas schlecht gewählt. Hat aber eine ähnliche funktion.

        Zu den Koeffizienten. Einfach gesagt werden durch die DCT Koeffizienten ermittelt, welche Luminanzunterschiede in einem Pixelblock vorherschen. Jeder Koeffizient steht, wie bei der FFT die einzelnen Frequenzen, hier für den Wert einer Frequenz eines Helligkeitswertes. Zuerst wird der mittlere Helligkeitswert ermittelt und als Koeffizient ausgedrückt (Gleichstromanteil). Die folgenden Koeffizienten beschreiben immer den Helligkeitsunterschied, also + oder -. Für jeden Pixelblock gibt es der Frequenz nach aufsteigende Koeffizienten welche in kleineren Pixelblöcken die entsprechenden Helligkeitsunterschiede ausdrücken. Durch die alleinige Speicherung der Unterschiedswerte kann enorm an redundanz eingespart werden, trotz einigermaßen korrekter Darstellung. Das schlimmste sind eigentlich die Randregionen der 64 8x8 Blöcke. Dort kommt es meist zu Sprungstellen.
        So ich hoffe mal ich hab mich einigermaßen verständlich und korrekt ausgedrückt.
      • Von ruyven_macaran Trockeneisprofi (m/w)
        Mit Texturen kenne ich mich n bissl besser aus da werdene explizit niedriger aufgelöste Mip-Maps erstellt, die zusätzlich gespeichert werden. Sinn der Sache ist auch nicht so sehr die Einsparung von Bandbreite (dafür gibt es zusätzlich reine Komprimierungsmechanismen), sondern Vereinfachung der Berechnung bzw. Verhinderung von Unterabtastatung. (Aliasing&Flimmern, wenn eine hochaufgelöste Textur auf wenigen Pixeln wiedergegeben werden müsste. Da ist es sinnvoller, eine niederaufgelöste Variante zu erzeugen)

        Das mit dem Koeffizienten - kannst du mal erklären, was der in der Komprimierung macht?
      • Von Masochist Komplett-PC-Käufer(in)
        Zitat von TempestX1
        Nicht ganz. Es gibt wie schon im Thread geschrieben verlustbehaftete Kompression und verlustfreie Kompression. Die Datei wird bei beidem kleiner, aber bei letzterem gibt es zum Originalbild keine Unterschiede.
        Da stimm ich Dir schon zu und es is richtig was du schreibst. Nur es war von mir erstmal im groben nur gemeint das beim komprimieren eben redundante, irrelevante und auch tlw. eben benötigte Daten entsorgt werden. Was bei der Wiedergabe für den Menschen wichtig ist und was nicht, ist sehr unterschiedlich, aber dies ist eben der ausgangspunkt von Codecs wie JPEG oder MPEG2-Layer3. Es gibt auf jeden fall auch so genannte "verlustfreie" Codecs. Datenverlust haben fast alle nur der Informationsverlust ist eben unterschiedlich ^^

        Zitat von ruyven_macaran

        Der Browser muss aber bei jedem Bild einzeln entscheiden, wieviel er davon braucht.
        Ja das stimmt schon, aber er bekommt ja meist den Header zuerst um was mit der Datei anfangen zu können, zumindest wenn er es Progressiv laden soll. Früher ging das mal irgendwo einzustellen. Egal, im normalfall bekommt er sicherlich erst den Header und damit weis er sofort wieviel er von der Datei braucht (selbst die Downloads geschehen bei den meisten Browsern Progressiv und um zu wissen wieviel Speicherplatz benötigt wird, wird meist erst der Header übertragen und analysiert). Bei symmetrischen Übertragungsraten wie bei ISDN ist es somit ohne weiteres möglich dem Server die (im vergleich zur Datenrate) große Datei vor dem kompletten Senden abzuwürgen (oder zumindest die Übertragung auf der "langsamen" letzten Meile zu verhindern).
        Zitat von ruyven_macaran

        Aber führt eine derartige Komprimierungsform nicht in sich zu einer insgesamt größeren Datei? Afaik beruhen die meisten Komprimierungstechniken darauf, dass Informationen mehrerer Pixel auf eine Struktur hin anaylsiert und diese Struktur dann übertragen/gespeichert wird (also "4*rot" statt "rot-rot-rot-rot"). Daraus entsteht nicht automatisch eine niedriger aufgelöste Form des Bildes, die müsste man extra erzeugen.
        Das einzige Verfahren, bei dem sie automatisch integriert wäre, wäre eine Vereinigung der Pixel zu immer größeren Kacheln, wobei zur Wiederherstellung der hochauflösenden Form nur noch die Abweichung der jeweiligen Subeinheit zum Mittelwert des großen&ganzen übertragen wird. Da wäre die Kompressionsrate bei kontrastreichen Bildern aber nahe null.
        Kontrastreiche Bilder lassen sich auch nur schlecht komprimieren. Die Lauflängenkodierung wird nicht unbedingt immer angewendet und dient auch nur der redundanzreduktion. Die meisten Coder nutzen aber komplexere verfahren der Zeichenkodierung, da nur wenige Dateien viele gleiche aufeinanderfolgende Zeichen beinhalten.
        Bei JPEG gibt es definitiv die Möglichkeit des auslesens der ersten Koeffizienten eines jeden Bildblocks. Dazu muss eben nur beim Komprimieren ein häckchen bei Progressiv gesetzt werden, dann sollten diese Daten auch am Anfang der Datei stehen.
        Zitat von Nasenbaer

        Wegen diesen letzten Schrittes bringt es eigentlich auch nie was die Daten nochmal zu zippen - JPEG, MP3s, Filme werden dadurch fast immer größer als vorher.
        Das liegt aber hauptsächlich daran das Zip-Dateien eine eigene Codetabelle (oder so ähnlich) erstellen. Dadurch kommt zu den ohnehin schon komprimierten Daten noch zusätzliche Information hinzu. (nur so als Ergänzung zu deiner Aussage)
        Zitat von ruyven_macaran

        Aber mein Argument hat bestand: Das ganze Systeme basiert auf Pixeln/Bildabschnitten, nicht auf hierarchischen System, dass das ganze Bild erfasst und zunehmend feiner darstellt. Es liegt keine Sequenz vor, die das ganze Bild grob Beschreibt und eine Art Voransicht ermöglichen würde.
        Prinzipiell schon, denn wie gesagt es gibt die Möglichkeit die Koeffizienten der DFT für die niederfrequenten (verschwommenen) Bildinhalte zuerst auszulesen.
        Übrigens: In PC-Games wird ein ähnliches Verfahren angewendet um Texturspeicher zu sparen. Texturen werden erst komplett geladen wenn sich die Kameraperspektive nähert. Zuvor erscheinen nur die verschwommenen Texturen der niedrigen Koeffizienten. Das gleiche gilt seit kurzem auch für die Geometrie. Hier nennt es sich dann Tesselation.
      • Von ruyven_macaran Trockeneisprofi (m/w)
        Das jpeg gezielt Informationen weglässt, wusste ich gar nicht - dachte nur, dass es sich nicht drum kümmert, wenn sich komprimierte Form nicht mehr eindeutig hochrechnen lässt.
        Aber mein Argument hat bestand: Das ganze Systeme basiert auf Pixeln/Bildabschnitten, nicht auf hierarchischen System, dass das ganze Bild erfasst und zunehmend feiner darstellt. Es liegt keine Sequenz vor, die das ganze Bild grob Beschreibt und eine Art Voransicht ermöglichen würde.
  • Print / Abo
    Apps
    PC Games Hardware 01/2017 PC Games 12/2016 PC Games MMore 01/2016 play³ 12/2016 Games Aktuell 12/2016 buffed 12/2016 XBG Games 11/2016
    PCGH Magazin 01/2017 PC Games 12/2016 PC Games MMORE Computec Kiosk On the Run! Birdies Run
article
776503
Internet
Webp löst bald Jpeg ab?
Google will mit seinem neuen Bildformat Webp JPEG ablösen. Basierend auf dem VP8-Codec erlaubt das neue Format im Schnitt eine 39 Prozent stärkere Kompression als bisherige Formate. Kritiker bezweifeln die Qualität der neuen Bilder.
http://www.pcgameshardware.de/Internet-Thema-34041/News/Webp-loest-bald-Jpeg-ab-776503/
01.10.2010
http://www.pcgameshardware.de/screenshots/medium/2010/10/x264_psnr.png
google,internet,bildbearbeitung
news