Hi,

es gibt ja in OpenGL diverse Textur kompressionsverfahren... bisher hab ich das nie verwendet, und bevor ich mich da jetzt reinlese nur um festzustellen das das, was ich will garnicht geht frag ich hier mal

Gibt es bei den kompressionen irgendeine, die das Bild verlustfrei komprimiert, oder wenigstens nur mit mini mini mini minimalem verlust? ^^
Und, wenn ja... kann ich die Bild daten schon im RAM komprimieren und dann die schon komprimierten daten an die Grafikkarte schicken?
Und wenn das auch ja.. wie ist der algo für's komprimieren, so das die GraKa die daten versteht?

Daanke schonmal,
Aya~

Bei komprimierten Texturen nehm ich immer DDS. Das kann man direkt komprimiert an die Grafikkarte schicken.
Verlust hat man beim kombrimieren eigentlich immer. Aber es gibt für DDS noch verschiedene Kompressions Algorythmen die das kaschieren können.

_________________
(\__/)
(='.'=)
(")_(")

DDS kann die unterschiedlichsten Formate beinhalten. Das gebräuchlichste (was du wohl auch meinst) ist DXT1 oder evtl wird dir s3tc ein Begriff sein. Diese Format ist recht einfach aufgebaut. Aber näheres plus Anschauungsbeispiel findest in dem Artikel "Wie stark komprimiert 3Dc?" auf 3dcenter.de. Verluste wirst du irgendwie immer haben. Wobei NVidia das verdammt gut hinbekommt (letztes Bild). Aber ich denke der Aufwand wird auch etwas größer sein als normal. Und so was selber mal eben zu entwickelt könnte kompliziert werden.

Es gibt auch diverse andere Formate wie das in dem Artikel angesprochene 3Dc aber das ist eher nur für Normalmaps oder sonderfälle. Für reine Texturen gibt es meines wissens nach nicht so viel. Extensions gibts auch noch wie Sand am Meer. Aber wenn man mal genau schaut haben die fast alle die gleichen Konstanten.

Joar, DXT und S3TC mein ich. Aber das es für Delphi da nicht schon Code für gibt würde mich wundern. In der Java Welt kenn ich gleich zwei APIs die DDS erzeugen können.

_________________
(\__/)
(='.'=)
(")_(")

Da muss ich passen. Für die glBitmap habe ich genau die andere Richtung (Dateien laden) gesucht. Bzw speichere ich DDS grundsätzlich nur unkomprimiert.

Das Speichern von DDS ist ansich ja harmlos.
Das Problem eher ist die Komprimierung. Nvidia und ATI haben zwar Bibliotheken veröffentlicht, die komprimieren, aber diese liegen im MS VC++ Lib-Format vor
So bleibt bei uns entweder der Weg über die Grafikkarte oder man schreibt sich das selber.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Letzteres haben die Java Jungs getan. Der interne Aufbau des Formates ist hinlänglich bekannt und passende Algorythem findet man im Netz auch.

_________________
(\__/)
(='.'=)
(")_(")

Vieleicht kann man oc2k1 mal auf den Thead aufmerksam machen, denn der schreibt viel zum thema Kompremierung.
Er hat eigene Algos geschrieben die mit der GPU laufen und nutzt auch schon existierende.
Ich kann mich auch noch daran erinnern, das er ein Shader geschrieben hat, der unkompremierte bilder zur laufzeit kompremiert.
Ich glaube er könnte dir da weiter helfen. Wenn er in den Delphigl irc channel rein kommt, sag ich ihn mal bescheit.

Vorteile hat es jede menge, denn S3TC wird von der GPU verstanden und so werden beim senden der Daten Zeit gespart(kleinere Daten werden über den Bus gejagt). Das zeichen geht auch schneller von statten, da die daten auch kompremiert im VRam liegen und die GPU weniger Daten zu ziehen und zu verarbeiten hat. Einziges manko ist die Qualität aber selbst die ist ziemlich gut.
Hier mal ein Bild von OC2k1, was er gestern im irc gepostet hat.
http://cpux.de/index.php?url=/compression1.png

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hier sonst mal der Thread zu einer der APIs - JSquish

_________________
(\__/)
(='.'=)
(")_(")

Nun mein s3tc komprimierender shaderliefert nicht die beste qualität, er ist rein auf geschwindigkeit optimiert.

Zum erstellen von komprimierten texturen verwende ich ein gimpplugin, welches meines wissens nach opengl zum komprimieren benutzt (zumindest braucht verlangt es eine openglunterstützung), es sollte also eine api vorhanden sein.

Wie man an meinem Bild erkennen kann, ist DXT1 nicht mehr zeitgemäß. Spätestens mit HDR beleuchtung kommt es zu üblen artefakten. Also hab ich mir überlegt was ich mit minimalem aufwand beim dekomprimieren verbessern kann. Das ergebnis war, das ich die Helligkeit vom Farbanteil getrennt habe. Und so für jeden 4x4 Block stat 4 Farben 2x8 Farben zu verfügung stehen.

Hier erst mal ein minimaler Shader zum dekomprimieren. Die hauptarbeit wird dabei von DXT5 abgenommen nur noch die letzte multiplikation mussselbst gemacht werden.

Für alle die keine shader benutzen müsste es auch über blending realisierbar sein. Dabei muss der Wert im Frambuffer verworfen werden undDer Farbwert mit dem Alphawert multipliziert werden. Allerdings muss bei der beleuchtung auf den Alphawert aufgepasst werden, damit er nicht vom Licht abhängig wird (eine Emissive Lichtquelle mit 1.0 für alpha und alles andere auf 0 setzten)

Zur Zeit erstell ich die DXT5 komprimierten Bilder auch mit dem Gimpplugin, erzeuge jedoch voher einen Alphakanal mit "Color->Color to Alpha" mit ausgewähltem schwarz.
Das ist noch nicht optmal, da Die Farbwerte auf 5 oder 6 bit quantisiert werden und sich dieser Quantisierungsfehler durch die Multiplikation auf den entgültigen Wert durchschlägt.

So ist ein DXT5 Block ausgebaut:
16bit Color | 16 bit Color | 16x2bit indextabelle | 8bit alpha | 8bit alpha | 16x3bit alphaindex

So stell ich mir den korrekten algoritmus vor:
1. Das Bild wird in 4x4 Blöcke unterteilt. Diese werden Zeilenweise abgearbeitet/geschrieben
2. Suche den hellsten Farbkanal und dividiere alle Farben durch den Wert. von einem RGB Würfel werden nun nur noch 3 Flächen genutzt. Die Ausname bilden schwarze Pixel, sie dürfen keinen einfluss auf die Farbe nehmen (problem bei der gimpvariante)
3. Unter berücksichtigung der Helleigkeit als Gewichtungsfaktor, die von der Durchschnittsfarbe am meisten abweichende suchen. Die zweite Farbe ist die, die am wenigsten Ähnlichkeit hat.
4. Den COlorblock mit den beiden Farben DXT1 komprimieren und für die Alphablockkompression wieder dekomprimieren. Damit steh eine quantisierte Kopie der Farben zur verfügung.
5. Alle 4x4 Quantisierten Farben durch die Originalwerte teilen. Da für jeden RGB anteilteil leicht unterschiedliche Werte herauskommen (durch die Quantisierung) diese Werte mitteln.
6. Von den 16 Helligkeitsfaktoren den hellsten und dunkelsten auswählen. Sie bilden die Basiswerte für den Alphablock.
7. Den alphablock indizieren

Für HDR kompression kann man Bits im Colorblock opfern um mehr bit für die Helligkeit zu bekommen. Werden die Farbanteile mit dem Wert 1/32 beschrieben, wird auch die Helligkeit später um den Faktor 32 dunkler sein. Insgesampt wäre ein dynamikumfang von 16 bit möglich:
5 bit aus dem Coloranteil + 8 bit aus der Helligkeit + 3 bit aus der Alphaindextabelle.
Die letzten 3 bit werden wahrscheinlich nicht nutzbar sein, so das der dynmikbereich immerhin auf geschätze 11-12 bit sinvoll nutzbar wäre.

Hi,

ook vielen dank
Dann werde ich jetzt mal im netz nach ein paar schönen Algos dafür suchen wie ich die bilder komprimieren kann.
(Der weg es von der GraKa machen zu lassen, wäre zwar auch möglich, aber ich will erstmal schauen ob ich es so hinbekomme ^^)

Aya~

Hi nochma,

wenn ich doch erstmal den weg über die GraKa gehen will... wie bekomm ich den die komprimierten daten der textur aus der GraKa wieder in den arbeitsspeicher?

Aya~

Dazu gibt es die wunderbare Methode glGetCompressedTexImage. Habe das aber bisher selber noch nicht gemacht. Sondern immer nur glGetTextmage benutzt.

Daanke, funktioniert wunderbar