Bin gerade kräftig dabei meine glBitmap auf SDL umzustellen und so weit funktioniert das auch alles ganz gut. Leider befinde ich mich aber gerade in einer kleinen Zwickmühle. Den SDL bzw SDL_image ist nur in der Lage Bilder zu lesen. Bei TGA / BMP und DDS interessiert mich das nicht. TGA und DDS habe ich auch vorher schon komplett selber eingelesen und geschrieben. Da musste ich nur TStream und RWops kappseln. Bei BMPs habe ich mich auch dazu entschlossen, weil es einfach besser.

Nur PNGs und JPEGs sind ein wenig komplexer. Das würde ich ungern selber implementieren wollen. Habe mich also mal nach alternativen umgesehen.

1. Eine wäre das Projekt FreeImage. Das bringt praktischerwese auch gleich Delphi Header mit. Aber irgendwie scheint mir das ganze auch ein bisschen Windowslastig zu sein.

2. Wären jeweils die Libs libpng und jpeglib. Zur libpng exisitieren so halbwegs sinnvolle Header (in der glBMP.pas ist eines dabei). Den müsste man nur auf den neusten Stand bringen. Bei der jpeglib sieht es ein wenig anders aus. Diese Lib ist aber auch schon seit 8 Jahren nicht mehr angefasst worden. Aber das müsste ich es wohl vollkommen alleine machen. Und dann muss ich mich trotzdem noch mit einer doch nicht geringen Schnittstelle rumschlagen. Alleine die für PNGs umfasst irgendwas an die 40 Methoden.

3. Ich würde die Bilder vorerst nur zum Laden unterstützen und das würde ich dann auch mit der SDL_image machen. Da ich soweiso eine schnitstelle zu surfaces aufbauen will/muss sollte das wohl eher kein Aufwand sein. Aber über kurz oder Lang sollte ich mir dann schon noch etwas dafür überlegen.

4. Irgendetwas ganz anderes?

Bevor jetzt der ein oder andere Panik schiebt. Das betrifft nur den SDL Bereich. Im nicht SDL Bereich lade/speichere ich die BMPs auch nur ohne TBitmap aber sonst bleibt alles gleich.

Ich würde gerne mal eure Meinungen dazu hören. Bin auch für ganz andere Vorschläge offen. So lange sie für alle Plattformen funktionieren. Ach ja. Und ganz wichtig. Die Daten müssen aus einem Stream/geöffneten Datei gelesen werden. Weil ich zum Zeitpunkt des wirklichen Ladens keinen Dateinamen mehr habe. Kann sein, dass FreeImage das auch gar nicht unterstützt. Das weiß ich noch nicht. libPng und jpeglib können es. SDL_image benutzt diese Beiden.

Mit SDL_Image lesen und TGA/BMP zu Fuß schreiben und später konvertieren. So kann man die Screenshot mit fast keiner stöhrung machen. Wenn man zwischen drin noch JPEG komprimieren will ruckelt das Game oder man muss mit einer so niedriegen piorität komprimieren, das das schreiben unkomprimierter daten quasi schneller geht.
Wenn man Videos auf nehmen will ist es unter zumindest unter Linux besser den unkomprimierten Datenstrom dürch eine Named pipe zu schleusen und dann mit mencoder zu codieren. Das sollte dann aber besser in einer art Timedemomode laufen. (Mit einer zweiten CPU und einer festen Bildwiederhohlrate könnte es aber durchaus gehen )

Wie gesagt die nicht komprimierten Formate sind alle kein Thema. TGA und DDS hatte ich sowieso schon immer per Hand gemacht und BMP mache ich jetzt auch per Hand. Wenn ich das unter SDL mit SDL_image lade habe ich aber dennoch das Problem, dass ich im Windows es wieder irgendwie anders machen müsste. Und das TBitmap ist teilweise auch ein bisschen sehr kleinlich.

Aber bitte nicht falsch verstehen. Wie da irgendwas abgespeichert wird ist für mich nicht primär von interesse. Das muss der entsprechende Entwickler schon mit sich und seinem Gewissen ausmachen. Ich habe halt auch die ein oder andere Anwendung vor bei der ich nur Zeichne, wenn sich etwas verändert hat. Und dann spielt es überhaupt keine Rolle. Und auch mal Budda bei die Fische zu tun. Ich will das auch für die Fonts haben. Dort belegt ein PNG am wenigsten Platz und das lässt sich am Besten irgendwo mit einbetten. In XML zum Beispiel. Vor allem, wenn man bedenkt, dass sich die Fonttexturen wohl verdammt gut komprimieren lassen müssen.

Und auch nicht zu vergessen. Den Downloadzahlen zu Folge wird die glBitmap wohl auch in der ein oder anderen Anwenung mit benutzt. Rein statistisch gesehen. Und weiß der Geier was dort alles mit gemacht wird. Und da will ich ungern den Speichersupport für jpeg und png klauen. Wobei das wie gesagt auch nur die SDL Variante betrifft.

Unabhängig von der Implementationsfrage, warum PNG/JPEG? PNG könnte ich noch nachvollziehn, aber du hast doch TGA, DDS und BMP (würde ich nur als source nehmen). Das reicht doch vollkommen. Lieber PCX und RAW noch implementieren, aber wozu die anderen beiden?

@Implementierung: DevIL kann doch JPGE und PNG lesen, vielleicht ist deren Doku ordentlich und du kannst die Infos daraus saugen

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

JPEG wegen der unschlagbaren kompression. Wird als Texturformat wohl eher seltener gebraucht aber JPEGs gibt es auch als reines Graustufenbild. Mit einer entsprechenden Komprimierung ist das von der Größe her recht unschlagbar. JPEGs sind aber eher nur nice to have. Kein muss. Nur mit reinem Windows Delphi sind JPEGs kein Akt und damit wars drinne. Und die unterstützung dafür will ich nach möglichkeit behalten.

PNGs weil ich es für ein absolut geiles Format halte. Verlustfreie kompression. (Leider nicht unbedingt immer das Kleinste aber immer kleiner als Unkomprimiert) Aber dafür unterstützt PNG zum Beispiel auch 4 und 16 Bit Pro Kanal. Bzw das obligatorische Graustufen Bild. Alphakanal sowieso. Alles wie gesagt gepaart mit der Kompression und einer wirklich guten Unterstützung in anderen Programmen. Und man darf davon ausgehen, dass die im Laufe der Zeit noch besser wird.

PCX? Das ist doch nur 256 Farben oder irre ich mich da jetzt?

Aber das mit der Devil ist durchaus noch ein Punkt. Die habe ich auf Linux auch schon mal gesehen, die kann beides von alleine und wir haben auch schon einen Header dafür. Werde ich mir auf jeden Fall mal anschauen.

Ja PCX hat nur 256 Farben. Für Graustufen Bilder reicht das doch.
@16Bit pro Kanal, ok. Das kann DDS nicht. 8 Bit reichen doch auch pro Farbkanal, oder wozu die 16 Bit?

Dafür hat DDS noch andere nette Formate die zwar nicht im DXT 1,2,3,4 oder 5 Format gespeichert sind, aber auch sehr platzsparend daher kommen.

Mein Hauptkontra bei JPEG ist, das man es zur optimalen Nutzung nur einmal speichern darf. Also der direkte Weg von Source nach JPEG. JPEG -> bearbeiten -> JPEG führt leider unweigerlich zu Verlusten in der Bildqualität.

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

Na ja. BMPs, JPEGs, PNGs, TGAs und DDSs können Graustufen ablegen. PNGs, TGAs und DDSs können außerdem auch noch einen Alphakanal mit ablegen. Also sehe ich keine Notwendigkeit ein reines Graustufen ohne Alpha Format zu unterstützen.

Wobei DDS ja auch in der Lage sein soll 16Bit Floats abzuspeichern. Zu mindest meine ich das bei dem Plugin von NVidia gesehen zu haben. Was im übrigen das größte Problem ist. Die wirklich miserable Unterstützung davon.

16Bit Aufwärts. HDR? Das ist derzeit zwar noch nicht wirklich häufig vertreten und bringt auf den aktuellen Monitoren sowieso nicht so wirklich viel. Aber deswegen muss ich in ein paar Jahren doch nicht schon wieder alles umstellen müssen. Und rein Theopraktisch kann ich in der glBitmap bis zu 32Bit Pro Kanal unterstützen. Zu mindest funktioniert RGB10A2 derzeit schon problemlos.

Achso, für HDR ist das gut - kann nicht alles wissen. Dachte bisher immer das die HDR Werte errechnet werden und nicht in der Textur liegen oder versteh ich gerade was falsch?

@DDS Formate: version 7.83 des PS Plugins kann die folgenden Formate...

• DXT1 RGB (No Alpha)
• DXT1 ARGB (1 bit Alpha)
• DXT3 ARGB (Explicit Alpha)
• DXT5 ARGB (Interpolated Alpha)
• 4:4:4:4 ARGB (16 bit)
• :1:5:5:5 ARGB (16 bit)
• 5:6:5 RGB (16 bit)
• 8:8:8:8 ARGB (32 bit)
• 8:8:8 RGB (24 bit)
• 5:5:5 RGB (16 bit)
• palette RGB (256 colors)
• V8U8 DuDv (16 bit, EMBM)
• CxV8U8 Norm (16 bit, Normal Map)
• A8 Alpha (8 bit, Alpha Only)
• palette RGB (16 colors)
• 8:8:8:8 Q8W8V8u8 (32bit, signed)
• A8L8 Alpha/Lum (16 bit)
• fp32 fp (32 bit, floating point)
• fp32 x 4 fp (32 bit, floating point)
• fp16 x 4 fp (16 bit, floating point)
• L8 (8 bit, Luminance)
• palette ARGB (256 colors + Alpha)
• palette ARGB (16 colors + Alpha)
• fp16 fp (16 bit, floating point)
• DXT5_NM XYZ (normal map compression)

Schön viele FOrmate, welches würde man da denn für HDR nutzen?
Gibt es eigentlich zu den Formaten auch ne aktuelle Doku? Denn mehr als DXT1, 3 und 5 kann mein TextureLoader derzeit nicht lesen...für die 4:4:4:4 und Kompilate hab ich noch Infos, aber beim Rest setz ich Fragezeichen.

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

Bei HDR muss man abwiegen welches Texturformat man gerade braucht. Häufig reichen die gewöhlichen Texturformate als input aus. Wenn das nicht der Fall ist sollte jede Komponente mindestens float16 sein. Normale Texturen bekommmen probleme wen sie durch eine nahe Lichtquelle stark aufgehellt werden. Allerdings ist es auch extrem schwer gutes HDR Rohmaterial zu bekommen.

Ansonsten würde ich zum lesen der Bilder bei SDL Image bleiben. FÜr die komprimieren Texturformate macht es eventuel noch sinn einen eigenen Loader zu schreiben...

Nichtwissen: Macht ja auch nichts. Dafür gibt es ja genügend die einem dabei helfen. Ich weiß auch bei weitem nicht alles.

HDR: Das stimmt. Es kommt immer darauf an was man gerade damit vor hat. Aber es gibt da ja auch den umgekehrten Weg. Also HDR auslesen und abspeichern. Aber Photoshop unterstützt ja auch schon 16 Bit (Integer) pro Kanal. Bzw OpenGL auch schon seit 1.1. Nur die Floatingtexturen sind erst wesentlich später hinzugekommen. Aber ich denke auch mal bei HDR gibt es auch einen entscheidenen Unterschied zwischen 16Bit Integer und Floats. Floats sind viel Flexibler was ihre Wertebereiche angeht.

oc2k1: SDL_image benutze ich derzeit noch gar nicht. Sehe da auch keine Notwendigkeit dafür. Ich muss ja auch immer bedenken, dass ich nicht alles doppelt entwickeln will und ich den Windowsteil nicht abklemmen darf. Und ich möchte nicht für das Laden diese Library benutzen und zum Spiechern dann wieder was Anderes. Oder in 3 Monaten dann wieder alles umbasteln.

Ich kenne aktuell nur die Infos aus der MSDN.
Da werden die Datenformate aber nicht gross erklärt.

@DDS im glBitmap:
Aktualisier dann bitte doch mal den Wikiartikel.
Ich ging jetzt davon aus, dass es bisher keinen Loader von DDS-Dateien gibt und habe mich jetzt auch drangesetzt...

Wobei es irgendwie keine (Grafik)Programme gibt, die DDS lesen können. Das PS-Plugin von Nvidia funktioniert bei mir mit PSP nicht



Aber jetzt mal B2T:
Da du gute Argumente für das Speichern gebracht hast, würde ich sagen, dass es keinen Sinn macht, SDL_Image zu benutzen.
Er ist als Loader klasse, weil man sich kaum kümmern muss, was man für Dateien vor einem hat, aber wenn du sie speichern willst, musst du es schon wissen.

Ich würde dann wirklich eher versuchen das TBitmap weg zu bekommen und über die beiden Bibliotheken gehen. Das mit dem Headern ist leider immer ein Problem, vielleicht könnten sich dafür Leute finden. (Würde auch selber mitmachen wenn ich wieder daheim Internet habe und nicht nur an der Uni Internet habe)

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

PSP = PaintShopPro? Kann kam dafür keine eigenen Plugins schreiben?
@MSDN: Danke, werd ich mal reinschaun. Vielleicht findet sich bei NVidia auch noch was...im SDK oder so. Oder ich schau mal ins ATI SDK.

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

TBitmap ist weg. Speichern habe ich gerade erst angefangen aber laden geht.

Wiki: Ähm ja. Habe ich wohl verpennt. Mache ich dann wenn SDL unterstützt wird. Ist sonst ein bissel viel Aufwand.

DDS: Es gibt für GIMP ein Plugin mit dem man ganz gut arbeiten kann. Allerdings unterstützt dieses Plugin nur wenige Formate. Und MipMaps bzw Cubemaps wieder einzulesen ist irgendwie ein bisschen schwierig gewesen. Also um nicht zu sagen nicht machbar gewesen. Bzw lieferte ganz komische Ergebnisse.

devil (library): Habe mal in die Doku geschaut. So weit sah das alles sehr gut aus. Nur leider unterstützt die PNGs nicht zum Speichern auf ein Handle. Allerdings lässt das derzeit die Vermutung aufkommen, dass die libPNG gar nicht auf Handels speichern kann. Wenn das natürlich der Fall wäre hätte ich ein größeres Problem.

Hallo,
ich muss auch noch meinen Senf dazugeben, wenn auch etwas spät.

@Lossy: ich habe mich in den letzten Tagen sehr intensiv mit Bildformaten beschäftigt (Hintergrund: ich plane eine sanfte, langfristige Migration von Windows nach Linux, da ist es wichtig, sich klarzumachen, welche Formate man mitnehmen kann/will). Ich weiß nicht genau, wie viele Formate Du unterstützen willst, aber es scheint mir sinnvoll, eins zu haben, das man verlustfrei abspeichern kann und zusätzlich eins, bei dem die Kompression ein bisschen besser ist, das also mit Verlust abspeichert. Das sage ich schon aus Eigennutz, weil ich bisher immer Deine glBitmap verwendet habe. Wegen der Migration bin ich aber auf SDL umgestiegen. Ich habe nun das gleiche Problem wie Du: SDL speichert nicht ab. Ich habe das bisher nicht gebraucht, aber jetzt wollte ich mir einen Video Capturer (mittels Frame Buffer) schreiben - Bildformate abspeichern können wäre da nicht schlecht. Video Capturer für Delphi habe ich gefunden, aber die verwenden alle die Windows-Untergrundsoftware VFW. Ich habe keine Lust, nach der Umstellung programmiertechnisch unbekleidet dazustehen. Es genügt schon, dass ich mit Free Pascal überhaupt keine GUI mehr habe (ich weiß nicht, warum, aber ich habe immer so ein ungutes Gefühl bei Lazarus).

Eine Bitmap "per Hand" abspeichern könnte man schließlich in Linux auch, nicht wahr? Und TGA/PNG sind ja auch offene Formate. Bleiben nur noch die - mit Verlust - komprimierten Bilder. Meiner Ansicht gibt es keine Alternative zu JPEG/JPEG2000, da die hohe Videokompression im Internet unbedingt gebraucht wird (GIF wäre natürlich auch schön, wegen der Animationen. Seufz!)

Du hast selbst gesagt, dass die JPeg-Library bereits seit 8 Jahren nicht mehr verändert wurde. Was ich darüber gelesen habe, bedeutet: es ist eine veraltete Technologie (Fast Fourier-Transformation). Die neuere Technologie (Wavelets) ist in JPEG2000 eingebaut. Diese Bilder sehen auch bei großer Vergrößerung viel besser aus als JPG's, aber - verflixt nochmal! - es wird von den üblichen Grafikprogrammen nicht/kaum unterstützt - also bleibt JPEG.


Ich habe bei meiner Internet-Suche folgendes gefunden: http://ainc.de/
Dort gibt es ein Freeware-Delphi-Programm, das eine Videokopression mit Wavelets durchführt. Der Autor macht alles "zu Fuss". Vielleicht wirfst Du mal einen Blick drauf.

Noch wichtiger ist vielleicht: ich werde so etwas ohnehin basteln, aus dem vorhandenen Code von obiger URL, nicht weil ich das kann (leider noch nicht), sondern weil ich etwas lernen will und weil mich die Fourier/Wavelet-Technologie interessiert.
Wenn Du das brauchen kannst, würde es mich freuen. Das hätte für mich auch den Vorteil, das sich ein zweiter den Code ansieht und auch testet. Einen Zeithorizont habe ich aber noch keinen (die Unit die ich durchackern muss hat 1800 Zeilen mit mathematisch anspruchsvollem Code und ich werde das bestimmt nicht einfach abschreiben).

Traude.

Jede Antwort ist willkommen. Die Zeit spielt keine Rolle. Das Einzige was zählt ist das Leben. (Das fünfte Element)

Der Grund warum JPEG2000 nicht benutzt wird liegt wohl darin, dass es ein lizenzpflichtiges Format ist. Wenn ich mich gerade nicht völlig vertue. Und genau das wird auch einer der Gründe sein, warum das Format aussterben wird. Weil außer einer recht guten Kompression hat es nichts besonderes zu Bieten. Und in der Zeit der breitbandigen Anschlüsse interessiert es kaum noch jemanden. Ob das Bild 100 oder 20 KB groß ist.

Ja ein PNG händisch einzubauen wäre auch noch eine Möglichkeit aber das ist für mich jetzt so keine Option. Wenn ich mir mal den Code von pngimage (Delphiklasse) anschaue, dann wird mir anders. Das sind mal eben 200 KB an Quellen. Meine Aktuelle glBitmap ist gerade mal 150 KB Groß und das ist eigentlich auch nicht mal so sonderlich klein. Und wenn ich ganz ehrlich bin bin ich dafür 1. zu Faul und 2. denke ich nicht, dass ich darüber genügend wissen habe um auch wirklich sichere Anwendungen zu gewährleisten. Also wie es vor einiger Zeit war als in der zlib ein Bufferoverflow aufgetreten ist. Mit einer externen Bibliothek bräuchte man einfach nur die dll austauschen. Aber im Quellcode gegossen müsste man erst einmal die Stelle im Code finden und diesen dann beseitigen. Und durch die Verbreitung der libpng (sei es DEVil oder direkt) denke ich mal schon, dass so ziemlich alles gefunden wurde was man finden kann.

Gegen eine eigene Wavelet kompression / Format würde an und für sich nicht viel dagegen sprechen. Ich befürchte nur, dass es so gut wie keinen Interessenten dafür geben wird. Eben weil es von keinem anderen Programm unterstützt wird. Aber wenn du es so gestaltest, dass ich nur einen TStream oder RWops übergeben brauche dann wäre es für mich ein Kleines das zusätzlich noch einzubauen. Das würde dann aber per Define auskommentierbar sein. Um die Unterstützung nicht zu erzwingen. Eben weil es ungewöhnlich ist.

Formate: BMPs, DDSs und TGAs werden derzeit schon auf beiden Plattformen unterstützt. Das sowohl lesend als auch schreibend. JPEGs und PNGs einzulesen geht mittels SDL_image sehr einfach. Zur Not kann man diese dann auch extern einlesen und die Daten aus einem Surface laden. Somit wären ohne große Probleme auch andere Formate benutzbar. Aber das Schreiben halt.

PS: Komm mir bloß nicht mit dem Schimpfwort GIF. Außer für völlig überzogene Animationen ist es zu nichts mehr zu gebrauchen. Und die Animationen sind dann teilweise mal Locker 1 MB Groß, weil der Erstellen ein bisschen zu doof war das Format richtig zu benutzen. Abgesehen davon unterstützt GIF auch nur 256 Farben womit das für Grafikanwendungen tunlichst nicht mehr verwendet werden sollte. Da gibt es bessere Alternativen.