Hallo, ich arbeiten an einem Gerät mit großem Grafikdisplay welches über einen XPORT per Ethernet den Displayinhalt auch in einem Browser als abspeicherbares Bild darstellen soll. Der XPORT ist so konfiguriert, dass mein Controller (AVR - ATxmega128A1 mit 8MB SDRAM) sich nur um die HTML-Geschichten kümmert*, also die Anfragen vom Browser auswertet und entsprechende Webseiten zusücksendet. Das einfachste wird sein das Bild direkt in den HTML-Text mit einzubinden, also nicht als extern zu ladene Grafik die separat vom Browser beim interpretieren der Seite angefragt wird - das ist möglich**) Die dazu benötigte Base64-Kodierung ist ja ein sehr einfach zu implementieren - bleibt aber das Problem, dass ja immer noch ein Bild in einem vom Browser lesbaren Format als Ausgangspunkt gebraucht wird (PNG, GIF, vllt. auch noch BMP?, vllt. auch JPG ohne Kompression?). Im Code des Mikrocontrollers existiert das Bild einfach als ein 2D-Array (320x480) aus einem R/G/B-Vektor, daraus muss eben ein Bild im entsprechenden Format erstellt werden. Welches Format würde sich anbieten? Die Dateigröße/Kompression oder Features wie ein Alphakanal sind nicht relevant. Es geht mir daraum, dass sich das Bild im Ausgangsformat möglichst einfach in das jeweilige, Browser-/PC-lesbare Format überführen lässt. Für den PC-Bereich gibt es wohl Libraries für die genannten Formate, aber wie schaut es mit den Abhängigkeiten aus - wie aufgebläht sind diese, ist es überhaupt möglich eine solche für den AVR-GCC zu portieren ohne, dass es ein Projekt für sich wird?! Gibt es eine solche Library die sich einfach auf den AVR-GCC portieren lässt - oder gar schon portiert ist? ...ist vielleicht schon ein Overkill, da ich ja gar keine besonderen Funktionen (Alphakanal, Kompression, ...) benötige, sondern nur ein ganz einfach gehaltenes Bild erzeugen möchte. Grüße Sascha *) siehe: Beitrag "RS232 nach HTTP/HTML Konverter" **) siehe 'Inline-Grafiken': http://aktuell.de.selfhtml.org/artikel/grafik/inline-images/
Sascha W. schrieb: > Die Dateigröße/Kompression oder > Features wie ein Alphakanal sind nicht relevant Dann versuch es doch mal mit einer (indizierten) Bitmap, da kannst du dir mit einem Bildverarbeitungsprogramm einfach ein dummybild in weiss erzeugen, davon den Header nehmen, und deine Grafikdaten hinterherschieben.
> Im Code des Mikrocontrollers existiert das Bild einfach als ein > 2D-Array (320x480) aus einem R/G/B-Vektor, daraus muss eben ein > Bild im entsprechenden Format erstellt werden. Was ist das für ein Bild? Photo? Diagramm? Je nachdem sind andere Formate besser geeignet. Die Libs würde man schon auch auf dem AVR lauffähig kriegen. Alles eine Frage des Aufwands. JPG (für Photos) ist natürlich schon mit etwas heftigem Aufwand verbunden, aber wenn es GIF auch tut, wäre das ein Kompromiss die LZE Kompremierung lauffähig zu machen. Ansonsten bleibt dir natürlich immer noch BMP - das ist das einfachste. Allerdings ist bei BMP das zu übertragende Datenvolumen schon recht heftig, wenn man kein Run Length Encoding benutzen kann oder will.
Karl Heinz Buchegger schrieb: > Allerdings ist > bei BMP das zu übertragende Datenvolumen schon recht heftig, wenn man > kein Run Length Encoding benutzen kann oder will. Außerdem könnte es Browser geben, die das nicht freiwillig darstellen. PNG und JPEG sind da recht sicher (GIF auch).
Micha schrieb: > Elm Chan hat das was gezaubert: > http://elm-chan.org/fsw/tjpgd/00index.html Vorsicht: "TJpgDec Tiny JPEG Decompressor" Das ist die Gegenrichtung! Er will JPG erzeugen, nicht dekodieren. JPG ist in der Hinsicht wie MP3. Dekodieren geht noch mit kleinem Aufwand, aber Erzeugen ist heftig.
Evtl wäre auch svg Vektorgrafik eine Alternative. Dies ist im Wesentlichen nur eine XML Datei und eignet sich zum Darstellen von Diagrammen ggf besser. Gruß Roland
einfach eine tabelle o.Ä. wo dann zellen mit 1*1px erzeugt werden und background color eingetragen werden - dann ist das bild direkt in html drin
Also wenn das Bild im Browser nur dargestellt werden soll (nicht speichern) und die Menge der zu übertragenden Daten irrelevant ist, dann könntest du doch einfach eine HTML-Tabelle machen mit 1x1 pixel großen Feldern (Hintergrundfarbe je nach Wert in deinem Array setzen).
Die 1x1 Pixel HTML Varianten sind aber doch um ein vielfaches Größer... Jörg Wunsch schrieb: > Außerdem könnte es Browser geben, die das nicht > freiwillig darstellen. Welche Grund sollte es geben? Karl Heinz Buchegger schrieb: > Ansonsten bleibt dir natürlich immer noch BMP > Allerdings ist bei BMP das zu übertragende > Datenvolumen schon recht heftig Kommt drauf an, wenn das "große" Grafikdisplay S/W mit 320x240 Pixel ist hält sich das in Grenzen (~10kb). LZW o.ä. im Mikrocontroller geht, ist aber auch nicht mal eben gemacht, und verbraucht vermutlich mehr Zeit (und vorallem RAM) als die Übertragung einer Bitmap braucht. Roland Praml schrieb: > Evtl wäre auch svg Vektorgrafik eine Alternative. Aber nur wenn er nicht eine Bitmap als Ausgangslage hat.
Also bei dem anzuzeigendem Bild geht es um ein Diagramm/Histogramm mit einigen darübergelegten Werten, so ähnlich wie bei einem Oszilloskop. Das mit dem BMP klingt ganz gut, das Format ist nicht zu schwierig zu erzeugen - das Benutzen eines leeren/weißen Bildes als Template macht es wahrscheinlich noch einfacher und scheint ja tatsächlich möglich. Mein Opera 12.01 sowie IE 8 scheinen BMPs in Webseiten anzeigen zu können, habe ich soeben mit einer kleinen Test-HTML-Datei und einem Bitmap-Bild herausgefunden, ob sich ein BMP aber auch Inline in eine HTML-Datei einfügen lässt weiß ich noch nicht genau, das muss ich noch ausprobieren bzw. recherchieren. Die Möglichkeit das Bild per Tabelle darzustellen gefällt mir gar nicht, es ist doch recht groß (1/2 VGA - also 320x480) und solch eine Tabelle darzustellen ist doch eine Qual für den Browser - aber noch viel unschöner ist, dass man das 'Bild' nicht speichern kann, was doch eines der als zentralen angedachten Features der direkten Anzeige im Webbrowser darstellt. Eine Möglichkeit, auch wenn sie mir nicht wirklich gefällt, wäre vielleicht noch das Bild per JavaScript zeichnen zu lassen - das JavaScript steckt eben auch im HTML-Code welcher vom Mikrocontroller erzeugt wird und in dem dann entsprechend die Daten des Bildes stecken - aber eben in rohform. JPG wäre keine wirklich gute wahl - da eben kein Photo, doch es ist ja scheinbar auch möglich ein JPG ohne jegliche Kompression zu erzeugen? Ich sähe es als alternative wenn es sich eben leichter erzeugen lässt im Vergleich zu anderen in Frage kommenden Formaten; was aber wohl ohnehin nicht der Fall zu sein scheint. Ich forsche gleich noch etwas bezüglich des Einbettens von BMPs - hoffentlich funktioniert das, würde eine schlanke Lösung darstellen. Danke soweit schonmal für die Hinweise! Grüße Sascha
Läubi .. schrieb: > Die 1x1 Pixel HTML Varianten sind aber doch um ein vielfaches Größer... > > Jörg Wunsch schrieb: >> Außerdem könnte es Browser geben, die das nicht >> freiwillig darstellen. > Welche Grund sollte es geben? > > Karl Heinz Buchegger schrieb: >> Ansonsten bleibt dir natürlich immer noch BMP >> Allerdings ist bei BMP das zu übertragende >> Datenvolumen schon recht heftig > Kommt drauf an, wenn das "große" Grafikdisplay S/W mit 320x240 Pixel ist > hält sich das in Grenzen (~10kb). Argh. Ich hab bei meiner Rechnerei vergessen durch 8 zu dividieren. Mir sind ~80k rausgekommen. Eigentlich hätte mir das komisch vorkommen müssen. 80k für ein popeliges Bild. Er hat allerdings RGB, damit sinds 30k. Immer noch nicht dramatisch. Ob Browser BMP tatsächlich nicht können? Keine Ahnung, aus dem Bauch raus hätte ich gesagt: kann ich mir nicht vorstellen. Schliesslich ist MS am Markt ja nicht irgendwer.
> Also bei dem anzuzeigendem Bild geht es um ein Diagramm/Histogramm > mit einigen darübergelegten Werten, so ähnlich wie bei einem Oszilloskop. Da würde ich dann allerdings tatsächlich auch zu Vektorgrafik tendieren. Hat den Vorteil, dass es auf jedem Monitor immer sauber angezeigt wird. Egal ob der Client jetzt 640*480 Pixel Auflösung fährt oder 1680*1050
Hier zb http://www.mikrocontroller.net/articles/Datei:C-flow.svg die Grafik ist ein SVG
1 | digraph |
2 | {
|
3 | node [shape=box]; |
4 | "link" [shape=point]; |
5 | |
6 | "main.c" -> "main.o" [label = " Compiler"]; |
7 | "func.c" -> "func.o" [label = " Compiler"]; |
8 | |
9 | "Bibliotheken\n*.a" -> "link"; |
10 | "main.o" -> "link"; |
11 | "func.o" -> "link"; |
12 | |
13 | "link" -> "Fertiges Programm" [label = " Linker"]; |
14 | } |
Da kann man doch nicht meckern.
Die Datenmenge, also hauptsächlich die Dateigröße des Bildes, ist ein gewisses Argument, da die Seite mit dem eingebetteten Bild im Browser nur ~10-sekündlich aktualisiert werden soll, ist es nicht so tragisch, dass es wohl ganze ~450kB sind, die serielle Schnittstelle des XPORT soll maximal 921kbps schaffen - wird also rund 4s zur Übertragund brauchen, das ist schon recht heftig... Als GIF mit 256 Indexfarben wären es nur ~7.5kB, Übertragungsdauer ~64ms - Das klingt schon besser, LZW ließe sich wohl bewältigen, der xmega läuft mit 20MHz, da sollte das berechnen dieses GIF-Bildes aus dem Bild-Array wohl zügiger gehen als das Übertragen der 450kB über die lahme Schnittstelle des XPORTs. RAM steht wie erwähnt ja ausreichend zur Verfügung, die eigentliche Applikation braucht von dem 8MB gerade mal etwa ein viertel. Eine Vektorgrafik ist so eine Sache - da ich das Bild ja in erster Instanz mit 'LineTo/SetPixel/DrawRect/...' zeichne, ließe sich gleichzeitig wohl auch ein Vektorbild zum Browser-Export erstellen und im Speicher halten, SVG scheint als Format dann wohl auch nicht kompliziert in der Handhabung? Was für mich aber eindeutig dagegenspricht ist, dass ich auf dem PC mit einem SVG-Vektorbild wenig anfangen kann, meine ganzen Grafikprogramme können damit nicht umgehen, ich kann irgendwie noch nicht einordnen wie gut mit die Idee gefällt. Die einzig wirkliche Alternative zum Vektorbild scheint also definitv ein Format mit begrenzter Farbpalette - das dürfte recht einfach herzustellen sein, ist kein Nachteil in der Darstellung oder Verwendbarkeit des Bildes und erzeugt ein überschaubares Datenvolumen. Weiß jemand einzuschätzen wie komplex das GIF-Format in der Handhabung ist? Da ich es scheinbar zuvor noch nicht klar erwähnte: Das Bild um welches es sich handelt ist 320x480 Pixel groß und kommt locker mit <256 Farben aus.
Karl Heinz Buchegger schrieb: > Ob Browser BMP tatsächlich nicht können? > Keine Ahnung, aus dem Bauch raus hätte ich gesagt: kann ich mir nicht > vorstellen. Schliesslich ist MS am Markt ja nicht irgendwer. Ist aber auch in der MS-Welt im HTML-Bereich wenig üblich (schon aufgrund der schieren Datenmenge). Meines Wissens auch nicht von der W3C genormt. Firefox scheint es mittlerweile trotzdem zu können, ich glaube mich zu erinnern, dass ältere Mozilla-Varianten das nicht konnten. Wenn es Sascha natürlich nur für einen ganz bestimmten Browser braucht, spielt das keine große Rolle. PNG hat als Nachteil, dass man deflate-komprimieren muss. Es gibt kein unkomprimiertes PNG-Datenschema. SVG wird wieder von anderen Browsern nicht verstanden (mir ist so, als wäre Microsoft da nach wie vor das schwarze Schaf, stimmt das noch?). Weiß nicht, ob man GIF unkomprimiert bauen kann/darf. Wenn man sowieso eine Kompression in Betracht zieht, kann man natürlich auf PNG gehen. Die libpng setzt auf der zlib auf, letztere ist leider nicht sehr portierfreundlich bezüglich nicht bereits im Quellcode vorgesehener Architekturen: der configure-Script scheint "handgefeilt", ein cross-Build für einen AVR lässt sich "aus der Dose raus" nicht einmal anschieben.
Wenns sowieso ein HTML-"Osziloskop" werden soll: Es ist doch garkeine komplette Neuübertragung nötig, sondern es muss immer nur ein Datenpunkt nachgereicht werden, das Darstellen/Animieren würde ich per Javascript machen. SVG wär da auch schon fast overkill, so HTML5-Canvas würde sich aber anbieten. der µC muss dann nur noch die Messwerte per Websocket, AJAX, Json... rausblasen, den Rest macht der Browser. So als Beispiel, was mit JS und aktuellen Browsern so gehen würde: http://www.jqplot.com/
Sascha W. schrieb: > Was für mich aber eindeutig dagegenspricht ist, dass ich auf dem PC mit > einem SVG-Vektorbild wenig anfangen kann, meine ganzen Grafikprogramme > können damit nicht umgehen, ich kann irgendwie noch nicht einordnen wie > gut mit die Idee gefällt. Also zumindest Chrome bietet mir an, das Bild im Browser auch in anderen Formaten zu speichern. > ein Format mit begrenzter Farbpalette - das dürfte recht einfach > herzustellen sein, ist kein Nachteil in der Darstellung oder > Verwendbarkeit des Bildes und erzeugt ein überschaubares Datenvolumen. > > Weiß jemand einzuschätzen wie komplex das GIF-Format in der Handhabung > ist? Ist nicht schlimm, wenn du eine fixe Palette hast und der LZW erst mal läuft. > SVG wird wieder von anderen Browsern nicht verstanden (mir ist > so, als wäre Microsoft da nach wie vor das schwarze Schaf, stimmt > das noch?). Zumindest war es das mal. Gerade mit dem letzten IE probiert: funktioniert. Auch das Speichern in anderen Formaten scheint zu funktionieren. > Weiß nicht, ob man GIF unkomprimiert bauen kann/darf. Ich denke nicht. GIF ist untrennbar mit LZW Kompremierung verknüpft. Da LZW aber schon himmelalt ist, sollte sich das problemlos auf einem AVR machen lassen.
Ich nutze meist immer Opera in der jeweils neusten Version - der scheint zur Zeit das schwarze Schaf in Sachen SVG sein, so eine Datei kann nicht direkt angezeigt werden geschweige denn vom Browser aus in ein anderes Format umgewandelt werden. Gerade habe ich noch etwas interessantes entdeckt, was mir neu war: Auch das BMP-Format unterstützt Indexfarben sowie eine einfache Kompressionsmethode - durch die recht größen Farbflächen in dem Bild sollte das fast ausreichen, LZW würde es vielleicht noch etwas besser hinbekommen, aber auch die im BMP-Format mögliche Kompression sollte die Datenmenge in eine gut übertragbare Größenordnung bekommen, dafür ist es eben unschlagbar einfach in der Erzeugung der Daten. Ich werde als nächstes wohl mal ein Demoprogramm auf dem PC schreiben, welches das macht, was später auf dem Mikrocontroller passieren soll - um zu sehen welche Browser mit so einem, evtl. exotischen, Bitmap umgehen können und um die resultierende Datenmengen mit einigen verschiedenen Bildern mal anschauen zu können. Ich hoffe das klappt - das wäre unschlagbar einfach und eigentlich genau das was ich brauche. Das GIF-Format ist doch noch etwas komplexer (scheinbar - habe noch keine Detailierte Formatbeschreibung gefunden, wotsit.org hat nur tote Links...) durch die diverse Features wie z.B. die Animation. Mit einem Oszilloskop hat das ganze übrigens nichts zu tun, ich habe es nur erwähnt weil die Bildschirmanzeige halt auch einen Graphen anzeigt. Auch gefällt mir das konzept nicht, jetzt auch nicht Code welcher in verschiedenen Browsern laufen soll vom Mikrocontroller aus erzeugen und übertragen zu lassen um einfach nur ein sich langsam aktualisierendes Bildschirmabbild im Browser über das Netzwerk anzuzeigen. Mit Web-Programmierung, AXAJ, usw... bin ich ohnehin nicht vertraut. Ich greife gezielt auf den XPORT zurück weil das Projekt keine größeren Klimmzüge auf dem Gebiet rechtfertigt. Es soll so einfach wie möglich der Bildschirm, in abspeicherbarer Form, über das Netzwerk in einem Browser angezeigt werden können. Andere Daten sollen auf die selbe Weise vom Gerät über das Netzwerk abrufbar sein, doch nicht über einen beliebigen Browser sondern über eine dedizierte, selbtgeschriebene Software - da muss ich mich nicht um vorgegebene Datenformate kümmern, wöllte ich in diesem Szenario das Bildschirmabbild als BMP/PNG/... haben, würde ich es tatsächlich Clientseitig erzeugen - auf dem PC gibt es ja wirklich genügend einfache Möglichkeiten. Ich schaue mal ob das mit der Farbpalette und Kompression im BMP-Format wirklich so einfach funktioniert, sollte es das, wäre mein Problem (bestmöglich - würde ich gar sagen) gelöst! http://de.wikipedia.org/wiki/Windows_Bitmap Grüße Sascha
Karl Heinz Buchegger schrieb: > Ich denke nicht. GIF ist untrennbar mit LZW Kompremierung verknüpft. Da > LZW aber schon himmelalt ist, sollte sich das problemlos auf einem AVR > machen lassen. Das Problem bei LZW ist eher, dass das Bild zweimal durchlaufen werden muss und das nacher ein übles Bitgeschiebe ist. Ich bezweifel, dass gegenüber eine Indizierten Bitmap und ggf. RLE encodiert ein großer Vorteil erzielen lässt. Sascha W. schrieb: > ob sich ein BMP aber auch Inline in eine > HTML-Datei einfügen lässt weiß ich noch nicht genau Du musst natürlich den in deinem Beispiel genannten Content Type anpassen, ich sehe nicht wieso dass nicht klappen sollte. Karl Heinz Buchegger schrieb: > die Grafik ist ein SVG die grafik ja... > [..] > Da kann man doch nicht meckern. Der Text den du gepostet hast aber nicht! Das ist ein dotfile, welches erst noch nach SVG konvertiert wurde! Einfach auf die Grafik klicken und dann Quellcode anzeigen, da steckt doch noch etwas mehr dahinter... Sascha W. schrieb: > da ich das Bild ja in erster > Instanz mit 'LineTo/SetPixel/DrawRect/...' zeichne, ließe sich > gleichzeitig wohl auch ein Vektorbild zum Browser-Export erstellen und > im Speicher halten, SVG scheint als Format dann wohl auch nicht > kompliziert in der Handhabung? Nein ist nicht komplziert, die Datenmenge wird aber je nach Aufbau des Bildes auch nicht unbeträchtlich sein, ich bin eigentlich ein Fan von SVG (zu anzeigen konvertieren kann ich Inkscape empfehlen), allerdings ist die Brwoserunterstützung wohl erst ab IE9 gegeben.
Hi mal davon abgesehen das ich SVG auch für das richtige Mittel halte (sollten mittlerweile alle Browser (IE ab 9) für den Anwendungsfall gut genug unterstützen) werf ich mal noch http://lodev.org/lodepng/ in den Raum. $ avr-gcc --version avr-gcc (GCC) 4.5.3 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ avr-gcc -w -Os -c -D LODEPNG_NO_COMPILE_DECODER -D LODEPNG_NO_COMPILE_DISK lodepng.c mat@mat-frame:~/tmp $ size lodepng.o text data bss dec hex filename 32862 4155 514 37531 929b lodepng.o Klingt jetzt auch nicht so schlimm, schleppt keine Abhängigkeiten mit und kompiliert einfach so mit dem avr-gcc. Laufzeittest habe ich aber keinen gemacht. Mega16 ist das größte was hier rumliegt. Matthias
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.