Содержание к диссертации
Введение
1 Анализ архитектуры графических процессоров, современных форматов и алгоритмов сжатия текстур 12
1.1 Особенности текстурного сжатия 12
1.1.1 Основные требования к алгоритмам и форматам компрессии-декомпрессии текстур 14
1.1.2 Сжатие для ускорения загрузки 15
1.1.3 Качество и скорость сжатия 16
1.2 Ранние работы, связанные с текстурным сжатием 17
1.3 Семейство S3TC 19
1.3.1 Формат блока BC1 (S3TC/DXT1) 20
1.3.2 Особенности форматов BC6H и BC7 22
1.3.3 Формат блока BC7 24
1.4 Формат ASTC 27
1.4.1 Метод кодирования BISE 29
1.4.2 Прочие особенности 31
1.4.3 Формат блока ASTC 33
1.5 Анализ форматов сжатия текстур и особенностей алгоритмов сжатия 37
1.6 Обобщённая схема компрессии 38
1.7 Метрики ошибок сжатия 39
1.8 Существующие методы сжатия текстур в формате BC1 41
1.8.1 Быстрое сжатие 42
1.8.2 Метод ClusterFit 43
1.8.3 Алгоритм сжатия LSDxt 44
1.8.4 Сравнение качества 46
1.9 Существующие методы сжатия текстур в формате ASTC 47
1.9.1 Процедура компрессии для фиксированного типа блока 49
1.9.2 Процедура поиска наилучшего деления на регионы 50
1.10 Архитектура графического процессора 51
1.10.1 Модель вычислений OpenCL 52
1.10.2 Значимые отличия от классических идеализированных параллельных архитектур 54
1.11 Гетерогенные архитектуры 56
1.12 Выводы 59
2 Параллельный алгоритм сжатия текстур в формате BC1 61
2.1 Модификация алгоритма LSDxt 61
2.1.1 Модификация этапа сортировки 61
2.1.2 Отображение групп потоков на аппаратные SIMD-вектора 63
2.1.3 Расположение данных в локальной памяти 63
2.1.4 Использование регистровой памяти 66
2.2 Выводы 71
3 Межкадровая (динамическая) компрессия текстур 73
3.1 Стандарты и программные интерфейсы Direct3D и OpenGL 73
3.1.1 Графический конвейер Direct3D 11 74
3.2 Традиционный графический конвейер 75
3.3 Возможности межкадрового сжатия текстур в Direct3D и OpenGL 76
3.4 Графический конвейер с тайловой архитектурой 80
3.5 Выводы 83
4 Сжатие текстур с высокой глубиной цвета 84
4.1 Ограничения представления цвета с глубиной 8 бит 84
4.2 Критерий точности сохранения градиентных цветов 85
4.3 Модификация кодека gpu bc7 87
4.4 Выводы 89
5 Последовательно-параллельный алгоритм сжатия текстур в формате ASTC 91
5.1 Анализ работы кодека ASTC Evaluation Codec 91
5.1.1 Быстродействие в различных режимах 92
5.2 Адаптация алгоритма для работы в гетерогенной среде 93
5.2.1 Компиляция кода для архитектуры x64 94
5.2.2 Результаты профилирования производительности 94
5.2.3 Объединение блоков в пакеты 96
5.2.4 Компиляция во время исполнения 96
5.2.5 Изменение порядка этапов сжатия 97
5.3 Выбор размера пакета 99
5.4 Сравнение оригинального и предлагаемого кодеков 101
5.5 Выводы 102 Заключение 103
Литература 104
- Основные требования к алгоритмам и форматам компрессии-декомпрессии текстур
- Модификация этапа сортировки
- Традиционный графический конвейер
- Результаты профилирования производительности
Основные требования к алгоритмам и форматам компрессии-декомпрессии текстур
Далее в данной главе речь будет вестись именно о форматах, имеющих аппаратную поддержку декодирования и позволяющих обращаться к произвольному участку текстуры без полной распаковки. Однако можно отметить такое направление, как сжатие текстур для ускорения их загрузки в видеопамять. Оно используется для ускорения загрузки текстур с диска или по сети, что актуально для современных приложений, в которых объём текстур измеряется гигабайтами.
Здесь основной задачей является уменьшение занимаемого объёма. В данном случае отсутствуют такие ограничения, как необходимость произвольного доступа к тек-селям, что позволяет существенно увеличить степень сжатия. После загрузки такой текстуры в видеопамять, она распаковывается с использование программируемых шей-деров. Конечным результатом может быть несжатый формат текстуры или формат, ап-паратно поддерживаемый графическим процессором. При этом в видеопамяти может постоянно находиться полный набор текстур в сжатом виде и активный набор в аппа-ратно поддерживаемом формате.
По сравнению с универсальными методами сжатия (RLE, LZW, Deflate), специализированный подход позволяет увеличить степень компрессии. В случае игровых консолей данный приём позволяет разместить больше контента на одном blueray или dvd-диске.
К примеру, технология Virtual Texturing используемая в графическом движке IdTech5 [7] при подгрузке отдельных частей текстур позволяет транскодировать их из формата, близкого к JPEG, в формат DXT. Однако итоговая текстура будет содержать артефакты сжатия, вносимые обоими форматами.
Среди прочих работ так же можно отметить работу [8], в которой предлагается схема, способная производить сжатие текстур с различными уровнями детализации (mipmaps) без потерь и с потерями, а также работу [9], описывающую алгоритм сжатия без потерь текстур в формате ETC. 1.1.3 Качество и скорость сжатия
Понятно, что разница между оригинальным и восстановленным изображением во многом определяется форматом, в котором хранится сжатая текстура. Но кроме этого на качество в значительной степени влияет реализация компрессора. К сожалению, для большинства форматов преобразование текстуры в сжатый вид является нетривиальной задачей. И наилучший результат в отношении качества дают методы, основанные на переборе. Найти алгоритм, который делал бы это более рациональным способом, зачастую проблематично. Полный перебор позволяет получить текстуру с наилучшим возможным для данного формата качеством, однако это требует больших вычислительных затрат, а следовательно, и времени. Из выше сказанного следует, что при сравнении качества сжатых текстур необходимо обязательно указывать, как производилась компрессия.
Качество также может пострадать и при распаковке. Так, например, аппаратная реализация декодера текстур формата DXT1 на графических чипах GeForce/GeForce2 была такова, что все операции выполнялись в режиме 16 бит, без конвертации в 24 бита [10]. Это приводило к появлению дополнительных артефактов при распаковке (Рис.1.3).
Традиционный подход к сжатию текстур заключается в использовании предварительно сжатых текстур. В современных системах визуализации все чаще используются динамически генерируемые данные (карты окружений для имитации отражения, и т.д.), что делает актуальной задачу быстрого сжатия текстур в темпе генерации кадров ресурсами графического процессора. Стоит также отметить, что текстурное сжатие в реальном времени используется при передаче по сети видеопотоков высокого разрешения, например, в системе UltraGrid [11,12]. Однако традиционная архитектура ГП предполагает запись обработанных фрагментов в память. Поэтому сжатие возможно только после окончания формирования кадра и последующего чтения данных из памяти. Кроме этого, после записи сжатых данных в память необходима дополнительная операция копирования, что более подробно освещено в Главе 3. Таким образом, существующие техники межкадрового (динамического) сжатия требуют дополнительных затрат времени, не связанных с форматом и алгоритмом сжатия.
В простейшем случае каждый пиксель изображения можно закодировать целым числом (обычно 4 или 8 бит), определяющим индекс в таблице цветов (палитре). Такой подход широко применялся для реализации кадрового буфера в первых игровых консолях и видеоадаптерах, которые имели жесткие ограничения по объему памяти. Но использование палитры не подходит для сжатия текстур по следующим причинам: малая степень сжатия (8bpp) низкое качество из-за ограничения количества уникальных цветов (256 цветов при 8bpp) необходимость двух обращений в память (выборка индекса цвета и выборка соответствующего значения из палитры). Это увеличивает задержки и отрицательно сказывается на эффективности использования пропускной способности памяти.
Данный подход является частным случаем векторного квантования (VQ, Vector Quantisation), в котором вектор представлен одним пикселем. Более сложный вариант VQ-сжатия, в котором один вектор представляет сразу несколько соседних пикселей, использовался в игровой консоли Sega Dreamcast [2], что позволило добиться коэффициентов сжатия 1:5 и 1:8 при приемлемом качестве.
Альтернативным подходом является блочное сжатие, предполагающее разбиение изображения на независимые блоки. Каждый блок содержит всю необходимую для распаковки информацию, что позволяет получить значение цвета текселя за одно обращение в память.
Первым подобным алгоритмом был Block Truncating Coding (BTC), предназначенный для сжатия черно-белых изображений (в оттенках серого). Основная идея алгоритма — сохранить математическое ожидание и среднеквадратическое отклонение яркости. При этом в результирующем изображении внутри каждого блока используется только два уровня яркости и (Рис.1.4). Формат сжатого блока предполагает хранение обоих этих уровней и битовой карты, где каждый бит соответствует одному пикселю. При компрессии на первом шаге изображение разбивается на блоки размера MxN (обычно 4x4). Для каждого блока вычисляются математическое ожидание и
Модификация этапа сортировки
Упрощённо декодирование блока ASTC осуществляется следующим образом. Сначала по полю BlockMode выясняется количество и диапазон квантованных коэффициентов интерполяции. Коэффициенты считываются с хвоста блока при помощи BISE-декодирования. Коэффициенты деквантуются до диапазона 0..64. В случае, если количество коэффициентов меньше количества текселей в блоке, используется билинейная фильтрация для масштабирования сетки коэффициентов до размеров блока текселей.
Далее по значению поля Part определяется количество регионов, и номер разделения считывается из сжатого блока. При помощи хэш-функции генерируется номер региона для каждого текселя.
По полям ConfigData и MoreConfigData и количеству регионов определяется формат представления всех базовых цветов и определяется общее количество скалярных значений, которые необходимо прочитать. Однако диапазон этих значений не указывается в сжатом блоке. Но зная количество бит, занимаемых коэффициентами интерполяции и конфигурационной информации можно подсчитать, сколько бит доступно в блоке для хранения базовых цветов. А зная количество элементов в BISE последовательности можно определить максимальный диапазон, с которым они могут поместиться в это количество бит. Информация для восстановления базовых цветов всегда сохраняется с использованием максимального возможного диапазона. Далее базовые цвета распаковываются при помощи BISE-декодирования и деквантуются.
По номеру региона узнаётся необходимая пара базовых цветов для каждого тек-селя, и значения этих цветов смешиваются в пропорции задаваемой коэффициентом интерполяции. 1.5 Анализ форматов сжатия текстур и особенностей алгоритмов сжатия
Формат Размер блока Уровень сжатия Качество Сжимаемые цветовые компоненты Описание
Выбор конкретного формата сжатия ограничивается используемой аппаратной платформой. Так, на ПК доступно только семейство S3TC, а в мобильных устройствах — ETC или PVRTC, в зависимости от платформы (также встречается поддержка форматов BC1–BC5, но их использование не сильно распространенно). Поддержка формата ASTC имеется пока только у некоторых мобильных процессоров. В рамках семейства S3TC: BC7 предоставляет наилучшее качество для RGB и RGBA текстур и заменяет собой форматы BC2 и BC3
PVRTC2 полностью замещает собой формат PVRTC, улучшая качество сжатия и решая некоторые проблемы своего предшественника. PVRTC2 поддерживает RGB и RGBA текстуры.
ETC2 является результатом развития форматов ETC и PACKMAN и также полностью замещает их. ETC2 поддерживает только RGB текстуры, но различные комбинации блоков ETC2 и EAC предоставляют функционал, полностью аналогичный набору форматов BC1–BC5.
Формат ASTC поддерживает сжатие любых типов текстур и предоставляет различные варианты уровней сжатия.
Так как блоки сжимаются независимо, то возможна параллельная компрессия всего изображения, где отдельный поток обрабатывает отдельный блок. При сжатии с высоким уровнем качества, шаги 2–4, так или иначе, повторяются для различных комбинаций типа сжатого блока, пар базовых цветов и других параметров. В случае, когда проверяется следующая наперёд заданная комбинация (т.е. результаты предыдущей итерации не используются для уточнения текущих параметров), возможно также параллельное исполнение. При быстром сжатии шаги 4 и 5 обычно пропускаются, а выбор большинства параметров на шаге 2 ограничивается фиксированными значениями.
В большинстве случаев наиболее сложным в вычислительном плане является шаг 2. Как правило это будет означать некогерентное исполнение групп потоков, сжимающих соседние блоки. В случае исполнения на графических процессорах, это приводит к малой эффективности использования ресурсов ГП (что поясняется в параграфе 1.10). Для форматов с большим количеством параметров сжатого блока, таких как BC6H/BC7 и ASTC, эта проблема стоит ещё острее.
Поэтому для увеличения производительности необходимо искать способы параллельного исполнения шага 2, которые обладают высоким уровнем когерентности и 1.
Так как текстурное сжатие является сжатием с потерями, то в процессе компрессии в изображение неизбежно вносятся некоторые искажения. Общепринятыми метриками, позволяющими оценивать уровень этих искажений, являются среднеквадратиче-ская ошибка (MSE, mean square error) и пиковое отношение сигнал/шум (PSNR, peak signal to noise ratio) [43].
Традиционный графический конвейер
Стандартным методом представления изображений в компьютерных системах является TrueColor, подразумевающий использование цветовой модели RGB с глубиной цвета 8 бит, поэтому интенсивности каждого цветового канала (красного, зеленого и синего) могут принимать значения от 0 до 255. Хотя приложения могут использовать для хранения и обработки изображений прочие форматы с повышенной точностью, вывод на экран, как правило, осуществляется в формате TrueColor. При этом стандартным цветовым пространством является sRGB. Цветовое пространство определяет, какой реальный цвет соответствует каждому конкретному числовому значению цвета.
И хотя пространство sRGB покрывает всего около 35% всех видимых цветов, определённых международной комиссией по освещению CIE (Commission internationale de l eclairage) [71], глубины цвета TrueColor не хватает для отображения всех различимых человеком цветов даже внутри sRGB. Наибольшие проблемы возникают с отображением плавных градиентов, так как в некоторых случаях явно видны границы между соседними цветами. Наглядно подобный эффект продемонстрирован на Рис.4.1 на примере градиента с глубиной цвета 5 бит.
Данная проблема усугубляется при использовании более широких цветовых пространств, например AdobeRGB, где доступные в каждом цветовом канале 256 уровней еще сильнее отдаляются друг от друга (Рис. 4.2).
Изображения с высокой глубиной цвета обладают гораздо лучшими возможностями воспроизведения цветов и плавных градиентов, особенно при использовании устройств с широким цветовым охватом. Поэтому в профессиональных сферах применения, таких как работа с медицинскими снимками, кинопроизводство, графиче ский дизайн, обработка фотографий, зачастую используются мониторы с поддержкой глубины цвета 10 бит и более и соответствующие форматы представления цвета. И полноценная поддержка таких изображений при работе с трёхмерной графикой также является важной задачей.
Существующие форматы сжатия нацелены, прежде всего, на изображения с глубиной цвета 8 бит. Тем не менее, на этапе деквантования базовых цветов двоичное представление цветов может быть расширено до произвольного количества бит, и последующие операции распаковки могут проводиться с выбранной глубиной цвета. Однако очевидно, что цвета в сжатом блоке закодированы с ограниченной точностью, и увеличение глубины цвета оправдано только до некоторого значения. Но для определения такого значения требуется формальный признак, то есть необходимо ввести критерий, с помощью которого можно было бы оценить возможности конкретных форматов.
С позиции зрительного восприятия, изменение глубины цвета наиболее сильно сказывается на участках изображения с плавными цветовыми переходами. Поэтому критерий должен быть направлен именно на плавные градиенты.
Для определения максимальной глубины цвета , которую разумно использовать для конкретной схемы сжатия, предлагается оценивать максимальную ошибку сжатия для равномерного вертикального или горизонтального градиента с шагом , минимальным для данной глубины цвета.
В качестве критерия возможности компрессии текстур с глубиной цвета с помощью некоторого формата сжатия предлагается использовать условие . Другими словами, ошибка сжатия не должна превышать шага градиента. Дальнейшее увеличение глубины цвета приведёт к тому, что пары соседних значений не смогут быть различены в сжатом блоке.
Определим, для каких выполняется условие критерия для форматов сжатия семейства S3TC/BC.
При глубине цвета общее количество различных уровней интенсивности равно 2. Для упрощения дальнейших выкладок предположим, что интенсивности цветов нормированы, т.е. их значения принадлежат диапазону [0; 1]. В таком случае, минимально возможный шаг градиента будет определяться формулой (4.1).
На прямой интенсивностей все возможные базовые цвета будут выглядеть как набор точек с шагом . С учётом размера блока 4х4, градиент будет представлен четырьмя точками с шагом . Варианты расположения цветов градиента относительно базовых цветов представлены на Рис.4.3, где возможные базовые цвета обозначены большими точками, а цвета градиента — маленькими. В худшем случае (Рис.4.3Б), расстояние между выбранными базовыми цветами будет составлять 2.
Слагаемое “-1” в формуле (4.3) отражает ситуацию на Рис.4.3Б, когда для кодирования необходимо выбирать не соседние базовые цвета, цвета отстоящие друг от друга на величину 2. Значения , и для различных типов блоков представлены в таблице 4.1.
Таким образом, согласно предложенному критерию, формат BC7 может использоваться для изображений с глубиной цвета до 10 бит. Значение для форматов BC4 и BC5 также равно 10, однако они не представляют большого интереса, так как поддерживают только одно- и двухканальные текстуры.
Для хранения текстур с глубиной 10 бит предлагается ввести новый режим работы декодера, в котором деквантование базовых цветов и последующие операции будут производиться с точностью 10 бит. Аппаратная реализация дополнительного режима распаковки не составит большого труда, ибо логика работы декодера не меняется.
В то же время, сжатые текстуры остаются полностью совместимыми с обоими декодерами, так как формат сжатого блока остаётся прежним. Распаковка текстуры с глубиной 10 бит на “старом” декодере будет просто соответствовать понижению глубины цвета до 8 бит. И наоборот, текстуры с глубиной 8 бит при распаковке на предлагаемом декодере могут даже выиграть, по сравнению с обычной распаковкой и дальнейшим преобразованием до глубины цвета 10 бит, за счёт повышения точности представления промежуточных цветов в локальной палитре.
Естественно, для корректного сжатия текстур с глубиной цвета 10 бит необходима модификация компрессора, потому что существующие кодеры BC7 принимают на вход изображения с точностью 8 бит.
Для практической проверки состоятельности предложенного метода была произведена модификация параллельного кодека и тестирование качества сжатия различных текстур с глубиной цвета 10 бит [72]. За основу был взят кодек bc7_gpu, производящий сжатие в формат BC7 на графическом процессоре с использованием технологии OpenCL.
Для тестирования качества сжатия были выбраны текстуры с глубиной цвета 10 бит и наличием плавных градиентов. При сжатии текстур с помощью оригинального компрессора производилась предварительная конвертация исходного изображения в формат с представлением цвета TrueColor. После распаковки с использование оригинального декодера производилось преобразование значения в каждого цветового канала согласно формуле (4.4). Данная формула соответствует сдвигу на два разряда влево и копированию двух старших бит в высвободившиеся младшие разряды. Это стандартная целочисленная аппроксимация для деквантования, используемая, в том числе, и в аппаратных блоках графических процессоров.
Результаты профилирования производительности
Декодирование цветовых каналов ведётся так же, как и блока BC1, с той лишь разницей, что он всегда рассматривается как блок первого типа с четырьмя доступными цветами внутри блока.
При работе с полупрозрачными текстурами в процессе смешивания с фоном, значение цвета текселя необходимо умножать на коэффициент прозрачности из альфа-канала. В связи с этим в некоторых ситуациях удобно хранить в текстуре значения цветовых каналов уже умноженные на этот коэффициент, что обозначается термином «pre-multiplied alpha». Для таких ситуаций был предложен формат DXT2. Для формата же DXT3 предполагается хранение цветовых компонент в исходном виде. Тем не менее, с точки зрения хранения и декодирования разница в этих форматах отсутствует. Имя формата, всего на всего, давало приложению подсказку о смысле хранимых в цветовых каналах данных. Поэтому в формате BC3 эти ситуации не различаются, и приложение само ответственно за интерпретацию данных. Важно отметить, что для корректности результата, фильтрация текстур должна производиться со значениями, умноженными на альфа-канал.
Режим pre-multiplied alpha обладает определёнными преимуществами при фильтрации текстур и альфа-смешивании по сравнению с хранением исходных значений цветовых каналов и позволяет упростить аппаратную реализацию. Более подробно данный режим рассмотрен в работе [74].
Блок BC3, так же как и BC2, состоит из 64 бит, предназначенных для хранения альфа-канала, и 64 бит, повторяющих блок BC1. Но тут альфа-канал хранится в сжатом виде (Рис.A.2), аналогичном сжатию BC1: в блоке содержатся два базовых значения alpha_0 и alpha_1 с точностью 8 бит и таблица трёхбитных индексов, позволяющая любой точке принимать одно из восьми допустимых значений локальной палитры.
Для значений альфа-канала выделяются два типа блоков: когда alpha_0 alpha_1, шесть дополнительных значений локальной палитры вычисляются при помощи линейной интерполяции, в противном случае — только четыре значения, а оставшиеся два соответствуют максимальному и минимальному допустимому значению. Формирование локальной палитры проиллюстрировано в листинге A.1. Для цветовых данных блок всегда рассматривается как блок первого типа, при этом используются формулы (1.4) или (1.5).
По аналогии с DXT2/DXT3, форматы DXT4/DXT5 в Direct3D 9 отличаются смыслом содержимого цветовых каналов: для DXT4 предполагается хранение значений уже умноженных на коэффициент прозрачности, а для DXT5 – исходных значений. И точно также BC3 не делает различий между этими случаями.
В большинстве случаев формат BC3 позволяет получить лучшую точность значений альфа-канала, по сравнению с BC2.
Декодирование блока осуществляется точно так же, как и декодирование значений альфа-канала в формате BC3. Однако BC4, как правило, используется для хранения чисел с плавающей запятой в диапазонах [0, 1] или [-1, 1], и значения red_0 и red_1 в сжатом блоке интерпретируются соответствующим образом. Формирование палитры для случая [-1, 1] показано в листинге A.2.
Формат 3Dc был изначально разработан компанией ATI специально для сжатия текстур, содержащих карты нормалей, так как формат DXT1 не обеспечивал необходимого качества сжатия для подобных данных. В таких текстурах содержится информация о векторе нормали поверхности, что позволяет рассчитывать освещённость объектов с высоким уровнем детализации без повышения геометрической сложности объекта (Рис.1.1Б). В цветовых каналах подобных текстур хранятся координаты вектора нормали в трёхмерном пространстве, и все значения интерпретируются как вещественные числа в диапазоне [-1, 1]. Проблема сжатия заключается в том, что в BC1 значения разных цветовых каналов связаны между собой, так как используется одна общая таблица индексов. Для обычных цифровых изображений это допущение корректно, но для карт нормалей, где корреляция каналов намного слабее, не корректно. Кроме этого, BC1 мало пригодно для сжатия изображений, имеющих плавные градиенты (Рис.A.4).
Соответствующие форматам BC4 и BC5 спецификации OpenGL называются EXT_texture_compression_rgtc [18], ARB_texture_compression_rgtc [19] и EXT_texture_compression_latc [20]. При этом и rgtc и latc варианты спецификаций описывают оба формата BC4 и BC5. Только в rgtc распакованные данные интерпретируются как значения красного или красного и зелёного цветовых каналов, а в latc — как значения яркости или альфа-канала и яркости.
Формат BC6H предназначен для сжатия текстур с широким динамическим диапазоном или HDR текстур (High Dynamic Range) [76]. Альфа-канал не поддерживается, а для представления значений цветовых каналов используются 16 битные числа с плавающей запятой. Формат BC6H определён для двух вариантов – знакового и беззнакового. Соответственно, декодер может работать в знаковом или беззнаковом режиме. Тем не менее, значения на выходе декодера всегда являются знаковыми и соответствуют формату IEEE 754 half/binary16 (Рис.A.6А). Перед передачей в шейдер эти значения конвертируются в 32 битный тип float. Все типы блоков полностью совпадают для обеих версий BC6H, разница заключается лишь в трактовке значений базовых цветов. Условно, можно сказать, что для знаковой версии внутреннее представление значений соответствует Рис.A.6А, а для беззнаковой — Рис.A.6Б. На практике режимы работы декодера отличаются обработкой знаковых разрядов при деквантовании цветов и финальным преобразованием типа данных в half.
Всего определенно 14 типов блоков (Таблица A.1). BC6H поддерживает только один или два региона в блоке, то есть только одну или две пары базовых цветов. Номер разделения на регионы кодируется 5 битами, поэтому для выбора доступны только первые 32 варианта. В большинстве типов блоков (кроме Mode 10 и Mode 11) используется дельта-кодирование базовых цветов — непосредственно сохраняется только один базовый цвет 0, а для остальных сохраняется разница с 0.
При декодировании BC6H используется только целочисленная арифметика, в том числе и на этапе интерполяции, хотя финальные значения интерпретируются как числа с плавающей запятой. Это возможно за счёт метода кодирования чисел с плавающей запятой: мантисса располагается в младших битах, а экспонента — в старших, и экспонента кодируется в прямом коде со смещением. Поэтому интерпретация таких двоичных чисел как целочисленных имеет определённый математический смысл. В частности, для любых положительных вещественных A и B таких, что A B, отношение A B сохранится и при интерпретации двоичного кода как целых чисел. Пример целочисленной арифметики с вычислением среднего значения приведён в листинге A.3. При использовании линейной интерполяции, если двоичный порядок интерполируемых значений сильно отличается, итоговое преобразование будет иметь экспоненциальный характер (Рис.A.7).
