Geos Pixel Editor

    Hallo Rainer,

    Zitat von Rainer

    1. ReadBitmapFromFile liest auch transparente BMP 's unter Beibehaltung der Transparenz.


    Aktuell habe ich das Problem das WriteBitmapToFile die Maske nicht mit rausschreibt. Zumindest ist nach der Aktion WriteBitmapToFile -> Datei -> ReadBitmapFromFile die Maske weg (8-Bit-Bitmap; BF_MASK gesetzt). Eventuell habe ich aber auch irgendwo etwas vergessen. Das muss ich nochmal mit BinaryCompare ergründen, ob in der Datei mit/ohne Maske ein Unterschied feststellbar ist.

    Zitat von Rainer

    2. Es gibt sehr viele Versionen des Icon-Editors. Der Icon-Edito auf meiner (R-BASIC) Webseite sollte stabil laufen. Ich benutze ihn ständig.


    Okay, dann teste ich nochmal mit deiner Version.

    Zitat von Rainer

    3. Mit "In Datei speichern" schreibt der Icon-Editor die Bitmap als HugeArrary in eine VM-Datei, wobei der Kopfblock des HugeArray als Mapblock gesetzt wird. Aus GEOS-Sicht ist das die primitivste aller Varianten. Mit der VMFiles Library könntest du da rankommen, möglicherweise musst du aber Klimmzüge machen, weil, wenn ich mich recht erinnere, der Mapblock aus BASIC-Sicht nicht der aus SDK-Sicht ist. Das steht alles in der Doku.


    Mit der VM-Library habe ich mich die letzten Tage schon beschäftigt, als mir der Speicher zur GIF-Kompression ausging. Ich probiere das mal aus.


    Viele Grüße,
    Mario

    ..Hier komme ich nun auch langsam voran

    Nachdem ich das Thema schon vor einiger Zeit aufgrund der Komplexität ad acta gelegt hatte, habe ich mich nun nochmal tiefer damit beschäftigt: Es gibt im QuickBasic-Bereich zahlreiche antiquierte Code-Schnipsel für allerlei Funktionen und Probleme, welche man mit mehr oder weniger Aufwand nach R-BASIC portieren kann. Allerdings gibt es für die Ausgabe von GIF-Dateien nur einen einzigen sinnvollen Quellcode für QuickBasic. Und zwar den von Rich Geldreich aus dem Jahre 1992 (ja, der Mann hieß wirklich so :D ). Dieser Quellcode und die ganze Bitpopelei hat es wirklich in sich: Erst heute konnte ich alle Fehler in meiner R-BASIC-Portierung finden und ein regelkonformes GIF87A in 32x32px ausgeben. Das ganze braucht noch ziemlich viel Zeit und unterstützt noch keine Transparenz (erst mit GIF89A möglich) - aber der Anfang ist gemacht.
    Wie Rainer schon bemerkte, wird das Speichern dieses Formates mit in R-BASIC geschriebenen Code immer eine Weile dauern - aber ich finde das ist ein vertretbares Übel.

    PS:
    Falls der eine oder andere auch ab und zu mal per POKE und PEEK den R-BASIC-RAM bearbeitet: Ich habe mir für o.g. Problem eine kleine Hilfsprozedur geschrieben, welche den RAM-Inhalt im Stile eines Hex-Editors anzeigt. Wer Interesse daran hegt, bitte gern melden!

    Zitat von Rainer

    Den GIF-Decoder habe ich irgendwo in Netz gefunden und an GEOS angepasst. Einen Encoder habe ich nie versucht, die Algoithmen empfinde ich als ziemlich komplex. Aus heutiger Sicht muss man sehen, dass es in GEOS schon einen GIF Encoder gibt (für die Export-Funktion in GeoDraw). Der ist allerdings nicht perfekt, die Bilder sind z.T. pixelweise verschoben. Man müsste ihn also noch mal durchchecken oder gleich einen neuen schreiben. Und ich hatte damals auch keinen Zugriff darauf und ob und wie das aktuell geht, weiß ich nicht.

    Also jein, vom Prinzip her müsstes du wohl einen Encoder schreiben. Unter R-BASIC könnte das aber sehr langsam werden. Vielleicht findet sich ja ein anderer Weg.

    Wenn ich das richtig im Blick habe, klappt der GIF-Export beim Screen Dumper gut. Wenn hingegen GeoDraw-Grafik nach .GIF exportiert wird, bzw. ein ScreenShot aus der Zwischenablage in GeoDraw eingefügt und dann nach .GIF exportiert wird, werden horizontal und vertikal jeweils ein oder zwei weiße Pixelzeilen hinzugefügt.

    Der Export-Filter selber ist vielleicht in Ordnung, evtl. liegt der Fehler bei GeoDraw.

    Zitat von Bario

    ..Hier komme ich nun auch langsam voran

    Zitat von Bario

    Nachdem ich das Thema schon vor einiger Zeit aufgrund der Komplexität ad acta gelegt hatte, habe ich mich nun nochmal tiefer damit beschäftigt: Es gibt im QuickBasic-Bereich zahlreiche antiquierte Code-Schnipsel für allerlei Funktionen und Probleme, welche man mit mehr oder weniger Aufwand nach R-BASIC portieren kann. Allerdings gibt es für die Ausgabe von GIF-Dateien nur einen einzigen sinnvollen Quellcode für QuickBasic. Und zwar den von Rich Geldreich aus dem Jahre 1992 (ja, der Mann hieß wirklich so ). Dieser Quellcode und die ganze Bitpopelei hat es wirklich in sich: Erst heute konnte ich alle Fehler in meiner R-BASIC-Portierung finden und ein regelkonformes GIF87A in 32x32px ausgeben. Das ganze braucht noch ziemlich viel Zeit und unterstützt noch keine Transparenz (erst mit GIF89A möglich) - aber der Anfang ist gemacht.
    Wie Rainer schon bemerkte, wird das Speichern dieses Formates mit in R-BASIC geschriebenen Code immer eine Weile dauern - aber ich finde das ist ein vertretbares Übel.

    Echt beeindruckende R-BASIC-Programmierleistung! Lässt mich irgendwie vor Neid erblassen... :thumbup:

    Meine Befürchtung ist, dass der Export bei etwas größeren Grafiken doch seeehr langsam sein könnte.

    Vielleicht gibt es doch eine Möglichkeit, auf den vorhandenen Exportfilter zuzugreifen? Sollte man mal Falk zu dem Thema kontaktieren?

    Zitat von Mütze

    Meine Befürchtung ist, dass der Export bei etwas größeren Grafiken doch seeehr langsam sein könnte.

    Vielleicht gibt es doch eine Möglichkeit, auf den vorhandenen Exportfilter zuzugreifen? Sollte man mal Falk zu dem Thema kontaktieren?

    Ich bin nach Optimierung des Codes jetzt bei 3 Sekunden für ein 32x32px-Icon. Für die Zwecke des Pixel-Editors mit kleinen Bildabmessungen sollte das für's Erste reichen. Ich würde die resultierende Arbeitsunterbrechung dann auch mit "Hier wird noch jedes Pixel schonend von Hand kaltgepresst" schmücken. ;)
    Dennoch, und da gebe ich dir recht, kann es sich dabei nur um eine Quick&Dirty-Lösung für o.g. Zweck handeln - für größere Bilder oder gar Animationen benötigt man dann zwingend eine SDK-Library, welche idealerweise auf einer aktuellen Open-Source Grafik-Library basiert.

    Viele Grüße,
    Mario

    Zitat von Bario

    Dennoch, und da gebe ich dir recht, kann es sich dabei nur um eine Quick&Dirty-Lösung für o.g. Zweck handeln - für größere Bilder oder gar Animationen benötigt man dann zwingend eine SDK-Library, welche idealerweise auf einer aktuellen Open-Source Grafik-Library basiert.

    Vom Prinzip her gebe ich dir recht. Es war mir damals leider nicht möglich via GEOS API auf den Exportfilter zuzugreifen. Jetzt, das der Code offen verfügbar ist, sieht das möglicherweise anders aus, aber ich will da auf gar keine Fall irgend etwas versprechen, ich behalte es allerdings im Hinterkopf. Das Problem mit "aktuellem" OpenSource-Code ist, dass er sich nicht um die Speicherlimits von GEOS kümmert. Wenn die 1 MB Speicher brauchen fordern sie ihn einfach an. Man müsste also z.B. alten DOS-Code benutzen.
    Alternativ käme noch in Frage deinen R-BASIC Code in eine SDK-Library (also zurück nach C) zu portieren. Aber versprechen will ich nichts, derzeit hatte ich noch nicht einmal die Zeit das aktuelle Zeugs von Github auf meinen Rechner zu ziehen.
    Bario: wir können ja mal per PM reden.

    Rainer

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Zitat von Bario

    Ich bin nach Optimierung des Codes jetzt bei 3 Sekunden für ein 32x32px-Icon. Für die Zwecke des Pixel-Editors mit kleinen Bildabmessungen sollte das für's Erste reichen. Ich würde die resultierende Arbeitsunterbrechung dann auch mit "Hier wird noch jedes Pixel schonend von Hand kaltgepresst" schmücken. ;)

    Ja, stimmt, die Wartezeit ist noch völlig ok. Ein Haupteinsatzzweck wäre ja auch das Zeichnen von Icons. Ich freue mich schon und bin gespannt, wie schnell die App unter DOSBox läuft.

    Hallo Mario,

    habe es gerade ausprobiert, er hat sogar eine FLI-Datei geladen und das erste Bild angezeigt ;) Sehr gute Arbeit!
    Zwei Sachen dir mir aufgefallen sind:
    1. Wenn ich ein Bild laden will, das keine Palette hat, beendet sich das Programm. Warum? Ich würde dann die "Standard-Palette" aktivieren. Oder zumindest das Programm weiterlaufen lassen.
    2. Für größere Bilder ist der Vorschaubereich definitiv zu klein. Der Palettenbereich ist mir auch zu klein :)

    Gruß
    Rainer

    P.S Linien beginnt er immer links oben. Aber das fixt du bestimmt noch.

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Hallo Rainer,

    Zitat von Rainer

    habe es gerade ausprobiert, er hat sogar eine FLI-Datei geladen ...

    Sehr schön! :) Das habe ich noch nicht probiert. Aber er prüft alles mit GetImageInfo() und wenn es mindestens 1 Bild hat, wird es geöffnet.

    Zitat

    1. Wenn ich ein Bild laden will, das keine Palette hat, beendet sich das Programm. Warum? Ich würde dann die "Standard-Palette" aktivieren. Oder zumindest das Programm weiterlaufen lassen.

    Das ist definitiv kein normales Verhalten. Bilder, welche keine Palette haben? Also Truecolor 24-Bit? Hier sollte er sich hilfsweise aus einer 8-Bit-BitmapContent die Palette laden. Wenn dies aber z.B. eine 24-Bit-BMP-Grafik mit einer Maske ist, kann es zu Problemen kommen. Diese Kombination unterstütze ich nämlich noch nicht. Kannst du mir die Datei sonst einmal per Mail schicken?

    Zitat von Rainer

    2. Für größere Bilder ist der Vorschaubereich definitiv zu klein. Der Palettenbereich ist mir auch zu klein :)

    Das ist richtig. Ich habe den Fokus derzeit auf Grafiken bis ca. 48x30 gelegt, da auch die Performance bei größeren Grafiken noch verbesserungswürdig ist. Ich schau aber einmal, ob ich eine ausklappbare, größere Ansicht einbauen kann. Die Palette gefällt mir aktuell auch noch nicht - hier wird definitiv noch etwas dran gemacht.

    Viele Grüße,

    Mario

    Zitat von Bario

    Das ist richtig. Ich habe den Fokus derzeit auf Grafiken bis ca. 48x30 gelegt, da auch die Performance bei größeren Grafiken noch verbesserungswürdig ist. Ich schau aber einmal, ob ich eine ausklappbare, größere Ansicht einbauen kann. Die Palette gefällt mir aktuell auch noch nicht - hier wird definitiv noch etwas dran gemacht.


    Eigentlich mag ich keine Schwebepaletten (nennt man das so?). Vielleicht, weil es die großen GEOS-Programme damit übertreiben und man manchmal das ganze Display mit Dialogen gepflastert hat... ;)
    Im Fall deines Grafikprogramms kann ich mir aber sehr gut ein zusätzliches Fenster vorstellen, das die Farbpalette und die Vorschau aufnimmt. Dann hast du mehr Platz und der Nutzer schiebt es hin, wo es nicht stört.

    Ausserdem habe ich vorhin mal die Zeit gestoppt: Das Speichern der kleinen Testgrafik .BMP als GIF hat auf meinem alten Mac und DOSBox mit 60000 cycles ca. 22 Sek gedauert.

    Zitat von Mütze

    Eigentlich mag ich keine Schwebepaletten (nennt man das so?). Vielleicht, weil es die großen GEOS-Programme damit übertreiben und man manchmal das ganze Display mit Dialogen gepflastert hat... ;)
    Im Fall deines Grafikprogramms kann ich mir aber sehr gut ein zusätzliches Fenster vorstellen, das die Farbpalette und die Vorschau aufnimmt. Dann hast du mehr Platz und der Nutzer schiebt es hin, wo es nicht stört.

    Ich teste gerade eine Variante, die Palette unten an der Stelle (jedoch etwas größer) zu belassen und die Vorschaugrafik als extra Dialog auszuführen. Dieser ist mit einer ViewControl verbunden und unterstützt somit auch Zoom usw. Ich mag solche schwebenden Fenster auch nicht. Die Alternative wäre aber sehr viel graue Fensterfläche, wenn man nur kleine Grafiken bearbeitet - das sieht auch nicht schön aus und vergiftet die Kompaktheit der Oberfläche. Vorteil von diesem Dialog ist auch noch, dass man ihn zwischenzeitlich schließen kann, wenn man wirklich gerade keinen Platz hat.

    Zitat von Mütze

    Ausserdem habe ich vorhin mal die Zeit gestoppt: Das Speichern der kleinen Testgrafik .BMP als GIF hat auf meinem alten Mac und DOSBox mit 60000 cycles ca. 22 Sek gedauert.

    Für 48x30 scheint mir das doch recht lang. Weißt du zum Vergleich aus dem Kopf deinen Wert aus SPEED ? (Ich kann mit den 60000 Cycles nichts anfangen, da ich in keinem Emulator arbeite).

    Mario

    Zitat von Bario

    Ich teste gerade eine Variante, die Palette unten an der Stelle (jedoch etwas größer) zu belassen und die Vorschaugrafik als extra Dialog auszuführen. Dieser ist mit einer ViewControl verbunden und unterstützt somit auch Zoom usw. Ich mag solche schwebenden Fenster auch nicht. Die Alternative wäre aber sehr viel graue Fensterfläche, wenn man nur kleine Grafiken bearbeitet - das sieht auch nicht schön aus und vergiftet die Kompaktheit der Oberfläche. Vorteil von diesem Dialog ist auch noch, dass man ihn zwischenzeitlich schließen kann, wenn man wirklich gerade keinen Platz hat.

    Ich glaube, du findest da eine gute Lösung.

    Zitat von Mütze

    Ausserdem habe ich vorhin mal die Zeit gestoppt: Das Speichern der kleinen Testgrafik .BMP als GIF hat auf meinem alten Mac und DOSBox mit 60000 cycles ca. 22 Sek gedauert.

    Zitat von Bario

    Für 48x30 scheint mir das doch recht lang. Weißt du zum Vergleich aus dem Kopf deinen Wert aus SPEED ? (Ich kann mit den 60000 Cycles nichts anfangen, da ich in keinem Emulator arbeite).

    Speed liegt so um 2437. Auf meinem mac mini M1 siehts schon besser aus: Mit DOSBox und 100000 cycles waren es 13 Sek. Speed liegt dann bei 3980.

    Hi,

    Zitat von Bario

    Ich teste gerade eine Variante, die Palette unten an der Stelle (jedoch etwas größer) zu belassen und die Vorschaugrafik als extra Dialog auszuführen.


    Meine Idee wäre, die Palette dort zu belassen, aber doppelt so hoch zu machen. Dann hättets du auch mehr Platz für das Vorschaubild. Wenn das (jeweils) nicht reicht könnte man per Button oder Menü eine zusätzliche Dialogbox aktivieren.

    Gruß
    Rainer

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Hallo Mario,
    ich bin ja am wieder begeistert!
    beim Rumspielen sind mir drei simple, aber wichtige Dinge aufgefallen.
    1. Bei längeren Operataionen (z.B. drehen nach rechts) bekommt der Nutzer kein Feedback. -> Mindestens MarkBusy aufrufen, bessere noch einen App-modalen Dialog starrten "Bitte warten .... "
    2. Beim Drehen einer nichtquadratischen Bitmap wird entdweder das neue Format nicht angpasst, oder es ist nur ein Problem mit der Vorschau. Jedenfalls wird ein 128x196 Bild nicht zum 196x128 Bild. Beim Zurückdrehen ist es dann aber wieder OK. Irgendwie seltsam.

    Ansonsten...
    - gefällt mir das Burger-Menü im Vorschaufenster :)
    - wünsche ich mir eine Voranzeigder Bildgröße im "Öffnen" Dialog
    - Ein Problembild schicke dir per Mail

    Die Option "quantisieren" finde ich sehr spannend. Konnte sie aber nicht testen.

    Sehr gute Arbeit!

    Gruß
    Rainer

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Hallo Rainer,

    Langsam wird der Code echt lang und komplex. Ich hoffe die Fehlerchen halten sich diesmal trotzdem in Grenzen.

    Zitat von Rainer

    1. Bei längeren Operataionen (z.B. drehen nach rechts) bekommt der Nutzer kein Feedback. -> Mindestens MarkBusy aufrufen, bessere noch einen App-modalen Dialog starrten "Bitte warten .... "

    Dies wird aktuell nur durch "Transformieren..." in der Statusleiste signalisiert. Ein Markbusy gehört da aber auf alle Fälle noch rein. Gerade bei größeren Bildern mit Transparenz dauert es sicher mitunter sehr lang. Performancetechnisch sind die 4 Funktionen aber auch noch optimierbar.

    Zitat von Rainer

    2. Beim Drehen einer nichtquadratischen Bitmap wird entdweder das neue Format nicht angpasst, oder es ist nur ein Problem mit der Vorschau. Jedenfalls wird ein 128x196 Bild nicht zum 196x128 Bild. Beim Zurückdrehen ist es dann aber wieder OK. Irgendwie seltsam.

    Das ärgert mich jetzt, da dies eines der aufwendigeren Dinge bei den Dreh-Transformationen war und ich meinte dies ausgiebig getestet zu haben. ;(
    Hast du vor dem Transformieren den Bildbereich selektiert oder nicht?
    Je nachdem ob oder ob nicht werden unterschiedliche Methoden angewandt.

    Zitat von Rainer

    Ansonsten...
    - gefällt mir das Burger-Menü im Vorschaufenster :)
    - wünsche ich mir eine Voranzeigder Bildgröße im "Öffnen" Dialog
    - Ein Problembild schicke dir per Mail

    Die Idee von Bernd fand ich ja mega. :thumbup: Ich musste das einfach übernehmen. Gerade bei so kompakten Dialogen macht so ein Hamburger-Menü richtig was her.

    Die Infos aus der GraphicInfoStruct kann ich in den Öffnen-Dialog mit implementieren, kein Problem. Hab da aber auch noch eine Besonderheit gefunden, welche ich dir mal noch per Mail zukommen lasse.

    Den Rest, insbesondere das Paletten-Problem schaue ich mir die Tage mal an.

    Viele Grüße,
    Mario

    Hallo Mario,

    Zitat von Bario

    Dies wird aktuell nur durch "Transformieren..." in der Statusleiste signalisiert.


    Ja, das ist mir dann später auch aufgefallen. Ein App-Modaler Dialog hat noch den Vorteil, dass der Nutzer den Rest des Programms nicht bedienen Kann. Sonst klickt er noch 2x auf Drehen (weil er glaubt es geht nicht) und dass macht das Programm dann auch ... anschließend.

    Zitat von Bario

    Das ärgert mich jetzt, da dies eines der aufwendigeren Dinge bei den Dreh-Transformationen war und ich meinte dies ausgiebig getestet zu haben. ;(
    Hast du vor dem Transformieren den Bildbereich selektiert oder nicht?


    Nein, einfach nur das Bild geladen. Offensichtlich dreht er nur den mittleren quadratischen Teil. S. Anhang.

    Gruß
    Rainer

    1. Tolle Programmierleistung, Mario. :)

    2. Zumindest für die "Objekt spiegeln"-Icons gäbe es auch Icons in GeoDraw.

    3. Für das Icon des Hamburger-Menüs hat sich nach einigem Ausprobieren eine Größe von 24x10 bei mir als praktisch herausgestellt. Das fügt sich unter der Motif- und ISUI-Oberfläche halbwegs harmonisch in die Titelleiste ein.
    [size=10]
    [/size]
    Falls du die Icons verwenden möchtest:[size=10] [/size]

    [size=10]
    [/size]
    [size=10]
    [/size]

    Hallo zusammen,

    Die von Rainer entdeckten Bugs, was das Transformieren von Grafiken mit unterschiedlichen Seitenlängen angeht, sind jetzt behoben.
    Durch das Setzen der neuen Seitenlängen ging auch die Paletteninformation verloren, was ebenfalls behoben wurde.
    Weiterhin wurde durch einen Rundungsfehler bei "ungeraden" Selektionen und stätigem Drehen in eine Richtung ein Fortbewegen der Selektion nach links unten oder rechts oben beobachtet. Dies habe ich jetzt durch abwechselndes auf- und abrunden behoben.

    Eine Sanduhr (Markbusy) signalisiert jetzt auch die Rechentätigkeit und blockiert weitere Nutzereingaben

    Weitere, mir bereits bekannte Bugs sind:
    - Kopieren/Einfügen von 8-Bit-Grafiken mit "Sonder"-palette nähert die Farben automatisch immer der Standardpalette an. Damit ist diese Funktion in Verbindung mit einer "Sonder"-palette unbrauchbar.

    - Drehen von 1-Bit-Grafiken war in der Vergangenheit instabil (KR-09)

    EDIT:
    Neue Version ist wieder auf Seite 1 zu finden!

    Viele Grüße,

    Mario

    Hallo Bernd,

    Zitat von Mütze

    1. Tolle Programmierleistung, Mario. :)

    2. Zumindest für die "Objekt spiegeln"-Icons gäbe es auch Icons in GeoDraw.

    3. Für das Icon des Hamburger-Menüs hat sich nach einigem Ausprobieren eine Größe von 24x10 bei mir als praktisch herausgestellt. Das fügt sich unter der Motif- und ISUI-Oberfläche halbwegs harmonisch in die Titelleiste ein.

    Danke dir. Ich hatte tatsächlich trotz 'customize Toolbars' nichts dergleichen in GeoDraw gefunden.
    Finde aber meine Kreationen fast ein bisschen schöner. Das Hamburger-Menü binde ich mal testweise ein. Macht natürlich Sinn, dieses im gleichen Format wie alle anderen Titelleisten-Buttons zu gestalten.

    Mario