Графические устройства



  

Образ рисунка в файле

Исторически стандарт BMP предназначался для Windows, а в ней при построении изображений "по умолчанию" начало координат расположено в нижнем левом углу экрана. Значения по оси х возрастают слева направо, а по оси Y — снизу вверх. На первый взгляд ничего особенного в этом нет, именно так расположены и направлены оси координат при черчении или рисовании различных графиков на бумаге. Однако это только на первый взгляд.

Расположение строк. При таком расположении осей координат последняя строка рисунка оказывается первой, а его первая строка-- последней. Обычно образ рисунка записывают в файл так, чтобы его было удобно вce производить на экране.

Разработчики BMP так и поступили — образ рисунка хранится в файле в перевернутом виде, сначала записана его последняя строка, за ней предпоследняя и так вплоть до первой строки, которая записана последней. В таком случае, для построения рисунка снизу вверх строки из файла считываются последовательно друг за другом.
Следует отметить, что в перевернутом виде изображение хранится во всех графических форматах, предназначенных для использования Windows и ее приложениями. В частности, в разделе данной книги уже говорилось, что так хранятся рисунки курсоров (файлы типа cur) и пиктограмм (файлы типа ico).

На практике эта особенность форматов для Windows приводит к необходимости применения специальных подпрограмм, переворачивающих образ рисунка в процессе его воспроизведения.

Упаковка кодов точек

Если в образе рисунка использовано 2 или 16 цветов, то для сокращения размера файла он хранится в упакованном виде.

У 16-цветных рисунков значения кодов точек изменяются от о до огь, поэтому в одном байте можно записать коды двух подряд расположенных точек. Код левой точки записывается в старшую тетраду, а код правой -в младшую тетраду байта.
У 2-цветных рисунков значения кодов точек изменяются от о до 1 и в одном байте можно записать коды восьми подряд расположенных точек. Код левой точки группы записывается в старший (седьмой), а код правой точки группы — в младший (нулевой) разряд байта.

Такой способ упаковки точек рисунков, содержащих небольшое количество цветов, применяется не только в формате BMP, но также в PCX, GIF и других форматах. В разделе были приведены примеры подпрограмм 3.17 и 3.18, выполняющих распаковку в процессе построения строки рисунка.

Сжатие образа рисунка

Образы рисунков, содержащих более 2-х цветов, могут быть подвергнуты сжатию по способу RLE (Run-Length-Encoding). Прежде всего, отметим, что сжатие возможно только в формате для Windows, в формате для OS/2 оно просто не предусмотрено.

В формате для Windows (см. табл. А. 1) имеется поле BiCompr, в котором указано состояние образа рисунка. Если в этом поле указан о, то образ рисунка хранится в естественном виде. Bicompr=1 означает, что рисунок, содержащий 256 цветов, сжат по способу RLE. BiCompr=2 означает, что рисунок, содержащий 16 цветов, предварительно упакован по 2 точки в байт, а затем сжат по cпособу RLE.

Алгоритм декомпрессии файла, сжатого по способу RLE, следующий:

  1. 1. Если значение текущего (первого) байта отлично от нуля, то оно указывает, сколько раз надо повторить в выходном массиве код, находящийся в следующем байте. В противном случае проверяется код следующего байта.
  2. 2. Если он больше двух (от 3 до 255), то соответствующее количество последующих байтов просто копируется в выходной массив, т. к. они не упакованы.
  3. 3. Значения второго байта 0, 1 и 2 являются признаками конца строки (0), конца рисунка (1) и изменения текущих координат (2). В последнем случае в двух следующих байтах указаны приращения значений координат х и Y, которые надо прибавить к их текущим значениям.

Таким образом, в основе упаковки по способу RLE лежит замена группы подряд расположенных одинаковых кодов двумя байтами, в первом указыва-ются количество повторов, а во втором — повторяемый код. Сама по себе эта идея не принадлежит разработчикам стандарта BMP, они только выбирали конкретную реализацию. Аналогичный способ используется и в стандарте сх, но его реализация несколько проще. Мы обсуждали ее в разделе и в разделе основной части книги.

Замечание
Автор исследовал достаточно много файлов формата BMP, но не обнаружил ни одного сжатого рисунка. Напомним также, что в формате для OS/2 сжатие просто исключено. Остается только гадать, зачем надо было описывать способ сжатия и не использовать его на практике? Ведь аналогичный способ сжатия применяется при подготовке файлов формата PCX. Мы не будем рассматривать программирование распаковки именно по причине отсутствия упакованных рисунков.

  
Назад Начало Вперед



Книжный магазин