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

[s-andriano]

Сообщение от MooNDeaR

Правда, если честно, понятия не имею что я сделал,

Подозреваю, выравнивание на 1 байт.

sizeof(bmpheader) возвращает 14.

Это хорошо.
Тогда можно приступать к чтению BITMAPINFOHEADER.

[Аватар]

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

Про хранение в памяти ни одного слова и не было сказано. Имелось в виду значение прочитанных данных

[MooNDeaR]

Подозреваю, выравнивание на 1 байт.

На MSDN прочитал немного на заморском про этот pack Если я правильно понял, а я на это надеюсь, то цифра в директиве #pragma pack(1) указывает какому числу должно быть кратно выравнивание. Допустимы значения 1,2,4,8 и 16.

P.S.
Спасибо всем за помощь, всё успешно считано и для теста я даже монохроматическую картинку 25х25 пикселей в консольку псевдографикой отрисовал


Только вот один прикол - изображение оказывается записано в файле вверх ногами, поэтому пришлось строки с конца читать. Так и должно быть?

[s-andriano]

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

Про хранение в памяти ни одного слова и не было сказано. Имелось в виду значение прочитанных данных

Про "значение" тоже не было сказано ни слова, даже при том, что нигде не было упомянуто, что подразумевается под "значением".
Зато было сказано буквально следующее:

слова меняются местами и внутри слов байты меняются местами

А это категорически не соответствует действительности.

[s-andriano]

Сообщение от MooNDeaR

Только вот один прикол - изображение оказывается записано в файле вверх ногами, поэтому пришлось строки с конца читать. Так и должно быть?

Неужели в описании формата этого не было?
Да, ось X в файле BMP направлена слева направо, а ось Y, как и должно быть, если верить школьному курсу математики, снизу вверх. Тогда как в WinAPI (а также в DOS) принято, чтобы ось Y смотрела вниз.
Можно лишь отметить, что в OpenGL ось Y также смотрит вверх.
Так что какой режим считать "перевернутым" - вопрос неоднозначный.
Скорее всего, перевернуто именно в DOS/Windows.

Могу еще порекомендовать не читать строки из файла в обратном порядке, а, наоборот, читать последовательно, а в память записывать, начиная с последней. При условии, конечно, что программе они нужны именно в таком "перевернутом" виде.

[MooNDeaR]

Могу еще порекомендовать не читать строки из файла в обратном порядке, а, наоборот, читать последовательно, а в память записывать, начиная с последней. При условии, конечно, что программе они нужны именно в таком "перевернутом" виде.

Если честно, программе вообще по барабану, как они там расположены. Мне надо к изображению применить RLE шифрование.
Остался только один нерешенный вопрос: в структуре BITMAPFILEHEADER поле bfOffBits показывает 62. т.е. само изображение начинается с 63-го байта. Хедер = 14 байт, Инфо = 40 байт, итого 54 байта. Что записано в оставшихся 8-ми байтах?

Ну и сходу вопрос. Когда я сжимаю RLE-сжиманием, изображение потом должно читаться? Или читабельность вернется только после "расжатия" ?

[Ulex]

Что записано в оставшихся 8-ми байтах?

В оставшихся 8-ми байтах содержится массив RGBQUAD-ов, состоящий из двух элементов:

Если в BITMAPINFOHEADER поле biBitCount равно 1, то:

The bitmap is monochrome, and the bmiColors member contains two entries. Each bit in the bitmap array represents a pixel. If the bit is clear, the pixel is displayed with the color of the first entry in the bmiColors table; if the bit is set, the pixel has the color of the second entry in the table.

Т.е. чисто теоретически, да и собственно и практически вы можете сделать не чёрно-белую картинку, а красно-зелёную. Но при этом она всё равно будет монохромной.

[s-andriano]

Сообщение от MooNDeaR

Хедер = 14 байт, Инфо = 40 байт, итого 54 байта. Что записано в оставшихся 8-ми байтах?

Согласно документации там располагается палитра.

Ну и сходу вопрос. Когда я сжимаю RLE-сжиманием, изображение потом должно читаться? Или читабельность вернется только после "расжатия" ?

Сложный вопрос.
Как-то на практике принято применять несжатые BMP. Серьезные программы типа графических редакторов, конвертеров и вьюверов обычно понимают и сжатый. Но часть программ умеет работать только с несжатыми BMP.

[MooNDeaR]

Сложный вопрос.
Как-то на практике принято применять несжатые BMP. Серьезные программы типа графических редакторов, конвертеров и вьюверов обычно понимают и сжатый. Но часть программ умеет работать только с несжатыми BMP.

А как мне сообщить сторонней программе о том, что я сжал монохроматический файл? Записать что-то в Инфо структуру? Там вроде есть поле о использовании RLE сжатия, по поводу 4-х и 8-ми битных изображений По сути, мне фиолетово, эт просто лабораторная и если это очень гемморойно, то я потом разберусь

[s-andriano]

Да, в заголовке есть поле, в которое помещается идентификатор метода сжатия.
0 - несжатый.
Но если собираетесь сжимать, следует точно придерживаться одного из допустимых для BMP алгоритмов. И в заголовке проставить идентификатор именно этого алгоритма.