optimales Bildformat für Microcontroller + TFT

Stefan schrieb:

Hallo,

tja, dazu müsstest Du Dich über die Art der darzustellenden Bilder auslassen. Sind das synthetische Bilder mit wenigen Farben und Grauwerten oder natürliche Bilder mit Farb- und Helligkeitsverläufen und vielen Details sowie Rauschen. Je nach Art der Bilder kommen verschiedene Kopmpressionsmethoden in Frage. Bei synthetischen Bildern ohne Farb- und Helligkeitsverläufe funktioniert z.B. die Run Length Kodierung recht gut, bei natürlichen Bildern ziemlich schlecht.

Bye

Dazu muesste man sich die Uncompress Routinen vom Footprint her ansehen. Hast Du PNG probiert? Bin kein SW-Spezi, ich glaube die C-Routine dafuer heisst libpng. Zeilenweise sieht aber schlecht aus.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Stefan schrieb:

Das Bitmap-Format von Windows beherrscht auch Lauflängencodierung, wimre war das sogar effizienter als PCX. Gute Kompression erzielst Du bei beidem aber nur für Bilder, die viele einfarbige Flächen haben, also nicht für Fotos.

Bilddaten werden bei BMP/RLE wie gewünscht zeilenweise gespeichert. Wenn man noch ein fixe Farbpalette fordert, kann man das sicher sehr schnell und sehr speicherschonend dekodieren.

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net 
WWW: http://www.chzsoft.de/ 
PGP/GnuPG-Key-ID: 0x6DA025CA

Was soll das denn bringen? Die eigentlichen Imagedaten sind doch praktisch genauso gespeichert wie bei BMP. Und die knapp zwei Dutzend Bytes mehr durch den längeren Header von BMP dürften die Sache wohl auch kaum ausbremsen.

Huch, hab' ich was verpaßt? Seit wann ist denn PCX komprimiert? Nunja, jedenfalls ist mir zu der Zeit, als ich mich mal damit beschäftigt habe (muß so vor 20 Jahren gewesen sein), kein komprimiertes PCX über den Weg gelaufen. Ich kann mich auch nicht an irgendwelche Felder im Header erinnern, die was mit Kompression zu tun gehabt hätten.

Das ist Mist. Das erzwingt keine (oder bestenfalls sehr miese) Kompression. Wenn du acht Zeilen im Speicher halten kannst, sieht das schon wesentlich besser aus, dann würde ich PNG im interleaved Mode empfehlen.

Am besten wäre meiner Meinung nach aber, du bleibst erstmal bei unkomprimiertem BMP und verwendest deine Zeit darauf, den SD-Zugriff auf die Reihe zu bringen.

Schließlich geht es hier nur um ein gutes halbes MByte Daten, die sind bei vernünftigem Zugriff in weniger als zwei Zehntelsekunden von der SD-Karte gelesen. Allerdings nicht per SPI und schon garnicht per Soft-SPI...

Nur für 4- und 8-Bit indizierte Images, nicht für High- oder gar TrueColor.

Heiko Nocon schrieb:

Siehe . Mir ist damals umgekehrt früher kein PCX untergekommen, das nicht RLE-komprimiert war.

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net 
WWW: http://www.chzsoft.de/ 
PGP/GnuPG-Key-ID: 0x6DA025CA

Man koennte sich fuer Line-by-Line Compression Literatur wie diese ansehen:

1 Zeile mit 480 unsigned short hoert sich jedenfalls sportlich an. Doch wer weiss, es sollen schonmal 17 Leute in einen VW Kaefer gepasst haben.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Keine Ahnung was fuer Bildmaterial Stefan hat. Wenn es nur teilweise grossflaechige Bereiche gleicher Farbe und Helligkeit enthaelt, koennte man z.B. nur an diesen Stellen zeilenweise RLE benutzen. An anderen Stellen wo das Bild granularer ist dann auf reine Bitmap schalten. Damit das auch wirklich Ersparnis bei den zu uebertragenen Daten bringt, muesste man aber von 256 auf 128 Farben zurueckschalten. Dann kann man das freigewordene Bit benutzen um dem uC mitzuteilen, ob die gerade eingetrudelte Daten eine RLE Phase repaesentierten oder nicht.

Hier wird das am Ende der Seite beschrieben:

Gaebe auch noch andere Methoden, wenn unbedingt 256 Farben erhalten werden muessen. Eine Idee waere, Identifier Bytes am Anfang jeder Zeile zu setzen. Z.B. so:

Die Zeile wird gedanklich in 16 gleichlange Segmente geteilt. Ein Identifier am Anfang jeder Zeile hat zwei Bytes, und jedes der darin enthaltenen 16 Bits sagt, welche der Segmente RLE sind und welche nicht. Man kann auch drei Bytes und 24 Segmente nehmen, oder vier Bytes und 32 Segmente, usw.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Das hatte er aber doch sehr ordentlich und ohne jede Möglichkeit zur Fehlinterpretation beschrieben: 16Bit-HighColor im 565-Pixelformat.

Das ist das Format. Es sagt nichts ueber den Inhalt aus. Z.B. waere ein Landschaftsphoto aus dem Schwarzwald in diesem Format kaum RLE-komprimierbar, eine farbige Bedienoberflaeche waere hingegen sehr effizient komprimierbar.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Das ist wahr. Wenn es allerdings nur um eine farbige Bedienoberfläche geht, wäre der einfachste Ansatz, das Pixelformat zu ändern, nämlich auf

8-Bit-indiziert. Das reicht für jede sinnvolle Bedienoberfläche sicher auch und erschließt die Möglichkeit zur RLE-Kompression auch im BMP-Format.

Da könnte ich dann sogar eine fertige Anwendung beisteuern (4 oder 8 Bit-indiziert unkomprimiertes BMP rein->RLE-komprimiertes BMP raus, Kommandozeilenanwendung), die im Mittel 5% mehr herausholt als der Original-Encoder von Microsoft. Allerdings bei (geditherten) fotoartigen Bildern. Bei typischen Benutzeroberflächen dürfte die Ersparnis geringer ausfallen.

Tja, mein Kunde will Bilder darstellen, am liebsten als Video. Das hab ich ihm aber schon ausgeredet.

Das mit den Videos kam erst, als das ursprüngliche Projekt praktisch fertig war ;-)

Also es geht um ein Kiosk System, d.h. ein Automat, der über diesen Touch-Screen bedient werden soll. Der Kunde soll eine Bildsequenz auf eine SD Karte schreiben können. Diese Bildsequenz soll dann als kleiner Werbefilm auf dem Display ablaufen, bis der Betrachter den Bildschirm berührt. Dann wechselt das Gerät in den Bedienmodus, wo der Betrachter den Automaten bedienen kann.

Einsatzgebiete sind z.B. Hotels, Autohäuser, Autovermietungen. Denkbar sind also Werbefotos mit diversen Fahrzeugen, Logos von Fahrzeugherstellern, Werbefotos vom Hotel, Zimmeransichten, Foto vom Frühstücksbüffet etc.

Ich halte die Idee mit den Fotos für nicht besonders sinnvoll, aber was will man machen, wenn der Kunde das will.

Einige Ideen hab ich noch, wie man die Geschwindigkeit steigern kann, z.B. das Raster verschlechtern, also ein 400x240 Bild auf den 800x480 Bildschirm anzeigen. Das bringt fast den Faktor 4. Dann verkleinerung der aktiven Fläche, z.B. statt 800 x 480 nur 600 x

360 und den Rest der Fläche mit einem festen Inhalt, z.B. Text belegen, oder eine Textzeile durchlaufen lassen.

Das Display wird im Prinzip zeilenweise angesteuert, d.h. man übergibt zunächst die Koordinaten der Ecke oben links und die Koordinaten der Ecke unten rechts an das Display. Anschließend schreibt man die Bildpunkte als 16 Bit Werte (5+6+5) auf das Display.

Die Bilddatei wird byteweise gelesen. Da ich nicht genügend Arbeitsspeicher habe, um ein komplettes Bild im Ram des STM32 zu speichern, muss das Bild aufgebaut werden, während die Bilddatei gelesen wird. Eine Lauflängencodierung wäre also recht praktisch.

Soviel erstmal zu den Randbedingungen.

Gruß

Stefan

Das passt schon. Das Display hat 800x480 Pixel. Für jedes Pixel benötige ich 16 Bit, also ein unsigned Short. Die 480 unsigned short reichen dann für die Speicherung einer Bildzeile. Dazu benötige ich natürlich noch einige Bytes für die Berechnung...

Der Prozessor hat 20 kByte Ram.

Gruß

Stefan

Besser ist das.

Nunja: mit Konvertierung auf 8-Bit-indiziert (gedithert) und optimierter BMP-RLE sind bei 800x480 Bildgrößen so um die 370MByte machbar. Ohne allzu merkliche Qualitätsverluste.

Wenn du einen Bilderdienst kennst, der eingelieferte Fotos einfach so spiegelt, wie man sie hochlädt, stelle ich dir gerne ein paar Beispiele bereit.

Oha. Das sieht nach ziemlicher Sackgasse aus, aber vielleicht kann man noch anders tricksen. Z.B. Deine Idee mit halber Aufloesung, unter der Annahme dass der Prozessor das mit seinen 20k RAM, seiner Motorleistung und den Beschraenkungen des SPI Transfers schafft. Man koennte jedes neue Bild erstmal so laden, mit geringer Aufloesung. Die menschliche Reaktion ist erstmal die grobe Verarbeitung, "Oh, da ist ein schicker roter Sportwagen".

Danach sofort ein Update des gleichen Bildes in voller Aufloesung nachschieben, was aber langsamer und segmentweise laedt. Dabei wird z.B. erst das obere Viertel des Bildschirms ueberschrieben, dann das zweite Viertel von oben, und so weiter. Der Betrachter sollte davon wenig bemerken, denn es dauert ja normalerweise, bis er sich gedanklich auf einen neuen Bildinhalt konzentriert. Der Inhalt aendert sich nicht, nur die Aufloesung. So, als kaeme das Bild langsam von oben nach unten "in Fokus".

--
Gruesse, Joerg 

http://www.analogconsultants.com/

KByte natürlich, nicht MByte. So ein Blödsinn...

Nachtrag: Es kann sinnvoll sein, das zweite hoeher aufgeloeste Bild zeilenweise reinzuladen. Das kann ein unterbewusst empfundenes "Fokus-Ruckeln" verhindern. Wenn Dein Prozessor in der Lage ist, simultan SPI einzulesen und das Display zu bedienen, kann dieser Prozess sogar kontinuierlich und damit fuer den Betrachter sanft ablaufen.

Vermutlich kommt danach der naechte Kundenwunsch. Da Ganze haetten wir jetzt gern noch in 3D :-)

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Bau doch einfach zusätzlich einen Raspberry Pi ein. Damit kannst du dann problemlos HD-Videos mit 60 Hz und Soundausgabe abspielen :-)

Selbst der kleinste STM32F0 hat Hardware SPI, teilweise zwei davon, die mit 18 MBit/s laufen. Die SD-Card sollte das problemlos können, denn die Spezifikation für alle SD-Cards legt 20 MBit/s über den SPI-Modus als Minimum fest, für miniSD und microSD sogar 50 MBit/s.

Unkomprimiert sind deine Bilder 768000 Bytes groß, würde also in rund

0,4 Sekunden übertragen werden können. Rechnen wir noch ein wenig Overhead wegen dem Fat32-Dateisystem und Wartezeiten auf die SD-Card hinzu, dann kommen wir vielleicht auf eine Sekunde.

Wie ist "zu langsame" bei dir definiert? Wie schnell ist das Interface zur Bildausgabehardware? Ich hoffe die Bildausgabe hat double-buffering. Eine Sekunde lang ein Bild zeilenweise beim Aufbau zuzuschauen kann schon etwas nerven. Oder du programmierst ein paar interessante Effekte, wie z.B. Jalousienaufbau (das Bild dabei dann interlaced bereits vom PC aus auf die SD-Card speichern).

--
Frank Buss, http://www.frank-buss.de 
electronics and more: http://www.youtube.com/user/frankbuss

was für Bilder?

Für Fotos ist JPG das Mittel der Wahl. Für Grafiken PNG.

Damit wird es dünn. Mehr als RLE-Kodierung ist da nicht zu holen. Ich glaube selbst PNG braucht mehr als eine Zeile beim dekodieren.

Marcel