atari-home.de - Foren
Allgemeines => Atari - Talk => Thema gestartet von: tuxie am Mo 30.04.2018, 14:10:14
-
Hallo,
kennt jemand eine Möglichkeit ein normales jpg file so zu konvertieren das man es als icon verwenden kann ? ggf. für teradesk.
-
Hallo,
kennt jemand eine Möglichkeit ein normales jpg file so zu konvertieren das man es als icon verwenden kann ? ggf. für teradesk.
ORCS kann zwar kein jpg direkt laden, aber BMP oder GIF, dazu müsste es also konvertiert werden. Am besten dann gleich vorher die Anzahl der Farben reduzieren, ORCS hat zwar zum Teil die Funktion drin, ist aber keine Bild-Verarbeitung, da gibs wahrscheinlich bessere Tools ;)
-
Kann das Tool auch mehr Farben so das man z.b. Dateien bauen kann für Rechner mit höherer Farbtiefe ? Wo liegt da eigentlich das maximum des Dateiformats ?
-
Mit Papillon kannst Du Bildformate konvertieren, auch zwischen .JPG, .GIF oder .IMG und anderen, und dabei auch die Farbtiefe ändern.
Das Datei-Format .RSC könnte wohl noch viel mehr als die verfügbaren RCSs zulassen: Da liegt die Beschränkung afaik bei 256 Farben!
-
Icon Extract ist ein Tool speziell zum Konvertieren verschiedener Icon-Formate:
http://www.lafabrie.net/old/Atari/Index.htm
-
Die Links sind leider tot :(
-
Bei mir funktioniert der Link von @MJaap ohne Probleme.
-
...und hast Du das Programm auf der Seite laden können?
..z.B. diesen Link um Extract15.lzh runter zu laden?
http://www.lafabrie.net/old/Atari/Extract/T%E9l%E9chargement/Extract/EXTRACT15.LZH (http://www.lafabrie.net/old/Atari/Extract/T%E9l%E9chargement/Extract/EXTRACT15.LZH)
-
Die aktuelle Version habe ich nur auf Kurobox finden können:
ftp://kurobox.serveftp.net//utilities/icons/extract15.lzh
Hier ein Review der Version 1.0:
http://stcarchiv.de/stc2001/07/lbc-2001
-
Kann das Tool auch mehr Farben so das man z.b. Dateien bauen kann für Rechner mit höherer Farbtiefe ?
Wenn du mit "Tool" ORCS meinst, das kann Icons mit maximal 256 Farben (8 planes) verarbeiten. Um die vernünftig darstellen zu können, muss dann natürlich die aktuelle Auflösung auch mindestens 256 Farben haben.
Wo liegt da eigentlich das maximum des Dateiformats ?
Theoretisch gibt es da keine Beschränkung. Praktisch kenne ich aber kein AES oder Programm das mit mehr als 8 planes zurecht kommen würde. Auch ist nirgends definiert wie dann die eigentlichen Daten aussehen müssten, bis <= 8 planes werden die bits in separaten Planes gespeichert, was aber bei hi- oder truecolor keinen Sinn machen würde.
-
Webseite nicht erreichbar :(
-
Das mit dem Sinn muß man wörtlich sehen: Icons sind Sinn-Bilder (=Symbole). Ein zu großer Detail-Reichtum ist ihrer schnellen (Wieder-) Erkennbarkeit zuwider und widersprecht deshalb ihrem ergonomischen Zweck, also ihrem Sinn. Bereits an den bestehenden Icon-Sammlungen kann man das beobachten: Gute Icons sind holzschnitt-artig & minimalistisch und haben wenige Farben mit hoher Signal-Wirkung. Zu viel Zierat wirkt ablenkend & verwirrend. Aus diesem Grund sind eigtl. schon 256 Farben ein paar zu viele, obzwar 16 ein paar zu wenige sein mögen. Am besten vergleiche man in dieser Hinsicht Icons mit Verkehrszeichen, Staats-Symbolen, Marken & Logos sowie Schriftzeichen, die alle eine ähnliche Qualität haben. Es hat seinen guten Grund, daß unsere Buchstaben-Schrift den Hieroglyphen und anderen ähnlich komplexen Systemen überlegen ist.
Als meine Icon-Sammlung immer mehr anwuchs, habe ich mich gefragt, ob wir etwa im Begriff sind, uns kulturell zurück zu entwickeln in Richtung Hieroglyphen & Co. Die Frage ist von ähnlichem Gewicht wie die, ob unter den Zahl-Systemen das duale, das dezimale oder das hexagesimale zu bevorzugen sei - rechnen kann man bekanntlich mit allen, aber je nach Anwendung kann das eine oder das andere von Vorteil sein. Auf Dauer scheinen die einfacheren Systeme Erfolg zu haben. Wer genau hinschaut, kann ähnliches auch schon bei modernen Icons erkennen: Im Anhang ein Beispiel.
Edit.:
Das Beispiel-JPG ist anscheinend 8p. Ich hänge noch einen ScreenShot an, der zeigt, welche Darstellungen davon Papillon unter 4p zustande bringt.
-
Das mit den Icons ist etwas, wo ich mich wundere, dass kein Desktop mal den Ansatz vom Amiga (oder eingeschränkt Windows) ausprobiert hat. Am Atari ist es immer eine zentrale Icon-Sammlung in einer RSC-Datei, und der Desktop muss sich in einer Newdesk.INF quer über die Platten alle Icon-Zuordnungen (zum Glück gehen wenigstens Wildcards) merken. Beim Amiga vor liegt bei den meisten ausführbaren Datei eine gleichnamige Icon-Datei, die immer dann wenn sie gefunden wird, dargestellt wird. (Wenn keine da ist, wird allerdings leider kein Default-Icon dargestellt. Da muss man erst welche erzeugen, z.B. am Besten geht das mit DirOpus) Außerdem merkt sich Amiga-OS pro Ordner die manuelle (oder automatische) Anordnung dieser Symbole. (Bei Windows geht das nicht ganz so toll, man kann aber manuell EXE Dateien mit einer ICO-Datei verknüpfen).
-
Ich will wie im aktuellen mac os vektorgrafikbasierte Icons in Millionen Farben!!! 8) Und meinetwegen auch den Umgang mit den Icons wie im aktuellen mac os!
-
Das mit den Icons ist etwas, wo ich mich wundere, dass kein Desktop mal den Ansatz vom Amiga (oder eingeschränkt Windows) ausprobiert hat.
Das liegt im wesentlichen daran, daß Amiga dazu das Filesystem benutzt (Icons werden in erweiterten Attributen gespeichert). Abgesehen davon, daß FAT das nicht vorsieht, hat das auch den extremen Nachteil, daß der Desktop dann jedesmal die Datei öffnen+lesen muss. Ausserdem ist das nur bei exe-Dateien vorgesehen, für *.txt oä. möchtest du ja schliesslich nicht bei jeder Datei ein anderes Icon haben.
-
Jedes größere .APP hat ja eine .RSC, egal ob im separaten File oder eingebaut im Prg. Was fehlt ist eine Möglichkeit, dem OS zu sagen: "Verwende dieses Icon da in meinem Besitz". Genauer: Die Möglichkeit gibt es ja - aber nur ´von Hand´ und für jeden Desktop einzeln: Kann man sie automatisieren? Ist wohl angesichts der histor. Situation eine ziemlich rethorische Frage. Aber grundsätzlich ...
-------
Ich will wie im aktuellen mac os vektorgrafikbasierte Icons in Millionen Farben!!! 8) Und meinetwegen auch den Umgang mit den Icons wie im aktuellen mac os!
Dann kauf doch einfach ´nen Appel! ;D
-
Ich will wie im aktuellen mac os vektorgrafikbasierte Icons in Millionen Farben!!! 8) Und meinetwegen auch den Umgang mit den Icons wie im aktuellen mac os!
Mag sein, dass die Designer ihre Icons als Vektorgrafik erstellen, aber die Icon-Datei selbst enthält Bitmap-Grafiken. Wenn der Desktop erst in jede Programm/Resource-Datei gucken oder Vektorgrafiken konvertieren müsste, ginge das zu Lasten der Performance.
-
Jedes größere .APP hat ja eine .RSC, egal ob im separaten File oder eingebaut im Prg. Was fehlt ist eine Möglichkeit, dem OS zu sagen: "Verwende dieses Icon da in meinem Besitz". Genauer: Die Möglichkeit gibt es ja - aber nur ´von Hand´ und für jeden Desktop einzeln: Kann man sie automatisieren? Ist wohl angesichts der histor. Situation eine ziemlich rethorische Frage. Aber grundsätzlich ...
-------
Ich will wie im aktuellen mac os vektorgrafikbasierte Icons in Millionen Farben!!! 8) Und meinetwegen auch den Umgang mit den Icons wie im aktuellen mac os!
Dann kauf doch einfach ´nen Appel! ;D
Ich habe schon ein paar Äpfel in meinem Leben gekauft. 8) Und ich bin nie von denen enttäuscht worden.
-
Ich bin schwach allergisch gegen die meisten Apfelsorten. Saft, Kuchen, Apfelbrei und Apfelwein ist aber kein Problem.
-
Ich bin schwach allergisch gegen die meisten Apfelsorten. Saft, Kuchen, Apfelbrei und Apfelwein ist aber kein Problem.
Dein Problem. >:D
-
Jedes größere .APP hat ja eine .RSC, egal ob im separaten File oder eingebaut im Prg. Was fehlt ist eine Möglichkeit, dem OS zu sagen: "Verwende dieses Icon da in meinem Besitz". Genauer: Die Möglichkeit gibt es ja - aber nur ´von Hand´ und für jeden Desktop einzeln: Kann man sie automatisieren? Ist wohl angesichts der histor. Situation eine ziemlich rethorische Frage. Aber grundsätzlich ...
Klar, kann man machen. Aber:
- Verzeichnisse darstellen ist dann eher langsam, da zig Filesystemoperationen nötig sind, um dann das Icon eines .APP / .PRG malen zu können.
- Den Desktop mit x Stück abgelegten PRGs zeichnen zu können, wäre ein größeres Geschraddel mit mechanischen Festplatten, da ja für jedes .PRG wieder n Filesystemoperationen nötig sind.
- Man muss die Funktion entweder in jeden vorhandenen Alternativdesktop und in EmuTOS einbauen. Oder man schafft eine neue OS-Funktion dafür, die dann jeder Desktop ansteuern muss.
Ich glaube es gibt dringendere Aufgaben am ST :-)
-
- Verzeichnisse darstellen ist dann eher langsam, da zig Filesystemoperationen nötig sind, um dann das Icon eines .APP / .PRG malen zu können.
Siehe meinen Beitrag #12. Bei modernen Flash-basierten Laufwerken sehe ich da weniger Probleme. Andererseits, so eine zentgrale deskicon.rsc verschwendet ja permanent Speicherplatz für ein paar 100 Icons, selbst wenn in den akrtuell dargestellten Ordner nur eine Hand davon gebraucht wird.
-
Siehe meinen Beitrag #12. Bei modernen Flash-basierten Laufwerken sehe ich da weniger Probleme.
… und mit einer originalen ST-157N oder auf Floppies schläft einem das Gesicht ein. Ich bin froh, dass ich keine „Öffnungszeiten“ wie bei der Workbench der Amiga hab’.
-
Ach, ist doch schön, den Amiga beim Zusammenschrubben der Icons zuzugucken...
-
^^-- Amigo,
Du bist hier im Atari-Forum! (http://www.smileygarden.de/smilie/Weihnachten/smileygarden.de_Schneeball.gif) (http://www.smileygarden.de)
-------
... zig Filesystemoperationen nötig ...
Ich hatte nicht die in #14 beschriebene Mimik im Sinn, sondern eher
... eine neue OS-Funktion dafür, die dann jeder Desktop ansteuern ...
kann, also die Icon-Resource eher an die AES anzubinden als an jeden einzelnen Desktop (und dann auch noch jeweils ein klein wenig anders). Aber hier:
Ich glaube es gibt dringendere Aufgaben ...
stimme ich Dir vorläufig zu.
-------
Ich habe #11 nochmal editiert. Ausschnitte von .IMGs in 4p sind leicht via RCS in ein Icon zu übernehmen. Für 8p müßte das prinzipiell auch funzen - aber die unterschiedlichen Paletten sind hinderlich ...
Edit.:
Ein paar der imho besten und auf jeden Fall schnellsten Bild-Viewer stammen von APEX, ibs. auch ein "full 24-bit JPEG DSP-Viewer for the Falcon". Aber 8ung: Nur die APXGIF*.TTP lassen sich mit der Maus beenden, die andern muß man per Reset abwürgen.
Edit.: Typo korrigiert.
-
Mal eine Frage... weshalb werden die Icons in eine RSC-Datei gepackt? Mir ist bewusst das ab TOS2.xx eine RSC-Datei benutzt wird aber wieso benutzen viele Desktops das auch? Wo es doch mit der max. Anzahl der Icons und den verschiedenen Farbtiefen doch Einschränkungen gibt. Wieso statt dessen keine einzelnen Icons benutzen statt alle in einer großen Datei? Oder eine andere Idee... das Icon zum Programm in der eigentlichen Programmdatei speichern und für Dateien die keine Icons enthalten einzelne separate Icons benutzen.
-
^^-- Die Icon-Datei für den GEM-Desktop wurde nun mal von Atari im Format .RSC kreiert (schon von TOS_1 an, nicht erst ab TOS_2). Die meisten späteren Desktöppe haben das übernommen (aber nicht alle, und die das nicht taten, wie zB. die Ease oder NeoDesk, die sind dann auf der Strecke geblieben). Ein guter Grund dafür ist sicherlich, daß niemand Lust hat, die mühsame Sortiererei von Icons & deren Zuordnungen immer wieder neu machen zu müssen. In dieser Hinsicht war der von Thing und Jinnee eingeschlagene Weg ideal, da die alten Icon-Resourcen wiederverwendet werden können.
Nur für die alten Mono-Icons gilt die Beschränkung auf 64k. Mit Erscheinen der Color-Icons war eine Erweiterung des Formats fällig, die prinzipiell noch lange reicht. Beschränkungen ergeben sich leider aus den Fähigkeiten der versch. Desktöppe, zB. sind in MAGXDESK nur 500 Icons und nur je 200 Zuordnungen für Ordner, Prge. und Dateien möglich und Thing hat eine Beschränkung auf 1000 Zuordnungen. Der Grund dafür liegt im Aufwand für das Handling: Ab einer gewissen Größenordnung kommt man nicht mehr mit primitiven Such- & Sortier-Algorithmen aus, sie sind zu langsam. Dann muß man programmiertechnisch größeren Aufwand treiben, zB. Hashing - der wurde einfach in die Zukunft verschoben... Eine Hürde gibt´s bei Reihenfolge & Jokern.
Es ist immer der Desktop (wenn wir denn bei diesem probaten Konzept bleiben wollen, das uns allen so lieb geworden ist), der in seinen Fenstern die Icons darstellen muß und der deshalb _alle_ kennen muß. Eigene Icons, ob im Prg.-Code eingebettet oder in einer separaten .RSC, kann ja jede .APP auch verwenden, aber eben nur, wenn sie aktiv ist. Ein Desktop muß auch die inaktiven kennen.
Wünschenswert wäre ein Tool, mit dem man leicht ein einzelnes Icon in die Icon-Resourcen möglichst aller Desktöppe ein- und ausfügen könnte (einschließlich der nötigen Zuordnungen) - stattdessen muß man sich immer wieder durch den ganzen Haufen wühlen, mal mit mehr und mal mit weniger Komfort und Kommzurück, mitunter so unglücklich wie in TeraDesk.
-
Wie schon @Arthur also gerade festgestellt hat, und @ari.tao die Limitierung der Atari-Strategie beschreibt, ist die Herangehensweise von Amiga-OS hier doch nicht so schlecht, wenn man mal von den Ladezeiten absoeht. Denn da gibts keine Beschränkung der Anzahl Icons und Zuordnungen, weil alles on the fly gemacht wird. Ok, das braucht jedes Mal wenn man einen Ordner öffnet, etwas Zeit bis alles zusammengesucht ist, aber es scheint doch auch Vorteile zu haben. Die Frage ist, jetzt, wo Thing offen ist, ob es nicht möglich wäre, dem Desktop zusätzlich zur bisherigen Herangehensweise die Amiga-Strategie zusätzlich beizubringen. Zum Beispiel so, dass per Default ein vordefiniertes Icon aus der zentralen RSC verwendet wird (z.B. für alle *.prg), außer dass wenn im jeweiligen Ordner zu einer Datei eine *.ICO Datei liegt, die den gleichen Namen wie eine *.PRG-Datei im selben Ordner hat. lso z.B. eine WORDPLUS.ICO. Ob diese ICO einfach eine Bitmap ist, oder den selben Aufbau wie eine RSC hat, wäre eine Festlegungssache. Vielleicht sogar so, dass solche Icons als erstes oben links im Fenster dargestellt werden, damit man das gesuchte Programm sofort findet, ohne erstmal im Fenster nach unten zu scrollen...
-
wenn Ihr einen Amiga haben wollt, dann kauft euch doch einen >:D
-
Ich brauche mir keinen zu kaufen. Hab schon, fast so lange wie den ersten ST...
-
^^-- Du bist wohl in der falschen Kirche?
wenn Ihr einen Amiga haben wollt, dann kauft euch doch einen >:D
Wieso ´Ihr´? Wer denn noch außer 1ST1?
Ad #27: Ich habe keineswegs "die Limitierung der Atari-Strategie" beschrieben, sondern lediglich ein paar wenige Limits von ein paar wenigen Desktöppen (einschl. des im TOS eingebauten GEMDESK von Atari). Die Rödelei des Amiga-OS auf der Festplatte hatte schon TO in #14 genügend kritisiert. Ob die Doppel-Gleisigkeit mittels Resource-Zweig im FileSystem (wie der MacIntosh das früher hatte - das moderne MacOS kenne ich nicht genügend) wirklich eine gute Sache ist? Wir sind ja froh über die Kompatibilität zw. GEMDOS und MS-DOS.
Die Sortier-Reihenfolge läßt sich mit jedem mir bekannten Desktop festlegen, und eine Favoriten-Liste, in der bei entsprechender Namenswahl auch die wichtigen Kandidaten ganz oben stehen, ist mit Hilfe von Links unter MiNT oder MAGX leicht einzurichten - habe ich bei mir schon seit Jahren so in Betrieb.
-
^^-- Du bist wohl in der falschen Kirche?
Man muss seine Feinde kennen. Außerdem, das werdet ihr nicht wiederlegen können, der Amiga (mit XCopy im Nibble-Mode) ist die beste ST-Disketten-Kopiermaschine, die man sich vorstellen kann. Und jetzt, wo EmuTOS/MiNT drauf läuft, ist der Krieg eh vorbei.
-
Leute bitte, dieser krieg ist seit Jahren vorbei, es heißt 68K united und ganz ehrlich wir können voneinander Profitieren. Die Amiga Jungs haben dinge die wir gern hätten und umgekehrt ist das auch so. Es Muss deswegen ja nicht heißen das wir jetzt alle Amiga lieben müssen aber von der Amiga Seite ist das ganze viel offener und ich bin Täglich im Apollo Chat und werde immer wieder neugierig und optimistisch gefragt wie was funktioniert und habe schon sehr viel positives Feedback erfahren. Momentan ist es so das die Amiga Jungs unsere Anwendungen weiterentwickeln um sie Moderner zu machen weil sie diese Toll finden. Aber von unserer Seite kommt nur sehr wenig. Einige von hier sind auch im Apollo Forum präsent und geben auch gern mal ein Feedback. Ich persönlich finde es sehr schade das es so ist. Die zeit des Krieges ist einfach vorbei. Die Amiga Jungs reichen die hand um näher zusammen zu kommen....
Im Übrigen der Rudimentäre Desktop MDesk unterstützt JPG icons.. was natürlich nicht sehr sinnvoll ist da jpg doch recht groß und schwer zu handeln sind. Olivier Entwickelt ihn aber nicht weiter da er ihn nur Rudimentär für sein AES gebaut hat. Yopla die Taskbar Unterstützt jpg icons auch. Und auch die Skins sind jpg. Das heißt mit MyAES ist ein Grundstein in die richtige Richtung gesetzt. Leider fehlt mir die Zeit mich intensiver mit Programmierung zu beschäftigen. Ich habe mit Gunnar zusammen angefangen den fVDI Treiber zu optimieren, haben die Speicherzugriffe durch eigene Assemblerroutinen optimiert und somit einen höheren Speicherdurchsatz dadurch erzielt aber das ist noch nicht alles dort wäre viel mehr Potential der Saga Core ist schneller als ein Super Videl. Da die Vampire sehr bald auf dem ST fliegt wird es auch für Uns langsam interessant.
-
Im Übrigen der Rudimentäre Desktop MDesk unterstützt JPG icons.. was natürlich nicht sehr sinnvoll ist da jpg doch recht groß und schwer zu handeln sind.
Das auch – und JFIF/JPEG für Icons ist maximal ungeeignet, da lossy, d.h. manuelles Dithering oder saubere Kanten nicht möglich sind. GIF oder PNG sind bessere Alternativen.
-
... dieser krieg ist seit Jahren vorbei, ...
Da habe ich doch glatt das Kriegs-Ende verpaßt...
Also gut, Friede, Freundschaft, Eierkuchen! (http://www.smileygarden.de/smilie/Weihnachten/weihnachten-smilies-38.gif) (http://www.smileygarden.de)
... der Saga Core ist schneller als ein Super Videl. ...
Hiermit meinst Du sicher ´Saga im FPGA´?
Aber laufen denn damit unsere GEM-Prge.?!
-
Ja, es gibt ja VDI-Treiber für EmuTOS und MiNT. Sauber progarmmierte GEM-Apps laufen auf SAGA genauso gut, wie auf jeder anderen ST/TT/Falcon/Milan/Hades/Eagle/Firebee-Grafikkarte. Und wie Tuxie schon schrieb, die Amiga-Leute machen derzeit die Arbeit, die eigentlich wir Atari-Leute machen müssten, sie optimieren fVDI und MiNT für SAGA und den 68080. Irgendwie ist das peinlich, aber den Amiga-Leuten gefällt, was die Atari-Community vorgelegt hat.
-
Jetzt geht´s wieder drastisch OT - Aber das eigtl. Thema scheint ja erledigt zusein?!
-
Jetzt geht´s wieder drastisch OT - Aber das eigtl. Thema scheint ja erledigt zusein?!
Nicht ganz: Ich habe Icon Extract 1.5 auf die ST-Computer-Website hochgeladen.
http://st-computer.atariuptodate.de/index.php?content=software (http://st-computer.atariuptodate.de/index.php?content=software)
-
Ich hatte es schon aus der kurobox geladen und habe gestern Abend mal ´reingeschnuppert. Leider reicht mein Frz. nicht dafür - und die Kräfte meines Falcon wohl auch nicht? Vielleicht kann irgendjemand wenigstens den INFOS.TXT aus dem Frz. übersetzen?
Es gibt ein älteres Tool ICO2RSC.PRG von Dirk Haun - aber das kommt mit den in EXTRACT enthaltenen .ICOs leider nicht zurecht.
-
Ich hatte es schon aus der kurobox geladen und habe gestern Abend mal ´reingeschnuppert. Leider reicht mein Frz. nicht dafür - und die Kräfte meines Falcon wohl auch nicht? Vielleicht kann irgendjemand wenigstens den INFOS.TXT aus dem Frz. übersetzen?
Es gibt ein älteres Tool ICO2RSC.PRG von Dirk Haun - aber das kommt mit den in EXTRACT enthaltenen .ICOs leider nicht zurecht.
Ich hatte Icon Extract damals verwendet, um eine ganze Menge Windows-Iconsets zu konvertieren. Aber ja, der Programmierer ging etwas "over the top" mit dem Programm. Ich setze es mir mal auf die Liste für die ST-Computer 09/2018 - Test und Grundlagenartikel.
Die Amiga-User könnte man eventuell mit diesem alternativen Design glücklich machen ;) :
-
@MJaap die Grundlagenartikel in der ST-Computer sind echt eine wunderbare Sache! 8) (Mal so nebenbei.)
-
Ich setze es mir mal auf die Liste für die ST-Computer 09/2018 ...
Sooo lange soll ich warten!
Das Bild habe ich nicht verstanden.
OT on
Ist die PD aus dem aktuellen Heft schon online?
OT off