Новый формат изображений HVIF позволяет создавать красивые иконки весом в 500 байт

Haiku Vector Icon Format — новый векторный формат изображения для хранения иконок. Это должно удивлять по двум причинам: во-первых, большинство операционных систем полагаются на bitmap-изображения и считают это вполне достаточным; во-вторых, существует множество векторных графических форматов, взять хотя бы SVG. Разбираемся, зачем же был создан HVIF, и как вообще обстоят дела с хранением изображений сейчас.

HVIF был создан разработчиками HaikuOS, открытой операционной системы, вдохновлённой BeOS. Этот формат используется в качестве основного для системных иконок. Основной целью, которая была поставлена при разработке формата, было сделать файлы иконок как можно меньшими по весу. Векторный формат позволяет отображать иконки в хорошем качетсве,в отличии от bitmap форматов, сохраняя малый вес. Настолько малый, что иконку можно включить в метаданные файла, и таким образом ограничить количество обращений к диску.

В отличии от других операционных систем, HaikuOS не показывает миниатюры pdf файлов или изображений, вместо этого используются абстрактные иконки. Обычно иконки представляют из себя bitmap, и BeOS перенял этот стандарт не глядя. В нём были иконки двух размеров — 16×16 и 32×32. Посколько bitmap-изображения содержат лишь информацию о том какой пиксель в какой цвет должен быть окрашен, изменение их размера приводит либо к размытостям, либо к сильной шакалпикселизации. Изображения каждого разрешения представляет из себя отдельный файл, и хранится так же отдельно. Вместе они занимают 1280 байтов (1024 — для 32×32 и 256 — для 16×16). С тех пор (с 1990-х) иконки стали больше, в современных операционных системах используются изоображения 64×64 и даже 128х128. Даже если забыть про 128×128, то 64×64 это уже больше 5 килобайт веса. Каждый такой шажок по удвоению размеров иконки увеличивает количество байт для bitmap-изображения в четыре раза, и это ужасно.

В отличии от bitmap, векторные форматы хранят не данные о конкретных пикселях, а данные о линиях и градиентах. Очевидным минусом такого подхода становится то, что при увеличении сложности изображения (количества деталей в нём) вес файла возрастает многократно. К счастью, для иконок используются в основном абстрактные изображения. Сильным плюсом же являются почти безграничные возможности для масштабирования изображения — не имеет никакого значения в скольких размерах вы собираетесь отображать иконку — круг всегда останется кругом, а градиент — градиентом.

Таким образом, HVIF примерно в десять раз (файлы HVIF имеют средний рамер от 500 до 700 байт, а при желании можно уместиться и в 256) выигрывает по размерам как у bitmap изображения 64×64 (которое, к тому же, не может красиво масштабироваться), так и у самого популярного векторного формата SVG, который проигрывает HVIF из-за использования обычного текста в XML формате, а не бинарных файлов. Обратная сторона медали заключается в том, что структура бинарного файла HVIF накладывает определённые ограничения (256 элементов) на сложность изображения. Предполагается, что для иконок этого более чем достаточно.

К слову, идея использовать для отображения иконок векторный формат сама по себе не нова — такой подход был осуществлён в IRIX, а так же поддерживается в популярных оболчках для Linux — Gnome и KDE.

Вы можете сказать, что несколько килобайт для современных дисков (или даже для RAM) это очень и очень мало. Это так. Почему же тогда разработчики HVIF так заботятся о размере? Ведь иконок в системе не миллионы (даже не сотни или не десятки тысяч), чтобы несколько килобайтов как-то могли повлять на загруженность диска. Оказывается, дело в скорости. Один цикл ЦП составляет около четверти наносекунды; чтение из оперативной памяти — 60 наносекунд; чтение из относительно быстрого современного SSD — 20 микросекунд (т.е. 20 000 наносекунд); чтение с медленного диска — 10 миллисекунд (10 000 000 наносекунд). Обращения к диску — самые затратные по времени операции для операционной системы. Создатели HaikuOS вместо двух вызовов к диску (к метаданным и к файлу иконки) хотят оставить один — к метаданным, в которых сможет поместиться иконка. Это должно давать ощутимый прирост к скорости отображения, даже при условии того, что векторные форматы отображаются дольше (ведь перед отображениям они, фактически, должны быть конвертированы в bitmap-изображения, подогнанные под конкретный размер).

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

Больше технических подробностей про формат можно узнать в обзорной статье.