Suche eine Möglichkeit um Windows Bildformate,(Jpeg etc.) in Amiga Bildformate für Wokbench 1.3 mit DOpus in 24bit Farbtiefe zu konvertieren.
Bisher habe ich nur geschafft mit dem Windows Tool XnView http://www.chip.de/downloads/XnView-Kom ... 96168.html
ins Amiga IFF Format zu konvertieren.
Die Bilder lassen sich mit Directory Opus dann allerdings nur mit max. 32 Farben öffnen. Konvertiere ich mit mehr Farben gibts eine Fehlermeldung beim Laden. Habe im Web aber auch Pic und Ham Bilder mit 4096 Farben gefunden die problemlos mit Directory Opus 4.12 gelesen werden.
http://www.memphisamigagroup.net/diskmags/198808-02/
Mich würde interessieren ob es eine Möglichkeit gibt am PC Bilder mit dieser hohen Farbtiefe für Amiga zu konvertieren. Eine Schritt für Schritt Anleitung wäre toll.
Hinweis vorweg: Irfanview liest IFF kann aber nicht ins Amiga Format schreiben - fällt also weg.
Bilder/Fotos am PC für Amiga mit 4096 Farben konvertieren?
Moderatoren: gunatm, RetroMan, Independent, Dennis, Dirty Harry, CASSIUS
Bilder/Fotos am PC für Amiga mit 4096 Farben konvertieren?
Amiga 2000, Amiga 500 mit A590 SCSI HD, A570 CD-Rom, AlfaPower IDE, Amiga 1200 Elbox Mediator PCI, USB, Blizzard 68060 bzw. 68040 PPC 200MHz, C64 mit Final Cartridge III, MMC Replay, 1541 Ultimate II, C-64 Fischertechnik Roboter
http://amigamap.com/
http://amigamap.com/
Amiga 500 zum Fotos betrachten.
Hallo Reentier,
danke für deinen tollen Tipp mit PPaint.
Habe unter OS3.9 die Bilder soweit bearbeitet, dass ich diese dann nochmals auf dem Amiga 500 unter Deluxe Paint IV reinladen kann.
Es scheint so, als ob die machbare Qualität für einen Standard Amiga 500 bei 320x256 mit 64 Farben liegt.
Mehr habe ich bisher noch nicht geschafft aber für meine Zwecke passt das so. Ist ganz ansehlich und lädt auch schön schnell unter Directory Opus.
danke für deinen tollen Tipp mit PPaint.
Habe unter OS3.9 die Bilder soweit bearbeitet, dass ich diese dann nochmals auf dem Amiga 500 unter Deluxe Paint IV reinladen kann.
Es scheint so, als ob die machbare Qualität für einen Standard Amiga 500 bei 320x256 mit 64 Farben liegt.
Mehr habe ich bisher noch nicht geschafft aber für meine Zwecke passt das so. Ist ganz ansehlich und lädt auch schön schnell unter Directory Opus.
Amiga 2000, Amiga 500 mit A590 SCSI HD, A570 CD-Rom, AlfaPower IDE, Amiga 1200 Elbox Mediator PCI, USB, Blizzard 68060 bzw. 68040 PPC 200MHz, C64 mit Final Cartridge III, MMC Replay, 1541 Ultimate II, C-64 Fischertechnik Roboter
http://amigamap.com/
http://amigamap.com/
naja eigentlich egal welches Format. Wollte die bestmögliche Fotoqualität für einen Amiga 500 mit 1mb ram unter der Workbench 1.3.3 / Kick 1.3 herausfinden.
Amiga 2000, Amiga 500 mit A590 SCSI HD, A570 CD-Rom, AlfaPower IDE, Amiga 1200 Elbox Mediator PCI, USB, Blizzard 68060 bzw. 68040 PPC 200MHz, C64 mit Final Cartridge III, MMC Replay, 1541 Ultimate II, C-64 Fischertechnik Roboter
http://amigamap.com/
http://amigamap.com/
Bei einem normalen 500er sind pro Farbkanal nur 16 Abstufungen möglich. Das ergibt dan 16x16x16=4096 Farben.
Mehr als 6 Bit pro Pixel ist mit der verbauten Hardware aber nicht möglich. Das sind dann theoretisch 64 Farben. Dazu kommt dann aber noch, dass man nur die ersten 32 Farben direkt bestimmen kann. Für die zweite Hälfte werden die Farbwerte der ersten Hälfte mit halber Helligkeit verwendet.
Mit HAM haben sich die Entwickler eine Möglichkeit trotz der technischen Grenzen alle 4096 Farben darzustellen. Erklärung dazu gibt es z.B. hier: http://de.wikipedia.org/wiki/Hold-And-Modify-Modus
Dadurch dass die meisten Pixel in einem HAM-Bild auf die Farbinformationen des linken Nachbarpixels zugreifen, entstehen nach rechts unschöne Schlieren, wenn man Teile eines Bildes verändert. (Grafik-)Programme die HAM nutzen versuchen diese Schlieren wieder zu entfernen. In einem Malprogramm stört es nicht sonderlich wenn man dabei zuschauen kann wie die Schlieren wieder (mehr oder weniger) verschwinden. Für die meisten Spiele dauert das aber zu lange und wird daher kaum genutzt.
Sinn macht HAM eigentlich nur für einen echtem Amiga. Mir ist daher kein Programm auf einem anderem System bekannt, was HAM-Bilder erzeugt.
Was Grafikbearbeitung betrifft, bevorzuge ich auf der Kiste Brilliance2. Das ist von der Menüanordnung zwar etwas anders, dadurch aber gefühlt doppelt so schnell. Das Programm gibt es dann auch noch mal als TrueBrilliance2. Damit lassen sich dann auch IFF/ILBM-Bilder mit 24Bit bearbeiten und mit HAM darstellen und speichern. (Oder auch HAM8 beim 1200er/4000er mit AGA)
Mehr als 6 Bit pro Pixel ist mit der verbauten Hardware aber nicht möglich. Das sind dann theoretisch 64 Farben. Dazu kommt dann aber noch, dass man nur die ersten 32 Farben direkt bestimmen kann. Für die zweite Hälfte werden die Farbwerte der ersten Hälfte mit halber Helligkeit verwendet.
Mit HAM haben sich die Entwickler eine Möglichkeit trotz der technischen Grenzen alle 4096 Farben darzustellen. Erklärung dazu gibt es z.B. hier: http://de.wikipedia.org/wiki/Hold-And-Modify-Modus
Dadurch dass die meisten Pixel in einem HAM-Bild auf die Farbinformationen des linken Nachbarpixels zugreifen, entstehen nach rechts unschöne Schlieren, wenn man Teile eines Bildes verändert. (Grafik-)Programme die HAM nutzen versuchen diese Schlieren wieder zu entfernen. In einem Malprogramm stört es nicht sonderlich wenn man dabei zuschauen kann wie die Schlieren wieder (mehr oder weniger) verschwinden. Für die meisten Spiele dauert das aber zu lange und wird daher kaum genutzt.
Sinn macht HAM eigentlich nur für einen echtem Amiga. Mir ist daher kein Programm auf einem anderem System bekannt, was HAM-Bilder erzeugt.
Was Grafikbearbeitung betrifft, bevorzuge ich auf der Kiste Brilliance2. Das ist von der Menüanordnung zwar etwas anders, dadurch aber gefühlt doppelt so schnell. Das Programm gibt es dann auch noch mal als TrueBrilliance2. Damit lassen sich dann auch IFF/ILBM-Bilder mit 24Bit bearbeiten und mit HAM darstellen und speichern. (Oder auch HAM8 beim 1200er/4000er mit AGA)
Hey Leute danke für eure tolle Erklärung zum technischen Hintergrund zu HAM. Werde noch etwas weiter experimentieren aber für meinen kleinen 500er finde ich die 320x256 mit 64 Farben schon echt gut und die Ausfransungen halten sich auch in Grenzen.
Ich werd mir da mal eine Kleine Bildersammlung anlegen. Wie man aber schon anno 1988 (die Amiga Ladys aus dem Link oben z.b. Betty.ham) so gute Bilder für den Amiga mit 4096 Farben gemacht hat, ist mir ein Rätsel.
Ich werd mir da mal eine Kleine Bildersammlung anlegen. Wie man aber schon anno 1988 (die Amiga Ladys aus dem Link oben z.b. Betty.ham) so gute Bilder für den Amiga mit 4096 Farben gemacht hat, ist mir ein Rätsel.
Amiga 2000, Amiga 500 mit A590 SCSI HD, A570 CD-Rom, AlfaPower IDE, Amiga 1200 Elbox Mediator PCI, USB, Blizzard 68060 bzw. 68040 PPC 200MHz, C64 mit Final Cartridge III, MMC Replay, 1541 Ultimate II, C-64 Fischertechnik Roboter
http://amigamap.com/
http://amigamap.com/
Die Stärken und Schwächen von HAM sind in etwa die gleichen wie bei JPEG. D.h. es eignet sich vor allem für Fotos mit weichen Farbverläufen. Bei Zeichnungen und Hardcopies mit scharfen Kontrasten versagt es.
Ein 24bit-Bild in HAM umzuwandeln ist recht einfach. Wenn man dazu noch eine auf das Bild optimierte Palette benutzt, kann man auch die scharfen Kontraste sehr gut abbilden. D.h. bei einem Standbild kann man sehr gute Qualität erreichen. Insbesondere wenn es sich um ein Foto mit vielen Farbverläufen und wenigen scharfen Kanten handelt (wie bei betty.ham).
Schwierig wird es bei bewegten Bildern. Wenn man diese in Echtzeit berechnen möchte, bleibt nur der einfachste Algorithmus, der gleichzeitig die niedrigste Qualität bringt: jeweils ein Pixel setzt die Rot-, die Grün- und die Blau-Komponente. D.h. Ein Farbwechsel von weiß nach schwarz benötigt drei Pixel und sieht entsprechend verwaschen aus. Dafür ist der Algorithmus aber noch etwas einfacher (und damit schneller) als aus dem Bild eine Grautonvariante zu berechnen.
Ein 24bit-Bild in HAM umzuwandeln ist recht einfach. Wenn man dazu noch eine auf das Bild optimierte Palette benutzt, kann man auch die scharfen Kontraste sehr gut abbilden. D.h. bei einem Standbild kann man sehr gute Qualität erreichen. Insbesondere wenn es sich um ein Foto mit vielen Farbverläufen und wenigen scharfen Kanten handelt (wie bei betty.ham).
Schwierig wird es bei bewegten Bildern. Wenn man diese in Echtzeit berechnen möchte, bleibt nur der einfachste Algorithmus, der gleichzeitig die niedrigste Qualität bringt: jeweils ein Pixel setzt die Rot-, die Grün- und die Blau-Komponente. D.h. Ein Farbwechsel von weiß nach schwarz benötigt drei Pixel und sieht entsprechend verwaschen aus. Dafür ist der Algorithmus aber noch etwas einfacher (und damit schneller) als aus dem Bild eine Grautonvariante zu berechnen.