DEUTSCHE VERSION |
|
Links | | | Forums | | | Comments | | | Report news |
Chat | | | Polls | | | Newsticker | | | Archive |
amiga-news.de Forum > Amiga, AmigaOS 4 > Interesse an BMP-Reader für OS1.2? | [ - Search - New posts - Register - Login - ] |
-1- 2 | [ - Post reply - ] |
2005-03-15, 21:12 h Ralf27 Posts: 2779 User |
Ich entwickle zur Zeit ein BMP-Reader für den Amiga, der ab OS2.04 läuft. Gibt es interesse an einen separaten BMP-Reader für OS1.2? Features bis jetzt(v0.5): * BMP2.x bis BMP4.x Unterstützung * 1,4,8 und 24Bit, RLE8-Dekodierung(weitere folgen) * Ausgabe: 1-, 2-, 4-und 8-Bit und 24Bit(CybergraphX), Grau16, Grau256, HAM6, HAM8, (bei OS1.2 halt "nur" 1- ,2- und 4-Bit, Grau16, HAM6) * Cacheoption(Bild im Arbeitsspeicher(Fast oder Chip), vordekodieren möglich) * Speichern * ab 512kb Arbeitsspeicher * weitere Features in Arbeit -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2005-03-16, 13:48 h gni Posts: 1106 User |
Zitat:IMHO ist das verschwendete Zeit. 1.2/1.3 sind lange obsolet. Zitat:Was soll das sein? Zitat:1.2/1.3 können 5-bit bzw mit EHB 6-bit. [ - Answer - Quote - Direct link - ] |
2005-03-16, 14:21 h Ralf27 Posts: 2779 User |
Zitat:[/quote] Ist es genau so absolet wie A1000, oder wie der Amiga an sich? Es gibt bestimmt noch einige A500-User die ihre Kiste aufgerüstet haben(oder nicht) die eventuell so ein Programm gerne hätten. Deswegen die Umfrage. Es wäre fast nur ein Neucompilierung, insgesamt aber ca. ein Tag "arbeit". Das ganze ist eigentlich ein Funprojekt von mir. Zitat:Was soll das sein? [/quote] Es gibt nicht *das* BMP, es gibt viel unterschiedliche BMP-Formate. Das eine kann z.b. nur bis 32768*32768, das andere bis 2G*2G-Pixel. Das eine hat z.b. eine feste Palette (BMP V1.x), das andere eine vorgegebene oder keine (16-, 24,- oder 32Bit). Es gibt Formate die unterstützen Kompression, andere nicht. Es gibt da einige Unterschiede. Zitat:Zitat:1.2/1.3 können 5-bit bzw mit EHB 6-bit. 1.2/1.3 kann auch Ham6, bzw. ist mir schon klar was OS1.2, OS1.3 kann. BMPs mit 8, 16, 24 oder 32-Bit werden eben heruntergerechnet auf 16Grau oder 4096 Farben-HAM6. Denn von dir angesprochenen EHB-Mode nutze ich nicht. Weder auf OCS, noch auf AGA. -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2005-03-16, 14:34 h aPEX Posts: 4692 User |
he, klar gibt es noch 1.3 user!!! aber ich glaube ein bmp-reader waere auf meinem A1000 sinnlos. trotzdem vielen dank das du dir da noch gedanken machst! -- cu, aPEX Bild: http://www.a1k.org/bilderlink/a1000_lorbeer.gif A1000 Phoenix Revival Project http://www.a1k.org [ - Answer - Quote - Direct link - ] |
2005-03-16, 14:46 h analogkid Posts: 2394 User |
wenn der Aufwand nicht allzu groß ist, fände ich es recht witzig. Also ich hätte Interesse. -- Join us @ Sarkasmus-pur Talking about music is like dancing about architecture [ - Answer - Quote - Direct link - ] |
2005-03-16, 15:27 h Amiga4ever Posts: 537 User |
Zitat: Cool, was neues für 1.2 *habenwill* -- A2000, Blizzard2060/128MB, 2MB Chip-Ram, CV64/3D, OS 3.9 ---------- A500T, Ematrix 530/32MB, OS 3.1 ---------- A500T, Blizzard2060/96BM, 2MB Chip-Ram, OS 3.9 [ - Answer - Quote - Direct link - ] |
2005-03-16, 17:35 h Ralf27 Posts: 2779 User |
Zitat: Wieso wäre es Sinnlos? 256kb? Vielleicht läuft es auch damit, wäre sehr gut möglich. Mein Programm braucht ohne Cachefunktion sehr wenig Arbeitsspeicher und kann so auch sehr große Bilder anzeigen, bis halt 2GBytes große Bilder(eigentlich 4GB, aber da gibt es das "vorzeichenbehaftete Problem") Aber da ist noch was, das Betriebssystem.. was hat denn der A1000 orginal? 1.0? 1.1? Welche OS-Betriebssystemroutinen hat er denn? Welche sind denn davon Bugfree? Witzig wäre es schon, interesant auch, aber es stimmt schon, eigentlich unsinnig. Aber das ist eben ein Hobby von mir. Es gibt ja schon einige BMP-Reader, auch einer der mit WarpUP alle BMP-Formate unterstützt und sehr schnell ist. Aber der läuft mit Sicherheit nicht auf dem A1000. Wenn wir schon beim A1000 sind: Ich würde mir gerne mal einen A1000 in Aktion ansehn und auch mal näher betrachten. Vorallem das Betriebssystem und die Routinen. -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2005-03-16, 17:36 h gni Posts: 1106 User |
Zitat:Amigas mit 1.2/1.3 sind obsolet, ja. Zitat:Hochgerüstete Amigas haben mindestens 2.04. Warum sich den Zwängen von älteren OS-Versionen aussetzen? Zitat:Ich dachte Du benutzt WritePixelLine8()? Was machst Du unter 1.2/1.3? Zitat:Woher hast Du diese absonderlichen Bezeichnungen "BMP2.x, BMP4.x"? Diese Bezeichnungen sind mir noch nie untergekommen.Zitat:Es gibt nicht *das* BMP, es gibt viel unterschiedliche BMP-Formate. Das eine kann z.b. nur bis 32768*32768, das andere bis 2G*2G-Pixel. Das eine hat z.b. eine feste Palette (BMP V1.x), das andere eine vorgegebene oder keine (16-, 24,- oder 32Bit). Es gibt Formate die unterstützen Kompression, andere nicht. Es gibt da einige Unterschiede.Zitat:Was soll das sein? Zitat:Warum willst Du dann unter 1.2/1.3 nur 16 Farben unterstützen, wenn auch 32 (5bit) gehen? Eventuell nur in LoRes, ist zu lange her ;-) Zitat:Der ist auch nur für OCS/ECS sinnvoll. [ Dieser Beitrag wurde von gni am 16.03.2005 editiert. ] [ - Answer - Quote - Direct link - ] |
2005-03-16, 17:38 h Ralf27 Posts: 2779 User |
Zitat: Es ist ein Hobby und es macht Spaß (was es ja machen soll). Außerdem würde ich gerne mal wieder meinen A500 rausholen und ihn wieder anwerfen. Leider hab ich bis jetzt noch nicht meinen A500 an den Beamer gehängt, aber das werd ich wohl bald nachholen. Ich kenn da schon Leuts die früher einen A500 hatten und an die Zeiten zurückdenken. Das würde bestimmt einige nette Abende am A500 ergeben. -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2005-03-16, 17:40 h gni Posts: 1106 User |
Zitat:Mit PPC-Karte sollte es gehen ;-) [ - Answer - Quote - Direct link - ] |
2005-03-16, 17:48 h Ralf27 Posts: 2779 User |
Zitat:Das mag sein, aber ich hab z.b. noch einen A500 denn ich bestimmt unter keinen Umständen aufrüsten werde. Wieso? Der ist mir so wie er ist am liebsten. Zitat:Nein, benutze ich nicht. Ich benutze WritePixelArray8. Unter 1.2/1.3 gibt es diese Funktion nicht, da hast Du recht. Deswegen würde das auch eine separates Programm geben. Mann kann ja jede Funktion des Betriebssystem nachprogrammieren, aber in diesem speziellen Fall würde ich halt etwas Hardwarenah programmieren und fertig. Ist zwar nicht nach dem Programmierrichtlinien, aber deswegen halt auch separat. Zitat:Dies ist keine "absonderliche" Bezeichnung, sondern die ganz normale Bezeichnung. Es gibt halt unterschiedliche BMP-Versionen. z.b. BMP V1 von Windows 1.0, BMP V4 ist von Windows95. Ich denk mir mal das es für dich absonderlich ist, weil Du dich vermutlich nicht nicht mit BMP-Unterlagen beschäftigt hast. -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2005-03-16, 17:50 h Ralf27 Posts: 2779 User |
Zitat: Ja, das wäre mal ein Projekt für denn A1000. PPC-Turbokarte einbauen und am besten noch ein G5. Das wäre mal ein echter, fetter Amiga. -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2005-03-16, 17:52 h whose Posts: 2156 User |
Zitat: Damit wäre ich vorsichtig nachdem apex schon so viele Projekte auf den Weg gebracht hat (an dieser Stelle: RESPEKT für Deine Leistung bei der Phoenix-Neuauflage!), traue ich ihm sogar zu, die nötigen Leute zu finden, um dem 1000er nen PPC zu verpassen Grüße [ - Answer - Quote - Direct link - ] |
2005-03-16, 17:57 h Ralf27 Posts: 2779 User |
Zitat: Das würde dem "Back to the Roots" eine neue Bedeutung geben. Ein A1000 mit G5, hey, das wärs. Egal wie sinnvoll, aber das wärs. -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2005-03-16, 18:25 h gni Posts: 1106 User |
Zitat:Intern benutzt das bestimmt WritePixelLine8 ;-) Zitat:Mit entsprechenden Checks kann es ein Programm bleiben. Auch wenn Du C benutzt, solltest Du dennoch beachten, das die meisten Laufzeitumgebungen erst ab 2.0 funktionieren. Zitat:Wer verwendet die?Zitat:Dies ist keine "absonderliche" Bezeichnung, sondern die ganz normale Bezeichnung. Zitat:Das es unterschiedliche Versionen gibt, ist mir bekannt. Zitat:Ich kenne das BMP-Format recht gut. Hast Du schon mal BMPs mit JPEG-Komprimierung gesehen? Willst Du diese auch unterstützen? SCNR. [ Dieser Beitrag wurde von gni am 16.03.2005 editiert. ] [ - Answer - Quote - Direct link - ] |
2005-03-16, 18:38 h Ralf27 Posts: 2779 User |
Zitat:Darf sie ruhig, wie sie möchte. Zitat:Ne, das geht ganz bestimmt nicht, denn das Programm wird komplett anderst. Z.b. keine ASL-Requester, der CybergraphX-Code kann komplett raus, sowie auch der "geht nicht auf OCS"-Code. Es wäre eigentlich ein Programm an einem Programm. Außerdem benutze ich kein C, sondern einfaches Basic. (Kein Scherz) Zitat: Jo, spezifiziere das Protokol und ich baus ein. Du hast schon recht, RLE4 und RLE8 benutzt fast kein Programm, fast. Mit z.b. PPaint kann man BMP mit RLE4 und RLE8 speichern. Mir ist aber bis jetzt wirklich noch kein Programm bekannt das RLE24 benutzt und vermutlich werde ich es auch nicht einbauen. Der 16Bit-Mode ist eh der Hammer, da er 4Bytes pro Pixel braucht! (24Bit=3Bytes pro Pixel). Der 32Bit-Mode ist auch so eine Sache. Wie bekomme ich z.b. 10Bit pro R G B zur Grafikkarte? Welche auf dem Amiga-Grafikkarte benutzt 32Bit? Die Voodoo? Ich glaub noch nicht mal die. Höchstens 24Bit+8Bit Alpha, das wars. Wenn ich denn einbauen sollte, dann reduziert auf 24Bit. Der 16Bit-Bild-Code hat eh mein Programm eben etwas aufgebläht und ich kann es noch nicht mal testen. Hab kein 16Bit-Bild zum testen. -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2005-03-16, 18:40 h DrNOP Posts: 4118 User |
Zitat:Und dann fragst du hier noch lange nach?? Da wird die Diskussion um den Sinn des ganzen länger als die Umsetzung - was für einen Sinn hat das? -- Es gibt keine Notbremse für all den technischen Humbug, mit dem wir unsere Zeit vertrödeln. [ - Answer - Quote - Direct link - ] |
2005-03-16, 22:48 h Ralf27 Posts: 2779 User |
Hab es eben mal testweise umgeschrieben. Das Programm ist ja 100% Basic. Ich hab auch die Cunky2Planar-Routine in Basic geschrieben. Die braucht aber "im OS1.2"-Mode jetzt stattliche 0,3 Sekunden auf einem 060er um einen Lowres-Screen von Chunky zu Planar zu wandeln. Will gar nicht wissen wie es auf einem 68000er aussehn würde. Da müßte ich wohl andere Geschütze auffahren. Da ich kein C kann müßte ich wohl auf ASM zurückgreifen. Ich werd das irgendwann mal machen, aber nicht in der nächsten Zeit. Inzwischen würde ich doch zu gerne wissen welche Befehle man noch unter OS1.1 zur Verfügung hat. [ Dieser Beitrag wurde von Ralf27 am 16.03.2005 editiert. ] [ - Answer - Quote - Direct link - ] |
2005-03-17, 09:28 h gni Posts: 1106 User |
Zitat:Eventuell fährst Du mit zwei Programmen wirklich besser. Es ist dennoch möglich alles in einem(!) Programm zu machen mit den *richtigen* Checks auf die OS-Version. Zitat:Respekt! :-) Zitat:Das war kein Scherz, MS hat JPEG-Komprimierung für BMP spezifiziert... Und wie sieht es mit TopDown-BMPs aus? Unterstützt Du die auch? *g*Zitat:Jo, spezifiziere das Protokol und ich baus ein. :D :D :D Zitat:RLE24 habe ich auch noch nicht in freier Wildbahn gesehen. AFAIK, ist das auch nur von OS/2 Feature. Zitat:Nö, der 16bit-Mode braucht 2 Byte. Die RGB-Anteile sind dann entweder 555 (15bit) oder 565 (16bit). Zitat:Indem Du daraus einen "passenden" Wert machst. Solche BMPs habe ich auch noch nie gesehen. Zitat:Suchen ;-) [ - Answer - Quote - Direct link - ] |
2005-03-17, 12:59 h Ralf27 Posts: 2779 User |
Zitat:Klar, möglich wäre es, aber wie schon geschrieben, das ist etwas was ich lieber sauber trenne. [quote] Das war kein Scherz, MS hat JPEG-Komprimierung für BMP spezifiziert... Und wie sieht es mit TopDown-BMPs aus? Unterstützt Du die auch? *g* [quote] Also, im ganzen Internet ist mir kein Dokument aufgefallen das das von Microsoft spezifiziert. Das mit den BMPs für Icone ist mir aufgefallen, aber das unterstütze ich nicht. Zitat:Zja, ich hab eben nochmal nachgesehn, es sind 4Byte, je nach Version. Vergess Alpha nicht. Der ist da auch noch dabei. Das ist ja das verrückte. Zitat:Ist mir klar, aus 10Bit mach ich 8Bit und fertig isses. Die Frage war aber eher gewesen ob es auf dem Amiga die Möglichkeit gibt diese Bilder wirklich auch in 10Bit Farbtiefe pro Kanal anzuzeigen? Aber wie mir scheint wäre das ganze nur mit einem Hack möglich. Es sieht so aus als würde CybergraphX das nicht unterstützen. Vielleicht geht das ja bald auf dem A1000. -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2005-03-17, 14:08 h gni Posts: 1106 User |
Zitat:JPEG oder TopDown BMPs? BTW, es gibt sor BMPs die PNG-Komprimierung verwenden. Zitat:Irgendwas mußt Du mißverstehen. 16bit sind immer 2 Byte und das Layout der RGB-Daten in diesen 16Bit habe ich Dir genannt. Man könnte mit anderen Anteilen arbeiten, aber nur die genannten werden von Windows für 16Bit-BMPs unterstützt.Zitat:Zja, ich hab eben nochmal nachgesehn, es sind 4Byte, je nach Version. Vergess Alpha nicht. Der ist da auch noch dabei. Das ist ja das verrückte. Zitat:Nein. [ - Answer - Quote - Direct link - ] |
2005-03-17, 15:34 h Ralf27 Posts: 2779 User |
Zitat:Die JPEG-Komprimierung in BMPs. Zitat:Der Aufbau der 16Bit und 32Bit-Daten werden in der RMaske, GMask und BMaske definiert. Du hast recht wenn du sagst das eigentlich nur zwei Varianten von Windows unterstützt werden. Aber dennoch geh ich lieber nach diesen Masken als nach reiner Vermutung. Außerdem hab ich den Dokumentationen auch AMaske in 16Bit gefunden. Insofern kann man nicht immer sicher gehn ob die Daten in 2Bytes gespeichert werden. Da müßte man wohl wirklich über die Länge im Header gehn. Vermutlich wäre die Vermutung von dir bei 99,99% der Fälle ein Volltreffer. Aber ich muß auch tippen das im Internet in Sachen BMP einiges geschrieben wird was nicht stimmt, bzw. die BMP-Versionen quer durcheinander gewürfelt. Z.b. steht in nicht jeder RLE-Dokumentation zu BMP das die Array auf 2 Byte kontrolliert werden sollte und sonst ein Dummy rein muß. Ohne RLE ist die Sache auf 4Byte (LONG) am Zeilenende zu kontrollieren. -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2005-03-17, 16:30 h gni Posts: 1106 User |
[/quote] Ralf27: Zitat:Die JPEG-Komprimierung in BMPs. [/quote] Das es das gibt, steht alles in der MS eigenen Dokumentation. [/quote] Der Aufbau der 16Bit und 32Bit-Daten werden in der RMaske, GMask und BMaske definiert. Du hast recht wenn du sagst das eigentlich nur zwei Varianten von Windows unterstützt werden. Aber dennoch geh ich lieber nach diesen Masken als nach reiner Vermutung. [/quote] Aus dem was Du schreibst, ist klar ersichtlich, das Du den Aufbau von 16/32 Bit BMPs *nicht* verstanden hast. Eventuell sind deine Informationen auch einfach nur falsch, zb. wenn Du bei Headergröße nur 40 akzeptierst oder Pad-Bytes vor den Bilddaten nicht überspringst. [/quote] Außerdem hab ich den Dokumentationen auch AMaske in 16Bit gefunden. Insofern kann man nicht immer sicher gehn ob die Daten in 2Bytes gespeichert werden. Da müßte man wohl wirklich über die Länge im Header gehn. [/quote] Alphakanal gibt es bei BMP nicht, weder bei 16bit noch bei 32bit. [/quote] Z.b. steht in nicht jeder RLE-Dokumentation zu BMP das die Array auf 2 Byte kontrolliert werden sollte und sonst ein Dummy rein muß. Ohne RLE ist die Sache auf 4Byte (LONG) am Zeilenende zu kontrollieren. [/quote] Habe ich nicht verstanden. Fakt ist, das die Zeilebreite des Dekoderpuffers in *Bits* ein Vielfaches von 32 sein muß. Im Aminet gibt es einen BMP-Dekoder mit Quellen. [ Dieser Beitrag wurde von gni am 17.03.2005 editiert. ] [ - Answer - Quote - Direct link - ] |
2005-03-17, 18:55 h Ralf27 Posts: 2779 User |
Zitat:Ich unterstütze nicht nur Header mit 40, sondern auch mit 12 und 108 bzw. ohne Headerl-Info (BMP V1). Zitat:Da unterliegst du einem Irrtum, denn Alpha ist drin. Wenn du schon die Dokumentation hast, dann lies sie mal durch. Oder wieso sollte im Header (Laenge 108) ein RMaske, GMaske, BMaske und AMaske definiert sein? Die AMaske ist die Alpha-Maske. Damit werden die Alpha-Channel-Bits im Long definiert. Zitat: Ja, du hast recht bei nichtkomprimierten BMPSs, aber liegst falsch bei RLE-komprimierten, denn da sind es 16bit. Wäre es anderst, dann würde mein Dekoder nicht funktionieren. Aber da er funktioniert, ist es wohl richtig. Aber ich muß auch tippen das im Internet viele falsche Infos über BMPs stehn. Das mußt ich leider auch feststellen. Wenn du schon im Aminet die BMP-Dekoder ansiehst (also denn Quellcode), dann schau dir einfach mal an wie der RLE-dekodierer läuft. [ Dieser Beitrag wurde von Ralf27 am 17.03.2005 editiert. ] [ - Answer - Quote - Direct link - ] |
2005-03-17, 19:07 h Ralf27 Posts: 2779 User |
Kleiner Auszug aus der Dokumentation: --- In the v4.x BMP format, 16- and 32-bit pixels are stored as little-endian 4-byte RGB values. Common masks for 32-bit data include RGB888 and RGB101010. These bit depths also require bitfields encoding and the mask fields in the bitmap header to define their pixel format. 24-bit bitmap data is always stored as 3-byte RGB values. --- Ich hab es natürlich noch nicht mit 16bit getestet und vielleicht ist auch meine Informationsquelle mies, aber bis jetzt hat sie sehr gute Infos geliefert. Es kann ja sein das es wirklich so ist, das 16bit in 2Bytes gespeichert wird. Aber hast du da infos? Doku oder Quellcodeausschnitte die das aufzeigen? Insofern würde ich das ganze doch lieber einfach mal an 16bit-Bildern austesten. -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2005-03-18, 11:07 h gni Posts: 1106 User |
[/quote] Ralf27: Ich unterstütze nicht nur Header mit 40, sondern auch mit 12 und 108 bzw. ohne Headerl-Info (BMP V1). Zitat:Oder wieso sollte im Header (Laenge 108) ein RMaske, GMaske, BMaske und AMaske definiert sein? Die AMaske ist die Alpha-Maske. Damit werden die Alpha-Channel-Bits im Long definiert. [/quote] Diese Felder hast Du nur bei Headern > 40 Byte. 16/32 Bit BMPs sind aber auch bei Headergröße 40 möglich. Deswegen sind die Masken entwder implizit gegeben oder stehen in bmi_Colors. Die RGB-Masken in den erweiterten Headern sin u.U. gültig. Wie Du die Alphamaske verwenden willst, ist mir nicht klar. [/quote] Zitat:Ja, du hast recht bei nichtkomprimierten BMPSs, aber liegst falsch bei RLE-komprimierten, denn da sind es 16bit. Wäre es anderst, dann würde mein Dekoder nicht funktionieren. Aber da er funktioniert, ist es wohl richtig. [/quote] Warum soll es bei RLE-komprimnierten BMPs anders sein? [/quote] Wenn du schon im Aminet die BMP-Dekoder ansiehst (also denn Quellcode), dann schau dir einfach mal an wie der RLE-dekodierer läuft. [/quote] Was soll ich da sehen? Der Dekoder rundet die Zeilebreite immer auf das nächste Vielfache von 32. [ - Answer - Quote - Direct link - ] |
2005-03-18, 11:15 h gni Posts: 1106 User |
Zitat:Definitiv falsch für 16bit. Die MS-Doku spricht explizit von WORD-Daten (16bit = 2Byte). Für 32bit ist es korrekt als DWORD (32bit = 4Bytes). Die Masken *können* im erweiterten Header stehen, müssen aber nicht. Dann sind die Standardmasken zu benutzen. Die Non-Stanadarmasken stehen immer in bmi_colors als DWORD. [/quote] Es kann ja sein das es wirklich so ist, das 16bit in 2Bytes gespeichert wird. Aber hast du da infos? Doku oder Quellcodeausschnitte die das aufzeigen? [/quote] Steht in der MS-Doku im MSDN und der BMP-Dekoder im AmiNet macht es auch so. [ Dieser Beitrag wurde von gni am 18.03.2005 editiert. ] [ - Answer - Quote - Direct link - ] |
2005-03-18, 12:11 h Ralf27 Posts: 2779 User |
Zitat: Es gibt für dieses "Problem" eine einfache Lösung: MS<>OS2 Ich bin mir nicht sicher, aber das könnte es sein. Um die Sache wirklich ganz zu klären: Wir brauchen wohl 16Bit-Bilder! -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2005-03-18, 12:20 h Ralf27 Posts: 2779 User |
Zitat:Ohne HeaderInfo ist es V1. Da sind auch die Breite und die Höhe noch in WORD-Länge angeben. Später werden es LONGs. Ja, 108 ist V4, da stehen auch die Masken drin. Da stehen auch Gamma-Korrekturen und noch mehr drin. Der Header ist voll von Infos die ich wohl nie unterstützen werde. Zitat:Natürlich sind die Infos nur vorhanden, wenn sie auch in den Headern stehn. Z.b. gibt es im BMP V1 noch nicht mal eine Farbpalette. Ja, auch nicht bei 1,4 oder 8 Bit. Die AMaske wird genau so benutzt wie die RMaske, GMaske oder BMaske. Die Masken sind LONGS und werden einfach über die LONGs bei 16 oder 32Bit gelegt. Die definieren die Bits die jeweils benutzt werden für die jeweilige Maske. Zitat:Es ist halt so, vielleicht um Bytes zu sparen. Aber zum anderen werden wieder Dummybytes rausgeworfen damit es "16Bit-rund" wird. Zitat:Dann schau nochmal hin. Nochmal: Ohne RLE=Eine Zeile durch 32Bit Teilbar, rest Dummy-Bytes Mit RLE=Keine feste Zeilenlänge, Zeilenende durch 00 00 definiert. Wie schonmal geschrieben: Da mein Enkoder funktioniert, ist es wohl so. Auch das unterwegs Dummies auf 16Bit rein müssen. Die Zeilen sind ja komprimiert und damit unterschiedlich lang. Müssen aber *nicht* "32Bit-rund" breit sein. Da bin ich mir ganz sicher. PS: Die MS-Dokumentation würde ich gerne mal sehn. Könntest du sie mir mal zukommen lassen? -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
2005-03-18, 14:02 h gni Posts: 1106 User |
Zitat:Wieder falsch... 16/32Bit BMPs gibt es nur im Windows-Format. [ - Answer - Quote - Direct link - ] |
-1- 2 | [ - Post reply - ] |
amiga-news.de Forum > Amiga, AmigaOS 4 > Interesse an BMP-Reader für OS1.2? | [ - Search - New posts - Register - Login - ] |
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |