Bei der Anzeige von Bildern auf Display am Mikrocontroller kommt es immer wieder vor, dass man die entsprechenden Bilder erst einmal in ein compiler-verträgliches Format konvertieren muss. Da ich (und auch andere Forenbenutzer) keine akzeptable Lösung für dieses Problem fand habe ich mich dazu entschlossen, selbst einen Konverter dafür zu schreiben. Diesen möchte ich euch nicht vorenthalten und stelle ihn euch zur Verfügung. Er kommt mit folgenden Bildformaten zurecht: - bmp - png - gif - jpeg Als Ausgabeformat kann man wählen zwischen - Schwarz/weis (1Bit/Pixel) - 8Bit Graustufen (8Bit/Pixel) - RGB444 (12Bit/Pixel) - RGB565 (16Bit/Pixel) - RGB666 (18Bit/Pixel) - RGB888 (24Bit/Pixel) Beim auszugebenden Array kann man vorgeben, wieviele Werte pro Zeile angezeigt werden sollen. Je nach Koordinatensystem des Displays am Mikrocontroller kann das Bild an x- und y-Achse gespiegelt werden. Falls jemand noch Verbesserungsvorschläge zu dem Konverter hat darf er sie mir gerne mitteilen. Ich bin gespannt auf eure Kritik
Marco G. schrieb: > Falls jemand noch Verbesserungsvorschläge zu dem Konverter hat darf er > sie mir gerne mitteilen. Ich bin gespannt auf eure Kritik Link zu einem Github-Repo würde ich mir angucken, aber eine exe-file? Warum das?
:
Bearbeitet durch User
> Link zu einem Github-Repo würde ich mir angucken, aber eine exe-file?
Die ist ganz harmlos. Verschlüsselt die Festplatte, versendet Spam, lädt
KiPos herunter, DoS't ein paar andere Rechner, rechnet an einem
verteilten Projekt für Biowaffen mit, attackiert Server im Internet,
versucht deinen router zu knacken um 0900-Rufnummern anzuwählen - aber
das alles ganz sauber im Hintergrund, du wirst es kaum bemerken!
Na das in Thread so schnell eskaliert hätte ich jetzt auch nicht erwartet... Mir persönlich geht es eher gegen den Strich, wenn ich mir unvollständigen Quellcode runterladen, compilieren und dann feststellen muss, dass noch irgendwelche Abhängigkeiten fehlen die ich mir mühselig zusammensuchen muss. Ich habe das Programm mit Qt geschrieben und aufgrund der vielen Abhängigkeiten gleich compiliert und als Installationsdatei zur Verfügung gestellt. Somit sollte es für jeden einfach handzuhaben sein. Wem das nicht zusagt kann sich auch gerne selbst etwas schreiben
Marco G. schrieb: > Wem das nicht zusagt kann sich auch gerne selbst etwas schreiben Du kannst aber schon zugeben, das das starten eines EXE-Files aus unklarer Quelle ein ziemliches Risiko darstellt.
Hallo Marco, Marco G. schrieb: > Wem das nicht zusagt kann sich auch gerne selbst etwas schreiben Schuldigung, aber Du hattest um Verbesserungsvorschläge und Kritik gebeten! Zwei Antworten würde ich jetzt auch nicht "Eskalation" nennen ;-) Ich finde so ein Tools nützlich. Allerdings, würde ich es mit einem command line interface bedienen wollen, um es in builds mit zu integrieren (ich gehe mal davon aus, dass Du Qt verwendest, weil das Tool eine GUI hat). mfg Torsten
Marco G. schrieb: > Als Ausgabeformat kann man wählen zwischen > - Schwarz/weis (1Bit/Pixel) > - 8Bit Graustufen (8Bit/Pixel) > - RGB444 (12Bit/Pixel) > - RGB565 (16Bit/Pixel) > - RGB666 (18Bit/Pixel) > - RGB888 (24Bit/Pixel) Und das für eine Anwendung im Mikrocontroller? Ach nö. Ich hatte hier vor langer Zeit schon mal sowas Ähnliches vorgestellt, damals ging es mir um das Darstellen von Map-Kacheln (Google, OSM usw.) auf einem µC. Die gewöhnlichen PC-Formate (GIF, PNG, JPG) sind in ihrer Dekodierung viel zu aufwendig für einen kleinen µC und BMP ist viel zu platzfressend. Deshalb hatte ich mir ein farbreduziertes Format ausgedacht, was zwar 16 bis 24 Bit Farbe prinzipiell kann, aber davon eben nur 48 verschiedene Farben pro Bild. Dafür läßt es sich leicht dekomprimieren und liefert bei eher plakativen Bildern ne gute Qualität. Wenn überhaupt, würde ich nur sowas verwenden, aber keine BMP's in 565 oder noch breiter. Auch die Gegenseite hatte ich hier schon mal gepostet, als Bildkonverter für die Lernbetty. Macht aus relativ beliebigen Bildern Graustufe mit 2 Bit pro Pixel. Nun, daß du hier ne EXE angeheftet hast, stört mich nicht (bin für sowas gerüstet), aber die EXE hättest du dir sparen können und stattdessen eine ordentliche Dokumentation deines Projektes als PDF posten können. Also was das soll, wie das im Detail funktioniert, welche Strukturen du vorgesehen hast, wie das zugehörige GDI aussehen soll und so weiter. W.S.
W.S. schrieb: > Und das für eine Anwendung im Mikrocontroller? > > Ach nö. Wenn man mit den Möglichkeiten nichts anzufangen weiß, ist das kein Grund, undankbar zu sein und in die "Verunglimpfung"-Posaune zu blasen. Hier teilt einer völlig uneigennützig sein Wissen - und wird angemacht! "Undank ist des ..."
Daten unter Linux oder vielleicht auch Cygwin in C Header umwandeln: xxd -i foo.bin > foo.h
Hi, ich finde das Projekt super, allerdings hätte ich auch Ängste die .EXE auszuführen. Ohne ein gesichertes System, mache ich sowas grundsätzlich nicht und ich rate jedem dazu es ebenfalls niemals zu machen. Hast du nicht vielleicht das ganze Projekt zum selber anschauen und kompilieren?
Mit der .c/.h Export Funktionalität von Gimp kommt man auch recht weit. Allerdings deckt das wahrscheinlich nicht alle Funktionen des Programms vom TO ab. Eine Kommandozeilenversion würde ich allerdings auch hilfreich zwecks Build-Automatisierung finden. Ansonsten: ein nützliches kleines Tool und Dank an den TO (mit der Hoffnung auf den Quellcode) für die Veröffentlichung. Gruß, kanadakruemel
Als ich diese Funktion benoetigte, habe ich Gimp verwendet.
Homer schrieb: > oder vielleicht auch Cygwin xxd lässt sich problemlos als native Win32-Anwendung übersetzen, so daß man keinen Linux-Emulationslayer braucht.
Marco G. schrieb: > Ich habe das Programm mit Qt geschrieben Falls du nicht gerade eine kommerzielle Qt-Lizenz hast, dann bist du allerdings dadurch nun sogar verpflichtet, es zumindest unter LGPL weiterzugeben. Dass man parallel zum Sourcecode eine .exe-Datei für diejenigen weitergibt, die 1.) damit überhaupt was anfangen können und 2.) keine Lust haben, es sich selbst zu compilieren, dagegen spricht allerdings nichts. Grundsätzlich finde ich ansonsten die Idee nicht so schlecht. Für pure 1-Bit-Grafiken genügt mir auch Gimp oder ImageMagick mit Ausgabe als XBM, aber gerade die gewichteten RGB-Grafiken brauchen immer irgendeine Verarbeitung.
Micha H. schrieb: > Eine Kommandozeilenversion würde ich allerdings auch hilfreich zwecks > Build-Automatisierung finden. +1 Ich baue sowas auch ganz gern ins Makefile des jeweiligen Projekts ein.
Hallo zusammen, vielen Dank für die vielen gut gemeinten Beiträge. Ich habe mir die ersten Kritiken zu Herzen genommen und das Programm als Kommandozeilentool weiterentwickelt. Zu einem späteren Zeitpunkt wird dann auch noch eine passende GUI dazu kommen, damit auch diejenigen, die mit Kommandozeilen nichts zu tun haben wollen auch auf ihre Kosten kommen. Desweiteren habe ich das Projekt als Quellcode bei Github eingestellt, sodass sich jeder überzeugen kann, dass es nicht an geheimen Biowaffenprojekten mithilft ;-) Hier der Link dazu: https://github.com/MG-Programmer/imageConverter
Jörg W. schrieb: > Marco G. schrieb: >> Ich habe das Programm mit Qt geschrieben > > Falls du nicht gerade eine kommerzielle Qt-Lizenz hast, dann bist du > allerdings dadurch nun sogar verpflichtet, es zumindest unter > LGPL weiterzugeben. > > Dass man parallel zum Sourcecode eine .exe-Datei für diejenigen > weitergibt, die 1.) damit überhaupt was anfangen können und 2.) keine > Lust haben, es sich selbst zu compilieren, dagegen spricht allerdings > nichts. > > Grundsätzlich finde ich ansonsten die Idee nicht so schlecht. Für > pure 1-Bit-Grafiken genügt mir auch Gimp oder ImageMagick mit Ausgabe > als XBM, aber gerade die gewichteten RGB-Grafiken brauchen immer > irgendeine Verarbeitung. Ich habe das Tool hauptsächlich dafür gebraucht, um Pixel im RGB444 Format platzsparend in einem byte-Array unterzubringen. Es werden hier immer 2 Pixel in 3 Byte gespeichert. So etwas ist dann mit Gimp nicht mehr möglich und deshalb habe ich es auch ursprünglich geschrieben. Da ich bestimmt nicht der einzige mit diesem Problem bin und auch schon viel Hilfe zu anderen Problemstellungen aus der Community bekommen habe dachte ich, dass man dieser auch mal etwas zurückgeben sollte.
So. Jetzt sind beide Projekte (command line tool und gui) als separate Projekte auf Github verfügbar. Ich freue mich auf weitere Anregungen und Kritik. https://github.com/MG-Programmer/imageConverter
Gibt es ein Ausgabeformat für 1 Bit, welches auf den KS0108 Displaycontroller zugeschnitten ist, also pro Byte 1x8 Pixel?
Mr. Claudius schrieb: > Gibt es ein Ausgabeformat für 1 Bit, welches auf den KS0108 > Displaycontroller zugeschnitten ist, also pro Byte 1x8 Pixel? Ja das ist mit meinem Programm auch möglich. Das Ausgabeformat ist dann "Mono". Ist dann schwarz/weiß und jedes Pixel benötigt 1 Bit => 8Pixel/byte
Undank ist des.. schrieb: > Wenn man mit den Möglichkeiten nichts anzufangen weiß, ist das kein > Grund, undankbar zu sein und in die "Verunglimpfung"-Posaune zu blasen. > Hier teilt einer völlig uneigennützig sein Wissen - und wird angemacht! Nee, mein Lieber, so ist das nicht, sondern: Wenn jemand sich was ausgedacht hat und dabei die Verhältnisse auf einem durchschnittlichen µC zu wenig bedacht hat, dann kommt dabei eben etwas heraus, was man nur schlecht gebrauchen kann, weil es einem den Speicher zustopft. Das ist der Kernpunkt und hier wird keiner "angemacht" (scheußliches Wort!), sondern in aller Ruhe auf diesen Punkt hingewiesen. Dabei gibt's dafür eine deutlich bessere Lösung. Aber man muß das eben wollen und nicht wie du von Verunglimpfung reden. W.S.
W.S. schrieb: > Nee, mein Lieber, so ist das nicht, sondern: Wenn jemand sich was > ausgedacht hat und dabei die Verhältnisse auf einem durchschnittlichen > µC zu wenig bedacht hat, dann kommt dabei eben etwas heraus, was man nur > schlecht gebrauchen kann, weil es einem den Speicher zustopft. Ich glaube Du hast nicht ganz verstanden, was Marco da gemacht hat. Er extrahiert aus gängigen Grafik-Formaten die Daten, befreit sie von Meta-Daten und liefert die Rohdaten in für Mikrocontroller optimierter Form. mfg Torsten
Marco G. schrieb: > Desweiteren habe ich das Projekt als Quellcode bei Github eingestellt, Ein Lob dafür. Sehr gut!
W.S. schrieb: > Verhältnisse auf einem durchschnittlichen µC Im Durchschnitt war der Dorfteich einen Meter tief … Was auf einem ATmega8 völlig untragbar ist, ist auf einem „durchschnittlichen“ ARM oft genug schon nur noch noise floor. Wenn man an einem Controller überhaupt irgendwelche Grafik betreiben will, dann wird man vermutlich nicht gerade die allerkleinsten dafür nehmen. Wenn man sich aber für eine Grafikausgabe entschieden hat, dann muss man irgendwie auch in der Lage sein, die Daten dafür im Programmcode unterzubringen. Einzige Ausnahme: man will nur pure Texte oder Linien zeichnen, dann braucht man natürlich keinerlei Bilddaten im Code. Bislang habe ich aber in allen Projekten, bei denen ein Grafikdisplay im Spiel war, in der Tat auch Bilddaten mit dabei gehabt.
W.S. schrieb: > Nee, mein Lieber, so ist das nicht, sondern: Wenn jemand sich was > ausgedacht hat und dabei die Verhältnisse auf einem durchschnittlichen > µC zu wenig bedacht hat, dann kommt dabei eben etwas heraus, was man nur > schlecht gebrauchen kann, weil es einem den Speicher zustopft. Gerade weil mir die Verhältnisse auf einem Mikrocontroller bekannt sind habe ich das Programm geschrieben. Wie weiter oben beschrieben packt er die Pixeldaten beim RGB444 Format platzsparend in 1,5Byte/Pixel und nicht wie andere in 2Byte und verschwende bei jedem Pixel 25%(4Bit). Ich habe es auch geschrieben, weil ich einen konkreten Anwendungsfall dafür habe und auf einem kleinen TFT mit 18Bit Farbtiefe Bilder ausgeben muss. Das Projekt läuft allerdings auch mit einem STM32L4 (ARM), sodass ich dafür genügend Resourcen habe. Dass Bilder den Speicher "zustopfen" liegt in der Natur der Sache. Um die Bilder auch auf einem kleinen Mikrocontroller verfügbar zu machen habe ich die Möglichkeit der Skalierung eingebaut, wobei die Farbtiefe auf bis zu 1Bit pro Pixel reduziert werden kann. Somit können Bilder auch auf einfachen, monochromen Grafikdisplays ausgegeben werden. Die Bilder werden in jedem Fall speicherplatzsparend in einem Array hinterlegt.
Marco G. schrieb: > Ja das ist mit meinem Programm auch möglich. Das Ausgabeformat ist dann > "Mono". > Ist dann schwarz/weiß und jedes Pixel benötigt 1 Bit => 8Pixel/byte Ich habe mich unklar ausgedrückt: meine Frage bezog sich nicht auf die Farbtiefe, sondern auf die Organisation der Pixel. Beim KS0108 werden immer 8 Pixel in Y-Richtung gleichzeit beschrieben, während der automatische Adressinkrement in X-Richtung geht, daher finde ich ein Format sinnvoll, bei dem die Bytes einfach der Reihe nach zum Display geschaufelt werden können (und alle 128 Bytes die Y-Adresse zu inkrementieren), ohne nach jedem Schreibvorgang X- und Y-Adresse neu setzen oder Pointer neu berechnen zu müssen.
Mr. Claudius schrieb: > Ich habe mich unklar ausgedrückt: meine Frage bezog sich nicht auf die > Farbtiefe, sondern auf die Organisation der Pixel. > Beim KS0108 werden immer 8 Pixel in Y-Richtung gleichzeit beschrieben, > während der automatische Adressinkrement in X-Richtung geht, daher finde > ich ein Format sinnvoll, bei dem die Bytes einfach der Reihe nach zum > Display geschaufelt werden können (und alle 128 Bytes die Y-Adresse zu > inkrementieren), ohne nach jedem Schreibvorgang X- und Y-Adresse neu > setzen oder Pointer neu berechnen zu müssen. Ja, das ist auch möglich. Das Tool verarbeitet die Pixel standardmäßig von link nach rechts und von oben nach unten und schreibt sie dementsprechend in das Array. Es ist hierbei möglich, sowohl die X- als auch die Y-Richtung zu ändern und somit den vom KS0108 benötigten Pixelstrom von oben nach unten und von links nach rechts zu erzeugen.
Angehängte Dateien:
-
Castillo.jpg
39 KB -
Castillo_200.bmp
170 KB -
Castillo_100.bmp
170 KB
Mr. Claudius schrieb: > Ich habe mich unklar ausgedrückt: meine Frage bezog sich nicht auf die > Farbtiefe, sondern auf die Organisation der Pixel. > Beim KS0108 werden immer 8 Pixel in Y-Richtung... Nein, das ist nicht das Thema einer Bild- Text- oder Grafikdarstellung, sondern es ist das Thema eines GDI. Es ist mit Sicherheit falsch, sich mit Grafikformaten auf eine ganz bestimmte Display-Art festzulegen. Stattdessen sollte man sich Gedanken machen über ein platzsparendes, also komprimiertes Format, das sich aber dann bittsehr ohne viel Aufwand zum Darstellen dekodieren läßt. Die üblichen Formate (JPG, PNG, GIF) sind für kleine µC ziemlich schlecht geeignet und BMP oder Artverwandtes ist einfach sehr platzaufwendig. Deshalb der Gedanke an die Reduzierung der im Bild verwendeten Farben auf ein verträgliches Maß - so daß man das Ganze passabel komprimieren kann - und dann selbige per Palette in die reale Farbe umsetzen. Marco G. schrieb: > Gerade weil mir die Verhältnisse auf einem Mikrocontroller bekannt > sind habe ich das Programm geschrieben. Wie weiter oben beschrieben > packt er die Pixeldaten beim RGB444 Format platzsparend in 1,5Byte/Pixel > und nicht wie andere in 2Byte und verschwende bei jedem Pixel 25%(4Bit). Das verstehe ich noch nicht als platzsparend. Du speicherst pro Pixel eben soviel Bit, wie dessen gewünschte Farbauflösung. Das ist im Prinzip BMP und ungenutzte Bitmuster sind vergeigt - und das ist eben nicht platzsparend, weil unkomprimiert. Wenn du tatsächlich echte Bilder in Echtfarbe darstellen mußt, dann sehe ich das ja ein, aber in den allermeisten Fällen hat man im konkreten Bild weniger als 2^Bitanzahl Farben - und wenn es denn doch so viele seien sollten, dann kann man ohne wirklich unerträgliche Qualitätseinbuße die Anzahl der Farben reduzieren. Ich häng dir mal was dran: Originalbild mit etwa 90000 Farben, dann als BMP, aber auf 200 Farben reduziert, dann BMP und auf nur 100 Farben reduziert. Es sind nur 8 Bit BMP's, also unkomprimiert und nicht in einem µC-gerechten Format. Man kann aber erkennen, daß schon bei 200 tatsächlichen Farben das Bild für einfache Anzeigezwecke völlig ausreichend ist. Tja - und bei diesen 200 Farben kann man das Ganze mit relativ einfachen Mitteln komprimieren. Ich hatte das damals so gemacht, daß ich mir eine Bitbreite ausgesucht habe, davon etwa 3/4 als mögliche Farben vorgesehen habe und den Rest für Wiederholungen vorgesehen habe. Bei den damaligen Kartenbildern waren das 6 Bit, davon 0..47 echte Farben (Paletteneinträge) und 48..63 für mögliche Wiederholungen. Bei 8 Bit und eher fotoartigen Bildern würde ich 0..240 für Farben vorsehen und 241..255 für die Anzahl von Pixelwiederholungen. Das läßt sich ausgesprochen leicht dekodieren und schafft eine dezente Kompression, die bei relativ gleichförmigen Bildern bis zu Faktor 8 schafft. Mal ein paar Zahlen (Karte vom gesamten Deutschland): Zoomlevel 8 = 1.8 MB, Zoomlevel 9 = 6.6 MB, Zoomlevel 10 = 21 MB bis hin zu Zoomlevel 13 = 701 MB (Die Zoomlevel entsprechen denen von Googlemaps, da sieht man bei Level 13 den Flughafen Tegel schon etwa drei Finger breit auf'm Laptop) Das ist insgesamt fast genauso komprimiert wie JPG. Aber leichter zu dekodieren - zum Preis der Reduzierung der pro Kachel vorhandenen Farben, nicht jedoch der darstellbaren Farbtiefe. W.S.
Ich werfe zum Vergleich mal das Image-Convert Tool von FTDI in die Runde: http://www.ftdichip.com/Support/Utilities.htm#EVEImageConverters Ja, okay, sicher, das ist erstmal für FT8xx, ist ja jetzt nur mal als Anregung gedacht was andere so machen. Interessant ist an dem das die Bilder ZLIB komprimiert werden, das spart kräftig Platz bei Bildern mit homogenen Flächen die man vorher auch vorzugsweise nur in .png verarbeitet hat um Kompressions-Artefakte zu vermeiden, so etwa für Icons. Mal abgesehen von den ganzen Formaten in die man noch runter-konvertieren kann. Mit der aktuellen Version 0.9.1 muss man aufpassen, die hat per Default Dithering an, damit werden die Bilder dann mal eben doppelt so gross wie sie sein müssten. So falls das jemand ausprobiert. Wobei, Beispiel und so, in dem Fall wird das Bild vom Grafik-Chip wieder entpackt, ich weiss jetzt nicht wie aufwändig das auf dem Controller selber zu implementieren wäre.
Torsten R. schrieb: > Ich finde so ein Tools nützlich. Allerdings, würde ich es mit einem > command line interface bedienen wollen, um es in builds mit zu > integrieren Gibt es alles bereits, z.B. convert aus dem ImageMagick Projekt: http://imagemagick.org/script/index.php Grafik-Format dann nach Gusto, z.B. XPM (C-Source). Auf kleinen µC angenehmer ist evtl. sowas wie Portable Anymap, dann man direkt im Binärformat einbinden und einfach auswerten kann: Wozu den Umweg über enie C-Quelle, wenn das Formal dermaßen einfach ist :-)) https://de.wikipedia.org/wiki/Portable_Anymap http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata
Johann L. schrieb: > Wozu den Umweg über enie C-Quelle, wenn das Formal dermaßen einfach ist Weil man Grafikformate schlecht in den Code linken kann? Klar kann man das auch über objcopy aus reinen Binärdateien tun, aber wirklich einfacher finde ich das auch nicht unbedingt. Außerdem ging es ihm ja auch und gerade um Sonderformate wie 12 Bit/Pixel, da bist du mit den Standardtools dann wirklich aufgeschmissen. Solange es ein XBM oder XPM tut, kann man natürlich auch Standarwerkzeuge nehmen.
Hallo , wie kann ich die kon. Bilder speicher ? bin im Happylab Salzburg habe eine Einschulung für die cnc gemacht (totaler Anfäger)vielen Dank Fritz
Hallo Marco, habe dein Programm runtergeladen und benutze es aktuell in einem Projekt. Es funktioniert super und hat mir die aufwendige Einarbeitung in Grafikformate ersparrt. Vielen Dank dafür.
Hallo Maco wäre der Aufwand groß eine Funktion für das asm Format einzufügen. .db
Moin, das Tool konvertiert zwar aber das Ergebnis ist für SiliconLabs WMB8920 mit DOG LCD unbrauchbar. Wie im Grunde jedes Tool, das ich bisher getestet habe. Silicon Labs liefert eine eigene Bibliothek zur Manipulation des LCD und die mitgelieferte Graphik wird auch angezeigt. Das Image für das mitgelieferte C Array wurde mit fntcvtr erstellt. Das Tool ist leider unter Windows 10 nicht dazu zu bewegen die Arbeit aufzunehmen. Denke der Kelch geht wohl nicht an mir vorbei tiefer als gewünscht in die Materie einzusteigen. Gruß GeraldR63
Danke für das Programm! Ich benutze es um bmp dateien in ein Arduino freundliches Dateisystem zu konvertieren, um schlussendlich ein ssd1306 OLED Display zu betreiben. Funktioniert unter Windows 10 64-bit super.
Finde das Tool ist eine echte Hilfe. Ich muss BMP Grafiken in Pixelgrafik (mono) für uc umwandeln. Leider ist da ein bug in der mono Ausgabe. Wenn ich eine einfache 8x8 oder 16x16 schwarz weiss .bmp grafik umwandle. ist das erste Byte in der Ausgabe falsch. Auch stimmt die Bytereihenfolge nicht. Ursprung Bit 1 vom Bild ist bei Deinem Programm unüblicherweise oben rechts und nicht oben links.
Henry schrieb: > Auch stimmt die Bytereihenfolge nicht. Ursprung Bit 1 vom Bild ist bei > Deinem Programm unüblicherweise oben rechts und nicht oben links. Hast Du etwa übersehen, dass Marco G. schrieb: > kann das Bild an x- und y-Achse gespiegelt werden. Gruss Chregu
Angehängte Dateien:
-
Hercule.bmp
350 KB -
Castillo33.bmp
170 KB
Henry schrieb: > Finde das Tool ist eine echte Hilfe. Ich muss BMP Grafiken in > Pixelgrafik (mono) für uc umwandeln. Ist das bei diesem Tool denn nicht dasselbe? Ich häng mal ein paar Dateien dran, falls das jemanden interessiert. Davon auch das weiter oben (damals) gezeigte Bild in mehreren Farbreduzierungen. Die Platzersparnis ggü. reiner Bitmap ist wie folgt: Original: 360x480, ca.90000 Farben, 518.440 Bytes Speicherbedarf als Bitmap. Reduziert auf 112 Farben: 80196 Byte Platzbedarf als .c Dito auf 33 Farben: 50786 Byte als .c Dito auf 19 Farben: 33794 Byte als .c Und das Ganze als 565 Farbgrafik, also 16 Bit breit. Ich hatte das mal vor einigen Jahren geschrieben, ob das auf Win10 läuft, hab ich nie getestet. W.S.
Beitrag #6756199 wurde von einem Moderator gelöscht.
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.