Чтение BMP-файла "руками" [Cи]

[MooNDeaR]

Есть задача с помощью средств самого Си считать монохромный BMP-файл размером 320x240 (9600 байт). Естественно я сразу полез на Википедию, дабы узнать как устроен формат.
Итак, собственно вопрос: при попытке считать первую же структуру BITMAPFILEHEADER из файла получается фэйл. Вот текст самой программы.

#include <stdio.h>

struct bmpheader
{
	unsigned char	b1,b2;			//Символы BM (смение 0, длина 2)
	unsigned long 	bfSize;			//Размер файла в байтах	(Смещение 2, длина 4)
	unsigned short	bfReserved1;	        //Бесполезно (Смещение 6, длина 2)
	unsigned short	bfReserved2;	        //Бесполезно (Смещение 8, длина 2)
	unsigned long	bfOffBits;		//Смещение до самого изображения (Смещение 10, длина 4)
};

int main()
{
	FILE* f;

	bmpheader hdBMP;

	if((f = fopen("Mono.bmp","rb")) == NULL)
		return -1;
	
	fread(&hdBMP,sizeof(hdBMP),1,f);
	
	printf("%c%c\n",hdBMP.b1,hdBMP.b2);
	printf("%d\n",hdBMP.bfSize);
	printf("%d\n",hdBMP.bfReserved1);
	printf("%d\n",hdBMP.bfReserved2);
	printf("%d\n",hdBMP.bfOffBits);

	return 0;
}

При этом результат выполнения будет такой:

BM
0
0
62
2621440

И это очевидно неправильно. Во-первых размер файла 0. Я решил тип поля bfSize заменить на unsigned short. Результат был таким

BM
9662
0
0
4063232

Почему получается все поля принимают правильные значение, а поле bfOffBits такое кривое? Не могу понять

[s-andriano]

На С не пишу, так что сразу прошу извинить за, возможно, глупые вопросы.

Взял первый попавшийся BMP-файл и заглянул в него HEX-редактором - все правильно, значение 36h, т.е. 54 - как и положено.

Может, объявленная Вами структура имеет выравнивание на 4 байта?
Прочитайте первые 14 байт побайтно и выведите результат.

PS. Честно говоря, я первые 14 байт при чтении всегда пропускаю - в них все равно нет ничего интересного.

PPS. Да, еще, выведите размер структуры. На Паскале это было бы sizeof(bmpheader), как на С - не знаю, может, так же.

[MooNDeaR]

Не знаю где глюк, наверное в википедии, но после замены структуры на такой вид:

struct bmpheader
{
	unsigned char	b1,b2;			//Символы BM (смение 0, длина 2)
	unsigned short	bfSize;			//Размер файла в байтах	(Смещение 2, длина 2)
	unsigned short	bfReserved1;	        //Бесполезно (Смещение 6, длина 2)
	unsigned short	bfReserved2;	        //Бесполезно (Смещение 8, длина 2)
	unsigned short  padding;		//Мусор, для выравнивания
	unsigned short	bfOffBits;		//Смещение до самого изображения (Смещение 10, длина 2)
};

всё внезапно заработало правильно.

[s-andriano]

Повторю свою рекомендацию выяснить размер структуры. Если она окажется равной 18, а не 14 байтам - дело в выравнивании.
Я рекомендую все-таки разобраться с этим, потому что после заголовка файла будет заголовок изображения, в котором тоже чередуются поля разного размера.

[MooNDeaR]

Узнал размер структуры. Она выравнивается до 16 байт. Что всё равно не объясняет кривое считывание первых данных, ведь теоретически выравнивание дописывает байты к концу структуры, что испортило бы мне считывание следующей структуры BITMAPINFOHEADER, но никак не Хедера.

Нашел причину в кривой работе функции fread(). Она ОЧЕНЬ странно как-то считает данные. Не более двух байт за раз. Получаются вот такие перлы:
Есть последовательность байтов: 00000000 00000000 00000000 00101000 (число 40 в формате ulong)

Если записать структуру так:

struct Test
{
	unsigned short X;
	unsigned short Y;
} T;

Затем считать её фунцией fread() вот таким образом:

fread(&T,4,1,file);

а затем посмотреть значения X и Y, то получим, как и ожидали значения 0 (первые 2 байта нули) и 40 (вторые два байта).

НО! Вот если эту же структуру записать так:

struct Test
{
	unsigned long X;
}

и считать те же четыре байта, то должны получить, теоретически, число 40. Или я не прав? Что же мы получаем на самом деле (просмотрел двоичный вид числа):

00000000 00101000 00000000 00000000

Т.е. получается он сначала считал первые 2 байта и записал их в конец, потом еще 2 байта и записал их "сверху тех" и в результате получается число 2621440.

Что за шутки я не знаю, и понятия пока не имею как правильно это обходить

P.S.
Посмотрел на всё это дело из HEX-редактора.
Все числа оказывается записаны с конца, т.е. от младшего байта, к старшему. Т.е. поледовательность:

00000000 00000000 00000000 00101000

записана как:

00101000 00000000 00000000 00000000

.

Тобишь, согласно Википедии порядок байтов идет как Little-endian. Тогда мне вообще непонятен принцип работы функции fread()...

[Аватар]

Физически 40 для long на диске записано так: 00101000 00000000 00000000 00000000
при правильном чтении должно получится так: 00000000 00000000 00000000 00101000
т.е. слова меняются местами и внутри слов байты меняются местами. 100% проблемы выравнивания. На Си не пишу поэтому дальше пас. Хотя слышал о директиве препроцессора #pragma. Может в эту сторону копнуть?
Могу еще ссылочку подкинуть http://jenyay.net/Programming/Bmp

[MooNDeaR]

Физически 40 для long на диске записано так: 00101000 00000000 00000000 00000000
при правильном чтении должно получится так: 00000000 00000000 00000000 00101000

Да, я понимаю. Но в результате считывания ровно 4-й байт, получается вот это:

00000000 00101000 00000000 00000000

Т.е. функция fread() сначала правильно считывает первые 2 байта (переворачивает), затем вторые 2 байта и тоже переворачивает дописывая к концу типа unsigned long совсем не в тему эти нули, хотя надо было бы их дописывать к началу числа.

слышал о директиве препроцессора #pragma

Есть такая, но, насколько помню, в стандарт не входит, а работает только в некоторых IDE (Builder, MS Studio). Видел где-то на англоязычных форумах обсуждалась данная байда, и использовали как раз #pragma, но вот только я, если честно, нефига не понял. И еще мне непонятны пляски с этой fread().

[Аватар]

получается вот это

Скорее всего это из-за сдвига при чтении влево на 2 байта, в которых нули

[MooNDeaR]

Спасибо за совет про директиву #pragma.
Решил проблему вот таким образом:

#pragme pack(push)
#pragma pack(1)
struct bmpheader
{
	unsigned char	b1,b2;			//Символы BM (смение 0, длина 2)
	unsigned long	bfSize;			//Размер файла в байтах	(Смещение 2, длина 4)
	unsigned short	bfReserved1;	        //Бесполезно (Смещение 6, длина 2)
	unsigned short	bfReserved2;	        //Бесполезно (Смещение 8, длина 2)
	unsigned long	bfOffBits;		//Смещение до самого изображения (Смещение 10, длина 4)
};
#pragma pack(pop)

Правда, если честно, понятия не имею что я сделал, sizeof(bmpheader) возвращает 14. Просто порылся на англоязычных форумах. Буду читать. Еще раз спасибо.

[s-andriano]

Сообщение от Аватар

Физически 40 для long на диске записано так: 00101000 00000000 00000000 00000000
при правильном чтении должно получится так: 00000000 00000000 00000000 00101000
т.е. слова меняются местами и внутри слов байты меняются местами. 100%

Ничего подобного, что на диске, что в памяти на архитектуре Intel всегда Little-Endian.
Ничто ни с чем не меняется, все как было, так и остается.