Fragen zu Windows Bitmap einlesen #2

[zeropage]

Hallo,

ich habe ein ähnliches Thema vor Monaten eröffnet, eine Riesenpause gemacht und mich die Sache nun wieder abgenommen. Zum besseren Verständnis zeige ich den damaligen Eingangsbeitrag.
https://www.c-plusplus.net/forum/335804
Der alte Thread uferte etwas zu einer Grundsatzdiskussion aus, deshalb dieser neue.

Hallo,

ich möchte damit anfangen, kleine einfache Bilder zu verarbeiten. Als Format habe ich mir Windows Bitmap ausgewählt.

Um da besser durchzusteigen, will ich die Bytes der Datei erst mal nur ausgeben. Beschränke mich zum Anfang aber nur auf den Kopf und die Eigenschaften. Denn dort fangen schon genug Fragen an.

Als Grundlage habe ich den entsprechenden wiki-Artikel genommen.

https://de.wikipedia.org/ ....... teiformat_.28Version_3.29

struct Head
{
    static const int Size = 4;
    std::array <std::string, Size> bName {{ "bfType", "bfSize", "bfReserved", "bfOffbits" }};
    std::array <int, Size> bName_size {{ 2,4,4,4, }};
}head;
 
struct Info
{
    static const int Size = 11;
    std::array <std::string, Size> bName {{ "biSize", "biWidth", "biHeight", "biPlanes", "biBitCount", "biCompression", "biSizeImage", "biXPelsPerMeter", "biYPelsPerMeter", "biClrUsed", "biClrImportant" }};
    std::array <int, Size> bName_size {{ 4,4,4,2,2, 4,4,4,4,4,4 }};
}info;
 
struct dummy //nur ein dummy-struct für spätere Inhalte
{
    std::vector <char> dValue;
};
 
 
 
int main()
{
 
 
    std::vector <char> picmap;
    char byte;
    size_t offset = 0;
 
    std::string file_name = "WOLKEN.bmp";
    std::ifstream file (file_name.c_str(), std::ios::binary|std::ios::in);
    while (file.get(byte)) picmap.push_back(byte);
 
 
    std::cout << "_Head_" << '\n';
    for (int i=0; i<head.Size; i++)
    {
        std::cout << '#' << std::dec << offset << "  " << head.bName.at(i) << std::setw(11);
        for (int j=0; j<head.bName_size.at(i); j++)
        {
            std::cout << std::hex << int(picmap.at(offset)) << ' ';
            offset ++;
        }
        std::cout << '\n';
    }
 
    std::cout << '\n' << "_Info_" << '\n';
    for (int i=0; i<info.Size; i++)
    {
        std::cout << '#' << std::dec << offset << "  " << info.bName.at(i) << std::setw(11);
        for (int j=0; j<info.bName_size.at(i); j++)
        {
            std::cout << std::hex << int(picmap.at(offset)) << ' ';
            offset ++;
        }
        std::cout << '\n';
    }
 
 
}

Nun meine Fragen:

1 - ist es möglich die structs zu etwas größeren zusammenzufassen? Habe etwas über struct in einem struct nachgeschlagen, wollte aber wissen, ob es etwas besseres gibt.

2 - Ich wollte setw() für einen übersichtlichen Ausdruck nehmen, nur funktioniert das nicht, wie ich mir das vorstelle.
http://abload.de/image.php?img=unbenanntfnou7.png
Wie macht man das korrekt?

3 - Zum Einlesen eines Byte habe ich ein char genommen, nur frage ich mich, ob das korrekt ist, oder was man da besser nimmt?

4 - Wo und wie müsste ich eventuelle Kommentare setzen, damit ein geneigter Helfer schneller den Code überblicken kann? Bei zB Zeile 32 'Bytes der Datei in vector einlesen' stelle ich mir überflüssig vor?

Es würden zu dem Code noch weitere kleine Fragen kommen, würde aber gerne erst die oberen Punkte abhaken.

Ich bin ein relativ großes Stück weiter gekommen. Die formatierte Ausgabe steht (auch wenn sie nur ein Übergang darstellt, später wird sie nicht mehr benötigt) und ich kann gut die Farbtabelle bearbeiten.

Zur Erinnerung nochmal der entsprechende Wiki-Artikel, den ich als Grundlage genommen habe.

https://de.wikipedia.org/wiki/Windows_Bitmap#Dateiformat_.28Version_3.29

Bei den Bilddaten aber stoße ich auf ein Verständnisproblem. Es geht um biHeight

Die Bilddaten werden Zeile für Zeile gespeichert. Wenn biHeight positiv ist, beginnen die Bilddaten mit der letzten und enden mit der ersten Bildzeile, ansonsten ist es umgekehrt.

Ich weiß nicht, wie ich in den eingelesenen Werten einen negativen Wert erkennen und darstellen kann?

Einlesen tue ich sie so:

std::vector <char> picmap;
    //std::vector <uint8_t> bytes_vec; //spätere Verwendung
    char s_char;
    uint8_t byte; //wird später als <byte = picmap.at(offset);> verwendet
    std::size_t offset = 0;

    std::string file_ = "test";
    std::string file_name = file_ + ".bmp";
    std::ifstream file (file_name.c_str(), std::ios::binary);
    if (!file)
    {
        std::cout << "fehlende Datei!" << '\n';
        return 0;
    }
    while (file.get(s_char)) picmap.push_back(s_char);
    std::cout << "_File: " << file_name << '\n';

Bisher verstehe ich das so, das dort irgendwo ein seltsamer Wert sein muss, weil ich den Umweg über ein signed char nehmen muss. Ansonsten gibts in der Nähe des Wertes, der negativ sein könnte einen Fehler. Durch den späteren Cast zu uint8_t gibt es im Ausdruck dann aber keine Unregelmäßigkeiten.

Wie mache ich das also mit einem eventuell negativen Wert? Ich hoffe, der gesamte Beitrag ist trotzdem einigermaßen verständlich.

[Belli]

Na, wenn ich den Wiki-Artikel beim schnellen Überfliegen richtig verstanden habe, steht biHeight bei Offset 22 einer bmp-Datei.
Also positionierst Du Dich dort, liest einen int32_t ein, und prüfst, ob er positiv oder negativ ist?!

[zeropage]

Naja, dies ist mir eben nicht so recht verständlich

Das biHeight negativ sein könnte, scheint auch nicht mehr üblich zu sein. Ich habe momentan nur ein recht altes File, wo dies vorkommt und dort steht bei #22 60 01 00 00 = 352, die korrekte Bildhöhe. Ich weiß nur aus früheren Versuchen, das dort in der Nähe noch ein ff aufgetaucht ist, was ich als negatives Vorzeichen gewertet habe.

Dies steht aber momentan nur so sauber da, weil die Werte schon zu uint8_t gecastet sind.

Ich befürchte, wenn ich die Werte wie im Artikel und wie Du es andeutest, also in diesem Fall als int32_t einlesen will, den Code recht umfangreich umschreiben muss. Ich wollte ja wegen der Ausgabe zum Verständnis wirklich nur die einzelnen Bytes in hexadezimaler Form (und die Umrechung in dezimaler Form) darstellen.

[zeropage]

*Quatsch*

- sorry, ich mache lieber morgen oder so weiter -

[hustbaer]

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 per memcpy in einen int .
Wenn du Endianness Berücksichtigen willst, musst du statt memcpy eine eigene Funktion verwenden die auf little-endian einfach memcpy aufruft und auf big-endian Systemen "rückwärts" kopiert. Und halt Byteweise kopieren, also per char* bzw. unsigned char* .
Und schon hast du deinen signed 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 einen int32_t verwandeln, 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;

[Belli]

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.

[hustbaer]

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?

[Belli]

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

[wob]

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.

[Techel]

Beim Bitmap-Format ist laut Specs alles Kleinenderisch.

[hustbaer]

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.

[Belli]

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.

[SeppJ]

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.

[hustbaer]

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

[zeropage]

Danke für die ganzen Beiträge

Muss der Threadersteller erst wieder alle durcharbeiten.

[zeropage]

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

[hustbaer]

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.

[zeropage]

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?

[zeropage]

EDIT: Korrektur ist im oberen Beitrag.

[hustbaer]

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.