Fragen zu Windows Bitmap einlesen #2
-
*Quatsch*
- sorry, ich mache lieber morgen oder so weiter -
-
Also...
Es gibt eine einfache Variante (die fast überall verwendet wird), und eine "korrekte" (die kaum jemand verwendet).Die einfache verlässt sich darauf dass die Maschine two's complement verwendet (und die ganz einfache zusätzlich darauf dass sie little-endian verwendet).
Dabei schnappst du dir die 4 Byte aus deinen vector und kopierst sie permemcpyin einenint.
Wenn du Endianness Berücksichtigen willst, musst du stattmemcpyeine eigene Funktion verwenden die auf little-endian einfachmemcpyaufruft und auf big-endian Systemen "rückwärts" kopiert. Und halt Byteweise kopieren, also perchar*bzw.unsigned char*.
Und schon hast du deinensigned int.Die "korrekte" Variante wäre dir aus den 4 Bytes per
vector<unsigned char> data; ... uint32_t val = data[pos + 0] + (static_cast<uint32_t>(data[pos + 1]) << 8) + (static_cast<uint32_t>(data[pos + 2]) << 16) + (static_cast<uint32_t>(data[pos + 3]) << 24);erstmal ne unsigned Zahl zu basteln. Das sollte auf jeder Plattform so funktionieren, egal was für representation von Zahlen sie verwendet, egal wir breit die Datentypen sind etc.
Dann kanns du gucken ob die Bitmaske eine negative 32 Bit 2s complement Zahl darstellt indem du Bit 31 prüfst.
Also z.B.if ((val >> 31) & 1)
Wenn die Bitmaske eine negative Zahl darstellt, dann kannst du die dazupassende positive Zahl bekommen, indem du alle Bits invertierst und danach eins draufaddierst.
Die so erhaltene Zahl kannst du dann in einenint32_tverwandeln, und dann wieder negativ machen. So hast du die negative 2s complement Zahl in das native Format deiner Plattform konvertiert ohne dich dabei auf plattformabhängige Dinge zu verlassen.Bleibt lediglich noch ein Problem, und zwar wenn du 2s complement Hardware hast, und die negative Zahl die kleinste mögliche negative Zahl ist. Also z.B. -128 bei 8 Bit. Die passt als positive Variante nämlich nicht in einen gleich breiten signed Integer (max. bei 8 Bit wären da ja +127).
Das kannst du lösen indem du das "eins draufaddieren" verschiebst bis du die Zahl in den signed Integer gepackt und dort wieder negativ gemacht hast. Danach musst du natürlich eins subtrahieren statt addieren, da du ja das Vorzeichen wieder geändert hast.
Macht dann in Summe:
vector<unsigned char> data; ... uint32_t uval = data[pos + 0] + (static_cast<uint32_t>(data[pos + 1]) << 8) + (static_cast<uint32_t>(data[pos + 2]) << 16) + (static_cast<uint32_t>(data[pos + 3]) << 24); int32_t sval; if ((uval >> 31) & 1) sval = -static_cast<int32_t>(~uval) - 1; else sval = uval;
-
lemon03 schrieb:
Naja, dies ist mir eben nicht so recht verständlich
Das biHeight negativ sein könnte, scheint auch nicht mehr üblich zu sein.
...
Ich wollte ja wegen der Ausgabe zum Verständnis wirklich nur die einzelnen Bytes in hexadezimaler Form (und die Umrechung in dezimaler Form) darstellen.
Du kannst doch ganz unabhängig von jeglicher anderer Verarbeitung diesen einen Wert einlesen und prüfen, zB. zu Programmbeginn. Da sein Offset ja feststeht, ist das doch sehr einfach.
Danach positionierst Du Dich wieder auf den Dateibeginn und lässt Dein Programm laufen, wie bisher.
Zumindest weißt Du dann, ob biHeight negativ ist, oder nicht. Wenn es nicht mehr negativ sein kann, weil "scheint auch nicht mehr üblich zu sein", dann hast Du doch gar kein Problem.
Was die Endianness angeht, würde ich mich zunächst mal nicht darum kümmern, sondern unterstellen, dass die korrekt ist. Ich schätze, wenn es anders wäre, könnte ein Bilddarstellungsprogramm auch nix mit der Datei anfangen - das ist aber nur Spekulation.
-
Belli schrieb:
Was die Endianness angeht, würde ich mich zunächst mal nicht darum kümmern, sondern unterstellen, dass die korrekt ist. Ich schätze, wenn es anders wäre, könnte ein Bilddarstellungsprogramm auch nix mit der Datei anfangen - das ist aber nur Spekulation.
Quatsch.
Klar geht das. Wieso sollte man BMP auf big-endian Systemen nicht verwenden können?
-
So hab ich das nicht gemeint.
Wenn ich eine bmp-Datei auf einem Big-Endian - System habe, und die auf ein Little-Endian - System kopiere, dann könnte ich mir vorstellen, dass die Programme auf dem Little-Endian - System einige Dinge falsch interpretieren.Wenn ich die Datei nur auf Systemen mit gleicher Endianess (zB nur auf Windows, nur auf Linux, usw.) verwende, brauche ich mich nicht darum zu kümmern, was sie für eine Endianess hat.
Das ist doch nur interessant, wenn ich damit rechnen muss, dass sie von einem anderen System kommt, als das, auf welchem mein Programm läuft.
Und da stelle ich mir halt die Frage, ob Bilddarstellungsprogramme dann nicht vor genau den gleichen Problemen stehen ...
Edit:
Schließlich kann ich einem Integerwert nicht ansehen, ob er Bigendian oder Littleendian codiert ist ...
-
Quatsch.
Das Format definiert, ob die Daten LE oder BE gespeichert werden! Wenn die Formatdefinition mit der der Maschine, die das Bild liest, übereinstimmt, muss nichts getan werden. Stimmt das nicht überein, muss konvertiert werden.
BMP ist immer LE kodiert. Das heißt, wenn dein Programm nur auf LE-Maschinen läuft, musst du dir keine Gedanken um Endianess machen.
-
Beim Bitmap-Format ist laut Specs alles Kleinenderisch.
-
Wurde ja schon geschrieben, aber trotzdem nochmal...
Belli schrieb:
Edit:
Schließlich kann ich einem Integerwert nicht ansehen, ob er Bigendian oder Littleendian codiert ist ...Dem Integer nicht, nein. Du hast aber nen Kontext, und zwar weisst du dass der Integer aus nem .BMP File kommt. Und .BMP ist eben immer 2s complement little endian. Egal auf welcher Hardware. Wenn die Hardware was anderes verwendet, dann muss sie beim Lesen bzw. Schreiben von BMP Files eben "umrechnen".
Damit eben genau das nicht passiert was du schreibst, nämlich dass man ein BMP File von System X auf System Y nicht aufmachen kann wenn X und Y sich nicht über 1s/2s complement bzw. Endianness einig sind. Was ja total kacke wäre. Weswegen es nicht so ist.
-
Na umso besser.
Dann würde ich mich der Einfachheit halber (zumindest im ersten Wurf) um die Endianess nicht kümmern - ich unterstelle einfach mal, dass das Programm für einen x86(kompatiblen) geschrieben wird.
-
Belli schrieb:
Na umso besser.
Dann würde ich mich der Einfachheit halber (zumindest im ersten Wurf) um die Endianess nicht kümmern - ich unterstelle einfach mal, dass das Programm für einen x86(kompatiblen) geschrieben wird.Sooooo exotisch ist BigEndian nun auch wieder nicht. Eigentlich fast so ziemlich alles, was einen nennenswerten Marktanteil außer dem x86 hat.
-
ARM kann beides.
Und da x86 halt so stark ist, fahren Android und Windows den ARM auch mit little endian. (iOS vermutlich auch, hab's nicht nachrecherchiert.)Aber ja, es gibt sie noch die grossen Endianer
-
Danke für die ganzen Beiträge
Muss der Threadersteller erst wieder alle durcharbeiten.
-
Puh, also wieder ne große Pause ...
Danke nochmals für die Beiträge und den Beispielcode von hustbaer (den ich einfach ganz frech kopiert habe ;)). Da im Artikel steht
BMP verwendet die Little-Endian-Konvention.
dachte ich mir, darum muss ich mich nicht kümmern.
Jetzt habe ich aber das "Problem", das es gar keine negativen Werte gibt, auch bei dem Bild, wo ich vorher von ausgegangen bin. Vielleicht habe ich aber beim Schreiben des Code auch gepfuscht? Vielleicht habe ich auch was falsch verstanden?
Oder kann mir jemand ein Beispiel für einen Beispielvector in der Form des
bmp_data-vector mit negativen Werten geben, um dies zu überprüfen?struct Head //Kopf { static const auto Size = 4; std::array <std::pair <std::string, int>, Size> bType { { { "bfType", 1 }, //uint16_t { "bfSize", 2 }, //uint32_t { "bfReserved", 2 }, //uint32_t { "bfOffbits", 2 } //uint32_t } }; std::vector <int> data; } head; struct Info //Eigenschaften { static const auto Size = 11; std::array <std::pair <std::string, int>, Size> bType { { { "biSize", 2 }, //uint32_t { "biWidth", 3 }, //int32_t { "biHeight", 3 }, //int32_t { "biPlanes", 1 }, //uint16_t { "biBitCount", 1 }, //uint16_t { "biCompression", 2 }, //uint32_t { "biSizeImage", 2 }, //uint32_t { "biXPelsPerMeter", 3 }, //int32_t { "biYPelsPerMeter", 3 }, //int32_t { "biClrUsed", 2 }, //uint32_t { "biClrImportant", 2 } //uint32_t } }; std::vector <int> data; } info; /* struct ColTable //Farbtabelle { bool is_ = true; //existiert Farbtabelle std::vector <std::tuple <uint8_t, uint8_t, uint8_t, uint8_t>> tblEntry; } colTable; */ void read_bmpData (std::string file_, std::vector <unsigned char> &bmp_data) { std::string file_name = file_ + ".bmp"; char s_char; std::ifstream file (file_name.c_str(), std::ios::binary); if (!file) { std::string err_str = "!Fehler bei " + file_name; //throw err_str; std::cout << err_str; //wird noch behandelt } while (file.get(s_char)) bmp_data.push_back(s_char); std::cout << "_File: " << file_name << '\n' << '\n'; } uint16_t make_uint16 (std::vector <unsigned char> bmp_data, std::size_t pos) { uint16_t u_val = bmp_data.at(pos + 0) + (static_cast <uint16_t> (bmp_data.at(pos + 1)) << 8); return u_val; } uint32_t make_uint32 (std::vector <unsigned char> bmp_data, std::size_t pos) { uint32_t u_val = bmp_data.at(pos + 0) + (static_cast <uint32_t> (bmp_data.at(pos + 1)) << 8) + (static_cast <uint32_t> (bmp_data.at(pos + 2)) << 16) + (static_cast <uint32_t> (bmp_data.at(pos + 3)) << 24); return u_val; } int32_t make_int32 (std::vector <unsigned char> bmp_data, std::size_t pos) { uint32_t u_val = bmp_data.at(pos + 0) + (static_cast <uint32_t> (bmp_data.at(pos + 1)) << 8) + (static_cast <uint32_t> (bmp_data.at(pos + 2)) << 16) + (static_cast <uint32_t> (bmp_data.at(pos + 3)) << 24); int32_t s_val; if ((u_val >> 31) & 1) { s_val = - static_cast <int32_t> (~u_val) - 1; } else { s_val = u_val; } return s_val; } int main() { //std::string file_ = "test_me"; std::string file_ = "WOLKEN"; //std::string file_ = "046"; //std::string file_ = "Cubis"; std::vector <unsigned char> bmp_data; read_bmpData (file_, bmp_data); std::size_t offset = 0; uint16_t data_u16; uint32_t data_u32; int32_t data_32; for (auto i=0; i<head.Size; i++) { switch (head.bType.at(i).second) { case 1: data_u16 = make_uint16 (bmp_data, offset); head.data.push_back(data_u16); offset += 2; break; case 2: data_u32 = make_uint32 (bmp_data, offset); head.data.push_back(data_u32); offset += 4; break; case 3: data_32 = make_int32 (bmp_data, offset); head.data.push_back(data_32); offset += 4; break; } } for (auto i=0; i<info.Size; i++) { switch (info.bType.at(i).second) { case 1: data_u16 = make_uint16 (bmp_data, offset); info.data.push_back(data_u16); offset += 2; break; case 2: data_u32 = make_uint32 (bmp_data, offset); info.data.push_back(data_u32); offset += 4; break; case 3: data_32 = make_int32 (bmp_data, offset); info.data.push_back(data_32); offset += 4; break; } } for (std::size_t i=0; i<head.Size; i++) std::cout << head.bType.at(i).first << ": " << head.data.at(i) << '\n'; std::cout << '\n'; for (std::size_t i=0; i<info.Size; i++) std::cout << info.bType.at(i).first << ": " << info.data.at(i) << '\n'; }edit: einige Korrekturen im Code
-
lemon03 schrieb:
... int32_t s_val; if ((u_val >> 31) & 1) { s_val = -u_val; // <-------------------- } else { s_val = u_val; } ...Hast du in die markierte Zeile mal nen Breakpoint gemacht?
Und: Wieso hast du den Code in genau dieser Zeile geändert? Das hat schon nen Grund dass ich das so geschrieben habe wie ich es eben geschrieben habe.
-
Einen Breakpoint nicht (ich kann leider noch nicht in CodeBlocks den Debugger benutzen, weil ich mich noch nicht ganz mit
ERROR: You need to specify a debugger program in the debuggers's settings.auseinander gesetzt habe), aber ich habe eine cout-Ausgabe dort eingeführt, ob diese Wahl überhaupt getroffen wurde. Sie wurde nie aufgerufen.Die Zeilen habe ich geändert, weil ich davon ausgegangen bin, das die dortige Abfrage
if ((u_val >> 31) & 1)nur zur Entscheidung negativ oder positiv dient. Die weitere Verarbeitung wäre dann nur für eventuell andere Systeme. Dachte ich jedenfalls.Ich werd das mal korrigieren.
EDIT: Aber auch umgeschrieben, scheint es keine negativen Werte zu geben
uint32_t u_val = bmp_data.at(pos + 0) + (static_cast <uint32_t> (bmp_data.at(pos + 1)) << 8) + (static_cast <uint32_t> (bmp_data.at(pos + 2)) << 16) + (static_cast <uint32_t> (bmp_data.at(pos + 3)) << 24); int32_t s_val; if ((u_val >> 31) & 1) { s_val = - static_cast <int32_t> (~u_val) - 1; } else { s_val = u_val; } return s_val;Aber vielleicht ist das ja korrekt? Ich bräuchte zum Testen ein Beispiel, wo ganz bestimmt negative Werte enthalten sind?
-
EDIT: Korrektur ist im oberen Beitrag.
-
OK wenn das cout nie anschlägt dann wird es wohl keine negativen Werte gegeben haben in deinen Bitmaps.
lemon03 schrieb:
Aber vielleicht ist das ja korrekt? Ich bräuchte zum Testen ein Beispiel, wo ganz bestimmt negative Werte enthalten sind?
Ja korrekt ist es schon. Es gibt halt top-down und bottom-up BMPs. Standard ist bottom-up und bei denen ist die Höhe positiv.
D.h. du musst dir irgendwoher top-down BMPs zum Testen besorgen.
-
Jo danke dann
Und gute Idee, mal schauen ob man nach top-down BMPs goglen kannn, bzw was findet.
-
Super, hatte mehrere top-down Beispiele gefunden und bei allen wurde der korrekte Wert negativ angezeigt. Danke nochmals.
-
Na super
Nochwas...
Ich würde folgende Änderungen vorschlagen:int32_t make_int32 (std::vector <unsigned char> bmp_data, std::size_t pos) { uint32_t u_val = bmp_data.at(pos + 0) + (static_cast <uint32_t> (bmp_data.at(pos + 1)) << 8) + (static_cast <uint32_t> (bmp_data.at(pos + 2)) << 16) + (static_cast <uint32_t> (bmp_data.at(pos + 3)) << 24); int32_t s_val; if ((u_val >> 31) & 1) { s_val = - static_cast <int32_t> (~u_val) - 1; } else { s_val = u_val; } return s_val; } // => int32_t better_make_int32 (std::vector <unsigned char> const& /* 1 */ bmp_data, std::size_t pos) { uint32_t const /* 2 */ u_val = /* 3 */ make_uint32(bmp_data, pos); if ((u_val >> 31) & 1) { return - static_cast <int32_t> (~u_val) - 1; /* 4 */ } else { return u_val; /* 4 */ } }1: Du solltest nicht den ganzen std::vector kopieren. Das ist sogar im günstigsten Fall (wenig Daten) schon viel langsamer als nötig (dynamische Speicheranforderung!). Und wenn mal viel Daten drinnen wird's richtig langsam.
2: Lokale Variablen
constmachen wenn man sie (einfach, ohne grosse Umwege)constmachen kann. Damit man gleich sieht dass der Wert der Variable sich nach der Initialisierung nie mehr ändert.3: Code-Duplizierung vermeiden.
4: Mutable-State vermeiden, uninitialisierte Variablen vermeiden.
Uninitialisierte Variablen vermeiden allerdings nur, wenn man ihnen gleich bei der Initialisierung einen sinnvollen Wert geben kann. Wenn wirklich nur die Wahl besteht zwischen "uninitialisiert" oder "mit Dummy-Wert initialisiert", dann eher uninitialisiert. Meist kann man aber gleich mit dem passenden Wert initialisieren.Einige dieser Dinge (z.B. (1)) betreffen auch andere Funktionen, dort natürlich ebenso nachziehen.
Und wie bei allen Richtlinien gibt es natürlich Ausnahmen. Viel Aufwand zu betreiben um eine dieser Regeln zu befolgen ist nicht immer sinnvoll.
----
Und ich würde vorschlagen die Leerzeichen vor öffnenden Klammern und nach schliessenden Klammern weg zu lassen. Ausnahme: zwischen Keywords und runde Klammer kommt ein Leerzeichen
Also z.B.int x = MeineFunktion(param); // nach MeineFunktion nicht for (int i = 0; i < x; i++) // nach for schon { if (static_cast<int32_t>(i * i) < x) // nach if auch, nach static_cast aber nichtusw.
Das, also wo bei Klammern Leerzeichen gesetzt werden, ist nämlich eine der wenigen Regeln wo sich die meisten Programmierer einig sind. Zumindest ist das mein Eindruck anhand des Codes den ich so sehe.
EDIT: Copy/Paste/Edit Fehler korrigiert.
