|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > IFF-Bilder mit PPT 6.18 | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
|
20.07.2005, 14:48 Uhr Ralf27 Posts: 2779 Nutzer |
Hab eben was seltsames entdeckt: Wenn ich mit PPT 6.18 (aus dem Aminet) Bilder ins IFF-ILBM 24-Format wandle, dann können es andere Programm nicht mehr lesen. Also hab ich mir mal die Bildatei angesehn und hab einen ANNO-Chunk gefunden. Die Länge des ANNO-Chunk die dort angegeben ist past aber nicht richtig zu diesem Chunk, sodas die folgenden Chunk quasi von anderen Programm nicht gefunden werden, außer sie durchsuchen die Datei mit der BrutalForce-Methode, was ja auch nicht die feine Art ist. Also die große Frage: Wenn jetzt ein Chunk eine ungerade Anzahl an Bytes besitzt, müssen dann noch Füllbytes rein? Es scheint mir so das PPT auf volle LONGs geht. Was steht denn in den Standards zu IFF-ILBM? Müssen da dann Füllbytes rein? Wenn ja, auf Word oder gar auf Longs? Bezieht sich die Längenangabe im Chunk auf die Länge mit oder ohne Füllbytes? (bei PPT wohl ohne, was ich auch eigentlich annehme) Den das hat mich eben wirklich sehr irritiert als ich mit meinem Programm ein Bild laden wollte und er mir gemeldet hat das er kein BODY finden kann. PS: PPT ist ein recht interesantes Programm. Hm, ich finde es auch seltsam das PPT bei einem 24Bit-Bild ein CMAP-Chunk mit 4Bytes länge abspeichert... -- http://www.alternativercomputerclub.de.vu [ Dieser Beitrag wurde von Ralf27 am 20.07.2005 um 14:50 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 15:39 Uhr Gazelle Posts: 151 Nutzer |
Zitat: Ja. Es muss auf eine gerade Anzahl von Bytes gefüllt werden, wobei die Füllbytes NICHT in der Längenangabe des Chunks enthalten sind. Ob auf 4Bytes oder 2Bytes gerundet werden muss kann ich jetzt nicht sagen. Auf der DeveloperCD ist die Beschreibung drauf, AFAIK. Wikipedia meint einfach nur auf eine gerade Anzahl zu runden: Zitat: [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 15:42 Uhr thomas Posts: 7716 Nutzer |
Die Länge bezieht sich auf die reinen Daten, ohne Füllbytes und es wird ggf. genau ein Füllbyte eingefügt. Ich denke, PPT ist ein recht schrottiges Programm. Mehr Informationen zu IFF findest du hier: http://www.users.bigpond.com/james.jacobs/reg/iff.html Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 15:52 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Hm, leider kann ich damit die IFF-Bilder von diesem Prog nicht lesen, da da wohl 2 (  ) FüllBytes drin sind. Finde ich recht seltsam. Ich werde wohl eine Ausnahmeregelung in mein Prog einbauen, sodas auch diese Bilder gelesen werden können.PPT hat mir recht gute Dienste geleistet in Sachen konvertieren. Hab hier ein ca 5000*8000*24 großes JPEG-Bild, das ich so auf IFF-ILBM-24 bringen konnte und das ohne 256MB-Arbeitsspeicher zu benötigen. PPT hat da ein 128MB-Swapfile aufgebaut und gut war. Allerdings kann PPT wohl keine 24Bit-BMPs, was ja für mich interesanter gewesen wäre.  Allerdings bringt mich die Fullbytesstory auch etwas in wanken. Wie kommst du eigentlich darauf das PPT schrottig ist? Was gefällt dir daran nicht? -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 16:01 Uhr thomas Posts: 7716 Nutzer |
Wenn es schrottige Dateien schreibt, taugt es nichts. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 19:14 Uhr DariusBrewka Posts: 899 [Benutzer gesperrt] |
Da muss ich Thomas leider Recht geben, ich habe mit PPT nur Probleme gehabt. Es gab nicht ein mal, wo es nicht abgeschmiert ist, zum Konvertieren von Bildern gibt es sicher noch massig vernünftige Alternativen. [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 19:56 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Hm, ich hatte noch keine Abstürze die auf das Programm zurückzuführen waren. Allerdings hab ich das Programm auch nicht vollkommend ausgenutzt bzw. alle Funktionen benutzt. Das Problem ist, das ich sehr große Bilder habe und "nur" 128MB Arbeitsspeicher auf dem großen Amiga. Und da PPT einen Festplattencache unterstützt (quasi VMEM, aber nicht das gleiche) kann ich halt auch damit extremgroße Bilder konvertieren. Mit was für einem Amigatool kann ich denn extrem große Bilder konvertieren die bei weitem nicht in den Arbeitsspeicher passen? (Beispiel: JPG ->BMP24Bit) -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 21:22 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:Der Link ist recht gut. Ich wußte gar nicht das es *so* viele Chunks gibt. Da wird man ja quasi erschlagen. Aber leider hab ich da ja noch das Englischproblem, ich versteh es kaum.  PS: Ich hab ein Programm gefunden das die IFF-Bilder von PPT akzeptiert -> Multiview. Ich weis jetzt gar nicht mehr was für ein Datatyp ich da jetzt damals installiert habe... -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 21:25 Uhr Ralf27 Posts: 2779 Nutzer |
Nochwas: Wenn jetzt die Tage der Amiga seinen 20er feiert, dann wurde wohl das IFF-Format wohl schon vor seiner Vorstellung festgelegt. Alle Achtung. Ich wüßte auch zu gerne wie lange vorher schon die Softwarefirmen den Amiga zum testen hatten, bzw. um darauf Programm zu entwickeln und zu testen. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 21:53 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das IFF-Format stammt von Electronic Arts, nicht von Commodore. Es wurde auch nicht ausschließlich für den Amiga entwickelt, auch wenn Amiga-Entwickler beteiligt waren. Und es wurde auch auf dem Macintosh sehr intensiv genutzt. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 22:25 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:Ich hab nicht behauptet das es von Commodore ist. Es wurde ja im Januar 1985 herrausgegeben. Also war es mehr Zufall das der Amiga im Sommer 1985 herrausgekommen und es quasi auf dem Amiga Standard wurde? Nunja, eigentlich mehr "Gott sei dank", wenn jeder seine eigene Suppe gekocht hätte... -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 22:26 Uhr Ralf27 Posts: 2779 Nutzer |
Die Frage ist jetzt viel mehr, was für ein Konverter könnte ich jetzt benutzen um übergroße Bilder zu konvertieren? -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 22:32 Uhr Holger Posts: 8116 Nutzer |
Für einen Zufall halte ich das nicht. Wofür brauchst Du denn überhaupt diesen Konverter? Wenn die Bilder schon so groß sind, daß typische Konvertierungsprogramme daran scheitern, welche Amiga-Tools verarbeiten dann diese Bild nach der Umwandlung? mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 22:33 Uhr Wishmaster Posts: 140 Nutzer |
@Ralf27: versuch mal Arteffect, ich glaube das verwendet auch Swapfiles. [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 22:46 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Zja, mein Programm kann es noch nach der Konvertierung verarbeiten. Bis jetzt geht es bis 32767*32767*24, später aber bis 2G*2G... also theoretisch. Dateigröße bis 2GB. (eventuell später bis 4GB, aber eher unwahrscheinlich).Das Problem ist zur Zeit nur, das es halt quasi "nur" ein BMP-Viewer ist (ok, mit eingeschränktem IFF-ILBM-Support). Das besagte Bild ist übrigens aus dem Scanner und haut komprimiert mit 88MB auf die Waage.  Das größte Bild das ich habe ist 700MB (unkomprimiert) groß.-- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2005, 22:48 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:Geht leider auch nicht, kein VMEM. Jedenfalls in der Version die ich hier habe (Aminet). -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2005, 17:32 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: ArtEffect bekommst Du schon für knapp 15 EUR. -- http://www.norman-interactive.com [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2005, 18:40 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: djpeg macht genau das was ich brauche und liegt im Aminet. Somit benötige ich ArtEffect nicht, bzw. kann es denn die 15Euro-Version? Ich meinte der Konvertieren von übergroßen Bildern? -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2005, 18:56 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: Die "15 Euro Version" ist die Vollversion von ArtEffect 4.0. Da es Virtuellen Speicher benutzt, kannst Du praktisch beliebig große Bilder damit bearbeiten. Da ich aber 144MB Speicher in meiner Kiste habe... -- http://www.norman-interactive.com [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2005, 20:26 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Ich hab 128MB+2MB Chip, aber das reicht bei einigen Bildern von mir einfach nicht aus. Da ich eine BPPC habe, könnte ich auch 256MB drauf machen, das dürfte dann für die meisten Bilder ausreichen. Mal sehn, vielleicht mach ich das auch noch. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2005, 21:18 Uhr thomas Posts: 7716 Nutzer |
Warum schreibst du nicht selbst einen Converter ? Die jpeg.library gibt es im Aminet, damit kann man sehr einfach JPEG-Dateien laden und wenn ich mich recht erinnere, geht das auch Zeilenweise. Wie eine IFF-Datei aufgebaut ist, findest du unter dem Link, den ich dir gegeben habe. Wenn du Probleme hast, kannst du ja fragen. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2005, 21:26 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Hm, du bringst mich da auf gedanken... Wieso eigentlich nicht?Allerings hab ich schon bei einer iff.lib (weis nicht mehr genau welche, nicht die vom os) schon eine böse überraschung mit dem decomp-Befehl erlebt, der eigentlich so nicht richtig einsetzbar war. Jedenfalls ging es nur richtig, wenn man das ganze Bild komplett in den Arbeitsspeicher läd und auch gleich komplett dekodieren läßt. Aber nunja, meine Dekomprimierungsroutinen für IFF-ILBM sind inzwischen sogar in Basic recht schnell geworden. Also, das mit der JPEG-Story muß ich mir auch mal ansehn. Aber ich werd erst mal mein aktuelles Projekt weiter gedeien lassen, wenn ich wieder etwas mehr Zeit habe. Ich glaub ich bin aber dennoch kurz auf den Geschmack gekommen kurz mal im Aminet die Lib zu laden und sie mir mal anzusehn. Danke für den Tip! -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2005, 22:31 Uhr Ralf27 Posts: 2779 Nutzer |
@thomas: Hab mir eben die Lib angesehn. Ich hab ein Demo gefunden das vermutlich Zeilenweise direkt von Disk liest, aber irgendwie schreibt es das ganze in ein Buffer das so groß ist wie das ganze Bild und das ganze läuft irgendwie über HOOKs? Die Dinger hab ich noch nie richtig verstanden. Da steht zwar auch was im MBasic-Handbuch, aber dennoch ist es für mich ein chinesisches Dorf... Eigentlich ist mein BMP-Reader ja "nur" ein BMP-Reader, der auch inzwischen einen "innofiziellen" IFF-ILBM-Support hat für "BMP-konforme IFF-ILBM-Formate". Aber mein eigentliches Problem ist ja mit djpeg ja schon behoben, das ja meine Bilder ja auch mit einer Auslagerungs-Datei auf der Festplatte konvertiert. Ich hoffe das ich bald mein Programm weiterentwickeln kann. Allerdings bin ich jetzt beim umwandeln von meinem Programm von Basic-Befehle auf Systembefehle wirklich auf eine Hürden gestoßen die ich erst umschiffen muß. Das eine ist z.b. die Palettenstory, die ja erst ab OS3.0 wohl mit 32Bit läuft und davor mit 12Bit. Ich will ja ab OS2.04 mein Prog laufen lassen. Aber alles kann man irgendwie regeln. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2005, 23:43 Uhr MaikG Posts: 5172 Nutzer |
>Aber nunja, meine Dekomprimierungsroutinen für IFF-ILBM >sind inzwischen sogar in Basic recht schnell geworden. Im Beispiel von MB zum Anzeigen von IFF-ILBM ist eine Dekomp. Routine in ASM dabei. [ - Antworten - Zitieren - Direktlink - ] |
|
30.07.2005, 00:00 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Es gibt auch eine Lib die einen Dekomp-Befehl behinhaltet, aber leider geht der nur richtig wenn er das ganze Bild auf einem Rutsch "durchziehen" kann. Die Paramter lassen es nicht anderst zu, bzw. würde es schon gehn, wenn man schon vorher weis wieviel Bytes die Komprimierte Zeile im Bild hat. Und das kann man vorher wirklich sehr schlecht wissen. Ich hab mir auch schon überlegt mit so eine ASM-Routine zusammenzubauen. Aber das mach ich am Schluss wenn es ans optimieren geht, bzw. eventuell in Modulform, so das auch die C-Coder es mal versuchen können. Ich geh ja mal davon aus das C z.b. auf einem 060er mehr rausholt.Eigentlich wäre diese Routine wirklich sehr einfach, wenn die Datei komplett im Speicher ist und das entpackte Bild auch im Hauptspeicher ist. Allerdings kann man dann auch eine fertige Library benutzen. Anderst sieht es aus wenn es von Disk geladen werden muß, dekomprimiert und dann noch umgerechnet wird (Bildformat). Das kann schon recht komplex werden, wenn man die einzelnen Schritte mit Caches unterstützt, was vorallem bei der Dateiladerountine eine enorme Beschleunigung bringt. Und das ganze muß dann auch noch Zeilenweise laufen, da ja das Programm ja extra dafür da ist um übergroße Bilder anzeigen zu können die halt nicht in denn Arbeitsspeicher passen. Ich hab noch einige Ideen für mein BMP-Reader, allerdings fehlt mir die Zeit. Ich hab halt immer nur kurz Zeit und da finde ich keine Muße da weiter zu machen. PS: Ehrlichgetippt würde ich gerne C können. Ich arbeite indirekt auch daran.  -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
30.07.2005, 12:22 Uhr thomas Posts: 7716 Nutzer |
@Ralf27: Falls es dich noch interressiert, ich habe mal so einen Converter geschrieben: http://thomas-rapp.homepage.t-online.de/downloads/jpeg2iff.lha Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
01.08.2005, 11:12 Uhr gni Posts: 1106 Nutzer |
Zitat:Soweit ich weis, kann PPT 24-Bit BMPs sowohl Laden als auch Speichern. [ - Antworten - Zitieren - Direktlink - ] |
|
01.08.2005, 11:14 Uhr gni Posts: 1106 Nutzer |
Zitat:Was soll denn das sein? [ - Antworten - Zitieren - Direktlink - ] |
|
01.08.2005, 12:18 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Die Truecolor (24-Bit)-Option kann man bei BMP nicht auswählen. Somit kann man BMPs mit 24Bit wohl auch nich speichern. Das Testbild war übrigens auch in 24Bit. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
01.08.2005, 12:22 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Nun, ich dachte mir das sich da noch jemand meldet Also, bei BMP gibt es folgende Farbtiefen: 1,4,8,16,24,32-Bit. Mein Programm unterstützt 1,4,8 und 24. Und für jede Farbtiefe habe ich eine spezielle Darstellungsroutine geschrieben. Eigentlich sind diese nicht für planare Daten geeignet, aber wenn man vorher ein IFF-ILBM-Bild läd das genau diese Farbtiefe hat, dann kann mein Programm diese auch anzeigen. Dies ist als Bonus zu sehn, denn eigentlich ist es ja ein reiner BMP-Viewer. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > IFF-Bilder mit PPT 6.18 | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|