amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > AROS und Amiga-Emulatoren > zerstörte Grafik im Grafikpublisher (Turboprint) [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

02.02.2014, 19:06 Uhr

Bernward
Posts: 113
Nutzer
Hallo,

Habe seit einigen Tagen ein seltsames Verhalten beim Versuch Grafiken über den Grafikpublisher (Irseesoft/Turboprint) anzuzeigen und zu drucken.

Jedes Mal wenn ich Bilder in den Grafikpublisher "ziehe", sieht man statt des Bildes nur einen Pixelbrei, ähnlich einem früheren Schlussbild beim Fernsehen (farbiges "rieseln"). Auch der Ausdruck wird nichts bzw. nur so wie das falsche Bild (das Bild ist also wirklich zerstört und es wird nicht nur zerstört angezeigt). Dabei ist es egal ob jpg, gif, iff, Farbe oder sw (hier sieht es ein bisschen anders aus, aber ist auch ganz und gar zerstört mit einer Art "Streifung").

Interessanterweise klappt aber z.B. der Druck und das Einladen von Grafiken in Finalwriter oer manch anderen Programmen mit Druckfunktion (latex) problemlos. Deshalb scheiden wohl einfache Hardwarefehler aus und ich vermute Softwareprobleme.

Der Fehler tritt erst seit einigen Wochen auf und ist mir zuerst gar nicht so aufgefallen (hatte zuerst gedacht, dass nur eine oder zwei Grafiken defekt sind).

Ach ja, noch etwas. Mir ist in letzter Zeit aufgefallen, dass beim kopieren von (sehr großen) Grafiken von CD es manchmal erst beim wiederholten Mal geklappt hat. Dabei haben die Bilder fast immer einen fehlerhaften unteren Rand (Streifen). Mit FXPaint konnte man diese fehlerhaften Bilder trotzdem laden und sie dann mit dem Fehler so abspeichern, dass auch die anderen Programme sie (dann mit dem Fehler) wieder laden konnten, die sich sonst geweigert haben.

Manchmal habe ich durch mehrfaches Kopieren auch eine fehlerfreie Version erhalten. Ich habe allerdings zum kopieren DOpus verwendet (vielleicht liegt es daran).

An meinem System habe ich in letzter Zeit kaum etwas geändert.

Es handelt sich um ein gut ausgebautes Amithlonsystem mit einem AMD-1800 Prozessor, mit dem ich schon bald 18 Jahre arbeite.

Die Systempartition (Workbench<4GB) auf der Turbprint installiert ist, habe ich mehrfach gespiegelt/gesichert.

Alle alten Sicherungen haben nach dem zurückspielen keine Besserung gezeigt, obwohl sie früher ohne das Problem waren.

Auch eine Neuinstallation von Turboprint hat keine Verbesserung ergeben.

Kann mir jemand einen Tipp geben, wie und wo ich nach dem Fehler suchen soll, oder hat jemand gar selbst schon dieses seltsame Verhalten erlebt.

Würde mich freuen, wenn mir jemand etwas helfen kann.

Vielen Dank im Voraus



[ - Antworten - Zitieren - Direktlink - ]

03.02.2014, 09:30 Uhr

fingus
Posts: 152
Nutzer
@Bernward:

Habe ich gestern noch gehabt, bei einige jpg-Dateien. Ich mach dann immer folgendes:

Mit ImageFXDatei laden und als ILBM abspeichern, geht immer.

[ - Antworten - Zitieren - Direktlink - ]

03.02.2014, 12:24 Uhr

Thore
Posts: 2266
Nutzer
Ich hatte "Farb-Schnee" grundsätzlich dann, wenn ein Programm die Grafiken im ChipRAM sucht, obwohl sie im FastRAM abgelegt werden. Wie es beim Graphic Publisher ist weiß ich aber nicht.

[ - Antworten - Zitieren - Direktlink - ]

03.02.2014, 14:59 Uhr

Bernward
Posts: 113
Nutzer
@fingus:

Danke für deinen Hinweis...

Ich denke, du beziehst dich auf den fehlerhaften Streifen bei Bildern am unteren Rand - übrigens tritt es meistens bei jpg-Bildern auf.

Ja mit ImageFX geht es ebenfalls, diese Bilder zu laden, ebenfalls mit FXpaint. Wenn man sie dann erneut abspeichert - egal in welchem Format - dann können sie auch von anderen Programmen geladen werden wie Photogenics, PPaint... die sich sonst weigern, solche Bilder direkt zu laden.

Allerdings haben sie dann einen festen fehlerhaften Streifen am unteren Rand.

Mich würde in dem Zusammenhang aber interessierten, ob jemand weiß, woran es liegt, dass solche Fehler entstehen (dann könnte man vielleicht etwas dagegen machen).

Eine Spur war für mich, dass es fast nur bei sehr großen Bildern und besonders bei jpg Bildern auftritt.

Die Größe kann aber auch nur einfach deshalb Schuld sein, da es hier mehr Chancen für einen Fehler gibt...

Eine weitere Spur ist eben auch, dass manche Programme wie FXPaint oder eben IMageFX damit umgehen können und andere nicht... interessant wäre auch hier das warum...

Eine dritte Spur vermute ich in der Art, wie solche Grafiken gespeichert werden. Ich komme darauf, da ein häufigerer Kopierversuch manchmal zu guten bzw. besseren Grafiken führt. Auch habe ich bemerkt, dass beim Kopieren mit DOpus viel häufiger Fehler passieren als z.B. beim Kopieren mit doscontrol (habe dazu mehrfach CDs mit mehreren tausend Grafiken kopiert, da konnte man das direkt vergleichen). Also könnte das zerstören der Grafiken etwas mit der Art des Kopiervorgangs zu tun haben. Beim Kopieren über die Shell tritt der Fehler auch so gut wie gar nicht auf. deshalb klone ich Festplatten gern mit dem copy Befehl... Aber DOpus ist halt viel bequemer...

[ - Antworten - Zitieren - Direktlink - ]

04.02.2014, 03:11 Uhr

angel77
Posts: 832
Nutzer
Ich rate ja schon seit Jahren bei jeder sich mir bietenden Gelegenheit zu DOSControl ... ;)

Ansonsten fällt mir bei dem Verhalten nur Speicherfehler ein (sind die RAMs ok?) oder vielleicht etwas mit den Datatypes.

Ich habe selber kein Amithlon, daher kann ich leider sonst nicht wirklich was zur Lösungsfindung beitragen.

vlg,

@ngel
--
http://www.privatepassion.de - @ngel's private Seite

[ - Antworten - Zitieren - Direktlink - ]

24.02.2014, 23:10 Uhr

Bernward
Posts: 113
Nutzer
@angel77:

Danke für deine Tipps.

Habe versucht weiter zu testen. Das verrückte, seit 1995 gab es noch nie ein derartiges Problem mit dem Grafikpublisher, er hat immer anstandslos fast 20 Jahre problemlos funktioniert. Jetzt plötzlich macht er Zicken. Das andere verrückte ist, dass wenn man die gleichen Grafiken in Finalwriter 8ODER cYBERSHOW9 einlädt und dann druckt geht alles anstandslos. Deshalb kann es meiner Meinung auch nicht am Gesamtsystem liegen (oder verschiedene Programme reagieren verschieden empfindlich).

Hab es dennoch getestet. Andere Rams rein, Andere Datatypes, welche von älteren Sicherungen - wie erwartet keine Änderung.

Das einzige was ich in letzter Zeit mal geändert habe ist, dass ich die HDs von 120 GB auf 160 GB in der HDToolbox geändert habe (sind 160er, automatisch wurden aber nur 120er erkannt). Das musste ich per Hand machen (Werte per Hand eintragen, da nicht automatisch erkannt). Möglicherweise habe ich hier einen Fehler gemacht oder die GRafiken liegen jetzt in einem Bereich, in dem sie seltsam behandelt werden (werde ich noch einmal überprüfen).

Vielen Dank

Bernward
PS: Kann ich eigentlich hier Grafiken als Beispiel hochladen?

[ - Antworten - Zitieren - Direktlink - ]

25.02.2014, 09:02 Uhr

Thore
Posts: 2266
Nutzer
Was Du hier mal machen kannst:
1. Backup deiner Platte
2. Ein oder mehrere große Dateien auf die Platte kopieren und schauen ob es dann zu merkwürdigen Phänomenen kommt, z.B. daß das System kaputt geht oder Dateien nicht mehr ausführbar sind, Read/Write Errors etc. Dann stimmt die Offset-Berechnung der Festplatte tatsächlich nicht. (Deshalb auch vorher unbedingt ein Backup machen)

Wenn das nämlich der Fall ist, steht deinen Daten ein langsamer Tod bevor.

Allerdings dürften dann die gleichen Daten auf der Platte mit keinem Programm geöffnet werden können, also überall Grafikfehler kommen, oder ausführbare Programme Fehler werfen.

[ - Antworten - Zitieren - Direktlink - ]

02.03.2014, 17:32 Uhr

padrino
Posts: 575
Nutzer
Boah,

ich glaube mit TP hab ich schon 10 Jahre nicht mehr gedruckt.
Glaube mich vage zu erinnern, dass ich früher auch mal Probleme hatte.
Hmm, ob das fast/chip mem Problem war?
Glaube, es hatte was mit der 3rd party library zu tun, die der GP.
Wie hieß die noch?
Mal geprüft, ob die durch eine ältere Version ersetzt wurde?

CU,
Mario

[ - Antworten - Zitieren - Direktlink - ]

02.03.2014, 19:01 Uhr

AmigaHarry
Posts: 1637
Nutzer
Ich bin mir jetzt nicht ganz sicher, aber der Publisher nutzt doch die Datatypes zum Laden (FW, ImageFX usw. haben, soweit ich noch weis) eigenen Routinen). Villeicht liegt da dein Problem.......
--
Life starts at '030, fun at '040, impotence at '86!

[ - Antworten - Zitieren - Direktlink - ]

12.03.2014, 02:43 Uhr

padrino
Posts: 575
Nutzer
@AmigaHarry:

Kann's leider nicht testen, da ich kein Amiga System im Moment habe.
Aber ich könnte schwören, dass das eben nicht direkt über die Datatypes sondern über eine extra library,glaub mit "media" im Namen...

[ - Antworten - Zitieren - Direktlink - ]

12.03.2014, 08:24 Uhr

AmigaHarry
Posts: 1637
Nutzer
Soweit ich weis sucht er nur nach der multipic.library und die ist im TP: - Verzeichnis...... Inwieweit die dann selbst die Bilder lädt oder ob die dann auf Datatypes zugreift weis ich auch nicht genau.....
Ich hatte dieses Problem nur einmal an meinem A3000T/PPC, aber da lags am PPC, der damals, aus welchen Gründen auch immer, mit mit den WarpDatatypes nicht wollte. Daher für mich das Indiz, das der Publisher die Datatypes benutzt.....
--
Life starts at '030, fun at '040, impotence at '86!

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > AROS und Amiga-Emulatoren > zerstörte Grafik im Grafikpublisher (Turboprint) [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1997-2019 by amiga-news.de - alle Rechte vorbehalten.
.