nicht angemeldet
.gif erstellen mit Perl
0 0 0 0
0
0 0
.gif erstellen mit Perl
Hallo,
was muß ich haben/wissen/tun, um mit Perl .gif-Grafiken zu erstellen? Gemeint sind damit nicht nur (aber auch) Zählergrafiken, die aus verschiedenen Einzelgrafiken zusammengesetzt und als Einheit zurückgeschickt werden, sondern auch beispielsweise Balkendiagramme oder sagen wir Sternbilder. Ich suche keine kompletten Tools (naja, vielleicht für die Zählergrafiken), sondern das Wissen! Wie sind .gif's aufgebaut? Was muß ich tun, um das Cachen der Grafik zu verhindern? Wie schicke ich nur die Grafik zurück, wie mache ich es am geschicktesten, wenn die Grafik als Teil einer HTML-Datei zurückgeschikt wird? Kann mir jemand (bevorzugt) Seiten oder Bücher empfehlen, oder sogar helfen?
Th@nx schon mal,
Cheatah
P.S.: Wenn's einfacher ist (oder sinnvoll zu wissen), gilt das ganze natürlich auch für .jpg!
-
Hallo,
was muß ich haben/wissen/tun, um mit Perl .gif-Grafiken zu erstellen? Gemeint sind damit nicht nur (aber auch) Zählergrafiken, die aus verschiedenen Einzelgrafiken zusammengesetzt und als Einheit zurückgeschickt werden, sondern auch beispielsweise Balkendiagramme oder sagen wir Sternbilder. Ich suche keine kompletten Tools (naja, vielleicht für die Zählergrafiken), sondern das Wissen! Wie sind .gif's aufgebaut? Was muß ich tun, um das Cachen der Grafik zu verhindern? Wie schicke ich nur die Grafik zurück, wie mache ich es am geschicktesten, wenn die Grafik als Teil einer HTML-Datei zurückgeschikt wird? Kann mir jemand (bevorzugt) Seiten oder Bücher empfehlen, oder sogar helfen?
Also auf http://www.perl.com/ gibt es irgendwo ein Modul, daß GD.pm heißt. Damit kannst du Gifs erstellen. Aber mit Jpegs geht es leider nicht.
-
Hi,
Also auf http://www.perl.com/ gibt es irgendwo ein Modul, daß GD.pm heißt. Damit kannst du Gifs erstellen.
gefunden... aber verwirrt mich etwas zu sehr. Ich habe hier leider keinen lokalen Perl-Interpreter, und mit tar.gz kann ich auch nichts anfangen. Außerdem verlasse ich mich ungern auf Dinge, die ich nicht verstehe - und über 100kB große Module zählen leider dazu (zu mal ich von Modulen bisher keine Ahnung habe) :-/
Naja, ich hab's erst mal runtergeladen, vielleicht brauche ich es ja irgendwann. Was ich aber eigentlich erhofft hatte, waren Infos, welche Daten ich wie übertragen muß (Header, MIME-Type etc.), und wie der Aufbau des .gif's danach ist (zeilenweise? wie viele Bits pro Pixel? etc.) Weißt Du zufällig, wo ich so etwas finden kann?Aber mit Jpegs geht es leider nicht.
Ist nicht weiter schlimm, das wäre auch mehr 'ne Notlösung gewesen :-)
Auf jeden Fall danke!
Cheatah
-
Hi,
Naja, ich hab's erst mal runtergeladen, vielleicht brauche ich es ja irgendwann. Was ich aber eigentlich erhofft hatte, waren Infos, welche Daten ich wie übertragen muß (Header, MIME-Type etc.), und wie der Aufbau des .gif's danach ist (zeilenweise? wie viele Bits pro Pixel? etc.) Weißt Du zufällig, wo ich so etwas finden kann?
Tja, so billig wirst Du leider nicht davonkommen. Check out http://www.dcs.ed.ac.uk/~mxr/gfx/, the Graphics File Format Page. Lies Dir die spec durch und frag Dich dann nochmal: Willst Du wirklich mit Perl das GIF-Format nachbauen? Ich vermute mal nein. Aber wenn Du fuer Dein Problem eine gute Loesung findest, please contact me, ich haeng naemlich gerade an genau derselben Sache. Allerdings baue ich schlicht und einfach einen Counter (primitivste Variante, sozusagen zum Einsteigen), und der kann auch eine Text Only Version sein.
Ich habe mir aber mal was ueberlegt: Wenn man alle zehn Ziffern als GIFs auf dem Server hat, und jedes einzeln uebertragen kann, geht das mit Perl ganz gut (denke ich). In der HTML-Datei baust Du nicht nur ein Counterbild ein, sondern soviele, wie Du Ziffern (voraussichtlich) brauchst. Das Counterscript rufst Du jeweils mit einem Parameter auf, die wievielte Ziffer gerad abgefragt wird. Das heisst, dass Du dasselbe Script fuer einen einzigen Zaehlerstand 5 mal aufrufst, wenn Du 5 Ziffern haben willst. Das ist, was mir dazu einfaellt. Aber das muss voraussetzen, dass der Browser die Bilder in einer bestimmten Reihenfolge anfordert, und das kannst Du nicht festlegen, leider. Also ist die Idee so wohl nicht zu gebrauchen.Calocybe
-
Hi,
Tja, so billig wirst Du leider nicht davonkommen. Check out http://www.dcs.ed.ac.uk/~mxr/gfx/, the Graphics File Format Page. Lies Dir die spec durch und frag Dich dann nochmal: Willst Du wirklich mit Perl das GIF-Format nachbauen?
tja, wenn ich mir das so angucke... *schluck* :-/
Ich habe mir aber mal was ueberlegt: Wenn man alle zehn Ziffern als GIFs auf dem Server hat, und jedes einzeln uebertragen kann, geht das mit Perl ganz gut (denke ich). In der HTML-Datei baust Du nicht nur ein Counterbild ein, sondern soviele, wie Du Ziffern (voraussichtlich) brauchst. Das Counterscript rufst Du jeweils mit einem Parameter auf, die wievielte Ziffer gerad abgefragt wird. Das heisst, dass Du dasselbe Script fuer einen einzigen Zaehlerstand 5 mal aufrufst, wenn Du 5 Ziffern haben willst.
Klar, dieser Trick ist alt, allerdings ist das alles andere als komfortabel. Außerdem will ich nicht nur Countergrafiken ausgeben, sondern auch Grafiken innerhalb der Statistik, und zwar mehr als nur ein paar Balken (trivial). Da liegt der Hund begraben! (Armes Viech *grins*)
Das ist, was mir dazu einfaellt. Aber das muss voraussetzen, dass der Browser die Bilder in einer bestimmten Reihenfolge anfordert, und das kannst Du nicht festlegen, leider. Also ist die Idee so wohl nicht zu gebrauchen.
Doch, schon. Nur wird dann der Reload-Check 5 mal aufgerufen, was auch einen ganz guten Traffic bedeutet... nämlich beinahe 5 mal so hoch wie normal! Mir ist es als eine einzige Grafik halt wesentlich lieber - alles andere wäre auch ziemlich zerhackstückelt. Naja, auf jeden Fall danke für die Idee :-)
Cheatah
-
Klar, dieser Trick ist alt, [...]
Echt? Mist. ;-)
Das ist, was mir dazu einfaellt. Aber das muss voraussetzen, dass der Browser die Bilder in einer bestimmten Reihenfolge anfordert, und das kannst Du nicht festlegen, leider. Also ist die Idee so wohl nicht zu gebrauchen.
Doch, schon. Nur wird dann der Reload-Check 5 mal aufgerufen, was auch einen ganz guten Traffic bedeutet... nämlich beinahe 5 mal so hoch wie normal! Mir ist es als eine einzige Grafik halt wesentlich lieber - alles andere wäre auch ziemlich zerhackstückelt. Naja, auf jeden Fall danke für die Idee :-)
Naja, Du brauchst ihn ja den Wert nur hochzaehlen, wenn z.B. die hoechste Stelle angefordert wird. Jedoch gibt es da noch ein Problem: Nehmen wir mal an, der Browser fordert die Grafiken ganz brav der Reihe nach an, zuerst die hoechste Stelle, zuletzt die niedrigste. Aber, was ist, wenn zwei Leute die Seite fast im selben Moment aufrufen? Browser 1 fordert Grafik fuer hoechste Stelle an, Counter wird um eins von 1998 auf 1999 hochgezaehlt und Grafik zurueckgeliefert. Browser 2 fordert an, 1999 -> 2000. Browser 1 fordert naechste Stelle an, und das ist eine 0 (von 2000), nicht eine 9 von 1999. So schreibt er letztendlich eine 1000 hin. Und das war noch ein einfaches Dilemma. Was ist erst, wenn 10 Clients anfordern, schoen durcheinander, damit es sich richtig lohnt? Nee, nee, da ist mir mein Textcounter doch lieber: Voellig simpel zu bauen, viel flexibler einsetzbar (versch. Schriftarten usw.).
Calocybe
-
Hi,
Klar, dieser Trick ist alt, [...]
Echt? Mist. ;-)*grins* :-)
Naja, Du brauchst ihn ja den Wert nur hochzaehlen, wenn z.B. die hoechste Stelle angefordert wird. Jedoch gibt es da noch ein Problem: Nehmen wir mal an, der Browser fordert die Grafiken ganz brav der Reihe nach an, zuerst die hoechste Stelle, zuletzt die niedrigste. Aber, was ist, wenn zwei Leute die Seite fast im selben Moment aufrufen? Browser 1 fordert Grafik fuer hoechste Stelle an, Counter wird um eins von 1998 auf 1999 hochgezaehlt und Grafik zurueckgeliefert. Browser 2 fordert an, 1999 -> 2000. Browser 1 fordert naechste Stelle an, und das ist eine 0 (von 2000), nicht eine 9 von 1999. So schreibt er letztendlich eine 1000 hin. Und das war noch ein einfaches Dilemma. Was ist erst, wenn 10 Clients anfordern, schoen durcheinander, damit es sich richtig lohnt?
Du hast das Problem richtig erkannt, eben deshalb müßte ich bei jedem Aufruf das Hochzählen überprüfen... Ne, mit einer einzigen Countergrafik ist es schon besser :-)
Nee, nee, da ist mir mein Textcounter doch lieber: Voellig simpel zu bauen, viel flexibler einsetzbar (versch. Schriftarten usw.).
Stimmt schon, aber das läßt sich schlecht Kunden verkaufen, die einen schön gestalteten Counter auf ihrer Homepage haben wollen... das Ding ist ja nicht nur für mich!
Cheatah
-
Hallo Cheatah u. Calocybe,
bei euren Überlegungen zu graphischen Countern
habt ihr euch vermutlich etwas vergallopiert.Ihr braucht nur einmal zu übertragen und das
CGI-Script/SSI trägt halt die benötigten IMGs
beim Absenden entsprechend ein.Selbst wenn das eine Uhr wäre, dann bräuchtet
ihr doch nur alle 10/11 Digits und einen
anfänglichen Stellwert zu laden und ein
JS-Timeoutevent(1000) steuert welches IMG an
welcher Stelle sichtbar sein soll.
Diese Uhr kann aber leicht nach dem Mond gehen.Der Umfang dieser Aufgabenstellung rechtfertigt
den Perl-Nachbau von .GIFs noch nicht, wenn ihr
euch aber die Darstellung einer Analoguhr vor-
stelltet, dann wäre das schon diesen Aufwand
wert. Classisch wären sowas sonst ja 43200 IMGs
bei einer Auflösung von 1 sec. und viel traffic.
Ob man sowas auch in JS hinkriegt?Was ich sonst an .GIF gefunden hatte steht in
diesem Thread schon hinreichend geschrieben.
GIF ist etwas pfriemelig, vor Allem wegen der
möglichen Format-Varianten und der Kompression
der Datenblöcke. Format-Varianten kann man bei
einer anwendungsbezogenen Lösung natürlich in
Grenzen halten.Klaus
-
Hallo Cheatah,
da fällt mir doch gerade noch ein.
Um eine Balkenstatistik per Server/Perl zu bauen,
könntest Du natürlich auch mal über Tabellen und
eine begrenzte Anzahl graphischer Elemente nach-
denken.
Als Elemente kämst Du wohl mit den 2 Ordinaten
und außerdem ein mittleres Balkenelement und
ein Endstück aus. (Farben?)
HTML erlaubt ja recht komplexe und verschachtelte
Tabellen, sodaß das prinzipiell ginge.
Die Frage der Auflösung ist dann gleichzeitig
eine Frage des Aufwandes und des Fleißes!Klaus
-
Hi Klaus,
Um eine Balkenstatistik per Server/Perl zu bauen,
könntest Du natürlich auch mal über Tabellen und
eine begrenzte Anzahl graphischer Elemente nach-
denken.glaub mir, ganz so trivial ist meine Problematik nicht... auch geht es nicht nur um Countergrafiken! Ich will eine zwei- und evtl. sogar dreidimensionale graphische Auswertung verschiedener Dinge machen. Nimm beispielsweise nur mal ein Balkendiagramm mit einer Tendenz-Linie - die geht mit einfachen HTML-Mitteln schon nicht mehr. Für andere Dinge (x-y-Auswertung) muß ich wiederum einzelne Pixel setzen, und zwar in verschiedenen Farben für verschiedene Stärken. Auch hier versagen HTML-Mittel. Wenn ich nicht auf diese Auswertungen verzichten will, *muß* ich eine Grafik serverseitig produzieren! Dazu brauche ich Infos über Aufbau von Header, Farbtabelle, Definition von Breite und Höhe usw.
Mittlerweile habe ich die Spezifikation von gif87a ausgedruckt, aber durch die 16 Seiten steige ich kaum durch. Mit gif89a habe ich es gar nicht erst probiert, dazu war mir mein Papier zu schade... Kennt jemand eine Übersicht (Internet, ein Buch will ich mir eigentlich nicht kaufen, so wichtig ist es dann doch nicht), wo man die wichtigsten Infos erhält und sich dann an der Praxis versuchen kann?
Cheatah
-
Hi Cheatah,
glaub mir, ganz so trivial ist meine Problematik nicht...
glaub ich Dir aufs Wort. Eine eher triviale
Lösung für ein nicht-triviales Problem ist aber
recht selten. Es hätte aber ja sein können, daß
Du auch etwas einfachere Sachen dabeihast.Mittlerweile habe ich die Spezifikation von gif87a...
Kennt jemand eine ÜbersichtIn besagtem Buch von Günther Born sind etliche
Seiten darüber drin. Das blöde dabei ist, daß bei
etlichen Dateielementen Kommentare wie optional,
kann, muß aber nicht und wenn ..., dann... stehen.GIF ist sehr flexibel und vielfältig und das
macht das Verstehen schwierig. Eigentlich gehe
ich davon aus, daß Du nur einen Subset brauchen
wirst, aber welchen?
Den ganzen Bereich 'multiple images' wirst Du wohl
ignorieren können. Damit kommt wohl auch nur der
Bereich globale Palette auf Dich zu, die lokalen
sind dann uninteressant.
Animation und (loop)control wird Dich wohl auch
kaum interessieren.
Wenn Deine Statistiken durchsichtig sein sollen,
dann kommst Du nicht um GIF89a herum.Besonders abschreckend für mich ist der Gedanke,
daß GIF mit Datenblocks maximaler Länge operiert
und diese noch 'LZW-ähnlich' komprimiert sind.
D.h. ein größeres Bild muß eventuell auf mehrere
256er Chunks verteilt werden, der Inhalt eines
solchen Chunks bedeutet aber eben nicht 256 Pixel!
etc pp.Ich versuche mal meine Faulheit zu überwinden.
Klaus
PS: einlesen willst Du GIFs hoffentlich nicht, oder?
-
Hi Klaus,
Es hätte aber ja sein können, daß
Du auch etwas einfachere Sachen dabeihast.naja, das Thema "Balkengrafiken" habe ich schon optimiert... :-)
In besagtem Buch von Günther Born sind etliche
Seiten darüber drin. Das blöde dabei ist, daß bei
etlichen Dateielementen Kommentare wie optional,
kann, muß aber nicht und wenn ..., dann... stehen.Das befürchte ich. Was ich brauche ist aber erst mal "für ein ganz einfaches GIF braucht man/macht man...", wenn es dann komplizierter werden soll kann ich immer noch tiefer in die Materie eingehen.
GIF ist sehr flexibel und vielfältig und das
macht das Verstehen schwierig.Tja, das ist mein Problem... :-)
Eigentlich gehe
ich davon aus, daß Du nur einen Subset brauchen
wirst, aber welchen?Du beschreibst es schon ganz gut, es sollen eben "nur" ganz einfache rechteckige Grafiken mit x Farben sein. Wenn es denn einfacher ist, x=256 Farben zu nehmen, ist das nicht das Problem - weiter optimieren kann ich später noch. Nur erst mal herstellen muß ich es können! *heul*
Wenn Deine Statistiken durchsichtig sein sollen,
dann kommst Du nicht um GIF89a herum.Ah ja, danke, daran hätte ich vermutlich nicht gedacht. Ich glaube aber im Moment nicht, daß ich Transparenz benutzen werde. Na, mal sehen...
Besonders abschreckend für mich ist der Gedanke,
daß GIF mit Datenblocks maximaler Länge operiert
und diese noch 'LZW-ähnlich' komprimiert sind.
D.h. ein größeres Bild muß eventuell auf mehrere
256er Chunks verteilt werden, der Inhalt eines
solchen Chunks bedeutet aber eben nicht 256 Pixel!Oh je... das ist jetzt ein völlig neuer Begriff für mich! Was heißt "LZW-ähnliche Komprimierung"? Wo kriege ich Infos über dieses Format?
Ich glaube, ich muß doch mal 'ne Suchmaschine anschmeißen. Bisher habe ich mich nur davor gefürchtet, daß ich mit den paar Suchbegriffen, die ich hatte, eine Megaauswahl an Seiten bekommen würde, wo z.B. dieser Artikel auch drin auftauchen könnte...Ich versuche mal meine Faulheit zu überwinden.
Das wäre nett :-)))
PS: einlesen willst Du GIFs hoffentlich nicht, oder?
Nun ja, ein Counter fügt normalerweise mehrere Einzelgrafiken zusammen, wobei die Einzelgrafiken evtl. auch erst aus einem Counterstrip extrahiert werden...? Oder wie meintest Du das?
Cheatah
-
Hi Cheatah,
nu' > *heul* man nich, dazu ist das Forum ja da.
PS: einlesen willst Du GIFs hoffentlich nicht, oder?
Nun ja, ein Counter fügt ...
Das laß man erstmal lieber sein. Bring erstmal
Deinen Server dazu Dir 4.. <IMGs...> einzufügen.
Ist für einen Counter einfacher!
Was Anderes ist, wenn Du leere Knöpfe dynamisch
beschriften willst.'LZW' ist ein Algorithmus/Verfahren um Daten zu komprimieren.
L und Z und W sind die Anfangsbuchstaben der Namen
der Erfinder, näheres vergessen.
'LZW-ähnlich' heisst leider, daß das Verfahren von
Compuserve für GIF abgewandelt wurde.Soweit im Moment, versuche mich weiter zu überwinden
Klaus
-
Hi Cheatah,
ich nehme mal einen neuen Thread,
werde ja wohl doch ein paar Tage brauchen.Klaus
-
Hi Klaus,
ich nehme mal einen neuen Thread,
werde ja wohl doch ein paar Tage brauchen.sieht so aus. Bis hierhin sag ich erst mal brav "danke" und sehe, was wir zwei beide im neuen Thread zustande kriegen :-)
Cheatah
-
-
-
Hi!
Allem Anschein nach scheint doch das Modul GD.pm geradezu perfekt geignet zu sein.
Von der Größe solltest Du Dich keineswegs abschrecken lassen. Es wird eine recht einfache
Objektorientierte Schnittstelle zur Verfügung gestellt.Es gibt da Funktionen für:
- gif-Objekt erstellen (entweder ganz neu, oder aber aus einer Datei einlesen)
- Farben anlegen (innerhalb des Gif)
- passende Farben im Gif suchen (wenn z.B. ein Bild geladen wurde, und man
die vordefinierte Farbe haben möchte, die der Wunschfarbe am ehesten entspricht) - Punkte setzen
- Linien ziehen
- Polygone zeichnen
- Flächen füllen
...
Es können auch sogenannte Brushes verwendet werden. Man kann dabei ein anderes Gif
als Pinsel zum Punkt setzen, Linie zeichnen ... benutzen.
Du beschreibst es schon ganz gut, es sollen eben "nur" ganz einfache rechteckige Grafiken mit x Farben sein. Wenn es denn einfacher ist, x=256 Farben zu nehmen, ist das nicht das Problem - weiter optimieren kann ich später noch. Nur erst mal herstellen muß ich es können! *heul*
Klingt doh geradezu einfach, wenn man sich die GD.pm funktionalität zunutze macht.
Wenn Du allerdings ins 3D-eingemachte möchtest, so mußt Du Dir da wohl selbst ein
paar Gedanken zur Projektion machen ...PS: einlesen willst Du GIFs hoffentlich nicht, oder?
Nun ja, ein Counter fügt normalerweise mehrere Einzelgrafiken zusammen, wobei die Einzelgrafiken evtl. auch erst aus einem Counterstrip extrahiert werden...? Oder wie meintest Du das?
Auch dies läßt sich per Brushes ohne weiteres abbilden ...
Schau doch einfach mal unter
http://stein.cshl.org/WWW/software/GD/GD.htmlDie Beispiele, die man dort findet, machen einen so richtig kribbelig. Es kommen einem
dann die mutigsten Ideen, irgenwas per CGI zu visualisieren.Viel Spaß,
Jörk-
Hi Jörk,
Allem Anschein nach scheint doch das Modul GD.pm geradezu perfekt geignet zu sein.
Von der Größe solltest Du Dich keineswegs abschrecken lassen. Es wird eine recht einfache
Objektorientierte Schnittstelle zur Verfügung gestellt.tja, dann werde ich es mir wohl doch mal etwas genauer ansehen... aber von der Größe lasse ich mich deshalb abschrecken, weil mein momentandes Statistik-Script bereits jetzt wenn ein entsprechend umfangreiches Logfile besteht zwischenzeitlich abbricht (online auf dem Server). Ich muß mir da sowieso noch einige Gedanken machen, aber auf jeden Fall will ich es nicht noch mit Optionen füllen, von denen ich am Ende nur einen Bruchteil brauche... :-)
Danke für den Link!
Cheatah
-
-
-
-
-
-
-
-
-
-
Hi,
Also auf http://www.perl.com/ gibt es irgendwo ein Modul, daß GD.pm heißt. Damit kannst du Gifs erstellen.
gefunden... aber verwirrt mich etwas zu sehr. Ich habe hier leider keinen lokalen Perl-Interpreter, und mit tar.gz kann ich auch nichts anfangen. Außerdem verlasse ich mich ungern auf Dinge, die ich nicht verstehe - und über 100kB große Module zählen leider dazu (zu mal ich von Modulen bisher keine Ahnung habe) :-/
Also wie das unter Windows geht, weis ich leider nicht. Ich hab hier Linux. Dort ist das ne Sache von einer Minute. Ne tar.gz bekommst du mit Winzip entpackt.
Naja, ich hab's erst mal runtergeladen, vielleicht brauche ich es ja irgendwann. Was ich aber eigentlich erhofft hatte, waren Infos, welche Daten ich wie übertragen muß (Header, MIME-Type etc.), und wie der Aufbau des .gif's danach ist (zeilenweise? wie viele Bits pro Pixel? etc.) Weißt Du zufällig, wo ich so etwas finden kann?
Schau mal auf www.oreilly.de nach. Dort gibt es etwas über ein Buch "Programmieren mit Perlmodulen". Auf der Seite von dem Buch ist die deutsche Übersetzung der Manpage.
Aber mit Jpegs geht es leider nicht.
Ist nicht weiter schlimm, das wäre auch mehr 'ne Notlösung gewesen :-)
Auf jeden Fall danke!
Cheatah
Wenn du noch ne Frage hast, schick mir einfach ne Mail.
-
-
-
hi Cheatah,
das Wissen! Wie sind .gif's aufgebaut?
dazu empfehle ich "Born, G. Dateiformate, Addison Wesley" Ist schon etwas aelter, aber wird es wohl noch oder in neuer Auflage geben.
Tschuess
Olaf -
hi Cheatah,
1. kleiner Nachtrag zum Buch: "G. Born GRAFIK Dateiformate" - gibt unzählige Bücher Formate von ihm zum Thema Formate.
2. GIF erzeugen
Jörks Insistieren auf dem PERL - Modul ist sicher berechtigt, nur wenn das Modul es nicht bringt verweise ich auf "netpbm" ein Grafikpaket, das unter Linux läuft aber auch - wenn ich mich recht erinnere - für andere OS-se verfügbar ist. Dies erlaubt das Konvertieren von Grafikdateien (auch über Eingabe über "stdin", d.h. mit diesem Programm ist es möglich, daß ein Byte/BitArray, das eine Grafik beschreibt eingegeben wird und hinten als GIF (o.a. JPEG) wieder herauskommt. Dann braucht man sich nicht mit der Programmierung der Kompression von GIF u.a. befassen.
<gg> Wenn aber so laufend Grafiken dynamisch erstellt werden sollen, wird das die Performance des Servers in die Knie zwingen </gg>
Tschuess
Olaf