xbm

Мне в комментариях к предыдущей заметке задали в вопрос — а насколько графика, представленная шрифтом Брайля, проигрывает по размеру формату XBM? Я прикинул, что должна даже выигрывать — всё-таки XBM весьма многословный формат, предназначенный, прежде всего, для встраивания картинок в программы на языке Си.

Давайте посмотрим на какую-нибудь небольшую картинку:

#define bullet_width 7
#define bullet_height 7
static char bullet_bits[] = {
   0x1c, 0x3e, 0x5f, 0x3f, 0x5d, 0x2a, 0x14};

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

В итоге размер файла можно примерно оценить на как 77 + 7×7/(8/5) ≈ 107 байт. В реальности чуть больше из-за форматирования.

Если же перевести эту картинку в шрифт Брайля, то всё получится куда компактнее. Каждый символ шрифта занимает три байта и кодирует сразу восемь точек (2×4), плюс надо учесть в расчётах переводы строк: ceil(7/4) × (ceil(7/2) × 3 + 1) = 26 байт.

А есть ли условия, при которых XBM был бы компактнее его представления в Брайле?

Логика подсказывает, что это должны быть какие-то граничные случаи, вроде картинки в один пиксель по какому-то из измерений — в Брайле всё равно придётся завать восемь точек, как ни крути.

Я наугад выбрал разрешение 1×100 и угадал: 77 + 1×100/(8/5) ≈ 140 байт против ceil(1/4) × (ceil(100/2) × 3 + 1) = 151 байт.

Добавлено позднее: я не знаю как решить задачу нахождения этого порога аналитически, поэтому решил перебором, написав программу на языке R:

lhs <- \(w, h) ceiling(w/4) * (3 * ceiling(h/2) + 1)
rhs <- \(w, h) 77 + (5 * w * h) / 8

holds <- \(w, h) lhs(w, h) > rhs(w, h)

W <- 500
H <- 500

min_h <- \(w) { i <- which(holds(w, 1:H))[1]; if (is.na(i)) NULL else i }
min_w <- \(h) { i <- which(holds(1:W, h))[1]; if (is.na(i)) NULL else i }

for (w in 1:W) {
  if (is.null(h <- min_h(w))) break
  cat(sprintf("w = %d, h min = %d\n", w, h))
}

for (h in 1:H) {
  if (is.null(w <- min_w(h))) break
  cat(sprintf("h = %d, w min = %d\n", h, w))
}

Получились следующие значения:

w = 1, h min = 87
w = 2, h min = 299
h = 1, w min = 201

То есть картинки 1×87, 2×299 и 201×1 (бо́льшую сторону можно увеличивать, это увеличит разрыв) занимают в Брайле больше, чем в XBM. В реальности это не точные границы, так как внутри XBM указывается название картинки, которое может быть разного размера.

Если помните, недавно я, вдохновлённый строчкой из песни «в каждой строчке — только точки», пытался выяснить что вообще можно записать точками, если использовать азбуку Морзе. Мне тогда один из комментаторов напомнил про шрифт Брайля — тактильный шрифт для слепых, состоящий из точек.

Он есть в Юникоде, поэтому на экране им можно написать что угодно и, как и требуется в песне, там будут только точки. Я тогда подумал, что «что угодно» можно трактовать и шире — если постараться, точками этого шрифта можно выводить в консоли любую графику.

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

Шрифт Брайля бывает двух систем — шеститочечный и восьмиточечный. Для целей рисования удобнее брать восьмиточечный — между символами есть зазоры, как если бы это были обычные буквы, и нам выгоднее использовать более насыщенный точками элемент.

Таким образом у нас получается блок 2×4, где мы, подбирая код символа, можем получить любое сочетание точек. Я боялся, что в расположении точек нет никакой системы, но к моему счастью оказалось, что каждая точка, которую надо закодировать, отображается на конкретный бит численного представления нужного символа.

Оставалось только решить, что я, собственно, буду выводить. Это должно быть что-то простое и одноцветное — набор из восьми точек можно покрасить только в один цвет, поэтому лучше цвета не использовать вообще. Поскольку в последнее время я много вожусь с браузером «Виола», где много однобитной графики в формате XBM, то я решил выводить картинки в этом формате — тем более, что он текстовый, что мне на руку.

Так, к примеру, выглядит картинка с логотипом «Виолы» в этом формате:

#define violaLogo_width 32
#define violaLogo_height 20
static char violaLogo_bits[] = {
   0xe0, 0x03, 0x00, 0x00, 0x18, 0x0c, 0x0f, 0x00, 0xe4, 0x8b, 0x30, 0x00,
   0xfa, 0x8f, 0x4f, 0x00, 0xfa, 0xff, 0xff, 0x00, 0xfd, 0xff, 0xff, 0x50,
   0xfd, 0x2f, 0xe9, 0xff, 0xfd, 0x07, 0x00, 0x00, 0x7d, 0xfc, 0xff, 0x50,
   0xbd, 0xfd, 0xff, 0x00, 0xba, 0x3b, 0x7f, 0x00, 0x3a, 0xdb, 0x1e, 0x00,
   0x7c, 0xd7, 0x00, 0x01, 0x78, 0xd6, 0x06, 0x19, 0xe0, 0xce, 0x00, 0x25,
   0x00, 0xcc, 0x32, 0x21, 0x00, 0xd8, 0x5a, 0x39, 0x00, 0xf0, 0x6a, 0x25,
   0x00, 0x60, 0x32, 0x79, 0x00, 0x00, 0x00, 0x00};

Алгоритм обещал получиться простым, поэтому для реализации я выбрал bash, тем более, что такую обработку там делать иногда даже проще, чем в большинстве других языков. Вот, например, вся функция чтения данных из файла картинки, получилось очень просто:

load_xbm() {
    local file="$1" hex h

    W=$(awk '/^#define.*_width/ {print $3;exit}' "$file")
    H=$(awk '/^#define.*_height/{print $3;exit}' "$file")
    BPR=$(( (W + 7) / 8 ))

    for h in $(sed -n '/{/,/}/{/{/d;s/}.*//;s/0x//g;y/,/ /;p;}' "$file"); do
        BYTES+=($[16#$h])
    done
}

Очень долго пришлось разбираться с битовыми сдвигами и порядком чтения точек из чисел, на это ушла просто прорва времени. Я пытался сделать это в уме, но не справился и перешёл на бумагу. Оказалось, что я не дошёл буквально полшага — надо было только изменить вывод точек на обратный.

Блокнот с моими попытками объяснить себе как будут выводиться точки

В итоге получился небольшой скрипт, в котором, если убрать все пустые строки, около полусотни строчек. Я его выложил, как водится, на «Гитхаб».

Пример вывода двух картинок, взятых из набора браузера «Виола»

Когда-то я делал библиотеку PEAR для графических форматов XBM и BMP (монохромного). Хотелось получить средство вывода графики в том случае, если на хостинге нет библиотеки GD, чтобы, хотя бы, какие-то простенькие диаграммы можно было строить. BMP — персонально для IE, в котором убрали поддержку формата BMP из-за ошибки в библиотеке отображения этого формата. Парням из Microsoft показалось, что проще ликвидировать поддержку, чем исправлять ошибку.

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

Когда-то, когда сотовые телефоны ещё были большими, была такая штука — WAP, этакий урезанный WWW для сотовых телефонов. Собственно, WAP и сейчас пока живее всех живых, хотя сайтов в этом формате относительно немного. В WAP использовались картинки в специальном формате — WBMP (Wireless BMP, level 0). Если кому-нибудь ещё интересен этот формат — добро пожаловать, у меня теперь есть библиотека для работы с ним.

Есть такой интересный принцип дарить подарки — покупать в подарок то, что люди сами бы себе никогда не купили. У меня, похоже, одно из хобби — копать там, где ничего не растёт. В том смысле, что меня больше увлекают проекты, где практической пользы меньше, чем льда на Солнце.

Было время, меня увлёк графический формат XBM, единственное достоинство которого (впрочем, вполне достаточное, на мой взгляд) — безумная простота, позволяющая манипулировать графикой в этом формате из любого хоть чего-то стоящего языка программирования. Я даже разродился модулем ImageXBM и прочими вещами.

И вот я узнаю, что Internet Explorer 6.0SP1 и выше не поддерживает мой любимый формат! Причину цитирую:

A  change was made to Internet Explorer for Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1 so that it does not render the XBM image file format. This update adds this change to all other supported versions of Internet Explorer. This change has been made to help prevent the Internet Explorer process from closing unexpectedly when users view invalidly-formed images. The XBM format is no longer supported by Internet Explorer.

Что переводится, примерно, так: «у нас что-то не работало, поэтому мы просто это отключили». Оплакал я смерть формата, которые за годы своей жизни так и не стал известен большинству разработчиков, да и сделал другой модуль.

Image_MonoBMP — модуля для работы с монохромными изображениями в формате BMP. А чтобы подтвердить, что я опять дарю вам то, что вы себе сами бы не купили, скажу, что этот формат, конечно, поддерживается Internet Explorer и Opera, но FireFox плевать на него хотел, да, в общем-то, и правильно.

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