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

amiga-news.de Forum > Amiga, AmigaOS 4 > Interesse an BMP-Reader für OS1.2? [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 [ - Beitrag schreiben - ]

15.03.2005, 21:12 Uhr

Ralf27
Posts: 2779
Nutzer
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 :D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 13:48 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Ralf27:
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?

IMHO ist das verschwendete Zeit. 1.2/1.3 sind lange obsolet.
Zitat:
* BMP2.x bis BMP4.x Unterstützung
Was soll das sein?
Zitat:
* 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)
1.2/1.3 können 5-bit bzw mit EHB 6-bit.

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 14:21 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von gni:
Zitat:
Ralf27:
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?

IMHO ist das verschwendete Zeit. 1.2/1.3 sind lange obsolet.
[/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:
* BMP2.x bis BMP4.x Unterstützung
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:
* 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)
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. :D

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

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 14:34 Uhr

aPEX
Posts: 4692
Nutzer
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 :bounce:

Bild: http://www.a1k.org/bilderlink/a1000_lorbeer.gif A1000 Phoenix Revival Project :commo: http://www.a1k.org



[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 14:46 Uhr

analogkid
Posts: 2394
Nutzer
wenn der Aufwand nicht allzu groß ist, fände ich es recht witzig. Also ich hätte Interesse.
--
Join us @ Sarkasmus-pur

:amiga: :dance1:

Talking about music is like dancing about architecture

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 15:27 Uhr

Amiga4ever
Posts: 537
Nutzer
Zitat:
Original von Ralf27:

Gibt es interesse an einen separaten BMP-Reader für OS1.2?


Cool, was neues für 1.2 *habenwill* :D
--
:commo: A2000, Blizzard2060/128MB, 2MB Chip-Ram, CV64/3D, OS 3.9
----------
:commo: A500T, Ematrix 530/32MB, OS 3.1
----------
:commo: A500T, Blizzard2060/96BM, 2MB Chip-Ram, OS 3.9

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 17:35 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von aPEX:
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 :bounce:

Bild: http://www.a1k.org/bilderlink/a1000_lorbeer.gif A1000 Phoenix Revival Project :commo: http://www.a1k.org


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? :D

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. :D


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. :D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 17:36 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Ralf27:
Zitat:
gni:
Zitat:
Ralf27:
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?

IMHO ist das verschwendete Zeit. 1.2/1.3 sind lange obsolet.
Ist es genau so absolet wie A1000, oder wie der Amiga an sich?
Amigas mit 1.2/1.3 sind obsolet, ja.
Zitat:
Es gibt bestimmt noch einige A500-User die ihre Kiste aufgerüstet haben (oder nicht) die eventuell so ein Programm gerne hätten.
Hochgerüstete Amigas haben mindestens 2.04. Warum sich den Zwängen von älteren OS-Versionen aussetzen?
Zitat:
Es wäre fast nur ein Neucompilierung, insgesamt aber ca. ein Tag "arbeit". Das ganze ist eigentlich ein Funprojekt von mir.
Ich dachte Du benutzt WritePixelLine8()? Was machst Du unter 1.2/1.3?
Zitat:
Zitat:
Zitat:
* BMP2.x bis BMP4.x Unterstützung
Was soll das sein?
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.
Woher hast Du diese absonderlichen Bezeichnungen "BMP2.x, BMP4.x"? Diese Bezeichnungen sind mir noch nie untergekommen.
Zitat:
1.2/1.3 kann auch Ham6, bzw. ist mir schon klar was OS1.2, OS1.3 kann. :D
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:
Denn von dir angesprochenen EHB-Mode nutze ich nicht. Weder auf OCS, noch auf AGA.
Der ist auch nur für OCS/ECS sinnvoll.

[ Dieser Beitrag wurde von gni am 16.03.2005 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 17:38 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von analogkid:
wenn der Aufwand nicht allzu groß ist, fände ich es recht witzig. Also ich hätte Interesse.
--
Join us @ Sarkasmus-pur


:amiga: :dance1:

Talking about music is like dancing about architecture


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. :D :D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 17:40 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Ralf27:
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. :D

Mit PPC-Karte sollte es gehen ;-)

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 17:48 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Hochgerüstete Amigas haben mindestens 2.04. Warum sich den Zwängen von älteren OS-Versionen aussetzen?
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:
Ich dachte Du benutzt WritePixelLine8()? Was machst Du unter 1.2/1.3?
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:
Woher hast Du diese absonderlichen Bezeichnungen "BMP2.x, BMP4.x"? Diese Bezeichnungen sind mir noch nie untergekommen.
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

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 17:50 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von gni:
Zitat:
Ralf27:
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. :D

Mit PPC-Karte sollte es gehen ;-)


Ja, das wäre mal ein Projekt für denn A1000. PPC-Turbokarte einbauen und am besten noch ein G5. :D

Das wäre mal ein echter, fetter Amiga. :D :D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 17:52 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Zitat:
Ralf27:
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. :D

Mit PPC-Karte sollte es gehen ;-)

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

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 17:57 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von whose:
Zitat:
Original von gni:
Zitat:
Ralf27:
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. :D

Mit PPC-Karte sollte es gehen ;-)

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


Das würde dem "Back to the Roots" eine neue Bedeutung geben. :lach:

Ein A1000 mit G5, hey, das wärs. Egal wie sinnvoll, aber das wärs. :P
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 18:25 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Ralf27:
Ich benutze WritePixelArray8.

Intern benutzt das bestimmt WritePixelLine8 ;-)
Zitat:
Unter 1.2/1.3 gibt es diese Funktion nicht, da hast Du recht. Deswegen würde das auch eine separates Programm geben.
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:
Zitat:
Woher hast Du diese absonderlichen Bezeichnungen "BMP2.x, BMP4.x"? Diese Bezeichnungen sind mir noch nie untergekommen.
Dies ist keine "absonderliche" Bezeichnung, sondern die ganz normale Bezeichnung.
Wer verwendet die?
Zitat:
Es gibt halt unterschiedliche BMP-Versionen. z.b. BMP V1 von Windows 1.0, BMP V4 ist von Windows95.
Das es unterschiedliche Versionen gibt, ist mir bekannt.
Zitat:
Ich denk mir mal das es für dich absonderlich ist, weil Du dich vermutlich nicht nicht mit BMP-Unterlagen beschäftigt hast.
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. ]

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 18:38 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Intern benutzt das bestimmt WritePixelLine8 ;-)
Darf sie ruhig, wie sie möchte. :D
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.
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:
Ich kenne das BMP-Format recht gut. Hast Du schon mal BMPs mit JPEG-Komprimierung gesehen? Willst Du diese auch unterstützen?
SCNR.


Jo, spezifiziere das Protokol und ich baus ein. :D :D :D

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. :angry:
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 18:40 Uhr

DrNOP
Posts: 4118
Nutzer
Zitat:
Original von Ralf27:
Es wäre fast nur ein Neucompilierung, insgesamt aber ca. ein Tag "arbeit".

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? :P
--
Es gibt keine Notbremse für all den technischen Humbug, mit dem wir unsere Zeit vertrödeln.

[ - Antworten - Zitieren - Direktlink - ]

16.03.2005, 22:48 Uhr

Ralf27
Posts: 2779
Nutzer
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. :D

[ Dieser Beitrag wurde von Ralf27 am 16.03.2005 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

17.03.2005, 09:28 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Ralf27:
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.

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:
Außerdem benutze ich kein C, sondern einfaches Basic. (Kein Scherz)
Respekt! :-)
Zitat:
Zitat:
Ich kenne das BMP-Format recht gut. Hast Du schon mal BMPs mit JPEG-Komprimierung gesehen? Willst Du diese auch unterstützen?
Jo, spezifiziere das Protokol und ich baus ein. :D :D :D
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:
Mir ist aber bis jetzt wirklich noch kein Programm bekannt das RLE24 benutzt und vermutlich werde ich es auch nicht einbauen.
RLE24 habe ich auch noch nicht in freier Wildbahn gesehen. AFAIK, ist das auch nur von OS/2 Feature.
Zitat:
Der 16Bit-Mode ist eh der Hammer, da er 4Bytes pro Pixel braucht!
Nö, der 16bit-Mode braucht 2 Byte. Die RGB-Anteile sind dann entweder 555 (15bit) oder 565 (16bit).
Zitat:
Der 32Bit-Mode ist auch so eine Sache. Wie bekomme ich z.b. 10Bit pro R G B zur Grafikkarte?
Indem Du daraus einen "passenden" Wert machst. Solche BMPs habe ich auch noch nie gesehen.
Zitat:
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. :angry:
Suchen ;-)

[ - Antworten - Zitieren - Direktlink - ]

17.03.2005, 12:59 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von gni:
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.

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. :D
Zitat:
Nö, der 16bit-Mode braucht 2 Byte. Die RGB-Anteile sind dann entweder 555 (15bit) oder 565 (16bit).
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:
Indem Du daraus einen "passenden" Wert machst. Solche BMPs habe ich auch noch nie gesehen.
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. :shock2: :D :D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

17.03.2005, 14:08 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Ralf27:
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*
Also, im ganzen Internet ist mir kein Dokument aufgefallen das das von Microsoft spezifiziert.
JPEG oder TopDown BMPs? BTW, es gibt sor BMPs die PNG-Komprimierung verwenden.
Zitat:
Zitat:
Nö, der 16bit-Mode braucht 2 Byte. Die RGB-Anteile sind dann entweder 555 (15bit) oder 565 (16bit).
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.
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:
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?
Nein.

[ - Antworten - Zitieren - Direktlink - ]

17.03.2005, 15:34 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von gni:
JPEG oder TopDown BMPs? BTW, es gibt sor BMPs die PNG-Komprimierung verwenden.

Die JPEG-Komprimierung in BMPs.
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.
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

[ - Antworten - Zitieren - Direktlink - ]

17.03.2005, 16:30 Uhr

gni
Posts: 1106
Nutzer
[/quote]
Ralf27:
Zitat:
Original von gni:
JPEG oder TopDown BMPs? BTW, es gibt sor BMPs die PNG-Komprimierung verwenden.

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. ]

[ - Antworten - Zitieren - Direktlink - ]

17.03.2005, 18:55 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
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.
Ich unterstütze nicht nur Header mit 40, sondern auch mit 12 und 108 bzw. ohne Headerl-Info (BMP V1).
Zitat:
Alphakanal gibt es bei BMP nicht, weder bei 16bit noch bei 32bit.
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:
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.

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. ]

[ - Antworten - Zitieren - Direktlink - ]

17.03.2005, 19:07 Uhr

Ralf27
Posts: 2779
Nutzer
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. :D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

18.03.2005, 11:07 Uhr

gni
Posts: 1106
Nutzer
[/quote]
Ralf27:
Ich unterstütze nicht nur Header mit 40, sondern auch mit 12 und 108 bzw. ohne Headerl-Info (BMP V1).
Zitat:
12 und 40 kenne ich. Was soll das sein ohne Headerl-Info? Und 108 Bytes ist der V4 Header?
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:
Fakt ist, das die Zeilebreite des Dekoderpuffers in *Bits* ein Vielfaches von 32 sein muß.
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.

[ - Antworten - Zitieren - Direktlink - ]

18.03.2005, 11:15 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Ralf27:
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.
---

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. ]

[ - Antworten - Zitieren - Direktlink - ]

18.03.2005, 12:11 Uhr

Ralf27
Posts: 2779
Nutzer
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.

Steht in der MS-Doku im MSDN und der BMP-Dekoder im AmiNet macht es auch so.



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! :D :D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

18.03.2005, 12:20 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
12 und 40 kenne ich. Was soll das sein ohne Headerl-Info? Und 108 Bytes ist der V4 Header?
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:
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.
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:
Warum soll es bei RLE-komprimnierten BMPs anders sein?
Es ist halt so, vielleicht um Bytes zu sparen. Aber zum anderen werden wieder Dummybytes rausgeworfen damit es "16Bit-rund" wird.
Zitat:
Was soll ich da sehen? Der Dekoder rundet die Zeilebreite immer auf das nächste Vielfache von 32.
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

[ - Antworten - Zitieren - Direktlink - ]

18.03.2005, 14:02 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Ralf27:
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.

Steht in der MS-Doku im MSDN und der BMP-Dekoder im AmiNet macht es auch so.

Es gibt für dieses "Problem" eine einfache Lösung: MS<>OS2

Ich bin mir nicht sicher, aber das könnte es sein.

Wieder falsch... 16/32Bit BMPs gibt es nur im Windows-Format.

[ - Antworten - Zitieren - Direktlink - ]


-1- 2 [ - Beitrag schreiben - ]


amiga-news.de Forum > Amiga, AmigaOS 4 > Interesse an BMP-Reader für OS1.2? [ - Suche - Neue Beiträge - Registrieren - Login - ]


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