amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Amiga, AmigaOS 4 > Jpeg-Viewer [ - Search - New posts - Register - Login - ]

-1- 2 [ - Post reply - ]

2003-04-30, 21:17 h

StefanONE
Posts: 453
User
Ich benötige einen Jpeg-Viewer, der mir das Bild in HAM8 anzeigt. Er sollte nach Möglichkeit den FastRAM-Speicher verwenden. Gibt es so etwas? Hab mal ins Aminet geschaut aber nichts gefunden, vieleicht auch übersehen.

Gruß
StefanONE

[ - Answer - Quote - Direct link - ]

2003-04-30, 22:09 h

trstenjak_adrian
Posts: 58
User
Machen das nicht Visage und alte Versionen von Fastview :dance3:
VT?


[ - Answer - Quote - Direct link - ]

2003-05-01, 20:08 h

Bluebird
Posts: 3260
User
hmmm ich nuzte immer sJFIF & H8jpg obwohl visage kann nahezu alle formate und hat keine
probleme mit progresiven jpegs ...


mfg Bluebird

[ - Answer - Quote - Direct link - ]

2003-05-02, 08:44 h

thomas
Posts: 7718
User

Multiview kann das auch, mit den richtigen Datatypes. Ich glaube, bei den ak-Datatypes kann man das einstellen, daß 24bit-Bilder in HAM umgerechnet werden.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]

2003-05-02, 09:20 h

TriMa
Posts: 2793
[Former member]
Ich kann auch Fastview empfehlen, den habe ich damals immer genommen.
--
MfG
TriMa
--
irc.euirc.net #Sarkasmus-pur @ http://www.sarkasmus-pur.de.vu

[ - Answer - Quote - Direct link - ]

2003-05-02, 21:09 h

Mario_II
Posts: 69
User
Bei mir zeigt Fastview nur IFFs an.
Für JPEGs muss ich immer VT bemühen.
Wie bringe ich denn Fastview das Lesen von JPEGs bei?

Mario II

[ - Answer - Quote - Direct link - ]

2003-05-02, 22:05 h

Bluebird
Posts: 3260
User
hmm dachte jetzt weil ham 8 an aga ;) , denn multiview kanns unter aga nicht sein hehe .
dazu h8jpg scaliert automatisch grosse jpegs auf eine groesse die 2mb chip darstellen koennen , das
feature vermiesse ich noch heute an der graka *schnief*

[ - Answer - Quote - Direct link - ]

2003-05-02, 22:26 h

Palgucker
Posts: 1342
User
Hallo Mario II

Wenn Fastview JPEG's anzeigen soll benötigst Du die Tower.library
und, wenn ich nicht irre, die codec.class in Classes/ sowie
picture- und jpeg.codec in Classes/Codecs/.
Mit der Multipic.library lassen sich auch PPM's anzeigen.
Ähnliches gilt auch für Visage - bis auf die PPM's. Wobei Visage auch
über Datatypes JPEG's anteigt, aber eben langsamer.

[ - Answer - Quote - Direct link - ]

2003-05-03, 01:34 h

StefanONE
Posts: 453
User
Hallo Palgucker,
wo bekomme ich diese Zusatzdateien für Fastview her? Im Aminet und bei Yahoo war nichts zu finden. Wenn Du diese Dateien hast, kannst Du sie mir zuschicken? Hier meine E-Mail: stefanreinke@t-online.de

Gruß
StefanONE

[ - Answer - Quote - Direct link - ]

2003-05-03, 02:39 h

Palgucker
Posts: 1342
User
Hallo StefanONE

Die Postkutsche ist gerade los;)

[ - Answer - Quote - Direct link - ]

2003-05-03, 13:53 h

Mario_II
Posts: 69
User
@ palgucker

kannst Du mir die Dateien bitte auch schicken? Mario_ii@amiga.org
Visage funzt bei mir (OS 3.9) nicht. Fehlermeldung beim
Aufrufen des Programms: "Fehler beim Parsen der Agumente: Pufferüberlauf"
Auf meiner 2. Bootpartition (OS 3.1) läuft Visage ohne Probleme. Was sagt
die Fehlermeldung aus?

Mario II

[ - Answer - Quote - Direct link - ]

2003-05-03, 15:18 h

Palgucker
Posts: 1342
User
Hallo Mario II

Bei mir geht heute ganzschön die Post ab ;)

Zu Pufferüberlauf fällt mir jetzt auch nichts ein. Kenne nur
"Befehl zu lang, wenn die Argumentzeile mehr als 512 Zeichen hat.
Aber mit ein bischen Glück erledigt sich dieses Problem auch mit
Einzug der Tower.library. Denn Visage zeigt bei mir auch Unterschiede
im "Handling". Habe ich z.B. mehrere JPEG's in der Argumentzeile, kann
ich das anzeigen der Bilder mit ESC einfach unterbrechen. Mit der
Option DT kann ich da drücken, was ich will, Visage lässt sich dann
nicht mehr stoppen.

Na, schaun ma mal



[ - Answer - Quote - Direct link - ]

2003-05-03, 16:59 h

yelworC
Posts: 401
User
Zitat:
Original von Palgucker:
Wobei Visage auch über Datatypes JPEG's anteigt, aber eben langsamer.


Das ist garnicht langsamer. Bei mir mit WarpDatatypes aufm 040/40 Prozessor ist es sogar schneller. Es wirkt nur langsamer, da die Bilder nicht schon während dem dekodieren Zeile für Zeile angezeigt werden. Vor allem progressive JPEGs sind sehr viel schneller.

Die zum Dekodieren benötigte Zeit kann man mit dem "TIME" Argument anzeigen lassen. So kann man das schön testen.

[ - Answer - Quote - Direct link - ]

2003-05-03, 17:55 h

DaxB
Posts: 1421
User
@yelworC:
Das musst du mir mal näher verklickern. Währe schön, wenn das hier auch funzen würde.

[ - Answer - Quote - Direct link - ]

2003-05-03, 19:30 h

Palgucker
Posts: 1342
User
hallo yelworC

Jetzt hast Du mich vielleicht erwischt, aber ich kann einfach nicht
das Gegenteil beweisen. Visage arbeitet einfach nicht mit meinem
jpeg.datatype zusammen. Während Multiview und VT über diesen Datatype
mir ein 320x256 grosses JPEG nach einigen Sekunden als FS-gedithertes
Bild anzeigen, bricht Visage mit DT-Option nach ca. 5 sec mit der
Meldung "nicht genug Speicher vorhanden" ab. Obwohl noch genügend frei
ist.
Auch wenn ich Multiview auf einen Ham-Schirm umlenke, dithert der
datatype fleißig weiter. Speichere ich dieses Bild ab, ist es wieder
ein "normales", soll heißen ungedithertes 24 Bit ILBM.

Übrigens wird dieses Bild ohne DT mit der Time Option bei mir nach
2.2 sec in Ham8 ausgegeben. Was nun aber auch nicht sagt, das der DT
langsamer ist.
Im Zusammenhang mit Ham8 finde ich aber, das Fastview/Visage mit
tower.library &co ein recht ideales Gespann sind.

[ - Answer - Quote - Direct link - ]

2003-05-03, 20:37 h

yelworC
Posts: 401
User
Hmm... da ihr beide AGA verwendet (bei DaxB weiß ichs, bei Palgucker vermute ich das mal anhand des Namens) liegt das Problem vielleicht dabei. Vor allem das Problem mit dem Speicher kenne ich auch noch aus den "guten alten AGA Zeiten". Das Problem ist wohl, dass bei Datatypes die Bilder nicht skaliert geladen werden und große Bilder einfach mehr Speicher fressen.

Auf einem 16Bit Screen habe ich diese Probleme nicht und es ist definitiv schneller, wenn ich die "DATATYPES" Option angebe.

Nachtrag: Ich bin nochmal in mich gegangen und zu dem Schluss gekommen, dass Palgucker ganz sicher AGA verwenden wird. Sonst würdest Du wohl kaum HAM8 verwenden. :)

[ Dieser Beitrag wurde von yelworC am 03.05.2003 editiert. ]

[ - Answer - Quote - Direct link - ]

2003-05-03, 23:59 h

Mario_II
Posts: 69
User
@ palgucker

es klappt! mit der "tower.library" und den classes zeigt Fastview
nun auch JPEGs an. Sogar schneller als es VT getan hat.
Bei Visage hat sich nichts geändert. :-(
Trotzdem, danke nochmals :-)

Mario II

[ Dieser Beitrag wurde von Mario_II am 04.05.2003 editiert. ]

[ - Answer - Quote - Direct link - ]

2003-05-04, 20:21 h

StefanONE
Posts: 453
User
Jetzt läuft Fastview bei mir auch richtig. Versuche gerade Fastview als externen Jpeg-Anzeiger für IBrowse 2.3 zu verwenden. Klappt irgentwie nicht. Hat da einer einen Tip?

Gruß
StefanONE

[ - Answer - Quote - Direct link - ]

2003-05-04, 22:55 h

Wolfman
Posts: 3668
User
Zitat:
Original von StefanONE:
Jetzt läuft Fastview bei mir auch richtig. Versuche gerade Fastview als externen Jpeg-Anzeiger für IBrowse 2.3 zu verwenden. Klappt irgentwie nicht. Hat da einer einen Tip?

Gruß
StefanONE


Da ich das jetzt zufälligerweise selber einrichten musste:

TYP: image/jpeg
Endung: jpg jpeg
Aktion: externer Anzeiger
Anzeiger: "DeinPfad"/Fastview
Argumente: %f

Allerdings kriege ich manchmal Fehlermeldungen bei Bildern, die aber z.B. Superview anzeigen kann.


--
Bild: http://home.arcor.de/the_wolf/Bilder/wolfman.jpg Bikers, Amigas and good Whiskey get better with age :bounce:


[ - Answer - Quote - Direct link - ]

2003-05-04, 23:39 h

StefanONE
Posts: 453
User
@Wolfman,
genauso hatte ich das vorher auch, lief aber nicht. Jetzt nach einem Reset läuft es. Wenn ich die Bilder mit IBowse betrachte, sind diese horizontal zusammen gestaucht. Wenn ich die Bilder vom der Festplatte aus lade sind sie ganz normal. Woran kann das liegen? Kann man vieleicht etwas an den Zusatzdateien (siehe oben) etwas anderes einstellen?

Gruß
StefanONE

[ - Answer - Quote - Direct link - ]

2003-05-06, 11:23 h

gni
Posts: 1106
User
Zitat:
Bluebird:
dazu h8jpg scaliert automatisch grosse jpegs auf eine groesse die 2mb chip darstellen koennen, das feature vermiesse ich noch heute an der graka *schnief*

Mir ist noch kein JPEG untergekommen, das auf einer Grafikkarte wegen Speichermangel nicht dargestellt werden konnte.

[ Dieser Beitrag wurde von gni am 06.05.2003 editiert. ]

[ - Answer - Quote - Direct link - ]

2003-05-06, 11:26 h

gni
Posts: 1106
User
Zitat:
Palgucker:
Wenn Fastview JPEG's anzeigen soll benötigst Du die Tower.library
und, wenn ich nicht irre, die codec.class in Classes/ sowie
picture- und jpeg.codec in Classes/Codecs/.

Dieser jpeg.codec ist _obsolete_,da er keine progessiven JPEGs dekodieren kann.

[ - Answer - Quote - Direct link - ]

2003-05-06, 11:30 h

gni
Posts: 1106
User
Zitat:
Mario_II:
Visage funzt bei mir (OS 3.9) nicht. Fehlermeldung beim Aufrufen des Programms: "Fehler beim Parsen der Agumente: Pufferüberlauf" Auf meiner 2. Bootpartition (OS 3.1) läuft Visage ohne Probleme. Was sagt die Fehlermeldung aus?

Das Icon von Visage ist defekt. 3.5+ unterstützt diese Icons, ist aber pingeliger mit deren Aufbau. Entweder anderes Icon nehmen oder das Icon in IconEdit laden+speichern (das macht es dann zu einem korrekten aber 3.5+ only Icon).

[ - Answer - Quote - Direct link - ]

2003-05-06, 11:35 h

gni
Posts: 1106
User
Zitat:
Palgucker:
Jetzt hast Du mich vielleicht erwischt, aber ich kann einfach nicht
das Gegenteil beweisen. Visage arbeitet einfach nicht mit meinem
jpeg.datatype zusammen. Während Multiview und VT über diesen Datatype
mir ein 320x256 grosses JPEG nach einigen Sekunden als FS-gedithertes
Bild anzeigen, bricht Visage mit DT-Option nach ca. 5 sec mit der
Meldung "nicht genug Speicher vorhanden" ab. Obwohl noch genügend frei
ist.

Vermutlich ein Bug im DT-Support von Visage (welche Version von Visage,
welcher Datatype?
Zitat:
Auch wenn ich Multiview auf einen Ham-Schirm umlenke, dithert der
datatype fleißig weiter. Speichere ich dieses Bild ab, ist es wieder
ein "normales", soll heißen ungedithertes 24 Bit ILBM.

Noe, es ist ein aus HAM erzeugtes 24bit ILBM.

[ - Answer - Quote - Direct link - ]

2003-05-06, 16:47 h

Palgucker
Posts: 1342
User
hallo gni

quote:
Dieser jpeg.codec ist _obsolete_,da er keine progessiven JPEGs
dekodieren kann.


Nun ja, dieser Codec ist aber immer noch nützlich, wenn man Fastview
das anzeigen von Jpeg's "beibringen" will.
Im übrigen kann ich nicht vor allem, was obsolete ist oder erscheint,
einen grossen Bogen machen. Dann könnte ich wohl gleich den ganzen
Rechner vor die Tür stellen.
;)

quote:
Vermutlich ein Bug im DT-Support von Visage (welche Version von Visage,
welcher Datatype?


Hab mir mal die Versionen angeschaut. Und, oh Graus, ich hab die ganze
Zeit mit der alten Version (39.5 vom 21.01.96) getestet. Mit der neuen
Version (39.22 vom 31.10.98) klappt es mit dem jpeg.datatype - aber auch
nur gedithert. Vielleicht ist auch der Datatype einfach nicht hamfähig.

Hab mir nun mal probeweise den AKjfif.datatype installiert und gestaunt.
Zum 1., weil er jetzt Freeware ist, und zum 2., weil er wirklich
genau so schnell ist, wie die codecs.
Und hamfähig ist er natürlich auch.
Kann mich noch erinnern, das ich ihn irgendwann mal von der Platte
verbannt hatte, da irgend eine Version mich mit Nervrequester quälen
wollte.
Da bin ich vielleicht etwas eigen, aber ich greife lieber zu 100
kleinen Freeware-Tools, als zum kostenpflichtigen Mega-Bildanzeiger.
Im Fall der JPEG's braucht man dann nur ein kleines Script, was in
einem kurzen Vorabcheck erstmal testet, um was für ein JPEG es sich
handelt (sequentiell,proggressive oder lossless), und die
entsprechenden Programme startet.

Übrigens werde ich die alte Version von Visage auch nicht gleich
in die "Tonne kloppen", denn die kann noch Gif's ohne Datatype
anzeigen, was ich persönlich recht nützlich finde.

quote:
Noe, es ist ein aus HAM erzeugtes 24bit ILBM.


Hast Du das unter AGA Bedingungen rausgefunden? Aber danke für den
Hinweis, denn das hätte ich wohl nicht so einfach rausbekommen.

mfg Palgucker





[ - Answer - Quote - Direct link - ]

2003-05-07, 11:39 h

gni
Posts: 1106
User
Zitat:
Palgucker:
quote:
Dieser jpeg.codec ist _obsolete_,da er keine progessiven JPEGs
dekodieren kann.

Nun ja, dieser Codec ist aber immer noch nützlich, wenn man Fastview
das anzeigen von Jpeg's "beibringen" will.

Das unterstützt wohl keine DTs?
Zitat:
Im übrigen kann ich nicht vor allem, was obsolete ist oder erscheint,
einen grossen Bogen machen. Dann könnte ich wohl gleich den ganzen
Rechner vor die Tür stellen.;)

Also mein Amiga ist nicht obsolete ;-) Software kann im Gegensatz dazu sehr wohl obsolete sein. Vor allem dieser Codec, da er keine progessiven JPEGs kann ;-)
Zitat:
quote:
Vermutlich ein Bug im DT-Support von Visage (welche Version von Visage, welcher Datatype?

Hab mir mal die Versionen angeschaut. Und, oh Graus, ich hab die ganze
Zeit mit der alten Version (39.5 vom 21.01.96) getestet.

Ich habe auch noch eine "alte" Version von Visage runliegen. Warum weis ich nicht mehr und nutzen tue ich sie auch nicht.
Zitat:
Mit der neuen Version (39.22 vom 31.10.98) klappt es mit dem jpeg.datatype - aber auch nur gedithert. Vielleicht ist auch der Datatype einfach nicht hamfähig.
Von welchem Datatype sprichts Du? Dem vom System? Die Hamfähigkeit eines DTs ist strenggenommen irrelevant. Wenn Du Multiview/Visage/etc. auf einen HAM-PubScreen schickst, dann wird ein 24bit Bild vom picture.datatype selber nach HAM konvertiert. Wenn der Datatype selber HAM unterstützt, dann öffnet Multiview/etc. entweder selber einen HAM-Screen oder der picture.datatype konvertiert alles wieder in ein für den gewählten Ausgabeschirm passendes Format (zb. 24bit ;-)
BTW, es gibt DTs, die das Dithern abschalten können, allerdings nur für 15bit und mehr.
Zitat:
Hab mir nun mal probeweise den AKjfif.datatype installiert und gestaunt. Zum 1., weil er jetzt Freeware ist, und zum 2., weil er wirklich genau so schnell ist, wie die codecs.
Die Schnelligkeit dieses DTs kommt ganz einfach vom verwendeten JPEG Dekoder, den alle neueren mir bekannten DTs verwenden. Die libjepg v6b ist einfach _schnell_. Es gibt aber dennoch schnellere DTs (und IMHO bessere DTs) als den den Du probeweise installiert hast. Er hatte allerdings gute Publicity ;-)
Zitat:
Und hamfähig ist er natürlich auch.
Das ist nur ein Gimmick, den man nicht unbedingt braucht.
Zitat:
Kann mich noch erinnern, das ich ihn irgendwann mal von der Platte
verbannt hatte, da irgend eine Version mich mit Nervrequester quälen
wollte.

Früher war der DT Shareware.
Zitat:
Im Fall der JPEG's braucht man dann nur ein kleines Script, was in
einem kurzen Vorabcheck erstmal testet, um was für ein JPEG es sich
handelt (sequentiell,proggressive oder lossless), und die
entsprechenden Programme startet.

Für die beiden ersten kann man ein Programm verwenden. Lossless ist mir noch nie untergekommen. Ein sehr ungebräuchliches Format.
Zitat:
quote:
Noe, es ist ein aus HAM erzeugtes 24bit ILBM.

Hast Du das unter AGA Bedingungen rausgefunden? Aber danke für den
Hinweis, denn das hätte ich wohl nicht so einfach rausbekommen.

Das hat nichts mit AGA zu tun. Wenn das 24bit Original auf einem HAM-Screen dargestellt war, Du es von dort gespeichert hast und das Ergebnis ein 24bit Bild ist, dann wurde es aus den HAM Daten erzeugt, da die original Daten zum Zeitpunkt des Speicherns längst weg sind.

[ - Answer - Quote - Direct link - ]

2003-05-07, 16:22 h

Palgucker
Posts: 1342
User
hallo gni

quote:
Das unterstützt wohl keine DTs?


Doch, macht es. Aber nicht bei JPEG's. Das Datatypconcept würde
wahrscheinlich mit dem Konzept von Fastview, alle Bitmaps im
Voraus zu laden, kollidieren. Auf jedenfall zeigt Fastview ohne
tower.library bei mir keine JPEG's an. Datatype hin, Datatype her.

quote:
Von welchem Datatype sprichts Du? Dem vom System?


Speziell meine ich den jpeg.datatype (V 44.4 vom 26.09.00), aber ein
paar andere Versionen zeigten die selben Symtome.

zu hamfähig

quote:
Das ist nur ein Gimmick, den man nicht unbedingt braucht.


Auf einem AGA Rechner kann man da aber ganz anderer Meinung sein!

quote:
Für die beiden ersten kann man ein Programm verwenden. Lossless ist
mir noch nie untergekommen. Ein sehr ungebräuchliches Format.


Und trotzdem ist es ein Standard, den die JPEGroup 1993 auf die
Menschheit losgelassen hat.

quote:
Das hat nichts mit AGA zu tun. Wenn das 24bit Original auf einem
HAM-Screen dargestellt war, Du es von dort gespeichert hast und das
Ergebnis ein 24bit Bild ist, dann wurde es aus den HAM Daten erzeugt,
da die original Daten zum Zeitpunkt des Speicherns längst weg sind.


Übrigens hatte ich gestern schon ein merkwürdiges Gefühl beim lesen
Deines Satzes >>Noe, es ist ein aus HAM erzeugtes 24bit ILBM.<<.
Ich war aber zu faul, das Gegenteil zu finden. Heute war ich da etwas
fleissiger.
Also um es auf den Punkt zu bringen:
Wenn Multiview ein jpeg unter AGA Bedingungen mit dem o.g. datatype
anzeigt, bekomme ich ein FS-gedithertes palettenorientiertes normales
Bild zu sehen(kein Ham!). Wenn ich nun dieses Bild speichere, ist es
ein 24-Bit ILBM, das aus einem 24-Bit chunky Speicherbereich gewonnen
wird, und nicht aus irgendeiner Ham8 Bitmap. Und Multiview hält
durchaus während der Anzeigedauer "Kontakt" zu den 24 Bit Orginaldaten.


mfg Palgucker

[ - Answer - Quote - Direct link - ]

2003-05-07, 18:23 h

Mario_II
Posts: 69
User
Zitat:
Original von gni:
Zitat:
Mario_II:
Visage funzt bei mir (OS 3.9) nicht. Fehlermeldung beim Aufrufen des Programms: "Fehler beim Parsen der Agumente: Pufferüberlauf" Auf meiner 2. Bootpartition (OS 3.1) läuft Visage ohne Probleme. Was sagt die Fehlermeldung aus?

Das Icon von Visage ist defekt. 3.5+ unterstützt diese Icons, ist aber pingeliger mit deren Aufbau. Entweder anderes Icon nehmen oder das Icon in IconEdit laden+speichern (das macht es dann zu einem korrekten aber 3.5+ only Icon).

@ gni

vielen Dank! Jetzt läuft Visage anstandslos.
Was wäre ich nur ohne die Gemeinde :-)

Mario II

[ - Answer - Quote - Direct link - ]

2003-05-08, 15:31 h

gni
Posts: 1106
User
Zitat:
Palgucker:
quote:
Das unterstützt wohl keine DTs?

Doch, macht es. Aber nicht bei JPEG's.

Bist Du sicher? FastView 2.0 (24.10.95) enthält keinen Verweis auf die datatypes.library. Der String "multipic.library" ist zu finden.
Zitat:
quote:
Von welchem Datatype sprichts Du? Dem vom System?

Speziell meine ich den jpeg.datatype (V 44.4 vom 26.09.00), aber ein
paar andere Versionen zeigten die selben Symtome. [dithern]

Der JPEG-DT von 3.5+ dekodiert das Bild nur und reicht die reinen RGB-Daten an den picture.datatype weiter. Der dithert das ganze dann und/oder macht gegebenenfalls HAM draus.
Zitat:
quote:
Das ist nur ein Gimmick, den man nicht unbedingt braucht.

Auf einem AGA Rechner kann man da aber ganz anderer Meinung sein!

Warum? Ein HAM-PubScreen tuts doch auch! Oder kannst Du keine PubScreens öffnen?
Zitat:
Multiview hält durchaus während der Anzeigedauer "Kontakt" zu den 24 Bit Orginaldaten.
Üblicherweise wird die Source-Bitmap nach dem Konvertieren der Daten ins Ausgabeformat freigegeben. Ich glaube kaum, das Multiview das anders macht. Wenn man beim Speichern eine HAM-Bitmap erhält, dann sind das wohl keine Originaldaten mehr ;)

[ - Answer - Quote - Direct link - ]

2003-05-08, 15:51 h

Bluebird
Posts: 3260
User
@gni ahh einer der genug kohle hat fuer ne 16 mb voodoo oder wie ? , dann mal glueckwunsch aber
wer ne merlin im z2 modus pica 2 /2+ oder picollo mit nur 2 mb hat wird wissen das bilder groesser 1280x1024 nicht
mehr dargestellt werden koennen !
heute sind ja bilder mit 3000x2000 erst "HQ" und ich wette das sowas auach keine cv64 oder pica 4 mehr anzeigt ohne zu scalieren ;)

mfg Bluebird

[ - Answer - Quote - Direct link - ]


-1- 2 [ - Post reply - ]


amiga-news.de Forum > Amiga, AmigaOS 4 > Jpeg-Viewer [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.