Question

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>

int main()
{
    FILE* bmp = NULL;
    uint32_t offset;
    uint8_t* temp = NULL;
    size_t read;
    unsigned int x_dim = 600, y_dim = 388;

    bmp = fopen("test_colour.bmp", "r");

    if (!bmp)
        return -1;

    /* Get the image data offset */
    fseek(bmp, 10, SEEK_SET);
    fgets((char*)&offset, 4, bmp);

    printf("Offset = %u\n", offset);

    temp = malloc(3*x_dim*y_dim*sizeof(uint8_t));

    if (!temp)
        return -1;

    /* Go the the position where the image data is stored */
    fseek(bmp, offset, SEEK_SET);

    /* Copy image data to array */
    printf("%u bytes requested!\n", 3*x_dim*y_dim);
    read = fread((void*)temp, sizeof(uint8_t), 3*x_dim*y_dim, bmp);
    printf("%Iu bytes read!\n", read);

    fclose(bmp);
    free(temp);

    return 0;
}

I’m using the above code to read the RGB data of a 24-bit per pixel BMP image to an array. The offset from the start of file where the image data starts (after the BMP header) is given at offset 10 according to the BMP specification. I get the following output when executing the above code.

Offset = 54
698400 bytes requested!
33018 bytes read!

The offset output seems to be correct because the file size is 698454 bytes (=698400+54). However, the value returned by fread() seems to indicate that not the entire image data could be read. However, I’m subsequently using the data in the temp array to convert the RGB data to greyscale and writing this data to a BMP file again. Visually checking the output image does not indicate any errors, i.e. it seems as if I actually read the entire input image in the first place although fread() seems to indicate differently.

Can someone explain this behaviour?

Answer 1

(I’ll bet you’re on Windows)

bmp = fopen("test_colour.bmp", "r");

should be

bmp = fopen("test_colour.bmp", "rb");

If the file is opened in text mode on Windows, the runtime will stop reading when it happens to hit a 0x1a (Ctrl-Z) byte, which Windows considers an EOF marker for text files. Even if it doesn’t hit a Ctrl-Z, you’ll get corrupted data when Windows converts CR/LF sequences into a single LF character.

However, I can’t explain why you’re able to get a good image from the partial file read (just lucky?).

You are able to render an image from the buffer because the fread() implementation does read the number of bytes you requested (or nearly so – the number gets rounded down to a multiple of some block size) into the buffer, then it scans the buffer looking for CR/LF sequences to convert and Ctrl-Z EOF flags.

So even though fread() returns 33018, the buffer has actually been nearly completely written with data from the file. The data isn’t 100% correct (for example, some CR characters were probably discarded) or complete, but in this case it’s close enough to render an image that looks like the one you expected.

Of course, this is simply an observation of how this particular runtime behaves currently – it may not always behave that way in the future (or even on all systems today).