nicht angemeldet
Bilder allein mit Hilfe von Tabellen
Liebe Forumsbesucher,
fuer alle, die die Home-Mailingliste nicht lesen und mal wieder richtig aus den Schuhen gehauen werden wollen beim Anblick fremder HTML-Kuenste, fuer die gibt es was Neues:
http://netzagentur.de/test/ undhttp://netzagentur.de/test/bart.html
Ein typisches "Jpeg" und ein typisches "Gif" bekommt man dort zu sehen, wobei die Ladezeit besonders des "Jpegs" etwas auffaellig ist.
Der Knaller kommt aber erst, wenn man "view source" im Browser macht. Es gibt gar keine Grafiken da - alles ist mit Hilfe von reinem HTML gemacht! Pixel werden einfach als 1x1px grosse Tabellenzellen mit unterschiedlichen bgcolor-Werten realisiert. Dass so eine Tabelle nicht ganz klein ist, ist offensichtlich. Aber auf diese Weise lassen sich tatsaechlich HTML-Seiten realisieren, die Grafiken enthalten koennen, ohne auf externe Referenzen zurueckgreifen zu muessen.
Und es handelt sich praktisch um ein neues Grafikformat! Und zwar eines, dass man hervorragend generieren kann - mit CGI-Scripts, mit JavaScript usw.
Also guckt's euch mal an.
viele Gruesse
Stefan Muenz
-
Hallo Stefan,
http://netzagentur.de/test/ undhttp://netzagentur.de/test/bart.html
sehr interessante Sache nur wie zum Teufel macht man so was?!
Der Tabellenassistent von Frontpage wird es wohl nicht gewesen sein und handcoded ist in diesem Fall wohl zuviel des guten ;)Viele Gruesse,
Stefan Einspender-
sehr interessante Sache nur wie zum Teufel macht man so was?!
Man kann sowas mit einem Skript machen (und vermutlich haben die das ebenfalls so gemacht) - es gibt diverse Libraries, mit denen man Bilder lesen und dann pixelweise ansprechen oder manipulieren kann. Ist noch nicht einmal schwer.
Allerdings finde ich dieses Tabellenbild zwar eine nette Idee aus der Kategorie "schau an, was alles möglich ist", aber ohne praktischen Nutzen - wer dynamisch eine Grafik erstellen will, sollte dann doch lieber auch gleich ein kleines GIF per Skript zusammenschrauben.
-
Man kann sowas mit einem Skript machen (und vermutlich haben die das ebenfalls so gemacht) - es gibt diverse Libraries, mit denen man Bilder lesen und dann pixelweise ansprechen oder manipulieren kann. Ist noch nicht einmal schwer.
Hi Hanno,
wo gibt es solche Libraries??
Gruß, Martin
-
wo gibt es solche Libraries??
GD und ImageMagick, jeweils für Perl erhältlich. Mehr dazu auf dem CPAN-Archiv Deiner Wahl (siehe www.perl.com)
-
-
-
Hallo Stefan,
sehr interessante Sache nur wie zum Teufel macht man so was?!
Der Tabellenassistent von Frontpage wird es wohl nicht gewesen sein und handcoded ist in diesem Fall wohl zuviel des guten ;)Tja, und genau hier setzt meine Phantasie an: Ein Grafikkonverter von Irgendwas (BMP,GIF,JPG...) nach HTML! Ein verrueckter Gedanke - aber es gaebe sicherlich interessante Anwendungsfaelle.
Ausserdem muesste man die Tabellentechnik vielleicht noch etwas optimieren. Sinnvoller waere es vermutlich, die Pixel und ihre Daten in einem JS-Array zu erzeugen, und die Tabelle dann dynamisch mit document.write() zu schreiben. Wuerde sicher noch mal ein paar Bytes sparen. Denn wenn man die Idee einfach mal als Ausgangspunkt betrachtet und mal versucht, das Ganze speichermaessig mit den heute in HTML, CSS und JS moeglichen Mitteln zu optimieren, dann koennte ein richtig heisses Ding daraus werden...
viele Gruesse
Stefan Muenz-
Hi Stefan und Stefan!
Das ist cool! Zwar tendiert der praktische Nutzen so ungefaehr gegen Null, aber die Idee ist einfach genial!
sehr interessante Sache nur wie zum Teufel macht man so was?!
Tja, und genau hier setzt meine Phantasie an: Ein Grafikkonverter von Irgendwas (BMP,GIF,JPG...) nach HTML! Ein verrueckter Gedanke - aber es gaebe sicherlich interessante Anwendungsfaelle.Genau mit so einem Grafikkonverter wurde das gemacht, vermute ich. Man schaue sich nur mal den Titel des Dokuments an: "c:\bart.bmp by gfx2html, Copyright (c) 1999 by Mathias Mischler". Gfx2html? Na wenn das kein Konverter ist! Objektiv betrachtet ist das auch nicht weiter schwer mit einem Perlscript zu realisieren, wie Hanno schon sagte. Fuer BMP braucht man da nicht mal irgendwelche Libraries, weil das Format (unkomprimiert) ziemlich primitiv ist.
Ausserdem muesste man die Tabellentechnik vielleicht noch etwas optimieren.
Ja, aber nur ein kleines bisschen... ;-)
Sinnvoller waere es vermutlich, die Pixel und ihre Daten in einem JS-Array zu erzeugen, und die Tabelle dann dynamisch mit document.write() zu schreiben. Wuerde sicher noch mal ein paar Bytes sparen.
Fuer die Uebertragungsgeschwindigkeit waere das gut. Aber letztlich ist da ein Dokument, das gerendert werden muss. Und das dauert auf meiner Maschine mit Netscape deutlich laenger als die Uebertragung. Mit JS wuerde es dann noch laenger dauern.
Denn wenn man die Idee einfach mal als Ausgangspunkt betrachtet und mal versucht, das Ganze speichermaessig mit den heute in HTML, CSS und JS moeglichen Mitteln zu optimieren, dann koennte ein richtig heisses Ding daraus werden...
Mmh.. So auf Anhieb faellt mir da nichts anderes als das mit den Tabellen ein, und das ist nun - bei aller Begeisterung fuer die Idee - einfach zu langsam. Da ist es wohl besser, die Energie in eine Routine zu stecken, die GIFs on the fly erstellt (gibt's ja, heisst GD.pm, aber ist das wirklich in Perl geschrieben?).
Calocybe
-
-
Hallo Stefan,
http://netzagentur.de/test/ undhttp://netzagentur.de/test/bart.html
sehr interessante Sache nur wie zum Teufel macht man so was?!
Der Tabellenassistent von Frontpage wird es wohl nicht gewesen sein und handcoded ist in diesem Fall wohl zuviel des guten ;)Wenn mich meine Errinerung nicht täuscht kann das Photoshop 5.5 aus dem Stegreif :-) Wie Stefan schon sagt wenn man den code aufwand so weit minimiern kann das die Html datei kleiner ist als ein optimiertes bild dann hat das sicher zukunft. Und die zeiten des Bilder-Stehlen sind dann auch schon schwieriger :-)) (hilft nur noch screenshot)
ciao
Ludwig-
Hallo Ludwig,
Wenn mich meine Errinerung nicht täuscht kann das Photoshop 5.5 aus dem Stegreif :-)
Mit GIMP (Linux-Software, für Windows als Beta-Version erhältlich) habe ich solchen Blödsinn auch einmal probiert. Jedoch war mein alter 486er zu schwach... der Netscape-Browser hängte sich (und Linux!!!) mitten im Bild auf. :-)
-
Also ich als alter Graphik Fetischist ;-) find diese Table-Idee klasse, sieht zwar noch etwas dürftig aus, aber das könnte was werden (auch wenn der Source noch recht fett ist) !
Thanx Felix, werd mir jetzt erstmal GIMP anschauen !C Ya Pepe
-
-
-
-
Ein typisches "Jpeg" und ein typisches "Gif" bekommt man dort zu sehen, wobei die Ladezeit besonders des "Jpegs" etwas auffaellig ist.
Nun ja, in der Browser-Fußzeile werden auch 303 kB HTML-Source angekündigt - so lange dauerte das dann halt auch, Gnade.
Und wie das erst aussah! Ich armer Tropf habe natürlich Netscape 3, sah in Zeile 1 erstmal
"td { font-size: 1pt; line-height: 1pt; } " (danke schön, ich nix CSS) und dann ein Inferno von riesengroßen buntigen Kacheln ...Wenn das aber nur mit neuen CSS-Browsern geht, dann müssen die immerhin mit PNG konkurrieren. Als Konkurrenz zu GIF hätte man ja immerhin anführen können, daß GIF unter Copyright steht, daß man also nicht einfach Konverter nach GIF ohne Lizenz schreiben darf.
Wieso das übrigens weniger leicht zu klauen sein soll (view-source und cut&paste?), habe ich nicht verstanden.
Wenn man wirklich gegen GIF und Konsorten antreten will, dann kann man auch deren Technik verwenden. Die erste einfache Optimierung wäre beispielsweise eine run-length-Codierung für gleichfarbige Pixel - das würde für Zeichnungen schon sehr helfen.
Dann braucht man natürlich wirklich eine JavaScript-Engine zum Malen, die im Client abgeschaltet sein kann ... also einen Platzhalter für <noscript> usw.Andere Frage: Funktioniert der Farbeffekt auch, wenn ich horizontale Linien über <TD COLSPAN ...> beschreibe? (Oder vertikale mit ROWSPAN, oder Flächen mit beidem ...)
Dann brauche ich kein JavaScript, kann aber einfarbige Abschnitte ziemlich toll komprimieren ...-
Hallo Michael
Wenn man wirklich gegen GIF und Konsorten antreten will, dann kann man auch deren Technik verwenden. Die erste einfache Optimierung wäre beispielsweise eine run-length-Codierung für gleichfarbige Pixel - das würde für Zeichnungen schon sehr helfen.
Was in HTML mit rowspan und colspan umsetzbar ist. Deshab sehe ich auch eher eine Umsetzung von GIF als eine von JPEG bei der Sache. Denn eben dieses verlustfreie Komprimierungsverfahren, das einfach nur gleichdatige Pixel zusammenfasst, ist mit den span-Angaben optimal abbildbar.
viele Gruesse
Stefan Muenz-
Die erste einfache Optimierung wäre beispielsweise eine run-length-Codierung für gleichfarbige Pixel - das würde für Zeichnungen schon sehr helfen.
Was in HTML mit rowspan und colspan umsetzbar ist. Deshab sehe ich auch eher eine Umsetzung von GIF als eine von JPEG bei der Sache.Je länger ich mir das durch den Kopf gehen lasse, desto spannender fände ich es, so einen intelligenten Komprimierer zu schreiben.
Meine Analogie ist übrigens nicht das zeilenorientiert denkende GIF, sondern dann gleich das flächenorientiert denkende PNG, denn ROWSPAN und COLSPAN kann man ja kombiniert einsetzen.Allerdings fühlt sich das Problem, eine Graphik in einem minimale Anzahl von einfarbigen Flächen zu zerlegen, irgendwie np-vollständig an - knapsack läßt grüßen ... bei hinreichend "bunten" Bildern kann das entsetzliche Laufzeiten verursachen.
(Beispiel: Eine mindestens 3 Pixel breite diagonale Linie, die man durch beliebig viele einander überlappende Quadrate darstellen könnte - hier ist die Mehrdeutigkeit intuitiv durch die Kantenlänge des Quadrats bestimmt, aber formuliere mal für alle solche Dinger einen effizienten Algorithmus, der eben nicht lange herumprobiert ...)-
Hallo,
Die erste einfache Optimierung wäre beispielsweise eine run-length-Codierung für gleichfarbige Pixel - das würde für Zeichnungen schon sehr helfen.
Was in HTML mit rowspan und colspan umsetzbar ist. Deshab sehe ich auch eher eine Umsetzung von GIF als eine von JPEG bei der Sache.Ich habe momentan als 'einziges' Format BMP mit 24 Bit. Das ist zwar nicht sonderlich kompatibel, wird aber nur für den Konvertiervorgang verwendet.
Der Ablauf ist folgender GIF/JPEP/PNG/sonstwas nehmen, mit einem Malprogramm verkleinern, Farben reduzieren, etc.
Dann mit dem Tool, momentan leider noch ein DOS-Programm mit kryprischer Aufrufsyntax, als HTML konvertieren.Dabei werden gleiche Farbflächen bereits mit ROWSPAN und COLSPAN zusammengefaßt.
Je länger ich mir das durch den Kopf gehen lasse, desto spannender fände ich es, so einen intelligenten Komprimierer zu schreiben.
Meine Analogie ist übrigens nicht das zeilenorientiert denkende GIF, sondern dann gleich das flächenorientiert denkende PNG, denn ROWSPAN und COLSPAN kann man ja kombiniert einsetzen.Momentan mache ich das Zusammenfassen mit einem Greedy-Algorithmus. Der ist auf keinen Fall optimal, aber dafür von der Laufzeit her polynomiell.
Eine integrale Optimierung wäre in der Tat np-vollständig, aber man kann ja ruhig mal 30 Sekunden oder so für die Komprimierung warten.
Die Optimierung muß dann so ablaufen, daß die größte Fläche gesucht wird, gemerkt und markiert. Das dann iterieren bis kein Pixel mehr übrig ist.
Dann ist es aber wirklich optimal :) Müßte man auch beweisen können.Ciao,
Mathias-
Momentan mache ich das Zusammenfassen mit einem Greedy-Algorithmus. Der ist auf keinen Fall optimal, aber dafür von der Laufzeit her polynomiell.
Eine integrale Optimierung wäre in der Tat np-vollständig, aber man kann ja ruhig mal 30 Sekunden oder so für die Komprimierung warten.
Die Optimierung muß dann so ablaufen, daß die größte Fläche gesucht wird, gemerkt und markiert. Das dann iterieren bis kein Pixel mehr übrig ist.
Dann ist es aber wirklich optimal :) Müßte man auch beweisen können.Ganz im Gegenteil bin ich sicher, daß *das* nicht optimal ist (aber durchaus "gut", vor allem bei typischen Graphiken, für die GIF die optimale Darstellung wäre) und hatte deshalb den Knapsack-Algorithmus als Referenz angegeben.
Es geht ja nicht darum, eine große und unzählig viele kleine Flächen zu finden, sondern *möglichst wenige*. Das ist viel schwieriger - für den allgemeinen Fall gibt es nichts Besseres, als jede mögliche Kombination von Flächen durchzuprobieren. Und das sind *entsetzlich* viele ...Mein Beispiel mit der diagonalen Linie und den Quadraten sollte zudem zeigen, daß die Lösung nicht einmal eindeutig sein muß und daß bestimmte Fälle durch "Hinsehen" leicht zu erkennen, aber schwer zu formalisieren sein werden.
Diese Mehrdeutigkeit wiederum könnte man dahingehend nutzen, diejenige Lösung auszuwählen, die vom Browser am schnellsten layoutet werden kann ... -
Die Optimierung muß dann so ablaufen, daß die größte Fläche gesucht wird, gemerkt und markiert. Das dann iterieren bis kein Pixel mehr übrig ist.
Dann ist es aber wirklich optimal :) Müßte man auch beweisen können.Ich male mal ein kleines Bildchen in schwarz-weiß:
.......
..###..
.#####.
.......Wie faßt Du nun die #-Zeichen zusammen?
a) Die größte Fläche ist das Rechteck mit Fläche 6 (2*3 Pixel) in der Mitte; dazu brauchst Du noch zwei weitere Flächen der Größe 1.
b) Die beste Zusammenfassung liefern aber die beiden Zeilen mit 3 und 5 Pixeln.
-
Hallo Michael,
a) Die größte Fläche ist das Rechteck mit Fläche 6 (2*3 Pixel) in der Mitte; dazu brauchst Du noch zwei weitere Flächen der Größe 1.
b) Die beste Zusammenfassung liefern aber die beiden Zeilen mit 3 und 5 Pixeln.Super, das war sehr anschaulich. Klaro hast Du recht, vor dem Beispiel hätte ich das bestimmt noch bestritten *lol*
Ich würde sagen, das dies nicht 'vernünftig' algorithmisch realisierbar ist.
Ich denke momentan eher über eine Cluster Zusammenfassung nach. Da müßte immer ein relativ gutes Ergebnis rauskommen und ist polynomiell lösbar.
Je nachdem, wie die Cluster zusammengefaßt werden, kann man dann möglich wenig Flächen oder möglichst große Flächen suchen.
Immer von oben Nachbarn zusammenfassen: Möglichst wenig Flächen. Abwechselnd von oben und unten zusammenfassen (od. Links und Rechts): Möglichst wenig Flächen.
Was hälst Du davon?
Ciao,
Mathias
-
-
-
-
-
-
Hallo Stefan,
fuer alle, die die Home-Mailingliste nicht lesen und mal wieder richtig aus den Schuhen gehauen werden wollen beim Anblick fremder HTML-Kuenste, fuer die gibt es was Neues:
Schau auch mal auf
<A HREF="http://www.kaffeetasse.de/test/xweb.html">http://www.kaffeetasse.de/test/xweb.html</A>
... und laß Dich überraschen.
<SUB>(Wenn Du was gegen die Verwendung hast, mail, dann werf ich es sofort runter)</SUB>P.S. Der Konverter ist von mir, war so eine Idee die mir in einem Biergarten gekommen ist. Sinnvolle Anwendungen dazu fallen mir immer noch nicht ein, aber es hat ein paar Vorteile: Bilder ohne Referenzen, Grabbing von Bildern mit "Speichern unter..." wird unterbunden, und Web-Washer funktionieren nicht.
Das man die Grafiken auch dann angezeigt bekommt, wenn Image-Loading off ist, ist irgendwo klar.
Sogar mit dem Lynx müßte was zu sehen sein ;)Größter Nachteil ist halt, daß die Bilder vom Datenvolumen her viel zu groß werden.
Ciao,
Mathias-
Hallo Mathias,
<SUB>(Wenn Du was gegen die Verwendung hast, mail, dann werf ich es sofort runter)</SUB>
Wie sollte ich!
Willkommen im Forum! Und deine HTML-Tags darfst du hier ablegen, die werden als Text dargestellt, damit wir hier HTML-Probleme waelzen koennen <g>P.S. Der Konverter ist von mir
Ich bemuehe mich, es ganz normal zu finden, dass jeder, ueber den man hier mal erfreulich redet, binnen eines Tages hier ist und sich in die Diskussion einmischt <g>
war so eine Idee die mir in einem Biergarten gekommen ist.
Ich habe nicht daran gezweifelt, dass diese Idee irgendwo anders haette entstanden sein koennen. Leute, die in Orten wohnen, in denen es keine Biergaerten gibt, werden das nie verstehen. Aber dafuer kommen ihnen halt auch nicht so Ideen ;-)
Sinnvolle Anwendungen dazu fallen mir immer noch nicht ein, aber es hat ein paar Vorteile: Bilder ohne Referenzen, Grabbing von Bildern mit "Speichern unter..." wird unterbunden, und Web-Washer funktionieren nicht.
Grafik als Klartext in einem Format, das jeder kennt - also wenn das nix ist!? Denk mal an kleine Grafiken, die man per JavaScript oder Perl/CGI im Browser erzeugen kann!
Wenn du mehr Ahnung hast von der Sache, lass dich ruhig mal hier auf die angefangene Algorithmus-Diskussion ein. Vielleicht findet ihr die optimale Technik zum Zusammenfassen. Dann noch die optimale HTML-Technik (wie schon gesagt, ich denke, das Ganze mit JavaScript in Form von Array-Daten und in Schleifen geschriebenen document.write-Befehlen wuerde noch mal einiges an Speicherbedarf reduzieren), und fertig ist das Patent fuer ein neues Grafikformat <g>.viele Gruesse
Stefan Muenz-
Hallo Stefan,
Willkommen im Forum! Und deine HTML-Tags darfst du hier ablegen, die werden als Text dargestellt, damit wir hier HTML-Probleme waelzen koennen <g>
Das habe ich auch gemerkt, nachdem die Nachricht losgeschickt war ;)
Ich habe mich schon so an die <'s und >'s in anderen Foren gewöhnt, um HTML Code sichtbar zu machen.Ich bemuehe mich, es ganz normal zu finden, dass jeder, ueber den man hier mal erfreulich redet, binnen eines Tages hier ist und sich in die Diskussion einmischt <g>
Das spricht für die aktive Kommunikation in der Netzgemeinde, und die Reichweite, Attraktivität und Kompetenz, die Dein Forum hat. Nimm es einfach als Kompliment hin.
Grafik als Klartext in einem Format, das jeder kennt - also wenn das nix ist!? Denk mal an kleine Grafiken, die man per JavaScript oder Perl/CGI im Browser erzeugen kann!
Wenn du mehr Ahnung hast von der Sache, lass dich ruhig mal hier auf die angefangene Algorithmus-Diskussion ein. Vielleicht findet ihr die optimale Technik zum Zusammenfassen. Dann noch die optimale HTML-Technik (wie schon gesagt, ich denke, das Ganze mit JavaScript in Form von Array-Daten und in Schleifen geschriebenen document.write-Befehlen wuerde noch mal einiges an Speicherbedarf reduzieren), und fertig ist das Patent fuer ein neues Grafikformat <g>.Von JS habe ich nicht allzu viel Ahnung. Wenn Du die Diskussion hier im Thread meinst, dann ist sie ja noch nicht allzu weit, so daß ich grad mal hier damit anfange, meine Ideen dazu niederzuschreiben:
Welche Informationen benötigt man für den Tabellenaufbau?
- Farbe evtl. Transparenz
- Größe der Spalte
- Breite der Spalte
Die Farbe muß man in Text codieren.
Alternative a) wie gewohnt 'FF8800' (24 Bit) oder 'F80' (16 Bit) (6 Bytes oder 3 Bytes).
Alternative b) möglichst Platzsparend (ich glaube bei UUencode passen 6 Bits in ein Byte) (4 Bytes oder 2 Bytes). Muß man bei HTML Seiten noch überlegen, welche Bits ohne Konvertierung sauber übertragen werden.Transparenz kann man in eine Ekelfarbe merken (escapen)(irgendsoeine grün-braun Matschfarbe), wenn die Farbe dann mal wirklich kommt, dann wird sie einfach im Grünton in 24 Bit um eins erhöht.
Größe/Breite jeweils ein Byte, z.B. "021e" (COLSPAN=2 ROWSPAN=30) oder so. Damit hätten wir max. 255 x 255.
Wenn wir uns auf 127 x 127 beschränken können wir noch im höchsten Bit kodieren, wieviele der nächsten Einträge KEINEN Eintrag dieser Art brauchen, z.B. 'F7' heißt, die nächsten 9 Einträge haben keinen COLSPAN Eintrag.Wichtig für den Aufbau wäre noch zu sagen:
-
Egal wie man optimiert, jede optimale Fläche hat immer einen Punkt links oben. Und das ist unser Referenzpunkt für die Fläche, d.h. mit so einem Auslesen machen wir nichts für spätere Optimierungen kaputt.
-
Um die Tabelle aufzubauen, muß man sich merken, welche Felder schon von Flächen per ROWSPAN/COLSPAN überdeckt sind. Da diese Farben nicht abgelegt sind, muß intelligent mitgezählt werden, damit die TABLE später konsistent wird.
So, damit müßte man sowas schreiben können ;))
Jetzt müssen wir uns nur noch auf das Format (alla UUEncode oder Hex) einigen.
Die Stringinhalte kann ich von meinem Tool gerne erstellen.
In JS bin ich leider nicht so fit, daß wäre ne riesige Quälerei, um die Kommandos zu finden, Stefan ? :))Ciao,
MathiasP.S. Patent für sowas kann man in Deutschland leider nicht machen.
Ist eine "Anweisung an den menschlichen Verstand" und keine "Anweisung zur Beherschung physikalischer Naturkräfte" und daher nicht patentfähig.
Da müssen wir dann schon ein Auslandspatent in den USA anstreben ;))-
Hallo,
Ich habe mich schon so an die <'s und >'s in anderen Foren gewöhnt, um HTML Code sichtbar zu machen.
Wäh... hier fehlt die Vorschau. :))
Ich meinte > und <. Hoffentlich klappt es jetzt. Das & solltest Du noch auf & konvertieren.
Ciao,
Mathias
-
-