Forum: Mikrocontroller und Digitale Elektronik Bildformat für Farb-LCD


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Walter T. (nicolas)


Lesenswert?

Hallo zusammen,

ich habe ein kleines Projekt mit einem STM32F446RE und einem 
ILI9341-Farbdisplay. Ich habe den ganzen Flash bezahlt - ich werde den 
ganzen Flash nutzen. Also kommt noch ein schickes Logo dazu.

Stellt sich die Frage nach dem passenden Format.

Beim ATmega und den klassischen 128x64-Pixel-Displays war der 
Speicherplatz ja kein Problem. Hat man einfach das Bitmap unkomprimiert 
gespeichert. Das klappt hier nicht mehr.

Anforderungen wären wohl:
  - Das Bild und Entpackalgorithmus sollten halbwegs klein sein
  - Es sollte sich blockweise entpacken lassen (für einen kompletten 
Framebuffer ist eben kein Platz da)
  - Der Entpack-Algorithmus sollte bekannt und offen sein
  - Für Logo-artige Bilder sind wohl indizierte Farbformate Mittel der 
Wahl


Was ist geeignet? Der erste Gedanke war PNG. Ein erster Versuch hat 
gezeigt, dass ein indiziertes RLE-komprimiertes BMP aber noch kleiner 
ist.

Oder gibt es noch etwas Besseres? Für jemand wie mich, der in der 
Bildbearbeitung Anfänger ist, ist auf einfacher == besser.

von Martin (Gast)


Lesenswert?

Walter T. schrieb:
> - Das Bild und Entpackalgorithmus sollten halbwegs klein sein

Du hast den ganzen Flash bezahlt also nutze ihn auch mit einem so großen 
wie möglichen Algorithmus ;-)

von Walter T. (nicolas)


Lesenswert?

Ich will den übrigen Platz aber für interessanten Blödsinn, nicht für 
blöden Blödsinn nutzen.

Wie dem auch sei. Der Wikipedia-Artikel über BMP sieht brauchbar aus, 
und der Header ließ sich nicht schwer dekodieren. Jetzt führe ich mir 
mal den Bildaufbau zu Gemütze.

: Bearbeitet durch User
von Johannes S. (jojos)


Lesenswert?

solche Daten könnte man auch auf ein SPI Flash auslagern, die kleinen 8 
pin ICs kosten nicht viel.

von Kahl Kuhlator (Gast)


Lesenswert?

Ein speicherfüllendes Bild in 16 Bit Farbtiefe für das ILI9341
hat unkomprimiert eine Grösse von 320x240x2 = 153600 Bytes.
Bei 153K passen in das Flash eines STM Controllers jede Menge
Bildchen rein, und wenn man sich ein externes SPI Flash gönnt
könnte man locker ein kleines Filmchen ablaufen lassen.

Wozu also der Ehrgeiz mit Formaten und Dekodierung ....
Beschäftigungstherapie? Sonnst nicht ausgelastet?

von Martin S. (strubi)


Lesenswert?

Die Antwort hast du dir ja schon gegeben.
Die Ilitek-Dinger haben intern eh nur RGB5:6:5, und fuer ein Logo kann 
man auch auf 3:3:2 gehen oder gleich indizieren.
So als 'Anekdote': Die guten alten digital picture frames ('dpf-ax') von 
Pearl hatten einen 8051 drin und ein paar Custom-JPEG-Routinen, inkl. 
USB-storage. Passte alles auf ein 2 Mbyte SPI-Flash, mit ca. 20-40 
Bildern.

von c-hater (Gast)


Lesenswert?

Walter T. schrieb:

> ein indiziertes RLE-komprimiertes BMP aber noch kleiner
> ist.
>
> Oder gibt es noch etwas Besseres?

Für Logos mit wenigen Farben und großen gleichfarbigen Flächen: nein, da 
ist ein indiziertes Format mit RLE kaum zu schlagen.

Für Bilder aber, die man normalerweise mit JPEG komprimieren würde, gibt 
es was, was zwar längst nicht so gut wie JPEG komprimiert, dafür aber 
darauf ausgelegt ist, sich leicht und schnell dekomprimieren zu lassen: 
ASTC.

Wird z.B. bei OpenGL für Texturen verwendet, aber z.B. auch bei, 
Trommelwirbel, Displays, nämlich denen mit BT81x-Displaycontrollern.

Der Algorithmus ist allerdings wesentlich komplexer als etwa RLE.

von Rolf M. (rmagnus)


Lesenswert?

c-hater schrieb:
> Für Logos mit wenigen Farben und großen gleichfarbigen Flächen: nein, da
> ist ein indiziertes Format mit RLE kaum zu schlagen.

Auch in der Hinsicht ist RLE nicht zu schlagen:

Walter T. schrieb:
> Für jemand wie mich, der in der Bildbearbeitung Anfänger ist, ist auf
> einfacher == besser.

Letztendlich kommt's beim Logo auch drauf an, wie viele Farben es hat. 
Man kann ja auch auf 4 Bit pro Pixel mit Indizierung runter. Dann hat 
man immer noch 16 Farben, oder eben 2 Bit für 4 Farben. Für die meisten 
Logos wird selbst das reichen.

Walter T. schrieb:
> Ich will den übrigen Platz aber für interessanten Blödsinn, nicht für
> blöden Blödsinn nutzen.

Das klingt halt etwas widersprüchlich. Du willst den ganzen Flash 
nutzen, also willst du ein Logo haben. Nur ist für das Logo zu wenig 
Flash da, deshalb willst du es komprimieren. Und das ganze muss so klein 
wie möglich sein, weil du den verbleibenden Flash eigentlich noch für 
wichtigere Dinge brauchst.

von Walter T. (nicolas)


Angehängte Dateien:

Lesenswert?

BMP lässt sich zeilenweise dekodieren. Das ist natürlich noch handlicher 
als blockweise.

Ich fand das eine interessante Programmieraufgabe. Wäre das Padding für 
den "absolute mode" in den Beschreibungen bei Microsoft, und nicht nur 
in alten Büchern, die man nur per Google Books zufällig findet 
beschrieben, wäre das im Wesentlichen nur eine nette Fingerübung.

Das Bild ist mit 4 Bit indizierten Farben (RLE_4) und nimmt knapp 11 kB 
ein.   Man sieht ganz gut, dass das für Farbverläufe alles andere als 
ideal ist. Aber RLE_8 wird wohl jetzt auch kein Hexenwerk mehr sein.

Bei Interesse stelle ich mal die Dokumente zusammen.

: Bearbeitet durch User
von Georg G. (df2au)


Lesenswert?

ImageConverter565 ist ein gutes Werkzeug, um Grafik Files passend zu 
skalieren und in C-Include-Files zu wandeln.

von Walter T. (nicolas)


Lesenswert?

Den Tipp werden sicherlich einige hilfreich finden.

Hier brauche ich das aber gar nicht. Eine BMP-Datei einzulesen und in 
ein C-Array mit dem selben Inhalt umzuwandeln ist ein Wenigzeiler in 
Matlab oder Python. Unter Linux geht das m.W. sogar mit Bordmitteln.

von c-hater (Gast)


Lesenswert?

Walter T. schrieb:

> Eine BMP-Datei einzulesen und in
> ein C-Array mit dem selben Inhalt umzuwandeln ist ein Wenigzeiler in
> Matlab oder Python.

Das dürfte in keiner normalerweise verwendeten Sprache eine besondere 
Herausforderung sein, nichtmal in C...

von c-hater (Gast)


Lesenswert?

Walter T. schrieb:

> BMP lässt sich zeilenweise dekodieren. Das ist natürlich noch handlicher
> als blockweise.

Poste doch mal das Originalbild. Mal schauen, was da so alles geht. Also 
als Kompromiss aus Decodieraufwand und Platzbedarf des komprimierten 
Bildes.

von Georg G. (df2au)


Lesenswert?

Walter T. schrieb:
> Hier brauche ich das aber gar nicht

Größe ändern und Farbtiefe anpassen machst du auch mit drei Zeilen. 
Glückwunsch.

von Walter T. (nicolas)


Angehängte Dateien:

Lesenswert?

c-hater schrieb:
> Das dürfte in keiner normalerweise verwendeten Sprache eine besondere
> Herausforderung sein, nichtmal in C...

Genau das macht den Reiz aus. Einfach draufschieben ohne besondere 
Konvertierung.

Und jetzt der sehr wirklich schöne Teil: BMPs mit der Speicherart 
BI_BITFIELDS haben das Datenformat so, dass man sie direkt auf das 
Display schieben kann. Mehrkosten gegenüber einem "speziell" 
konvertierten Bild: 138 Bytes für den Header und noch ein bischen fürs 
Padding am Zeilenende.

Ich habe mal die passenden Einstellungen für GIMP dargestellt. Nachdem 
RLE4 funktioniert hat, waren die anderen Modi nur noch eine Fingerübung.

von W.S. (Gast)


Lesenswert?

Walter T. schrieb:
> Stellt sich die Frage nach dem passenden Format.

Und dabei kommt dir nix anderes als die üblichen am PC gebräuchlichen 
Formate in den Sinn, als allererstes PNG.

Guck hier bei den Projekten mal nach sowas. Ich hatte vor Zeiten mal 
etwas dazu gepostet - aber dabei eher an die Bildkacheln für Googlemaps 
und Artverwandtes gedacht.

W.S.

von Walter T. (nicolas)


Lesenswert?

Zu ASTC? Welches Malprogramm kann denn überhaupt Daten in diesem Format 
speichern?

von W.S. (Gast)


Lesenswert?

Und welches Malprogramm kann den Quellcode für die Dekodier-Routine 
ausgeben?

Nö, beides (angepaßtes Bildformat + Dekodier-Routine) sind Obliegenheit 
des Programmierers.

Falls dir nach sowas sein sollte, dann suche hier mal nach "BildConv" 
und "BildReTester". Notfalls lade ich das Zeugs hier nochmal hoch.

W.S.

von Walter T. (nicolas)


Lesenswert?

Okay... also Du hälst es für vorteilhaft, auf beiden Seiten (PC und 
eigene Plattform) eine Baustelle zu haben, anstelle einfach eine 
Standardlösung zu nutzen?

Ich nicht. Wahrscheinlich liegt das daran, dass ich hier fachfremd bin.

von Johannes S. (jojos)


Lesenswert?

als fertige Lösung würde ich da wieder auf lvgl verweisen, das hat einen 
Konverter https://lvgl.io/tools/imageconverter und passende Image 
Routinen in der Software.
Da lvgl alles über einen Render Buffer macht, der min. nur 10 Zeilen der 
physikalischen Displaygröße groß sein muss, ist es da auch nötig einen 
beliebigen Teilausschnitt des Image adressieren zu können. Angezeigt 
wird das dann vom Image Widget das dann zusätzlich einige Optionen hat.
https://docs.lvgl.io/master/widgets/core/img.html

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Walter T. schrieb:
> Okay... also Du hälst es für vorteilhaft, auf beiden Seiten (PC und
> eigene Plattform) eine Baustelle zu haben, anstelle einfach eine
> Standardlösung zu nutzen?

Standard-Lösungen muß man immer auf ihre Zweckmäßigkeit unter den 
gegebenen Umständen abklopfen. Und die sind auf einem µC völlig anders 
als am PC.

W.S.

von Walter T. (nicolas)


Lesenswert?

Johannes S. schrieb:
> einen
> beliebigen Teilausschnitt des Image adressieren zu können.

Das ist tatsächlich ein brauchbarer Mehrwert.

Johannes S. schrieb:
> Da lvgl alles über einen Render Buffer macht, der min. nur 10 Zeilen der
> physikalischen Displaygröße groß sein muss,

Das ist natürlich eine Einschränkung. 6,4 kB für ein 320-Spalten-Display 
sind nicht nichts. Bei BMP kann ich notfalls alles über einen 4 Byte 
großen Buffer machen. Aber für einen verschiebbaren Ausschnitt müsste 
ich das Bitmap-Array jedes Mal von vorn komplett durchsuchen und 
Zeilenumbrüche zählen. Für Bilder mit verschiebbarem Ausschnitt kann der 
Mehrwert die Einschränkung also wahrscheinlich in vielen Fällen 
wettmachen.

: Bearbeitet durch User
von Philipp K. (philipp_k59)


Lesenswert?

Wieso will man Flash benutzen den man bezahlt hat und sucht dann 
Kompressionsmethoden?

Die Lösung richtet sich ja nach Datenmenge, Bildqualität, Auflösung, 
Farbtiefe und erwarteter Qualität auf dem Display.

Es gibt ja erstmal mindestens 100 Tools für Mikrocontroller die Bilder 
als Headerfiles  konvertieren.. rgb8,rgb444,rgb555,rgb565.. etc.

Dazu kann man mit z.B. Irfanview schauen wann die eigentliche 
Bildqualität je nach Input bei Farbreduzierung flöten geht. Dann kann 
man schauen in welche Richtung man muss.

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

Im neuen MagPi ist ein kleines Projekt erwähnt, Sprites auf dem Pi Pico
https://twitter.com/jamessutherland/status/1360330220277018628
wenn es Bewegtbilder sein sollen. Hier ein kleines Video dazu in 
miserabler Qualität

BMP habe ich auch mal benutzt
Beitrag "Re: Für Retro-Zwecke - PAL Sender?"
auf der letzten Seite des PDF sind zwei TV-"Testbilder", aus einem BMP 
ins Eprom, 3+3+2 Bit für RGB-Daten.

: Bearbeitet durch User
von Walter T. (nicolas)


Lesenswert?

Schick ist das. Manchmal finde ich es echt schade, dass kein kompletter 
Frame ins RAM passt. Und machen wir uns nichts vor: Spaß macht es erst, 
wenn zwei passen.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Philipp K. schrieb:
> Wieso will man Flash benutzen den man bezahlt hat und sucht dann
> Kompressionsmethoden?

Weil der in einem üblichen µC zur Verfügung stehende Flash von 64K bis 
1M im Vergleich zu Bildern (480x360 .. 800x480 und das jeweils in 16 bis 
32 Bit) doch recht klein ist.

Darum.

W.S.

von wegwerfname++ (Gast)


Lesenswert?

auch PNG kann komprimieren http://www.libpng.org/pub/png/libpng.html

von Walter T. (nicolas)


Lesenswert?

wegwerfname++ schrieb:
> auch PNG kann komprimieren http://www.libpng.org/pub/png/libpng.html

Deswegen war es auch mein erster Gedanke. Und unterstützt auch 
indizierte Farben und einen Alphakanal. Im Vergleich zu BMP ist es 
selbst bei kleinen Dateien (so 40x40 Pixel) ungefähr halb so groß, wenn 
man nicht vergisst, ohne Vorschau und ohne EXIF zu speichern.

Vorteil BMP:
 - Recht einfach implementiert
 - Kann auch direkt Bitmaps im RGB565-Format speichern, was sich direkt 
ans Display schicken lässt

und was ich diese Woche neu gelernt habe:
 - Unterstützt auch Alphakanal und nicht-rechteckige Bildränder
 - Es reicht ein beliebig kleiner Pixelpuffer (2 Bytes) zum Entpacken 
aus.

Ich bin zufrieden und es hat Spaß gemacht.

von c-hater (Gast)


Lesenswert?

Walter T. schrieb:

> Vorteil BMP:
>  - Recht einfach implementiert
>  - Kann auch direkt Bitmaps im RGB565-Format speichern, was sich direkt
> ans Display schicken lässt

Naja, das bloß halt nicht komprimiert. Entweder BI_BITFIELDS oder 
BI_RLEx. Beides gleichzeitig ist nicht.

Aber man kann im Prinzip beliebige Komprimierungen im BMP-Format 
unterbringen. Bei AVIs (die ebenfalls einen BMIH verwenden) wird's ja 
auch seit Jahrzehnten so gemacht. Bloß für's *.bmp-Fileformat ist sowas 
halt nicht spezifiziert.

von c-hater (Gast)


Lesenswert?

c-hater schrieb:

> Bloß für's *.bmp-Fileformat ist sowas
> halt nicht spezifiziert.

Wobei das auch nicht mehr ganz korrekt ist. Zwar meines Wissens nach 
nicht direkt für's BMP-Fileformat dokumentiert, aber trotzdem: Intern 
verwendet Windows mittlerweile auch in BMPs "eingebettete" PNGs, z.B. 
für Icons. Dafür ist es dann auch dokumentiert, allerdings eher etwas 
verschämt, garnicht so leicht zu finden, wenn man nicht gezielt danach 
sucht. Was ja erstmal voraussetzt, dass man schon weiss, dass es das 
überhaupt gibt.

von Walter T. (nicolas)


Lesenswert?

c-hater schrieb:
> Zwar meines Wissens nach
> nicht direkt für's BMP-Fileformat dokumentiert,

Eingebettete PNGs oder JPEGs sind dokumentiert. Nur eben nicht in den 
alten Dokus fürs V3-Format. Ich sehe allerdings auch keinen Mehrwert, 
diese Daten in einen BMP-Container zu packen.

Was mich wirklich wurmt: Es gibt kein RLE-1-Format (also gepackte 
1-Bit-SW-Bilder). Damit sind indizierte 4-Farb-Bilder faktisch kleiner 
als SW-Bilder.

: Bearbeitet durch User
von Markus F. (mfro)


Lesenswert?

Walter T. schrieb:
> Was mich wirklich wurmt: Es gibt kein RLE-1-Format (also gepackte
> 1-Bit-SW-Bilder). Damit sind indizierte 4-Farb-Bilder faktisch kleiner
> als SW-Bilder.

Das gab's schon in den 80ern auf dem Atari ST: 
https://www.fileformat.info/format/gemraster/egff.htm

von Walter T. (nicolas)


Lesenswert?

Sieh an. Vielleicht ist das einen Blick wert:

"PNG Image Decoding Library Does It With Minimal RAM"
https://hackaday.com/2021/07/17/png-image-decoding-library-does-it-with-minimal-ram/

Jemand hat eine Arduino-Library für PNG gebastelt. Wenn die Lizenz nicht 
ganz weit weg von nutzbar ist, wird mein BMP-Dekoder eine Woche nach dem 
Start direkt wieder auf den Altenteil geschickt.

von Christian F. (christian_f476)


Lesenswert?

c-hater schrieb:
> Das dürfte in keiner normalerweise verwendeten Sprache eine besondere
> Herausforderung sein, nichtmal in C

Und obendrein könnte man es auch verlinken und direkt verwenden

von c-hater (Gast)


Lesenswert?

Walter T. schrieb:

>> "PNG Image Decoding Library Does It With Minimal RAM"

Da steht doch gleich auch:

> It will run on any microcontroller that can spare at least 48 K of RAM

Damit ist das meiste Arduino-unterstützten Gelumpe gleich mal eben 
raus...

Ich bin völlig sicher: das kann nicht das Ende der Fahnenstange sein. 
;o)

von Walter T. (nicolas)


Lesenswert?

Sieh an. Ich hatte den Github-Teil noch gar nicht gelesen. Das hatte ich 
mir für heute abend vorgenommen. Aber "minmal memory footprint" und 48K 
ist arg Etikettenschwindel.

48K im RAM wäre einmal 240*200*1 Byte. Das klingt gerade nach einmal 
Framebuffer mit indizierten Farben. Schade.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Walter T. schrieb:
> Sieh an... Schade.

Tja, gelegentlich ist es tatsächlich besser, sich eigene Gedanken zu 
machen als das Internet nach Kopierbarem abzusuchen.

Was schwebt dir eigentlich vor - so als Flash-Füllung? Etwas eher 
cartoon-ähnliches oder ein Hintergrundbild oder noch was anderes?

W.S.

von Johannes S. (jojos)


Lesenswert?

Zitat aus dem Artikel von Larry Bank:
1
I decided to set a max image width of 640 x 32-bpp (which can also be 2560 x 8-bpp). The total memory required for decoding images of up to this width (and any length) is around 46K. This seemed like a reasonable balance, but unfortunately excludes a lot of smaller embedded devices. This couldn't be avoided because the zlib structures require 39K of RAM by themselves.

Da wird der Speicherbedarf kaum zu optimieren sein. Wenn das Bild 
allerdings nur als Splashscreen beim Gerätestart dient, dann kann man 
den Speicher danach ja wieder anderweitig verwenden. Ein Bild das sich 
im Zeitlupentempo aufbaut sieht aber auch wie gewollt und nicht gekonnt 
aus, sowas würde ich auch nicht einbauen.

von Walter T. (nicolas)


Lesenswert?

Johannes S. schrieb:
> Wenn das Bild
> allerdings nur als Splashscreen beim Gerätestart dient [...]

Verlockend für den Entwickler, nervig für den Nutzer. Ich halte 
Splash-Screens mittlerweile für Antifeatures. Entweder sie sind zu kurz 
zum Lesen oder sie dauern so lange, dass sie bei jedem Gerätestart 
stören.

W.S. schrieb:
> Tja, gelegentlich ist es tatsächlich besser, sich eigene Gedanken zu
> machen als das Internet nach Kopierbarem abzusuchen.

Meine BMP-Implementierung ist fertig und rockt. Siehe oben.

W.S. schrieb:
> Etwas eher
> cartoon-ähnliches oder ein Hintergrundbild oder noch was anderes?

Noch exotischer: Grafiken mit den Steckerbelegungen einblenden (da auf 
dem Gehäuse leider nur wenig Platz für Aufkleber ist). Ich ärgere mich 
regelmäßig, wenn ich "im Feld" Kabel konfektionieren muss und nur dafür 
der Laptop auf dem wackeligen Campingtisch oder der dreckigen Werkbank 
herumsteht.

Aber Hintergrundbild für den Info-Bildschirm ist auch angedacht. Wobei 
das gar nicht so einfach ist, eine Grafik zu entwerfen, die bei diesen 
Displays gut aussieht.

: Bearbeitet durch User
von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

Walter T. schrieb:
> Aber Hintergrundbild für den Info-Bildschirm ist auch angedacht. Wobei
> das gar nicht so einfach ist, eine Grafik zu entwerfen, die bei diesen
> Displays gut aussieht.

Naja - was gut aussieht, ist Geschmackssache.

Ich häng dir mal was dran - bloß um zu zeigen, was man mit (im Grunde) 
einfachen Mitteln selber machen kann. Der Kartenausschnitt ist nur rund 
131K groß und hat doch so etwa 1000x500 Pixel. Und entpacken geht recht 
einfach - ohne 46K an RAM.

Der Viewer ist für Windows.

W.S.

von Walter T. (nicolas)


Angehängte Dateien:

Lesenswert?

"QMFT" - sehr aussagekräftig.

Die Kompression ist nicht übel. Das sieht nach 16 Farben indiziert aus. 
BMP ist mit seiner primitiven RLE-Kompression da fast 40% größer. PNG 
fast 30% kleiner.

Bei mir wird der Speicherverbrauch der Karte allerdings auch mit ca. 2 
MB angesetzt (Task Manager Karte geladen/ungeladen).

: Bearbeitet durch User
von Horst M. (horst)


Angehängte Dateien:

Lesenswert?

Walter T. schrieb:
> Die Kompression ist nicht übel. Das sieht nach 16 Farben indiziert aus.
> BMP ist mit seiner primitiven RLE-Kompression da fast 40% größer. PNG
> fast 30% kleiner.

GIF mit 8 indizierten Farben kommt mit dem Beispielbild auf 72 KBytes.
Im Direktvergleich sind keine großen Unterschiede zum 16-Farben-Original 
erkennbar.

: Bearbeitet durch User
von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

Walter T. schrieb:
> "QMFT" - sehr aussagekräftig.

Was erwartest du? Etwa eine 4 stellige DIN-Nummer? Das Format ist kein 
am PC übliches Grafikformat.

Zum Gucken hier noch eine andere Landkarte.

W.S.

von Walter Tarpan (Gast) (Gast)


Lesenswert?

https://www.urbandictionary.com/define.php?term=QMFT

Und ich traue Dir nicht zu, den Terminus nicht zu kennen. So jung bist 
Du nicht.

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

Nachtrag:
Ich hatte später an diesem Zeugs noch etwas weiter gemacht, weil ich 
sowas für grafische Menüs benötigte. Ich hab hier auch mal was davon 
gepostet, aber das haben die Leute damals nicht kapiert. Stattdessen 
kamen Ansichten derart, daß man Bilder im 565 BMP Format bereits als 
"komprimiert" angesehen hatte. Nun ja...

Das Prinzip bei meinem Zeugs ist einfach: Es wird eine Palette verwendet 
und die Anzahl der Farben reduziert, was zum einen bei Icons und 
Grafiken überhaupt nicht stört (nur bei richtigen Bildern hat man da 
Probleme) und zum anderen die benötigte Bitbreite der Pixel reduziert. 
Wenn dann noch die Wertebereiche passend gewählt werden, so daß die 
Bitbreite für etwas mehr als für die Palettenindizes ausreicht, dann 
kann man den Überstand als Zähler für Wiederholungen nutzen. Das alles 
ist in Summe recht platzsparend und trotzdem leicht zu dekodieren. 
Obendrein hat man nur Bedarf an einigen wenigen Variablen im RAM und 
benötigt keinen großen Scratch-RAM.

Der momentane Ist-Stand ist noch verbesserungsfähig: Man könnte 
Bitbreite und Farbanzahl separat voneinander einstellen.

W.S.

von W.S. (Gast)


Lesenswert?

Walter Tarpan (Gast) schrieb:
> So jung bist
> Du nicht.

Höhö..

Anstatt zu frozzeln mach lieber was Schönes draus.

W.S.

von Walter T. (nicolas)


Lesenswert?

W.S. schrieb:
> Das Prinzip bei meinem Zeugs ist einfach: Es wird eine Palette verwendet
> und die Anzahl der Farben reduziert,

W.S. schrieb:
> dann
> kann man den Überstand als Zähler für Wiederholungen nutzen. Das alles
> ist in Summe recht platzsparend und trotzdem leicht zu dekodieren.

Okay, also indizierte Farben und umgekehrt polnische 
Lauflängenkodierung. Da kann ich mir gut vorstellen, dass das noch ein 
Stück effizienter als Lauflängenkodierung mit festen 4-Bit- oder 
8-Bit-Paketen mit Padding auf 4-Bytes-Grenzen je Zeile ist.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.