Hallo Mal wieder zusammen :) Ich Stelle mir seit einiger Zeit die Frage wie man auf einem Display (st7735 etc.) RGB Bilder laden kann. Meine Ergebnisse haben meistens dazu geführt das die Dateien in irgendeiner Quelle abgelegt sein müssen und anschließend geladen werden müssen. Nun frage ich mich jedoch ob das wirklich sein muss? Pixel Grafiken im Monochrom zb. Können ja auch einfach als Array geladen werden. Gibt es Tools die ein 24bit BMP oder 16bit BMP in so ein Array umwandeln und eine bekannte Funktion einer bekannten lib die das Recht simpel umsetzt? Danke euch vorab für diverse Ideen :) Vom Auslesen würde ich einfach eine Drawpixel funktion nehmen und den Array Inhalt von 1bit pro Pixel zu 16bit pro Pixel ändern. Nur wie erzeugt man eine solche Datei? LG :)
Ronald S. schrieb: > Ich Stelle mir seit einiger Zeit die Frage wie man auf einem Display > (st7735 etc.) RGB Bilder laden kann. > Meine Ergebnisse haben meistens dazu geführt das die Dateien in > irgendeiner Quelle abgelegt sein müssen und anschließend geladen werden > müssen. > > Nun frage ich mich jedoch ob das wirklich sein muss? Pixel Grafiken im > Monochrom zb. Können ja auch einfach als Array geladen werden. Sicher kann man eine Bilddatei auch als ein Array in den Quellcode mit hinein nehmen. Dann verliert man allerdings an Flexibilität: Bei einer Änderung der Bilder muss man nun jedes Mal den Quellcode neu übersetzen. Wenn die Bilder einfach als Dateien vorliegen, die erst zur Laufzeit eingelesen werden, kann man die Dateien austauschen ohne den Quellcode ändern zu müssen. Das ist eigentlich die bessere Lösung - oder übersehe ich hier etwas?
So ein Tool lässt sich doch schnell in 20 Zeilen selber schreiben: Bild einlesen mit einer Lib. Fopen(Ausgabedatei); For-Y ; For X; Write Pixel.
Mark B. schrieb: > Das ist eigentlich die bessere Lösung - oder übersehe > ich hier etwas? Es ist aber auch aufwendiger, weil Du entweder ein Dateisystem brauchst oder zumindest Flashbereiche für die Bilder definieren mußt. Kann man natürlich machen und in der Buildchain dann die Bereiche zu einem Hexfile zusammenfassen, wenn man alles flashen will. Rechnet sich aber nur, wenn man die Dateien auch tatsächlich öfter ändert und z.B. die Sourcen gar nicht verteilt.
Der Linker kann theoretisch beliebige Dateien zum Ausführbaren Code des Programmes hinzu linken. Der Haken ist, dass man dann im C Quelltext nur deren Speicheradresse hat, aber nicht nicht Größe. Ich hatte mal damit experimentiert und es rasch wieder aufgegeben. Ich benutze (mit diversen Tools generierte) Arrays oder ein separates Filesystem auf Mikro-SD Karte oder einem anderen Flash Speicher.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Der Haken ist, dass man dann im C Quelltext nur > deren Speicheradresse hat, aber nicht nicht Größe. Man kann ja die Adresse sowohl vom Beginn als auch vom Ende übergeben, dann hat man die Größe als Differenz. Oder man packt an die erste Speicheradresse im Binärformat die Größe des folgenden Binärinhalts (mit Endianess aufpassen).
User schrieb: > The GIMP kann C-code header Dateien exportieren. Vorher mit GIMP ds Bild zu monochrom wandeln (Farbe-> entsättigen) und die Funktion Bild-Modus->indiziert antesten.
Steve van de Grens schrieb: > Der Linker kann theoretisch beliebige Dateien zum Ausführbaren Code des > Programmes hinzu linken. Der Haken ist, dass man dann im C Quelltext nur > deren Speicheradresse hat, aber nicht nicht Größe. Siehe Beitrag "Re: Image Converter - Bild zu c array konvertieren"
Nop schrieb: > Man kann ja die Adresse sowohl vom Beginn als auch vom Ende übergeben, > dann hat man die Größe als Differenz. Das war der Punkt, an dem ich scheiterte. Aber Rolf macht mir Mut: Rolf M. schrieb: > Siehe Beitrag "Re: Image Converter - Bild zu c array konvertieren" Danke Rolf. Beim nächsten Bedarf probiere ich das mal. Schön zu lesen, dass es doch so geht wie ich eigentlich wollte. > Oder man packt an die erste Speicheradresse im Binärformat die Größe des > folgenden Binärinhalts (mit Endianess aufpassen). Dafür müsste man die Dateien modifizieren, finde ich nicht so "sexy".
:
Bearbeitet durch User
Google mal nach "ImageConverter565" von Henning Karlsen. Ist problemlos in der Bedienung und erzeugt genau das, was dir vorschwebt. Nachtrag: Ist Bestandteil der Arduino Lib UTFT von RinkyDinky.
:
Bearbeitet durch User
Danke euch für die Tipps Image Konverter und Gimp:) Die Vorteile Bilder als Bilder zu nutzen sind mir klar jedoch ist das einfach nicht vorgesehen :) Pic ohne SD Karte oder ähnliches:) Danke euch! Ich werde Testen
> Danke euch für die Tipps Image Konverter und Gimp:) xv kann das im uebrigen auch. Damit hab ich sowas schon vor >20Jahren gemacht: https://de.wikipedia.org/wiki/XV_(Software) Laeuft uebrigens immer noch bei mir. :) Olaf
Ich habe zum Spass mal ein makefile mit python target erstellt. So ein Programm ist ja trivial. (Ist im Anhang, das Forum entfernt sonst die Tabs). "make irgendwas.png.c" und es erstellt eine C Datei daraus. Der Vorteil an einem kleinen python script ist, man kann es sich anpassen wie man die daten gerade am liebsten hätte, und es ist simpel.
Daniel A. schrieb: > Ich habe zum Spass mal ein makefile mit python target erstellt. So ähnlich hatte ich das mal mit einem Perl Script gemacht. Für solche Aufgaben mag ich Script Sprachen. Aber nächstes mal will ich dem Link von Rolf folgen, falls das klappt. Beitrag "Re: RGB Bitmap im MCU in C"
Ronald S. schrieb: > Ich Stelle mir seit einiger Zeit die Frage wie man auf einem Display > (st7735 etc.) RGB Bilder laden kann. > Meine Ergebnisse haben meistens dazu geführt das die Dateien in > irgendeiner Quelle abgelegt sein müssen und anschließend geladen werden > müssen. Tja, alle Bilder, die von einem Display angezeigt werden sollen, müssen irgendwo (und irgendwie) gespeichert und in den Puffer des Displays geladen werden. Gratulation dazu, daß du das erkannt hast. Es gibt hier in diesem Forum eine ganze Menge von Beiträgen, die sich genau damit befaßt haben. Benutze einfach mal die Suchfunktion. W.S.
W.S. schrieb: > Ronald S. schrieb: >> Ich Stelle mir seit einiger Zeit die Frage wie man auf einem Display >> (st7735 etc.) RGB Bilder laden kann. >> Meine Ergebnisse haben meistens dazu geführt das die Dateien in >> irgendeiner Quelle abgelegt sein müssen und anschließend geladen werden >> müssen. > > Tja, alle Bilder, die von einem Display angezeigt werden sollen, müssen > irgendwo (und irgendwie) gespeichert und in den Puffer des Displays > geladen werden. Gratulation dazu, daß du das erkannt hast. > > Es gibt hier in diesem Forum eine ganze Menge von Beiträgen, die sich > genau damit befaßt haben. Benutze einfach mal die Suchfunktion. > > W.S. Glaub mir die hab ich benutzt. Und an dieser sei geäußert der Knackpunkt ist das ich kein Bitmap Puffern wollte. Bitte Erst lesen. Danke. So nun zu den nützlichen Beiträgen :) @olaf KV Werd ich mir auf jedenfall auch Mal anschauen. Und auch Vielen Dank für die Bereitstellung deines Skripts @Daniel. Kam Heute leider noch nicht zu Gimp und dem converter. An sich ja ist so ein kleines Programm schnell geschrieben vermutlich in Nähe zu jeder Sprache. Aber da fehlen mir einfach die Kenntnisse wie genau Bilddaten kodiert sind 😅 kurzum ich würde ewig brauchen. LG
Ronald S. schrieb: > der Knackpunkt ist das ich kein Bitmap Puffern wollte. An dieser Stelle setzen die Nextion Displays, denen der Mikrocontroller nur Befehlen muss, welches Bild wo erscheinen soll. Aber die Bilder selbst sind im Display (bzw. einer Speicherkarte am Display) gespeichert, so dass es sie selbst laden kann.
Steve van de Grens schrieb: > Ronald S. schrieb: >> der Knackpunkt ist das ich kein Bitmap Puffern wollte. > > An dieser Stelle setzen die Nextion Displays, denen der Mikrocontroller > nur Befehlen muss, welches Bild wo erscheinen soll. Aber die Bilder > selbst sind im Display (bzw. einer Speicherkarte am Display) > gespeichert, so dass es sie selbst laden kann. Das finde ich auch recht genial, habe ich im 3D Drucker. Allerdings ist das stets mit 2x flashen verbunden LG
Nur monochrome Grafik auf einem RGB TFT ist aber nur eine drittelschöne Lösung. Und eine Bitmap per DrawPixel zu zeichnen ist sehr lahm: da wird in jedem Aufruf mit 'set address window' der Schreibzeiger im Graphic Controller gesetzt, dafür werden bei einem ST/ILI Controller 11 Byte und dann der Pixelwert gesendet, also mehr Overhead als Nutzdaten. Der GC hat aber ein Autoincrement und man braucht das 'set address window' nur einmal aufrufen und dann die Pixel nacheinander hinterher feuern. Die 'bekannten' Libs haben dafür eine Transfer Bitmap Funktion die genau das macht. Effizient geht das mit DMA, man sollte da einfach einen µC nehmen der das hat und auch nicht mit Speicher geizen. Die STM32 haben da sogar einen speziellen DMA der noch Formate konvertieren kann.
:
Bearbeitet durch User
zur Suche im Forum: Ronald S. schrieb: > Glaub mir die hab ich benutzt. > Und an dieser sei geäußert der Knackpunkt ist das ich kein Bitmap > Puffern wollte. Bitte Erst lesen. Danke. So, der Knackpunkt ist, daß du deine Bilder nirgendwo speichern willst. Aha. Dann wird das Anzeigen derselben etwas schwieriger. Und wenn deine nirgendwo gespeicherten Bilder obendrein in einem Dateiformat vorliegen, was du in einem µC nur schwer dekodieren kannst, dann wird es nochmal etwas schwieriger. Also: Bitte erst nachdenken. Danke/Bittesehr. W.S.
J. S. schrieb: > Nur monochrome Grafik auf einem RGB TFT ist aber nur eine drittelschöne > Lösung. > Und eine Bitmap per DrawPixel zu zeichnen ist sehr lahm: da wird in > jedem Aufruf mit 'set address window' der Schreibzeiger im Graphic > Controller gesetzt, dafür werden bei einem ST/ILI Controller 11 Byte und > dann der Pixelwert gesendet, also mehr Overhead als Nutzdaten. Der GC > hat aber ein Autoincrement und man braucht das 'set address window' nur > einmal aufrufen und dann die Pixel nacheinander hinterher feuern. Die > 'bekannten' Libs haben dafür eine Transfer Bitmap Funktion die genau das > macht. > Effizient geht das mit DMA, man sollte da einfach einen µC nehmen der > das hat und auch nicht mit Speicher geizen. Die STM32 haben da sogar > einen speziellen DMA der noch Formate konvertieren kann. Ja ich könnte auch einen HDMI Bildschirm an ein RasPi anschließen oder besser meinen Fernseher an einen PC. Aber ich habe nun mal diese Hardware mit der ich das bewerkstelligen wollte. Was ist ein GC? DMA hätte ich sogar ... Sorry aber bei "nimm doch einfach was anderes" das triggert mich dann würd ich ja nicht Fragen ^^
W.S. schrieb: > zur Suche im Forum: > Ronald S. schrieb: >> Glaub mir die hab ich benutzt. >> Und an dieser sei geäußert der Knackpunkt ist das ich kein Bitmap >> Puffern wollte. Bitte Erst lesen. Danke. > > So, der Knackpunkt ist, daß du deine Bilder nirgendwo speichern willst. > Aha. Dann wird das Anzeigen derselben etwas schwieriger. Und wenn deine > nirgendwo gespeicherten Bilder obendrein in einem Dateiformat vorliegen, > was du in einem µC nur schwer dekodieren kannst, dann wird es nochmal > etwas schwieriger. > > Also: Bitte erst nachdenken. Danke/Bittesehr. > > W.S. Der Knackpunkt ist ist möchte ein eingebettetes System OHNE externen speicher. Die einzige Option wäre ein zusätzlicher flash Memory aber da bekomme ich das Bild auch nicht ohne weiteres drauf. Also erkläre mir doch wie ich ein 16bit BMP in C nehme. Soll ich's Mal per drag and drop in den Editor ziehen??
Es soll einfach geschlossen sein... Prinzipiell habe ich das alles mit dem von Georg genannten Imagekonverter hinbekommen. Das Problem ist nur das mit jetzt der Speicher ausgeht... Kann man diesen intern irgendwie direkt erweitern? Module müsste man ja erst ansteuern kann also nicht in den Quellcode... Danke für die hilfreichen Beiträge:)
Du schriebst ja nicht mal welche MCU du hast. Und Farb TFT und wenig Speicher ist einfach ein Fehler im Design.
J. S. schrieb: > Und Farb TFT und wenig > Speicher ist einfach ein Fehler im Design. Es sei denn, das alle Ausgaben algorithmisch erzeugt werden, à la Mandelbrotmenge.
Ronald S. schrieb: > Das Problem ist nur das mit jetzt der > Speicher ausgeht... Kann man diesen intern irgendwie direkt erweitern? Wie stellst du dir das vor? Willst du den Chip auf sägen und etwas einlöten? Oder willst du ihn mit Blumendünger wachsen lassen? Externe Speicher wolltest du ja nicht.
:
Bearbeitet durch User
Nimm doch einfach virtuellen Speicher. Das macht Windows genauso. Und Seagate verkauft immer noch Festplatten. In Komination ist diese Technik seit 30 Jahren bewährt.
Ronald S. schrieb: > Prinzipiell habe ich das alles mit dem von Georg genannten > Imagekonverter hinbekommen. Das Problem ist nur das mit jetzt der > Speicher ausgeht... Kann man diesen intern irgendwie direkt erweitern? Wie soll das denn gehen? Wenn es von deinem µC keine Variante mit mehr Speicher gibt, wirst du entweder mit dem vorhandenen Speicher auskommen oder einen externen anschließen müssen. Eine andere Option gibt es nicht.
Für Windows 95 gab es mal Softram zum Speicher verdoppeln, das hilft hier bestimmt auch.
Wenn du zu wenig Speicher hast, dann nimm halt komprimierte Bilder. PNG, JPG. was auch immer. Musst du halt einen kompakten Decoder finden.
Ich dachte wie gesagt an einen Flashbaustein oä. Ich habe einen PIC18F45. Bis auf 1 Bild werden in der Tat alle Ausgaben mit Funktionen erzeugt. Aber halt nur in 1Farbe und 1bit Pixel. Ich habe nichts gegen zusätzlichen Speicher er soll nur fest sein. Bzw. Eine Einbahnstraße. Reinspeichern ja auslesen nein :)
J. S. schrieb: > Du schriebst ja nicht mal welche MCU du hast. Und Farb TFT und wenig > Speicher ist einfach ein Fehler im Design. Ja das wird mir auch kein 2. Mal mehr passieren 😅
Ronald S. schrieb: > Ich habe einen PIC18F45. Wie viele Pins sind denn noch frei verfügbar. Flash gibt es auch mit I2C und SPI-Schnittstelle. Brauchst dann eben noch ein separates Programm, um erstmal den Flash mit dem Bild zu beschreiben und natürlich eine Leseroutine.
Ronald S. schrieb: > Reinspeichern ja auslesen nein :) Das ist doof, falls Dein Programm das Bild anzeigen können soll - dazu müßte es den wohl lesen. Wenn Du allerdings einen Ausleseschutz gegen unbefugtes Auslesen meinst, ist das leicht zu lösen, sofern die eigentliche Firmware auslesegeschützt ist. Dann speicherst Du nämlich im externen, ungeschützten Speicher eine verschlüsselte Version des Bildes, wobei der Schlüssel in der geschützten Firmware ist. Auch Mitlesen auf dem Bus hilft dann nichts, weil ja nur der verschlüsselte Inhalt übertragen wird. Allerdings wirst Du das Bild ja irgendwann mal anzeigen wollen, und spätestens dort könnte man dann wieder auf dem Display-Bus mitlesen - oder es einfach vom Display abphotographieren.
Ronald S. schrieb: > Ich dachte wie gesagt an einen Flashbaustein oä. Ich glaube, wir haben unterschiedliche Vorstellungen davon, was bei einem µc "intern" und "extern" heißt. Ein Flashbaustein ist für mich extern, denn ich muss ihn von außen an den µC anschließen. Du scheinst unter "extern" eher sowas wie eine SD-Karte mit einem Filesystem zu verstehen. Bernd schrieb: > Ronald S. schrieb: >> Ich habe einen PIC18F45. > Wie viele Pins sind denn noch frei verfügbar. > Flash gibt es auch mit I2C und SPI-Schnittstelle. > Brauchst dann eben noch ein separates Programm, um erstmal den Flash mit > dem Bild zu beschreiben und natürlich eine Leseroutine. Er hat ja schon geschrieben, dass das wohl aus irgendeinem Grund nicht geht: Ronald S. schrieb: > Module müsste man ja erst ansteuern kann also nicht in den Quellcode... Nop schrieb: > Ronald S. schrieb: >> Reinspeichern ja auslesen nein :) > > Das ist doof, falls Dein Programm das Bild anzeigen können soll - dazu > müßte es den wohl lesen. Dachte ich mir auch. Ansonsten vielleicht dieser hier: https://repeater-builder.com/molotora/gontor/25120-bw.pdf
Angehängte Dateien:
-
tasse_tee.jpg
9 KB
Ronald S. schrieb: > Also erkläre mir doch wie ich ein 16bit BMP in C nehme. Soll ich's Mal > per drag and drop in den Editor ziehen?? Also, wenn sich deine Künste auf drag&drop oder auf copy&paste konzentrieren, dann wird's schwierig für dich. Ich hatte hier in diesem Forum schon mal Programme und Beispiele und Quellstücke gepostet, womit man durch Farbreduktion, Palettenbenutzung und Bitstreamtechnik seine Bilder in den µC hineinkriegt und mit der Dekodierung keinen dollen Aufwand treiben muß. Aber offenbar ist dir selbst das Suchen im Forum zu unbequem, du willst es in mundgerechten Happen zugeworfen kriegen. So, zum schnuppern hier eine Tasse Tee in C. Alles weitere suchst oder erarbeitest du dir selber. W.S.
W.S. schrieb: > Ronald S. schrieb: >> Also erkläre mir doch wie ich ein 16bit BMP in C nehme. Soll ich's Mal >> per drag and drop in den Editor ziehen?? > > Also, wenn sich deine Künste auf drag&drop oder auf copy&paste > konzentrieren, dann wird's schwierig für dich. > > Ich hatte hier in diesem Forum schon mal Programme und Beispiele und > Quellstücke gepostet, womit man durch Farbreduktion, Palettenbenutzung > und Bitstreamtechnik seine Bilder in den µC hineinkriegt und mit der > Dekodierung keinen dollen Aufwand treiben muß. Aber offenbar ist dir > selbst das Suchen im Forum zu unbequem, du willst es in mundgerechten > Happen zugeworfen kriegen. > > So, zum schnuppern hier eine Tasse Tee in C. Alles weitere suchst oder > erarbeitest du dir selber. > > W.S. Da bin ich tatsächlich weiter als du. Den 16 Bit Code für das Bild lese ich mit schleifen direkt ein. Eine Dekodierung der Farben ist daher nicht notwendig Mein Problem liegt darin das das Char Array des Bildes mehr Speicher im Code verbraucht als ich noch habe. Auf wenn ich auf 8 oder 4 Bit runter gehe und die Farben entsprechend Kürze komme ich mit dem verbleibenden Speicher leider nicht aus :/ Und nein von copy Paste bin ich inzwischen weg funktioniert eh meistens nicht oder kaum xD Dennoch danke :)
Ronald S. schrieb: > Mein Problem liegt > darin das das Char Array des Bildes mehr Speicher im Code verbraucht als > ich noch habe. Dann entweder andere Hardware nehmen, also mit mehr Speicher, oder sofern vorhanden, spezielle Eigenarten des Bildmaterials ausnutzen. Beispielsweise Dialoge, Menüs und dergleichen speichert man nicht komplett als Bilder ab, sondern nur die Hintergründe, falls man die nicht sogar algorithmisch erzeugen kann, und die Schrift im Vordergrund erzeugt man on the fly, wozu man nur die Bitmaps der einzelnen Zeichen speichern braucht. Daß man bei embedded-Anwendungen tatsächlich total willkürliche Photos einblendet, ist nämlich ziemlich selten.
Nop schrieb: > Ronald S. schrieb: >> Mein Problem liegt >> darin das das Char Array des Bildes mehr Speicher im Code verbraucht als >> ich noch habe. > > Dann entweder andere Hardware nehmen, also mit mehr Speicher, oder > sofern vorhanden, spezielle Eigenarten des Bildmaterials ausnutzen. > > Beispielsweise Dialoge, Menüs und dergleichen speichert man nicht > komplett als Bilder ab, sondern nur die Hintergründe, falls man die > nicht sogar algorithmisch erzeugen kann, und die Schrift im Vordergrund > erzeugt man on the fly, wozu man nur die Bitmaps der einzelnen Zeichen > speichern braucht. > > Daß man bei embedded-Anwendungen tatsächlich total willkürliche Photos > einblendet, ist nämlich ziemlich selten. Jep mache ich es bisher auch. Allerdings sind tiefen Effekte ziemlich schwierig Algorithmisch zu erzeugen. Ich würde mir davon einfach eine schönere Darstellung erhoffen. Aber da führt wohl nichts am großen Speicher vorbei:) Andere Frage am Rande kann mir jemand gaaaanz grob sagen wie Bildschirme mit 10 16 etc. Pins arbeiten? Lg
Angehängte Dateien:
-
klein_jar_tft.jpg
17 KB
Georg G. schrieb: > Google mal nach "ImageConverter565" nur manchmal erwischt man TFT die nicht RGB sind sondern RBG dann muss man Bytes swappen und ggffs. mappen. ach ich mag es wenn am ESP32 nichts verdrahtet werden muss klein_jar in SW
Angehängte Dateien:
Joachim B. schrieb: > ach ich mag es wenn am ESP32 nichts verdrahtet werden muss klein_jar in > SW besseres Foto, das Handy ist doch besser als die WebCam
Ronald S. schrieb: > Andere Frage am Rande kann mir jemand gaaaanz grob sagen wie Bildschirme > mit 10 16 etc. Pins arbeiten? Link? Datenblatt?
Hoffentlich werden die Bilder zuerst auf 1 BPP reduziert und dann gespeichert. In 16 BPP im Controller ablegen und dann zur Laufzeit dekodieren wäre üble Verschwendung. Ob sich 1 BPP noch komprimieren lässt, das hängt vom Inhalt ab. Bei Grafiken mit großen Flächen bringt RLE vielleicht etwas, Bilder mit Graustufen durch Dithering werden damit eher aufgebläht.
Wer schon Probleme hat, Binärdaten in ein C-Array zu verwandeln, braucht ganz sicher erstmal keine Datenkompression...
Beitrag #7350089 wurde von einem Moderator gelöscht.
Also irgendwie komprimieren wird er es schon müssen, wenn er nicht mehr Speicher nutzen kann. Eventuell könnte QOI eine simple Lösung sein: https://qoiformat.org/qoi-specification.pdf Das Video hier finde ich auch noch recht gut: https://www.youtube.com/watch?v=EFUYNoFRHQI&t=1411s Das Format ist recht neu, nicht ganz so gut wie PNG, aber extrem simpel. Mit imagemagic ab 7.1.0-20 kann die Dinger konvertieren: "convert image.png image.qoi" Oder mit ffmpeg ab version 5.1: "ffmpeg -i image.png image.qoi" (anzeigen geht mit "ffplay image.qoi"). Alternativ, in debian testing und unstable ist auch schon ein tool drin, mit dem man die erstellen kann: https://packages.debian.org/search?keywords=qoi&searchon=names&suite=all§ion=all "qoiconv image.png image.qoi" Also einfach mal die Bilder konvertieren und schauen, ob deine Bilder damit anständig komprimieren. Falls es Photos sind dürfte es etwas komplexer werden, die werden von QOI und PNG nicht gut komprimiert. Für die braucht man schon was mit FTs.
:
Bearbeitet durch User
Ich habe jetzt auch mal noch einen QOI Decoder gemacht. Ist sehr ähnlich wie der Referenzdecoder heraus gekommen, macht ja auch sinn. Ist im Anhang, ich stelle des hiermit unter der MIT Lizenz zur Verfügung. 100 Zeilen im .c File, 33 Zeilen im .h File. Mein Decoder hat den ganzen state in einem struct. Dadurch kann man das stückchenweise dekodieren. Am Anfang initialisiert man struct qoi_decoder mit QOI_DECODER_INIT(datei_als_unsigned_char_array). Dann ruft man qoi_decode() auf. Dort gibt man das qoi_decoder srtuct mit, das Ausgabearray, und wie viele Pixel man will. Braucht man die nächsten paar Pixel, einfach nochmal aufrufen. Und wenn man 0 als Output Array angibt, überspringt es die Pixel. Wenn man es geschickt anstellt, wann man Pixel liest und wann / wievielte man überspringt, kann man eigentlich beliebige Ausschnitte aus dem Bild ausschneiden, usw. Das Ausgabeformat kann man in der qoi_output_store Funktion anpassen. Auf meinem PC ist dieses 272 Bytes gross. 256 Bytes sind diese Lookup Tabelle für vergangene Pixel. Wäre der Alpha Kanal nicht, käme man dort mit nur 192 Bytes aus (64 3 statt 64 4). Das ist sehr einfach anzupassen, aber dafür müsste man das Format und den Algorithmus anpassen, weil der Tabellenindex ein Hash aus den Farbkomponenten, inklusive Alpha Kanal, ist, selbst wenn das Ausgabebild gar ein Alpha hätte, und dann könnte man vorhandene Encoder nicht mehr verwenden... Alpha wird sowieso nicht gut komprimiert, der ist nicht teil der diff & luma OPs, damit machen Schattengradienten usw. keinen Spass. Andererseits, sind 256 Bytes für die Lookuptabelle, bei weitem besser als die bis zu ~30KB die man bei PNG beim dekodieren für das LZ77 Zeugs braucht. Ein Beispiel zum Dekodieren eines QOI nach BMP ist auch noch mit dabei. Compilieren:
1 | gcc -std=c11 -Wall -Wextra -pedantic -Werror -Os -ffunction-sections -fdata-sections -I. dpa-qoi.c qoi2bmp.c -o qoi2bmp |
QOI => BMP Konvertieren:
1 | ./qoi2bmp <image.qoi >image.qoi |
QOI => BMP und Anzeigen:
1 | ./qoi2bmp <image.qoi | okular - |
Noch eine Sache, imagemagic / convert kann ich zum konvertieren nach QOI nicht empfehlen. Die Versionen, die es noch nicht können, speichern einfach das falsche Format...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.