Bitmap curropts after being loaded and saved

I loaded a 24-bit uncompressed Bitmap into a 2D array of R,G,B unsigned chars, and then saved it again, I use file streams in binary modes to ensure no auto formatting occur, and the header is exported just as imported as whole...Padding is not required since i use images which are multiples of 4 in width.

Yet the output have the attached issue, some kind of...deformation

Note : I tried both FILE and fstream in binary modes and all gave that output Another thing is that on checking the output with a hex editor i found that it has a very repeated value of "CD" which appears to be some kind of corruption.

Update : Source code:

#include <fstream>
#include <iostream>
#pragma pack(2)
using namespace std;
struct RGB
{
    unsigned char R,G,B;
};

int main()
{
    ifstream f("Picture.bmp",ios::in|ios::binary);
    unsigned char Header[54];
    f.read(reinterpret_cast <char*> (Header),54);
    int W=*(int*) (&Header[18]);
    int H=*(int*) (&Header[22]);

    RGB**Pic=new RGB*[H];
    for (int i=0;i < H;i++)
    {
        Pic[i]=new RGB[W];
        for (int i2=0;i2<W;i2++)
        {
            f>>Pic[i][i2].R;
            f>>Pic[i][i2].B;
            f>>Pic[i][i2].G;
        }
    }
    ofstream save("Output.bmp",ios::out|ios::binary);
    save.write(reinterpret_cast<char*>(&Header),54);
    for (int i=0;i < H;i++)
    {
        for (int i2=0;i2<W;i2++)
        {
            save<<Pic[i][i2].R;
            save<<Pic[i][i2].B;
            save<<Pic[i][i2].G;
        }
    }
        return 0;
}

Thanks in advance.

The problem you're having is not with uninitialized values but how the >> operator works; it skips whitespace before reading (even in ios::binary mode). So whenever it reached a whitespace character (0x0A, 0x0D, etc.) it would skip it and thus corrupt your output.

You can fix this by adding f >> noskipws before working on the file.

Typically you want to operate on binary files with read()/write() (or get()/put() for single characters) and not use the extraction operators. Similarly to how you handled getting the width and height. If you were to do file >> someint then it would try to parse out the digits instead of reading sizeof(int) bytes.