Как bmp файл перевести цифровой массив

Обновлено: 07.07.2024

BMP (BitMaP) - основной метод хранения несжатых графических файлов. Фотография с 6-ти мегапискельного фотоаппарата в этом формате будет иметь размер 18М байт.

В начале 2000-х годов Microsoft пыталась сделать BMP-файлы основным видом графических файлов. В связи с этим была добавлена возможность хранения в этих файлах графических файлов других графических форматов (включая png, jpeg и др.). Но сейчас от этой идеи отказались и BMP-файлы используются лишь для хранения несжатых изображений.

Помимо базового варианта (3 байта на точку, BMP-24) может быть "серый" файл (1 байт на точку) и некоторые другие. Далее мы будем рассматриать только файлы формата BMP-24.

Строчки в bmp-файле хранятся в обратном порядке, то есть в начале идет самая нижняя строка изображения. Внутри строки байты имеют порядок BGR BGR . Кроме того, длина каждой строки выровнена до кратного четырех. То есть для изображения шириной 3 точки длина строки равна 12 байт (3 точки по 3 байта, всего 9 байт, затем увеличиваем длину строки до кратного 4).

В начале bmp-файла идет заголовок следующей структуры: Отметим, что в этом примере кода тип int предполагается 32-битовым. Если в вашем случае это не так, то вместо int надо использовать тип 4-х байтового целого числа. Аналогично, __int16 означает 16-битовое целое число. Если ваш компилятор такого идентификатора не знает, то его надо заменить на соответствующий.

Чтение файла формата BMP-24 можно осуществить следующей функцией. В переменных mx,my возвращаются размеры файла. Для графических данных функция выделяет память (new int[mx*my]). Именно этот указатель и возвращатся в качестве результата. Он указывает на одномерный массив целых чисел, в котором лежат последовательно цветовые значения всех пикселей изображения. В каждое целое 4-х байтовое число упаковано по 3 байта RGB в формате R + 256*G + 65536*B. В случае какой-либо ошибки память не выделяется, возвращается NULL.
ВНИМАНИЕ!. Освобождать память должна будет программа, вызвавшая данную функцию, например: Для записи в BMP-файл можно использовать фунцию

Эта статья про то, как выглядит графический формат bmp. Хоть это и один из простых форматов, но из-за того, что существует много вариаций этого формата, то не все моменты очевидны. Итак, хватит лить воду, начнем.

Структуры формата

Формат bmp (от слов BitMaP - битовая карта, или, говоря по-русски, битовый массив) представляет из себя несжатое (в основном) изображение, которое довольно легко читается и выводится в ОС Windows, в которой есть специальные функции API, которые в этом помогают.

Для начала приведем графическое представление данных в bmp (картинка взята из MSDN).

В начале стоит заголовок файла (BITMAPFILEHEADER). Он описан следующим образом:

bfType определяет тип файла. Здесь он должен быть BM. Если Вы откроете любой файл BMP в текстовом (а лучше в 16-ричном редакторе), то увидите, что первые два символа - это BM (от слова BitMap, как вы уже, наверное, догадались).
bfSize - это размер самого файла в байтах. Строго говоря вы должны его высчитывать (что рекомендуется), но я ставил размер файла неправильно (правда, не нарочно :)) и никаких проблем не было (ACDSee читало без проблем, моя программа работала), но я вам не рекомендую писать его заведомо неправильно, вдруг появится добросовестная программа, которая сверит этот размер с настоящим и решит, что это не bmp, а что-нибудь другое. В идеале все программы для того, чтобы убедиться, что перед ними действительно bmp, а не подделка, должны, во-первых, проверить, что bfType содержит "BM" (без кавычек), а, во-вторых, что bfSize равен размеру файла.
bfReserved1 и bfReserved2 зарезервированы и должны быть нулями.
bfOffBits. Это один из самых важных полей в этой структуре. Он показывает, где начинается сам битовый массив относительно начала файла (или, как написано в MSDN, "от начала структуры BITMAPFILEHEADER"), который и описывает картинку. То есть, чтобы гарантированно попадать на начало массива вы должны писать:

Здесь и далее будем считать, что переменная bfh объявлена как BITMAPFILEHEADER bfh;

А дальше идет структура BITMAPINFOHEADER, которая объявлена так:

biSize - это размер самой структуры. Ее нужно инициализировать следующим образом: bih.biSize = sizeof (BITMAPINFOHEADER);
Снова здесь и дальше будем считать, что bih объявлена следующим образом: BITMAPINFOHEADER bih;
biWidth и biHeight задают соответственно ширину и высоту картинки в пикселях.
biPlanes задает количество плоскостей. Пока оно всегда устанавливается в 1.
biBitCount - Количество бит на один пиксель. Подробнее про это поговорим ниже.
biCompression обозначает тип сжатия. Не удивляйтесь и не пугайтесь, что в bmp и вдруг сжатие. Я лично не видел не одной сжатой bmp (но я не говорю, что таких не существует). Если сжатия нет, то этот флаг надо устанавливать в BI_RGB. В этой статье мы говорим про несжатый формат, поэтому другие флаги я даже не буду перечислять. Похоже, что эта же структура используется и в файлах JPEG и PNG, потому что, начиная с Windows 98 тут появились варианты BI_JPEG, которая показывает, что эта картинка - JPEG и BI_PNG, что это PNG (про формат Jpeg я ничего не знаю, я только сделал эти выводы исходя из того, что написано в MSDN).
biSizeImage обозначает размер картинки в байтах. Если изображение несжато (то есть предыдущее поле установлено в BI_RGB), то здесь должен быть записан ноль. biXPelsPerMeter и biYPelsPerMeter обозначают соответственно горизонтальное и вертикальное разрешение (в пикселях на метр) конечного устройства, на которое будет выводиться битовый массив (растр). Приложение может использовать это значение для того, чтобы выбирать из группы ресурсов наиболее подходящий битовый массив для нужного устройства. Дело в том, что формат bmp - это по сути аппаратно-независимый растр, то есть когда внешний вид того, что получается не зависит от того, на что этот растр проецируется (если можно так выразится). Например, картинка будет выглядеть одинаково вне зависимости от того, рисуется она на экране монитора или печатается на принтере. Но вот разрешение у устройств разное, и именно для того, чтобы выбрать наиболее подходящую картинку из имеющихся и используют эти параметры.
biClrUsed определяет количество используемых цветов из таблицы. Если это значение равно нулю, то в растре используется максимально возможное количество цветов, которые разрешены значением biBitCount. Это актуально только для сжатых картинок. Если biClrUsed не нуль и biBitCount меньше 16, то biClrUsed определяет текущее число цветов графического движка или доступного драйвера устройства. Если biBitCount больше или равно 16, то biClrUsed определяет размер таблицы цветов, используемой для оптимизации текущей системной палитры.
biClrImportant - это количество важных цветов. Определяет число цветов, которые необходимы для того, чтобы изобразить рисунок. Если это значение равно 0 (как это обычно и бывает), то все цвета считаются важными.

Виды формата BMP

Все разновидности формата bmp условно можно разделить на два типа: палитровые и беспалитровые. То есть используется в данном с формате палитра или нет. Заметьте, что палитра может быть даже в беспалитровых форматах, только там она не используется. В беспалитровых bmp цвет высчитывается прямо из тех битов, которые идут в файле, начиная с некоторого места. А в палитровых каждый байт описывает один или несколько пикселей, причем значения байта (или битов) - это индекс цвета в палитре. Для начала приведу таблицу, которая сравнивает возможные варианты. Вид картинки (палитровая или беспалитровая) зависит от того, сколько бит отдается на один пиксель, то есть от значения biBitCount структуры BITMAPINFOHEADER.

biBitCount	Палитровый или беспалитровый формат	Максимально возможное количество цветов	Примечания
1	Палитровый	2	Двуцветная, заметьте, не обязательно черно-белая, палитровая картинка. Если бит растра (что это такое чуть ниже) сброшен (равен 0), то это значит, что на этом месте должен быть первый цвет из палитры, а если установлен (равен 1), то второй.
4	Палитровый	16	Каждый байт описывает 2 пикселя. Вот пример из MSDN.Если первый байт в картинке 0x1F, то он соответствует двум пикселям, цвет первого - второй цвет из палитры (потому что отсчет идет от нуля), а второй пиксель - 16-й цвет палитры.
8	Палитровый	256	Один из самых распространенных вариантов. Но в то же время и самых простых. Палитра занимает один килобайт (но на это лучше не рассчитывать). Один байт - это один цвет. Причем его значение - это номер цвета в палитре.
16	Беспалитровый	2^16 или 2^15	Это самый запутанный вариант. Начнем с того, что он беспалитровый, то есть каждые два байта (одно слово WORD) в растре однозначно определяют один пиксель. Но вот что получается: битов-то 16, а компонентов цветов - 3 (Красный, Зеленый, Синий). А 16 никак на 3 делиться не хочет. Поэтому здесь есть два варианта. Первый - использовать не 16, а 15 битов, тогда на каждую компоненту цвета выходит по 5 бит. Таким образом мы можем использовать максимум 2^15 = 32768 цветов и получается тройка R-G-B = 5-5-5. Но тогда за зря теряется целый бит из 16. Но так уж случилось, что наши глаза среди всех цветов лучше воспринимают зеленый цвет, поэтому и решили этот один бит отдавать на зеленую компоненту, то есть тогда получается тройка R-G-B = 5-6-5, и теперь мы может использовать 2^16 = 65536 цветов. Но что самое неприятное, что используют оба варианта. В MSDN предлагают для того, чтобы различать сколько же цветов используется, заполнять этим значением поле biClrUsed из структуры BITMAPINFOHEADER. Чтобы выделить каждую компоненту надо использовать следующие маски. Для формата 5-5-5: 0x001F для синей компоненты, 0x03E0 для зеленой и 0x7C00 для красной. Для формата 5-6-5: 0x001F - синяя, 0x07E0 - зеленая и 0xF800 красная компоненты соответственно.
24	Беспалитровый	2^24	А это самый простой формат. Здесь 3 байта определяют 3 компоненты цвета. То есть по компоненте на байт. Просто читаем по структуре RGBTRIPLE и используем его поля rgbtBlue, rgbtGreen, rgbtRed. Они идут именно в таком порядке.
32	Беспалитровый	2^32	Здесь 4 байта определяют 3 компоненты. Но, правда, один байт не используется. Его можно отдать, например, для альфа-канала (прозрачности). Читать растр в данном случае удобно структурами RGBQUAD, которая описана так:

Хранение данных в формате bmp

Ну вот и подошли к самому интересному. После структур BITMAPFILEHEADER и BITMAPINFOHEADER идет палитра. Причем, если формат беспалитровый, то ее может и не быть, однако, на это рассчитывать не надо. Дело в том, что, когда я только начинал разбираться с форматом bmp, в одной книжке я вычитал, что, якобы, если формат беспалитровый, то у нее вообще нет палитры. Там даже были две картинки - схемы формата: одна с палитрой, другая без. А я в это время писал программу, которая усердно оперирует с bmp-шками. И мне надо было преобразовывать входящие картинки из 256 цветов в 24-битные (если таковые имелись) во временные файлы. И я в 24-битных палитру просто не создавал (bfOffBits из структуры BITMAPFILEHEADER у меня был равен сумме sizeof(BITMAPFILEHEADER) + sizeof (BITMAPINFOHEADER), а входящие 24-разрядные оставлял без изменений. С 256-цветными растрами все работало как надо, пока мне не попалась 24-разрядная картинка, у которой внизу вместо нужной части отображался мусор. Я не сразу понял в чем дело. Пока не сравнил размер исходного файла с теоретическим, который должен был быть, не будь палитры. Разница оказалась ровно 1 Kб (ровно 1024 байта). Там была палитра. Поэтому никогда не рассчитывайте на то, есть ли палитра и не надейтесь на ее размер (хотя все картинки, которые мне попадались имели размер палитры 256 цветов, или 1Кб), всегда перемещайтесь по файлу на начало растра, используя bfOffBits. Палитра представляет из себя массив структур RGBQUAD идущих друг за другом. Даже если в палитре используются не все цвета (а только, например, 16), то часто все равно под палитру отводят 256 полей. А 256 * 4 = 1024, где 4 - размер структуры RGBQUAD, то есть и получается тот самый один килобайт.

Сразу за палитрой идет сам растр. Тут уже более запутано. Во-первых, пиксели тут описываются так, как написано в таблице выше в зависимости от формата. И могут сами содержать значение компонентов цвета (для беспалитровых), а могут быть индексами массива-палитры. Сама картинка записывается построчно. Во-вторых, картинка идет как бы перевернутая вверх ногами. То есть сначала записана нижняя строка, потом предпоследняя и так далее до самого верха. И, в-третьих, как написано в [1], если размер строки растра не кратен 4, то она дополняется от 1 до 3 пустыми (нулевыми) байтами, чтобы длина строки оказалась кратна параграфу. Вот это и есть самое неприятное. Дело в том, что для каждого формата приходится подстраивать это число пустых байтов (правда, я люблю туда записывать часть палитры, просто мне не хочется заводить лишние "нулевые" переменные, если все-равно эти байты пропускают и никому они не нужны). Я привожу таблицу с формулами, которые показывают для какого формата сколько байт надо дописывать в конец строки. Там под переменной Width, как можно догадаться, подразумевается ширина картинки. Все эти формулы были установлены экспериментально. Я приведу пример только для наиболее используемых форматов. Для остальных вы можете написать сами.

biBitCount	Формула на С
8	(3 * Width) % 4
16	(2 * Width) % 4
24	Width % 4

Примеры программ

Все исходники вы можете скачать отсюда.Я особо не буду тут много писать. Просто приведу функции с комментариями.

Привет 1. Создание картинки в формате bmp.
Здесь создается однотонная картинка. В примерах таких функций три: создание bmp 8, 16 и 24 бит. Я приведу только для 16-битных.

// Пусть у нас будет картинка размером 35 x 50 пикселей
int Width = 35 ;
int Height = 50 ;

color - цвет картинки. Значение этой переменной должно быть заполнено в соответствии с первой таблицей. Получившуюся картинку вы можете посмотреть в ACDSee, например. Просто я пробовал ее открыть в Photoshop'е, оказалось, что в этом формате он их читать не умеет. А вы можете :).

Пример 2. Преобразование картинки из формата 8 бит (256 цветов) в 24 бит.

В функцию надо передавать имена исходного и конечного файла соответственно.

Источники

Д. Гончаров, Т. Салихов. "DirectX 7.0 для программистов"
MSDN

Создайте в графическом редакторе PAINT растровое изображение размером 50*35 пикселов. Выберите максимальный масштаб изображения и включите сетку. Сохраните рисунок в формате BMP как монохромный (файл 50_35.bmp).

Откройте листинг файла 50_35.bmp в приложении Commander (TC, VC или WC) для просмотра (клавиша F3) в шестнадцатеричном (HEX) представлении.

Сопоставим картинку растрового изображения и HEX коды в листинге файла 50_35.bmp.

Коды с 19-го по 23-й (32 00 00 00) определяют размер растра (число пикселов) по горизонтали. Коды с 24-го по 27-й (23 00 00 00) определяют размер растра по вертикали. Чтобы убедиться в этом воспользуйтесь калькулятором. В рассматриваемом примере размер растра – 50 * 35. HEX коду 32 соответствует десятичное (DEC) число 50, HEX коду 23 – DEC число 35.

На размера растра отводится 4 байта (HEX кода). Одним байтом определяется размер от 0 до 255. При превышении 255 (код FF) будет задействован следующий байт. Например, DEC числу 256 соответствует HEX код 100. Размер растра 256 будет представлен в листинге файла (00 01 00 00).

Коды символов, начиная с 63-го и до конца файла, содержат последовательность данных о цвете точек растра – в порядке слева направо вдоль каждой ряда и снизу вверх по рядам. Один байт описывает 8 точек, белая точка в BIN коде описывается единицей, черная – нулем.

Сколько байт необходимо для описания 50 точек в одном ряду? Не менее 7 (7*8=56). Но используется 8 (8*8=64), соблюдается кратность 4 байтам (4*8=32). Обратите внимание в листинге файла на HEX коды в конце описания каждого ряда повторяются байты FF FF C0 00. Эти байты описывают последние 32 точки из 64-х. Из них 14 несуществующих точек (64-50=14) описаны нулями.

Точки какого ряда описаны кодом FC 1F? Отсчитываем ряды по (по 8 байт в каждом), можно также ориентироваться на код (C0 00) в конце каждого ряда. Получаем 11-й ряд. В нем находятся 5 точек. Проверяем результат с помощью калькулятора.

Программа последовательно считывает из BMP-файла HEX-коды. По этим данным определяется порядковый номер каждой черной точки в ряду, начиная слева. Порядковые номера черных точек каждого ряда заносятся в список, который после окончании чтения ряда записывается в файл Result.txt.

Информация, записанная в файл Result.txt:

Описание программы

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

Размер растра (xsize и ysize) определяется парой из 4-х байт. Как объединить эти 4 байта в одно число? Рассмотрим более простую задачу. Как из 4-х цифр «5» «8» «9» и «1» сформировать число 1985? Для этого каждую цифру сдвигаем влево на соответствующее количество разрядов (добавляем нули слева), а результат суммируем.

Аналогично решается задача формирования 4-х байтного числа. В пользовательской функции (r) из 4-х байтов сложением формируется одно число. Каждый байт перед сложением сдвигается на соответствующее количество разрядов (1, 2 и 3 байта). Сдвиг выполняется функцией Lsh, параметры сдвига указывается в битах (8, 16 и 24). Функция (r) возвращает число в 10-тичном представлении. Результат запоминается в переменных (xsize и ysize).

Далее считываются и обрабатываются точки, на предмет выявления их цвета. Используется внешний цикл по ysize и внутренний цикл по xsize.

Учитывая, что число байтов, которые описывают один ряд точек, кратно 4 объединим их по аналогии с предыдущей задачей. Только в этом случае из 4-х цифр «5» «8» «9» и «1» будем формировать число 5891:

Отметим, что любое число независимо от его представления (HEX, DEC, BIN) остается одним и тем же. А функции обрабатывают его по-разному. Например, функция read-char работает с байтами, а Lsh с битами.

После тестирования первого пиксела, единица в маске сдвигается вправо (lsh mask -1):

Тестирование каждой точки, которая описывается в переменной n, анализируется путем применения побитового умножения c значением переменной mask(if (= (logand n mask) 0) (setq lst (cons x lst))):

В верхнем примере проверялась крайняя 6-я точка сформированного числа, в нижнем примере – 19-я точка. Если результат побитового умножения ноль, то проверяемая точка – черная. Порядковый номер точки в ряду сохраняется в переменой x. Каждая черная точка заносится в начало списка (setq lst (cons x lst)). По окончании анализа ряда список записывается наоборот в файле результата result.txt (princ (reverse lst) fo).

На рисунке приведен пример простого изображения (размер 34 *10 точек) из 3-х красных точек в левом нижнем углу, остальные точки белые.

Раскрываем листинг файла и, сопоставляя с изображением, определяем, как описываются данные в нем:

Файл начинается с символов “BM”, указывающих на формат файла.

С 19 позиции 4 байта (22 00 00 00) указывают размер файла по X (количество точек в строке 34), с 23-й позиции – 4 байта (0A 00 00 00) указывают размер файла по Y (количество рядов 10).

Начиная с 55-го байта и до конца файла содержатся данные о цвете точек растра – в порядке слева направо вдоль каждого ряда и снизу вверх по рядам. Одна точка описывается тремя байтами, каждый из которых представляет синюю (Blue), зеленую (Green) и красную (Red) составляющие цвета. В рассматриваемом примере первая точка (красного цвета) описана байтами (00 00 FF) вторая (белого цвета) – (FF FF FF).

Каждый ряд точек описывается количеством байт, кратным 4. Ряд из 34 точек должен описываться 34*3 + 2 =104 байтами. Два байта (00 00) добавляется в конце описания каждого ряда для обеспечения кратности 4. Если бы ряд состоял из 33 точек, то в конце каждого ряда добавилось по 1 байту для обеспечения кратности 4 (33*3 + 1 =100).

Ниже приводится модуль программы, который используется в приложении для идентификации продуктов (фруктов и овощей) на основе данных от видеокамеры. Модуль обеспечивает загрузку картинки и считывания точек (по 3 байта на каждую точку) из файла.

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

За информационным заголовком следует таблица цветов, представляющая собой массив из 256 (по числу цветов) 4-байтовых полей. Каждое поле соответствует своему цвету в палитре, а три байта из четырех – компонентам синей, зеленой и красной составляющих для этого цвета. Последний, самый старший байт каждого поля зарезервирован и равен 0.

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

На нижнем рисунке представлено точечное изображение (10*5) и конец листинга файла, где захвачены несколько полей из таблицы цветов и приводятся данные об изображении (обведены красной линией).

На рисунке выделены по 4 байта цветов палитры, которые используются для указания цвета точек. Белый цвет имеет последний номер в таблице цветов – 255 (FF). Синий цвет указан под номером 252 (FC), зеленый – 250 (FA), красный – 249 (F9). Длина каждой строки дополняется 2-я байтами (00 00) для кратности 4 (10+2=12).

Методика замеров

Немного о методике – в таких случаях я предпочитаю не гоняться за сверхточными таймерами, а просто много раз выполнять одно и то же действие. Конечно, с одной стороны, в этом случае данные и код уже будут в кэше процессора. Но, зато мы вычленяем затраты на первый запуск кода, связанный с переводом MSIL-кода в код процессора и другие накладные расходы. Чтобы гарантировать это, предварительно запускаем каждый кусок кода один раз – выполняем так называемый «прогрев».

Компилируем код в Release. Запускаем его обязательно не из-под студии. Более того, студию также желательно закрыть – сталкивался со случаями, когда сам факт её «запущенности» иногда сказывается на полученных результатах. Также, желательно закрыть и другие приложения.

Запускаем код несколько раз, добиваясь типичных результатов – необходимо убедиться, что на нем не сказывается какой-то неожиданный процесс. Скажем, проснулся антивирус или еще что-то. Все эти меры позволяют нам получить стабильные, повторяемые результаты.

«Наивный» метод

Именно этот метод был применен в оригинальной статье. Он состоит в том, что используется метод Bitmap.GetPixel(x, y). Приведем полностью код подобного метода, который конвертирует содержимое битмапа в трехмерный байтовый массив. При этом первая размерность – это цветовая компонента (от 0 до 2), вторая – позиция y, третья – позиция x. Так сложилось в моих проектах, если вам захочется расположить данные иначе – думаю, проблем не возникнет.

Обратное преобразование аналогично, только перенос данных идет в другом направлении. Я не буду приводить его код здесь – желающие могут посмотреть в исходных кодах проекта по ссылке в конце статьи.

100 преобразований в изображение и обратно на моем ноутбуке с процессором I5-2520M 2.5GHz, требуют 43.90 сек. Получается, что при изображении 512*512, только на перенос данных, тратится порядка полусекунды!

Прямая работа с данными Bitmap

К счастью, класс Bitmap предоставляет более быстрый способ обратиться к своим данным. Для этого нам необходимо воспользоваться ссылками, предоставляемыми классом BitmapData и адресной арифметикой:

Такой подход дает нам получить 0.533 секунды на 100 преобразований (ускорились в 82 раза)! Думаю, это уже отвечает на вопрос – а стоит ли писать более сложный код преобразования? Но можем ли мы еще ускорить процесс, оставаясь в рамках managed-кода?

Массивы vs указатели

Многомерные массивы являются не самыми быстрыми структурами данных. Здесь производятся проверки на выход за пределы индекса, сам элемент вычисляется, используя операции умножения и сложения. Поскольку адресная арифметика уже дала нам один раз существенное ускорение при работе с данными Bitmap, то может быть, попробуем её применить и для многомерных массивов? Вот код прямого преобразования:

Результат? 0.162 сек на 100 преобразований. Так что ускорились еще в 3.3 раза (270 раз по сравнению с «наивной» версией). Именно подобный код и использовался мною при исследованиях алгоритмов.

Зачем вообще переносить?

Не совсем очевидно, а зачем вообще переносить данные из Bitmap. Может вообще, все преобразования осуществлять именно там? Соглашусь, что это один из возможных вариантов. Но, дело в том, что многие алгоритмы удобнее проверять на данных с плавающей запятой. Тогда нет проблем с переполнениями, потерей точности на промежуточных этапах. Преобразовать в double/float-массив можно аналогичным способом. Обратное преобразование требует проверки при конвертации в byte. Вот простой код такой проверки:

Добавление таких проверок и преобразование типов замедляет наш код. Версия с адресной арифметикой на double-массивах исполняется уже 0.713 сек (на 100 преобразований). Но на фоне «наивного» варианта – она просто молния.

А если нужно быстрее?

Если нужно быстрее, то пишем перенос, обработку на C, Asm, используем SIMD-команды. Загружаем растровый формат напрямую, без обертки Bitmap. Конечно, в этом случае мы выходим за пределы Managed-кода, со всеми вытекающими плюсами и минусами. И делать это имеет смысл для уже отлаженного алгоритма.

Порядок данных точно такой же, как и в оригинальном Bitmap. Т.е., компоненты перемешаны. Если мы хотим их отделить друг от друга — нужно будет все-равно проходиться циклом по массиву, копируя данные.
Тип у яркости остается byte, в то же время, часто бывает удобно промежуточные вычисления выполнять с плавающей запятой.
Marshal.Copy() работает с одномерными массивами. Да, они конечно самые быстрые и не очень сложно везде писать rgb[x+width*y], но все-таки.

Update 2016-04-25:
Пользователь Ant00 указал на ошибку в коде метода BitmapToByteRgbQ. Она не сказывалась на времени, но перекладывание осуществлялось неправильно. Была ошибка при копипасте фрагментов из работающего кода. Поправил. Спасибо за настойчивость (не с первого раза я внимательно рассмотрел код в статье, которой уже 2.5 года).

Читайте также: