Not in FIle

I have never heard of a file dump site. Is there one that you recommend. is it obvious on how to link it here, or would I need some pointers on that too.

jonnin (11328)

google has places you can drop files to share. dropbox is popular. there are hundreds of them, most are free for a small amount of info and charge if you want gigabytes. amazon's aws free has a bit of space.

you just need an internet link to it once its up somewhere.

I use Pastebin.

But you can't upload files to it, you have to copy and paste the contents into it.

It is free though, which is nice!

George P (5582)

File dump sites, AKA file hosting/file sharing sites.......

https://www.hostingadvice.com/how-to/free-file-hosting-services/

@stoneJax

To supplement your videos, or whatever, go to this book section 8 and particularly 8.6

Also, run the program there (8.6) after you have read the chapter material on BMP files.

The program works perfectly on a Mac and there is enough info for you to modify it to suit what you are doing. All it appears you have to do is make sure the data you are producing and saving is in the format explained in the book.

You won't need a hex editor. The bmp files are 'made visible' by using some sort of display/editor, built in or otherwise. (Mac's use preview.app, I've forgotten what the Windows equivalent is.)

You can read the book online:
https://www.academia.edu/33661556/C_for_EvEryonE

I was assuming a file dump site to be something unique that I never heard of, but I see what you mean now. I uploaded the screenshot of the bmp file in HxD to Google Drive and posted the link.

https://drive.google.com/file/d/16pV_KWK7xmfN_d9AUM43zZTSNQRUfgcX/view?usp=sharing

I'll check out this book in the meantime.

Thank you

salem c (3685)

https://en.wikipedia.org/wiki/BMP_file_format#Bitmap_file_header

Well the first thing to note from your image is that your "bm" is in lower case, not upper case.
It's "BM", not "bm".

The next 4 bytes (0x0015F936) say the file size is 1440054 bytes, is that right?
This is little endian, so the 0x36 byte is first (the least significant) and the 0x00 is last (the most significant).

Skip 4 reserved bytes, the next interesting bit is the image offset at byte 0x0A.
This is 0x00000036, or 54 decimal, which seems entirely plausible.

https://en.wikipedia.org/wiki/BMP_file_format#File_structure
The bitmap file header is always 14 bytes.
The DIB header is a fixed size with 7 different versions.
https://en.wikipedia.org/wiki/BMP_file_format#DIB_header_(bitmap_information_header)
One of those sizes is 40 (so 14 + 40 = 54).

From your image, decoding the next 40 bytes as a BITMAPINFOHEADER


Hex         Decimal     Purpose
00000028    40          the size of this header, in bytes (40)
00000320    1440        the bitmap width in pixels (signed integer)
00000258    600         the bitmap height in pixels (signed integer)
0001        1           the number of color planes (must be 1)
0018        24          the number of bits per pixel
00000000    0           the compression method being used (BI_RGB == None)
00000000    0           the image size; a dummy 0 can be given for BI_RGB bitmaps
00000960    2400        the horizontal resolution of the image
00000960    2400        the vertical resolution of the image
00000000    0           the number of colors in the color palette, or 0 to default to 2n
00000000    0           the number of important colors used, or 0 when every color is important;

But 1440 * 600 * 3 = 2592000.
This is a lot more than the 1440054 you claim is the size of the entire file in the bitmap file header.

The rest of the image looks like a big old black screen of RBG=0x000000

@OP
FWIW this is a two pixel bitmap.

Save the following hex dump exactly as it is using copy and paste to a hex editor, then save that as a .bmp file (not with a text editor, not as text, not .txt)

When you open the .bmp file with a viewer of some sort, with the aid of a magnifier you should see the two pixels, one red and one black.

424D3E00 00000000 00003600 00002800 00000100 00000200 00000100 18000000 00000800 00000000 00000000 00000000 00000000 00000000 FF000000 0000

Now try and produce the same hex data with your program keeping in mind the above comments by @salem on the file header.

Didn't work on my Mac.

Does Terminal have a built-in hex editor? I know it has vim and emacs, but I think those are text editors.

go to app store get free ‘hex fiend’

jonnin (11328)

you can dump in hex from c++ (for something simple) but you will want a full editor that can tell you what the int/double values are at a given byte sometimes.
My advice: be as picky about your hex editor as you are about your C++ IDE. There are a lot of poor ones out there, get something you like that does what you need to do.

Last edited on

Ganado (6783)

<Updated this code to let it still compile on *nix systems, thanks agent max>

Little program I threw together to convert againtry's post to binary:

#include <iostream>
#include <string>
#include <cctype>
#include <fcntl.h>

namespace util {
    
char toupper(char ch)
{
    return static_cast<char>(std::toupper(static_cast<unsigned char>(ch)));
}

}

bool valid_byte(char hexLHS, char hexRHS)
{
    return std::isxdigit(static_cast<unsigned char>(hexLHS)) &&
           std::isxdigit(static_cast<unsigned char>(hexRHS));
}

unsigned char hex_value(char uppercase_hex_ch)
{
    if (std::isdigit(static_cast<unsigned char>(uppercase_hex_ch)))
    {
        return static_cast<unsigned char>(uppercase_hex_ch - '0');
    }
    else // A B C D E F
    {
        return static_cast<unsigned char>(10 + uppercase_hex_ch - 'A');
    }
}

// input: 424D3E00 00000000 00003600 00002800 <etc>
int main(int argc, char* argv[])
{
    using namespace std;
    
#ifdef _WIN32
    // https://stackoverflow.com/questions/5654067/how-to-make-cout-behave-as-in-binary-mode
    _setmode(_fileno(stdout), _O_BINARY); // necessary for Windows binary mode. bleh.
#endif

    string hex_block;
    while (cin >> hex_block)
    {
        for (size_t i = 0; i < hex_block.length() / 2; i++)
        {
            char halfbyte_L = util::toupper( hex_block[2*i + 0] );
            char halfbyte_R = util::toupper( hex_block[2*i + 1] );
            
            //cerr << halfbyte_L << halfbyte_R << " --> ";
            
            if (valid_byte(halfbyte_L, halfbyte_R))
            {
                unsigned char byte = (hex_value(halfbyte_L) << 4) | (hex_value(halfbyte_R) & 0xF);
                
                //cerr << (int)byte << ' ';
                cout.write(reinterpret_cast<char*>(&byte), 1);
            }
            else
            {
                cerr << "Invalid byte: " << halfbyte_L << halfbyte_R << '\n';
            }
        }
                    
        //cerr << '\n';
    }
}

Usage (Windows echo):

echo 424D3E00 00000000 00003600 00002800 00000100 00000200 00000100 18000000 00000800 00000000 00000000 00000000 00000000 00000000 FF000000 0000 | hex_to_bin > out.bmp

(hex_to_bin being the above program)

Last edited on

jonnin wrote:
You can dump in hex from c++

What exactly do you mean? Use a C++ program to read hex in from a text file and read it out to a .bmp file?

The purpose of the exercise I am on about is for @OP to get his/her program to work on a very simple test case of a 2 pixel picture and bmp file that is verified. It’s not a test of a hex editor wherever it might come from.

The cooments by @salem already show b,m is one error. @ganado’s program workin in reverse would show the correct BM in the header

@OP’s program must produce a bmp file which looks the same as mine when it is read in a hex editor and obviously as 2 colored pixels when displayed as an ordinary bmp file.

Note that color choices aren’t significant as long as they are different in order to make sure there are exactly 2 pixels being generated.

Salem, it looks like you nailed it with "bm" needing to be "BM." After that change I was able to display a pixel in an image editor (Paint).

Looks like you accidently noted the Oct value for Hex 320 which is 1440. The Dec value is 800, so 800 x 600 x 3 = 1440000 turned out to be ok.

Question: how do you know which bytes in the Hex editor match up to what? It appears to read initialized values starting with the file header, and then the info header. But how do you know details such as to match 4 bytes for the files size? Is there a standard procedure for a Hex editor to read in a program file that has multiple headers?

I appreciates everyone's responses in taking the time to look at this.

how do you know which bytes in the Hex editor match up to what?

This is one amongst a zillion web pages:
https://medium.com/sysf/bits-to-bitmaps-a-simple-walkthrough-of-bmp-image-format-765dc6857393
See Block 4 of the article.

Don't forget https://en.wikipedia.org/wiki/BMP_file_format that you have already been referred to.

Last edited on

Okay, I will check it out.

Thanks again to everyone for your help!