Leute! Hört auf, eure Texturen zu formatieren!

[Krishty]

PS: Herzlichen Glückwunsch zum 1000. Post – und sogar gar noch nicht einmal im Jammer-Thread! :lol:

Wow, das hatte ich ganz vergessen … sonst wären in dem Post viel mehr Auslassungspunkte gelandet, wahrscheinlich auch eine Prise pessimistischer PopulärkulturReferenzen … naja, zumindest habe ich den richtigen Pegel … und die #1024 steht ja auch noch aus. Eigentlich ist deinem Satz nichts hinzuzufügen; danke.

[Krishty]

[Troll]
Microsoft warnt vor Thumbnail-Lücke in Windows
„Ausgelöst wird der Exploit dann durch eine vorgeblich negative Anzahl von Farbeinträgen in der Farbtabelle (biClrUsed).“

Naa, kontrolliert ihr auch brav jedes einzelne Feld des Grafikformats eurer Wahl auf gültigen Wertebereich? Prüft ihr auch brav dreifach, indem ihr das Offset der Farbpalette mit biClrUsed nicht nur gegen die Bittiefe, sondern auch gegen das Offset der Bilddaten in BITMAPFILEHEADER::bfOffBits gegenrechnet? Dafür sind redundante Felder ja schließlich da!

Klar doch.
Ich bin mir sicher, dass ihr das tut.
[/Troll]

[eXile]

Dafür sind redundante Felder ja schließlich da!

Ich glaube, du stellst dir das zu einfach vor. Das Vorhandensein von redundanten Feldern ist immer ein extrem starkes Indiz darauf, dass sich ein Format (bzw. die zugrundeliegende Datenstruktur) über die Zeit evolutionär entwickelt hat. Oder bei irgendwelchen Spezialfällen sind sie doch notwendig.

Mich selber überrascht der Artikel eigentlich weniger, seitdem ich die Evolution des ICO-Formats mir mal reingezogen habe (Teil 1, Teil 2, Teil 3, Teil 4). Da kommen direkt am Anfang so Schoten wie:

The bWidth and bHeight are the dimensions of the image. Originally, the supported range was 1 through 255, but starting in Windows 95 (and Windows NT 4), the value 0 is accepted as representing a width or height of 256.

Natürlich ist das total unsauber, aber wenn man nun einmal in der Situation ist und dann gerade der eine Wert frei ist … Meiner Meinung nach stellt übrigens das Anschalten des Mauszeigers (und das Setzen eines entsprechenden Icons) noch immer den Goldstandard für einen Lag-freien Cursor – auch in Graphikanwendungen! – dar.

[Krishty]

Ich glaube, du stellst dir das zu einfach vor. Das Vorhandensein von redundanten Feldern ist immer ein extrem starkes Indiz darauf, dass sich ein Format (bzw. die zugrundeliegende Datenstruktur) über die Zeit evolutionär entwickelt hat.

Jaja, klar; darum auch die Troll-Tags ;) Imo ist es aber längst nicht so, als hätte Microsoft keine Schuld daran – in MSPaint haben sie geschlagene zehn Jahre gebraucht, um die Speichervoreinstellung nicht auf BMP, sondern auf das in so ziemlich jeder Hinsicht überlege PNG zu setzen … und seit sie das tun, gehen JPG und BMP bei Amateurarbeiten und Screenshots im Web gefühlt stark zurück. Wenn sie mal früher damit angefangen hätten, würde es uns heute genau so wenig kümmern wie eine Sicherheitslücke in PCX-Thumbnails (falls noch einer weiß, das das ist). Wenn es ihnen BMP jetzt um die Ohren fliegt, ist das geradezu ironisch selbstverschuldet.

(PNG ist vor allem überlegen, weil seine Chunk-Struktur im Gegensatz zu BMP einen einigermaßen konsistenten Weg bietet, Wucherungen zu kontrollieren und die Logik der Anwendungen nicht zu verkomplizieren. Wer heute noch BMP benutzt, hat entweder exotische Beweggründe oder ist schlicht dumm.)

Meiner Meinung nach stellt übrigens das Anschalten des Mauszeigers (und das Setzen eines entsprechenden Icons) noch immer den Goldstandard für einen Lag-freien Cursor – auch in Graphikanwendungen! – dar.

Ja, die ICO-Geschichte kenne ich. Arbeitet CUR mittlerweile eigentlich auch schon mit PNG/MNG (wie ICO)?

P.S.:

Da kommen direkt am Anfang so Schoten wie:

The bWidth and bHeight are the dimensions of the image. Originally, the supported range was 1 through 255, but starting in Windows 95 (and Windows NT 4), the value 0 is accepted as representing a width or height of 256.

Genau deshalb speichere ich bei Ressourcen immer Ausmaß minus 1. Spart nicht nur so einen Murks, sondern auch Zombie States.

[BeRsErKeR]

(PNG ist vor allem überlegen, weil seine Chunk-Struktur im Gegensatz zu BMP einen einigermaßen konsistenten Weg bietet, Wucherungen zu kontrollieren und die Logik der Anwendungen nicht zu verkomplizieren. Wer heute noch BMP benutzt, hat entweder exotische Beweggründe oder ist schlicht dumm.)

Ich nutze ausschließlich BMPs als Zwischenformat, aus dem ich meine eigenen Formate (haben sich im Laufe der Zeit gewandelt, aber natürlich nur eins pro Projekt :D ) generiere. Mein Beweggrund ist, dass ein Konverter in 2 Minuten und ohne Lib-Abhängigkeiten geschrieben ist. Beim Zwischenformat kann man ja eh auf Kompression usw verzichten. Was natürlich dabei flöten geht, sind so Sachen wie Halbtransparenz, aber bislang kam ich mit einer geeigneten Colorkey-Farbe für Volltransparenz aus. Ich nutze dabei als Zwischenformat immer unkomprimierte 24-Bit Bitmaps (falls ich wirklich mal nen Alpha-Kanal brauche, missbrauche ich den Zero-Kanal von 32-Bit Bitmaps dafür). Letztlich kommt es ja nur auf das Zielformat an, was man dann auch nutzt. BMPs als Zielformat kann ich natürlich auch nicht empfehlen, aber der einfache Aufbau und die Bandbreite an Bildbearbeitungstools, die BMPs unterstützen, haben mich bislang immer überzeugt, BMPs bei der eigentlichen Erstellung der Grafiken zu verwenden (bzw. als Endformat, auf dem der Konverter aufsetzt). Während der Bildbearbeitung nutzt man ja oft sowieso geeignete Formate wie Photoshops PSD.


Allgemein zum Thema: Ich bin auch kein Freund von etlichen Formaten und redundanten Informationen. Ich schreibe meine Formate meist selbst und dabei bestehen sie so ziemlich aus den Rohdaten und eventuell noch Angaben zur Größe. Ab und an auch mal 1-2 Bits zum Thema Format/Alpha, aber dabei beschränke ich mich in der Regel auf 1-3 Formate. Allerdings kann man meine Erfahrung mit "großen" Spieleprojekten nicht als Maßstab nehmen. Ich halte es gern klein und designe die Formate so, dass sie möglichst wenig redundante Daten enthalten, einfach geladen werden können und meinen spartanischen Ansprüchen genügen.

[Krishty]

Ich nutze dabei als Zwischenformat immer unkomprimierte 24-Bit Bitmaps (falls ich wirklich mal nen Alpha-Kanal brauche, missbrauche ich den Zero-Kanal von 32-Bit Bitmaps dafür).

Das geht genau SO lange gut, bis dir solche Schoten passieren wie mir mit Gimp, das Monochrom-Bitmaps auf jeder Achse um acht Pixel verschiebt. Oder bis du mal ein anderes Programm brauchst, und das keine deiner zweihundert Bitmaps lesen will, weil die DPI-Angabe falsch ist (passierte mir damals unter XP mit Paint). Oder mal ein Programm ein paar Bytes Platz zwischen Info-Header und Pixeln lässt, weil sich die Datei mit SSE besser schreiben lies. Und und und … naja, sowas passiert mit fast jedem Format – aber BMP hat da besonders viel Potential.

PNG ist durch libpngs Allgemeinheit ein wenig umständlicher zu laden, dafür funktionieren dann aber alle Farbtiefen und relevanten Features bis in alle Ewigkeit.

[BeRsErKeR]

Wie gesagt nutze ich fast nur 24 Bit Bitmaps. Nichts Monochromes etc. Das einzig nervige sind dabei die eventuell nötigen ZeroBytes (was man bei den 32 Bit Bitmaps nicht hat). Ich lese da eigentlich nur Breite, Höhe und Pixeldaten aus. Der Rest im Header interessiert mich herzlich wenig. Und eine kleine Fehlererkennung im Konverter tut ja auch nicht weh (Dateigröße == Headergröße + Breite * Höhe * 3; Byte0-1 = "BM"). Bislang hatte ich keine Probleme, dass da Tools die Bitmaps anders gespeichert haben. Die Spec ist bei 24 Bit Bitmaps auch recht eindeutig, aber natürlich hast du recht, dass da immer ein Risiko besteht. Wenn der Konverter aber ein paar einfache Checks drin hat (ist ja bei einem speziellen BMP Format nicht so aufwendig), sollte man ganz gut leben können. Das Spiel/Programm arbeitet dann ja später nur mit dem eigenen Format und der Konverter wird halt so gebaut, dass er keinen Murks generiert. Das spart dann Zeit und Aufwand, an der Stelle wo es wichtig ist: beim Laden der Grafiken im eigentlichen Programm. Die BMPs bekommt ja abgesehen vom Entwickler eh niemand zu Gesicht.


Nochmal zum Thema Kodieren von Zusatzinformationen im Dateinamen: Ich hatte mal eine ähnliche Idee bei der Kodierung/Komprimierung von Dateien. Die Idee dahinter war, dass der Dateiname sowieso da ist und die Möglichkeit bietet zusätzliche Informationen zu speichern, wodurch man den Inhalt der Datei verkleinern bzw. Kodierungsinformationen ohne zusätzlichen Speicherplatz ablegen kann. Allerdings ist das natürlich nicht ganz der Sinn von Dateinamen. Ich persönlich habe aber nichts gegen deinen Ansatz. Er zeugt mMn von Einfallsreichtum, gerade auch in Hinblick auf die Idee, dass man dann komplett auf Headerdaten verzichten kann und die Rohdaten als "einzelnes Stück" vorliegen hat.

[Krishty]

Wenn die BMPs ihren Stammordner nicht verlassen und das Produkt mit dem „spartanischen“ Format arbeitet, ist ja dann alles im Lot :) Was ich anprangere ist, wenn sowas beim Kunden landet. Das ist ganz mies. (Gilt übrigens auch, wenn man auf Modder setzt – die haben es auch schon schwer genug, wenn die mitgelieferte Tool-Chain nicht auf hingehackten BMP-Loadern aufbaut ;) )

[BeRsErKeR]

Wenn die BMPs ihren Stammordner nicht verlassen und das Produkt mit dem „spartanischen“ Format arbeitet, ist ja dann alles im Lot :) Was ich anprangere ist, wenn sowas beim Kunden landet. Das ist ganz mies. (Gilt übrigens auch, wenn man auf Modder setzt – die haben es auch schon schwer genug, wenn die mitgelieferte Tool-Chain nicht auf hingehackten BMP-Loadern aufbaut ;) )

Ja da stimme ich dir vollkommen zu. Für solche Zwecke würde ich BMPs auch nicht verwenden. Schon allein wenn man sich mal die BMP-Doku anguckt und das ganze Wirrwarr zu all den Formaten durchliest. Ich nutze BMPs wirklich nur während der Entwicklungsphase als Zwischenformat, um einen simplen Übergang zwischen Bildbearbeitungsprogramm und Zielformat zu erreichen. Weil ein Export-Plugin für alle möglichen Tools zu schreiben würde ich nicht so lustig finden.

[eXile]

PNG ist durch libpngs Allgemeinheit ein wenig umständlicher zu laden, dafür funktionieren dann aber alle Farbtiefen und relevanten Features bis in alle Ewigkeit.

Wobei das weniger an libpng liegt, als an der festgezurrten PNG-Definition. libpng bzw. die zlib braucht man dafür nicht (unbedingt), wobei das natürlich das Laden noch einmal verkompliziert. ;)

[BeRsErKeR]

PNG ist durch libpngs Allgemeinheit ein wenig umständlicher zu laden, dafür funktionieren dann aber alle Farbtiefen und relevanten Features bis in alle Ewigkeit.

Wobei das weniger an libpng liegt, als an der festgezurrten PNG-Definition. libpng bzw. die zlib braucht man dafür nicht (unbedingt), wobei das natürlich das Laden noch einmal verkompliziert. ;)

Eben aus solchen Gründen verwende ich keine PNGs als Zwischenformat. ;)

[Krishty]

Weil sie so wohldefiniert sind? :P

Wir schweifen ab … im Hinblick auf die Absicht des Threads hat PNG ähnlich viel Ballast wie andere etablierte Formate auch; der Vorteil ist eben, dass alles in Chunks untergebracht ist und dadurch jeder Loader jede ihm unbekannte Erweiterung ohne weiteres überspringen kann. Bei BMP ist das ein wenig anders … siehe die unzähligen Kompressionsmethoden, die nur von den Windows-Interna tatsächlich implementiert werden. Es ist und bleibt aber eine Wahl des kleineren Übels.

[BeRsErKeR]

Ich wollte mit meinen Ausführungen nur sagen, dass das BMP-Format für mich eine Daseinsberechtigung hat, wenn auch nicht als Zielformat. Wenn man sich dabei auf ein ganz spezifisches Format (24 Bit / 32 Bit ohne Kompression usw) festlegt, ist das ganze eigentlich auch recht nah an Rohdaten. Der BMP-Header hat eine feste Größe und man pflückt sich einfach die 3-4 Informationen aus dem Header und verwirft den Rest beim Einlesen/Konvertieren. Eh ich mich da durch die PNG-Chunks gehangelt habe, lese ich lieber den BMP-Header und die Pixeldaten ein und bin fertig.

Um aber nochmal was zum eigentlichen Thema zu sagen: Ich kann dir (Krishty) nur zustimmen. Ich bin auch ein Freund von möglichst einfachen und performanten Formaten ohne viel Blabla drumrum und ohne EierlegendeWollMilchSau-Features, von denen meist nur ein Bruchteil benutzt werden.

Flexibilität finde ich nicht ganz so wichtig, außer vielleicht bei Bildbearbeitungstools selbst. Ein normales Projekt kommt meist mit einem oder einer Hand voll Formaten aus.

Gängige Formate sind meist auch nicht direkt für den Einsatz in Computerspielen konzipiert wurden, sondern sollen meist ein möglichst großes Einsatzsprektrum abdecken. Und in anderen Bereichen machen Meta-Informationen wie Kommentare vielleicht auch Sinn.