Diskussion:Windows Bitmap/Archiv

message: Sicher, dass als Farbtiefen auch 16 und 32 Bit zulässig sind? Ich war bisher immer im Glauben, es gingen nur 24 Bit. Mr. Anderson 21:56, 18. Dez 2004 (CET)
thread_title:  Bit 

message: Was ist damit gemeint, dass die Werte im Zweierkomplement gespeichert werden?
Am Beispiel der Bildgröße müsste ja zum Beispiel ein 32x32 Pixel großes Bitmap dann die Werte "0E FF FF FF" enthalten. In der Tat wird aber tatsächlich "20 00 00 00" gespeichert. Also kein Zweierkomplement. Ist vielleicht etwas anderes gemeint? Ist die Äußerung vielleicht komplett falsch? Ich bitte um Aufklärung. --Mike Becker 12:00, 29. März 2010 (CEST)
replies: text: Ich weiß nicht ob ich Deine Frage richtig verstehe, aber das Zweierkomplement muss doch nur tatsächlich gebildet werden, wenn ein negativer Wert vorliegt. (also z. B. wenn die Zeilen, abweichend vom Üblichen, von oben nach unten gespeichert werden) —Falk  Palaver … 01:36, 7. Jun. 2010 (CEST)
thread_title:  LONG bei Bildgröße 

message: Die Byte-Größen der verschiedenen Werte in den Headern stehen im Widerspruch zur englischen Wikipedia und einigen anderen Quellen im Internet. Ich weiß aber nicht, wer recht hat
:Welcher Wert ist in der en. WP anders? --Phrood 12:01, 10. Sep. 2007 (CEST)
replies: text: "Die Größe der Bilddaten beträgt biWidth×biHeight×biBitCount/8 wenn biCompression=BI_RGB". Das ist in der en. WP anders, dort wird noch ein Padding hinzugerechnet. Der korrekte Wert wäre also: ((biWidth*bitCount/8)+(4-((biWidth*bitCount/8)%4)))*biHeight. Sollte man aber vielleicht statt der Formel ein paar erklärende Sätze, wie in der en. WP einbauen. (nicht signierter Beitrag von 91.21.188.61 (Diskussion) 12:30, 30. Aug. 2010 (CEST)

text: Korrigiert. --Phrood 19:17, 23. Mär. 2008 (CET)
thread_title:  header 

message: Hab jetzt mal nen bissl damit rumgebastelt und mir so üebrlegt, das 19778 als Code
für das Dateiformat "Windows Bitmap" falsch sein müsste
da: 19778 = 0x4D42 = "MB"
und "BM" aber 0x424D ist, also 16973.
Photoshop speichert das auch als 0x424D ab - ob das mal jemand bestätigen könnte.
M.f.G. 3rik
:Du vergisst, dass die Werte - wie bei Intel-Prozessoren üblich - in der Little-Endian-Konvention abgespeichert werden (steht auch so im Artikel). Die Bytefolge "B" (0x42), "M" (0x4D) wird zwar in dieser Reihenfolge in der Datei abgespeichert, da die Signatur aber als Short interpretiert wird, repräsentiert sie in Wirklichkeit den Wert 0x4D42, also 19778. --Phrood 02:45, 25. Sep. 2007 (CEST)
thread_title:  BM = 16973 ? 

message: Ich habe gerade die Begriffe PNG und BMP nachgeschlagen.
Zwei ausgezeichnete Artikel. 
Leider für den schnellen Ueberblick für einen Laien sehr technisch.
Ich vermisse bei diesem Beitrag über BMP die bei PNG vorhandenen, für Unkundige sehr nützlichen Absätze "Vorteile" und "Nachteile", die einen guten Ueberblick über PNG im Vergleich zu anderen Formaten geben, wenn man sich mit den Sachen nicht auskennt.
Das wäre hier auch sehr nützlich.
Gruss, Harald Andres
(nicht signierter Beitrag von Harald Andres Schmid (Diskussion | Beiträge) 22:31, 2. Mär. 2009 (CET)
replies: text: So schön? Curtis Newton ↯ 13:41, 25. Mär. 2010 (CET)
thread_title:  Vorteile und Nachteile 

message: Warum sollte ich .bmp verwenden und nicht etwa .jpg ? (nicht signierter Beitrag von Hwy2001 (Diskussion | Beiträge) 22:58, 29. Aug. 2008 (CEST)
replies: text: jpg-Bilder sind anders als BMP-Bilder verlustbehaftet. Dafür benötigen sie erheblich weniger weniger Speicherplatz. Man muss halt selber wissen was einem im jeweiligen Fall wichtiger ist. Ich hoffe das konnte die Frage beantworten. (nicht signierter Beitrag von 91.46.54.188 (Diskussion | Beiträge) 19:23, 12. Sep. 2008 (CEST)
thread_title:  Vorteile und Nachteile ? 

message: BMPs gibt es in drei verschiedenen Versionen. Die meisten BMP-Dateien liegen in der Version 3 vor; es gibt keine früheren Versionen. Die späteren Versionen 4 und 5 sind höchst selten anzutreffen.
Das kann man so nicht stehen lassen.
Mir sind 7 verschiedene Versionen von Bitmap bekannt, wenn sich auch nicht alle davon auf das Betriebssystem Windows beziehen.
Unter Windows gibt es die Versionen 1 bis 5, die Versionsnummern beziehen sich dabei auf die Windows Version, dokumentiert sind die Formate im jeweiligen SDK. Die anderen beiden Versionen finden sich in OS/2, dokumentiert in der Presentation Manager Programming Reference, hier gibt es die Versionen 1 und 2, ebenfalls passend zur Version des Betriebssystems.
Der weitaus größte Anteil an bmp-Dateien dürften Windows 3.x Bitmaps sein, soweit ganz richtig. Frühere Versionen gibt es sehr wohl und zwar erheblich öfter, als die späteren Versionen. Dabei handelt es sich um die Gruppe der OS/2 1.0 oder Windows 2.0 Bitmaps. Liegen diese als bottom-up vor, sind die beiden Formate praktisch nicht zu unterscheiden. top-down wird nur von Windows 2.0 Bitmaps unterstützt, hier sieht es dann auch schwer aus mit der Lesbarkeit durch Programme. PaintShopPro9 kann z.B. solche Dateien lesen, die Windows Bild und Fax Anzeige von Windows XP, der Internet Explorer 7 und Firefox 3 hingegen nicht. Auch das aktuelle Windows SDK unterstützt hier nur die OS/2 1.0 Variante mit bottom-up. Verschwindend gering ist der Anteil an Dateien mit der Windows Version 1 (noch keines gefunden), OS/2 2.0 und Windows 4 und 5. Da wird es dann auch mit der Unterstützung durch Anzeige- und Bearbeitungs-Programme schwierig.
Die Frage ist, ob man den Artikel hier um die Windows Versionen erweitert und einen OS/2 Bitmap Artikel neu anlegt oder wie in der englischen Version die Bitmaps in einem Artikel unter anderem Titel zusammenfasst.
Peter. (nicht signierter Beitrag von 80.128.185.66 (Diskussion | Beiträge) 20:15, 21. Feb. 2009 (CEST)
thread_title:  Versionen 

message: image/bmp kann nicht korrekt sein, da ein Mime-Type dieses Namens nur von IANA vergeben werden kann. -- Xypron 11:54, 20. Jul. 2011 (CEST)
thread_title:  Mimetype 

message: Bevor man mit der Höhe multipliziert, muss man das Ergebnis von
 biWidth × biBitCount / 8
erstmal auf 4 Byte aufrunden! Bei einer Datei mit 33 * 50 Pixeln bei 8-Bit würde nach der jetzigen Formel
 biWidth × biHeight × biBitCount / 8 = 33 * 50 * 8 / 8 = 1650 Byte
rauskommen. Wenn man aber erstmal die Zeilenlänge berechnet
 biWidth × biBitCount / 8 = 33 * 8 / 8 = 33 Byte, aufgerundet 36 Byte
 36 * biHeight = 36 * 50 = 1800 Bytes
Einfach mal mit Paint eine Datei von 33 x 50 Pixeln anlegen, im 256-Farben-Modus speichern und an Adresse 34 die Größe der Bilddaten auslesen. Dort steht NICHT 1650 sondern 1800 !!!!!! (nicht signierter Beitrag von 212.111.239.36 (Diskussion) 16:42, 2. Mai 2014 (CEST)
replies: text: Da noch eine Quelle ranpacken (wird ja z.B. auf der MSDN-Seite was geben), und das dann kurz im Artikel beschreiben (aber anders als der aktuelle Vorschlag, warum "näherungsweise" wenn "aufrunden auf Vielfache von 4" das Ergebnis genau erzielt?), und das passt. --Michael Schumacher (Diskussion) 11:48, 3. Mai 2014 (CEST)
thread_title:  "Die Größe der Bilddaten beträgt biWidth × biHeight × biBitCount / 8" - Falsch! 

message: "Die Länge jeder Zeile ist ein Vielfaches von 4 Bytes, falls erforderlich, wird mit Nullbytes aufgefüllt." steht zuoberst beim Abschnitt "Bilddaten" so, womit nahe liegt, dass es für alle Kompressionsarten gilt. Das ist aber falsch! Für RLE8 und für RLE4 gilt es nicht. Solche Fehlinformationen können für Leute wie mich, die Importer / Exporter anhand des Wikipedia-Artikels schreiben, extrem zeitraubend sein. Ich ändere das nun im Artikel auch obwohl ich keine Quelle dafür habe, diverse Grafikprogramme (Paint, Windows-Fotoanzeige, etc.) geben mir recht. --Asfdlol (Diskussion) 14:11, 21. Aug. 2014 (CEST)
thread_title:  Die Länge jeder Zeile ist ein Vielfaches von 4 Bytes, falls erforderlich, wird mit Nullbytes aufgefüllt.