Как прочитать размер большого растрового изображения

Question

Как прочитать размер большого растрового изображения

0

У меня проблемы с чтением больших растровых изображений. Обратите внимание, что это 24-битный BMP файл. Поэтому у меня есть изображение размером 800х600. В файле, где он указывает ширину и высоту, я получаю это.

Ширина (4 байта):

20 03 00 00

Высота (4 байта):

58 02 00 00

Я экспортировал оба с Paint.NET и MS Paint. Оба имеют одинаковый выход. Похоже, что когда изображения становятся большими, вычисления ошибочны. С небольшими изображениями (100x100 и так далее) результаты - это то, что я хочу. Я тестировал изменение размера вручную (width = 800;), и он отлично работает для того, что мне нужно. То, что я делаю, суммирует все байты и объединяется в целое число.

Пример: (Я храню файл в векторе, называемом хранилищем):

unsigned int width = store[0x12] + store[0x13] + store[0x14] + store[0x15];

Затем я сделал программу, создав файл, чтобы сообщить мне, как была сохранена ширина.

ofstream s("hht.txt");
        s <<  width;
        s << "\n";
        s << dec << width;
        s << "\n";
        s << hex << width;
        s.close();

Это результат, который я получаю:

35
35
23

Итак, что я делаю неправильно?

ПРИМЕЧАНИЕ. Информация ширины -The находится в точке 0x12, а высота - 0x16. Файл -The - 800x600. -I не знают, как высота, но я знаю, что это неправильно.

user3804254 20 июль 2014, в 06:15

Источник

1

Попробуйте store[0x12] + store[0x13] << 8 + store[0x14] << 16 + store[0x15] << 24 и посмотрите, как это происходит.
PeterJ 20 июль 2014, в 03:34
0

@PeterJ дает мне 0.
user3804254 20 июль 2014, в 03:35
0

Когда вы видите число, например 1024, вы добавляете 1 + 0 + 2 + 4?
n.m. 20 июль 2014, в 03:36
0

@ Я не думаю, что прояснил себя. Я не добавляю 2 + 0 + 3 + 0 + 0, я получаю шестнадцатеричные значения, а не текст. Файл в шестнадцатеричном, а не в ascii.
user3804254 20 июль 2014, в 03:39
0

@PeterJ все еще дает мне 0.
user3804254 20 июль 2014, в 03:40
2

try width = *reinterpret_cast<uint32_t>(&store[0x12]) ;)
j_kubik 20 июль 2014, в 03:42
0

@j_kubik боже мой Спасибо большое. Это сработало! Пожалуйста, сделайте ваш комментарий ответом. Можете ли вы сказать мне, где я могу получить больше информации об этом? А как насчет store [0x13] и store [0x14] и store [0x15]? Кстати, я переключил uint32_t на int *.
user3804254 20 июль 2014, в 03:45
0

Хорошо, позвольте мне задать другой вопрос. Когда вы видите большое число, например 65 536, вы не добавляете 65 + 536 (десятичные числа), не так ли? Еще вы добавили 20 + 03 + 00 + 00 (шестнадцатеричные числа).
n.m. 20 июль 2014, в 03:46
2

@ user3804254: Вы смотрите 32-битные шестнадцатеричные числа с прямым порядком байтов . 0x00000320 равно 800 в десятичном виде, а 0x00000258 равно 600.
Blastfurnace 20 июль 2014, в 03:47
1

Здесь недостаточно быть ответом, и мне лень объяснять расположение переменных в памяти здесь - вы, вероятно, найдете что-то об этом в сети: P. Как уже было сказано, читайте о переменных размерах и машинах с прямым порядком байтов.
j_kubik 20 июль 2014, в 03:49
0

@nm :) Извините, но я не понимаю вашего вопроса. Число 800, и оно хранится как 20 03 00 00. Я хотел получить десятичное число от него. Похоже, решение было то, что сказал j_kubik. Я должен повторить, что файл в шестнадцатеричном формате, а не в ascii.
user3804254 20 июль 2014, в 03:50
0

Кстати, то, что я написал, нарушает правила псевдонимов, поэтому он может не работать при определенных обстоятельствах ...
j_kubik 20 июль 2014, в 03:50
0

Почему вы предположили, что он был сохранен в ASCI?
j_kubik 20 июль 2014, в 03:51
0

@j_kubik Я не предполагал, что это было в ASCII. Мне только что показалось, что nm говорит об ascii. Я всегда знал, что это было в гексе.
user3804254 20 июль 2014, в 03:56
0

В вашем коде вы добавляете гекс 20 и гекс 3 вместе, давая вам гекс 23 / декабрь 35. Декабрь 800 - это шестнадцатеричный 320. Значения имеют младший порядок, и вам нужно читать в гекс 03 как декабрь 768.
Maple 20 июль 2014, в 04:00
0

Вы знакомы с концепцией 10-значных и 16-значных чисел? Вы понимаете, что 00000320 в шестнадцатеричном формате - это 800 десятичных? Почему вы добавляете 00 + 00 + 03 + 20, а не 8 + 00?
n.m. 20 июль 2014, в 04:02
0

Люди пытаются вам сказать, что вы неверно истолковываете как ASCII, так это то, что вы не просто добавляете цифры числа, чтобы получить число. Для десятичного 800 вы добавляете 8 * 100 + 0 * 10 + 0 * 1, чтобы получить 800. Для шестнадцатеричного 320 вы добавляете 3 * 256 + 2 * 16 + 0 * 1, чтобы получить 800. Это была аналогия.
Mark Ransom 20 июль 2014, в 04:15

Показать ещё 15 комментариев

Теги:

c++

hex

decimal

binary

bitmap

1 ответ

Ещё вопросы

Попробуйте store[0x12] + store[0x13] << 8 + store[0x14] << 16 + store[0x15] << 24 и посмотрите, как это происходит.
Когда вы видите число, например 1024, вы добавляете 1 + 0 + 2 + 4?
@ Я не думаю, что прояснил себя. Я не добавляю 2 + 0 + 3 + 0 + 0, я получаю шестнадцатеричные значения, а не текст. Файл в шестнадцатеричном, а не в ascii.
@j_kubik боже мой Спасибо большое. Это сработало! Пожалуйста, сделайте ваш комментарий ответом. Можете ли вы сказать мне, где я могу получить больше информации об этом? А как насчет store [0x13] и store [0x14] и store [0x15]? Кстати, я переключил uint32_t на int *.
Хорошо, позвольте мне задать другой вопрос. Когда вы видите большое число, например 65 536, вы не добавляете 65 + 536 (десятичные числа), не так ли? Еще вы добавили 20 + 03 + 00 + 00 (шестнадцатеричные числа).
@ user3804254: Вы смотрите 32-битные шестнадцатеричные числа с прямым порядком байтов . 0x00000320 равно 800 в десятичном виде, а 0x00000258 равно 600.
Здесь недостаточно быть ответом, и мне лень объяснять расположение переменных в памяти здесь - вы, вероятно, найдете что-то об этом в сети: P. Как уже было сказано, читайте о переменных размерах и машинах с прямым порядком байтов.
@nm :) Извините, но я не понимаю вашего вопроса. Число 800, и оно хранится как 20 03 00 00. Я хотел получить десятичное число от него. Похоже, решение было то, что сказал j_kubik. Я должен повторить, что файл в шестнадцатеричном формате, а не в ascii.
Кстати, то, что я написал, нарушает правила псевдонимов, поэтому он может не работать при определенных обстоятельствах ...
Почему вы предположили, что он был сохранен в ASCI?
@j_kubik Я не предполагал, что это было в ASCII. Мне только что показалось, что nm говорит об ascii. Я всегда знал, что это было в гексе.
В вашем коде вы добавляете гекс 20 и гекс 3 вместе, давая вам гекс 23 / декабрь 35. Декабрь 800 - это шестнадцатеричный 320. Значения имеют младший порядок, и вам нужно читать в гекс 03 как декабрь 768.
Вы знакомы с концепцией 10-значных и 16-значных чисел? Вы понимаете, что 00000320 в шестнадцатеричном формате - это 800 десятичных? Почему вы добавляете 00 + 00 + 03 + 20, а не 8 + 00?
Люди пытаются вам сказать, что вы неверно истолковываете как ASCII, так это то, что вы не просто добавляете цифры числа, чтобы получить число. Для десятичного 800 вы добавляете 8 * 100 + 0 * 10 + 0 * 1, чтобы получить 800. Для шестнадцатеричного 320 вы добавляете 3 * 256 + 2 * 16 + 0 * 1, чтобы получить 800. Это была аналогия.

Maple · Accepted Answer · 2014-07-20T04-09-00.000Z

Есть пара ошибок в том, как вы вычисляете ширину.

unsigned int width = store[0x12] + store[0x13] + store[0x14] + store[0x15];

Что вы здесь делаете с вашим примером ширины:

unsigned int width = 0x20 + 0x03 + 0x00 + 0x00; // width = 0x23

Что это в десятичной форме:

unsigned int width = 32 + 3 + 0 + 0; // width = 35

Это не дает вам реального значения 20 03 00 00, потому что в этом случае 03 не должен представлять 0x03, он должен представлять 0x0300 (768 в десятичной системе).

Почему это работает с небольшими номерами? Ответ будет заключаться в том, что вы добавляете вместе одно число с тремя парами нулей в цифрах, которые обычно нужно умножать, чтобы получить их реальные значения. (Пример: ширина 32 будет равна 20 00 00 00, что добавит вместе 0x20 + 0x00 + 0x00 + 0x00, чтобы получить 0x20, что по-прежнему равно 32 десятичным)

Если вы еще не заметили, битмап содержит значения в порядке малозначности. Другими словами, значение ширины вместе не будет 0x20030000 (537067520 в десятичной форме), это будет 0x00000320 (800 в десятичной системе, ширина вашего растрового изображения).

width = *reinterpret_cast<uint32_t>(&store[0x12])

может работать в этом случае, но не только это может нарушить правила псевдонимов, это будет работать только на вашу реализацию, если uints тоже малозначительны. Если они большие, ваша ширина будет рассчитываться как 0x20030000 (537067520) вместо 0x00000320 (800).