eZip: сжатие без потерь и аппаратное декодирование¶

Введение¶

eZip — фирменный формат сжатия графических ресурсов без потерь от SiFli. На устройствах SF32 с соответствующей поддержкой аппаратный блок EZIP декодирует графические ресурсы eZip. Блок также поддерживает отдельные режимы GZIP и LZ4 для данных общего назначения; после распаковки данные записываются в память через AHB, а не передаются напрямую в EPIC. Вместо хранения каждого экранного ресурса в виде несжатого растрового изображения в NOR Flash, PSRAM или файловой системе изделие может хранить данные eZip и декодировать их по мере необходимости.

eZip-A — соответствующий формат для анимированных ресурсов. Исходные материалы преобразуются при сборке или подготовке ресурсов; eZip не является универсальным декодером изображений, который принимает произвольные файлы во время выполнения.

Для данных, не связанных с графикой, например образа OTA-обновления, необходимо определить и проверить весь процесс обновления: хранение, проверку целостности, совместимость и предполагаемый путь распаковки. Описанный в графическом тракте путь относится к ресурсам дисплея, а не к логике обновления на уровне приложения.

Для изделия с графическим интерфейсом цель состоит в том, чтобы считывать из хранилища меньше данных и не тратить время CPU приложения на повторную распаковку ресурсов. Это может сократить объём хранилища и трафик внешней памяти, оставив больше ресурсов для интерфейса, Bluetooth, аудио и прикладных задач.

Расположение eZip относительно ePicasso, TurboPixel и контроллера дисплея показано в обзоре графики. Эта статья посвящена подготовке ресурсов eZip, особенностям сжатия и декодированию.

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

Возможности и ограничения¶

eZip рассчитан на использование в производственном процессе подготовки ресурсов, а не на произвольную обработку файлов:

• Сжатие графики без потерь. Формат сохраняет данные изображения и поддерживает прозрачность. По описанию SiFli, типичный коэффициент сжатия графических ресурсов немного выше, чем у PNG; фиксированное числовое значение не приводится.
• Статические и анимированные ресурсы. GraphicsTool преобразует изображения PNG, GIF и APNG в статические ресурсы eZip или анимации eZip-A.
• Аппаратное ускорение декодирования на поддерживаемых устройствах. Оно может снизить нагрузку на CPU приложения; результат зависит от выбранного чипа, SDK, исходного формата и пути через драйвер.
• Процесс подготовки графики. GraphicsTool от SiFli работает с распространёнными исходными форматами, изменяет размер и формат изображений, выполняет пакетную обработку и создаёт ресурсы eZip/eZip-A.
• Интеграция с ePicasso на поддерживаемых устройствах. Прямая передача позволяет обойтись без буфера для полностью декодированного исходного изображения, снижая потребность в памяти и объём передач.

«Без потерь» относится к сжатию пикселей, переданных кодировщику, а не ко всем предыдущим преобразованиям. Изменение размера, преобразование RGB888 в RGB565 или удаление alpha могут привести к потере информации ещё до сжатия. Сравнивайте декодированные пиксели со входом кодировщика того же размера и формата; сохраняйте alpha, если нужна прозрачность.

Коэффициент сжатия и данные общего назначения¶

Для графических ресурсов используйте PNG как практическую точку отсчёта: SiFli указывает, что eZip обеспечивает коэффициент сжатия немного выше, чем PNG, сохраняя данные изображения без потерь и поддерживая прозрачность. Фактическое уменьшение размера файла зависит от размеров изображения, формата пикселей, прозрачности, использования палитры и детализации. Измерьте типовые ресурсы с утверждённой конфигурацией преобразования; не планируйте объём памяти по одному процентному значению.

Утилита EZIP от SiFli также может сжимать файлы общего назначения в форматах GZIP или LZ4. Это отдельная операция, не связанная с преобразованием графических ресурсов в eZip. Степень сжатия общих данных зависит от их содержимого: повторяющиеся или структурированные данные могут сжиматься хорошо, тогда как уже сжатые файлы — например изображения JPEG, видео MP4, архивы ZIP или зашифрованные данные — могут почти не уменьшиться либо не сжаться вовсе. Перед использованием этого пути для неграфических данных проверьте размер результата и режим распаковки, поддерживаемый целевым устройством.

HAL EZIP различает режимы графического eZip, GZIP и LZ4. Распаковка общих данных GZIP/LZ4 использует вывод в память через AHB, а не прямую передачу в EPIC. Архив OTA должен соответствовать выбранному режиму, а также поддерживаемым им формату кадрирования и ограничениям размера; графический файл .ezip нельзя заменить произвольным сжатым пакетом обновления.

Шаблон измерения размеров типовых изображений¶

Используйте этот раздел для фиксации сопоставимых измерений типовых UI-изображений без прозрачности и с альфа-каналом. Замените заполнители после преобразования каждого исходного изображения утверждёнными версиями инструментов и настройками. Вместе с результатами укажите исходные размеры, формат пикселей, обработку альфа-канала и качество JPEG. eZip и PNG сохраняют прозрачность исходного изображения, тогда как JPEG не поддерживает альфа-канал. Поэтому для сравнения изображения с прозрачностью задайте и документируйте предварительно наложенный фон; такое сравнение нельзя представлять как равноценное сохранению альфа-канала.

Рассчитывайте «Относительно BMP» как file size ÷ BMP file size × 100% в рамках одного сценария. Не сравнивайте напрямую строки для непрозрачных изображений и изображений с альфа-каналом и не используйте эту таблицу как универсальное утверждение о коэффициенте сжатия: это шаблон для измерений, а результаты зависят от изображения, площади прозрачности и настроек преобразования.

Зачем использовать eZip¶

Сокращение объёма хранения ресурсов¶

Сжатые ресурсы могут занимать меньше места в NOR Flash, PSRAM, NAND или съёмном хранилище, чем несжатые массивы пикселей. Это особенно полезно для циферблатов, многоязычных наборов шрифтов, коллекций значков, тем оформления и интерфейсов с большим количеством анимации.

Снижение трафика на шине памяти¶

Несжатые растровые изображения могут создавать значительный трафик до начала отрисовки, если хранятся во внешней NOR Flash или PSRAM. Передача сжатого ресурса и его декодирование рядом с графическим трактом могут снизить эту нагрузку. Реальный эффект зависит от коэффициента сжатия, исходного формата, характера обновления дисплея и скорости интерфейса хранилища.

Высвобождение времени CPU¶

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

Воспроизводимая подготовка ресурсов¶

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

Сравнение реализаций eZip¶

В таблице использованы названия, подтверждённые описаниями продуктов и SDK. Номер версии не гарантирует одинакового набора функций: проверьте выбранный чип, версию SDK, формат ресурсов и конфигурацию памяти платы.

Прямая передача в EPIC позволяет не хранить полностью декодированное исходное изображение перед отрисовкой. Она не устраняет потребность в рабочей памяти декодера или конечном буфере отрисовки и не превращает декодирование JPEG в функцию EZIP. Для отдельного тракта JPEGD используйте документированную цепочку драйверов соответствующего семейства.

Подготовка ресурсов¶

Храните редактируемые исходные ресурсы в системе контроля версий, а выходные файлы eZip формируйте как артефакты сборки:

1. Для выбранного устройства задайте разрешение дисплея, формат пикселей и требования к анимации.
2. Подготовьте исходные изображения или анимацию в целевых размерах; не используйте масштабирование во время выполнения, чтобы компенсировать неверно подготовленную графику.
3. Преобразуйте изображения, измените их размер и сформируйте файлы eZip или eZip-A с помощью SiFli GraphicsTool.
4. Зафиксируйте версию инструмента и профиль преобразования в проекте, а затем проверьте сгенерированные ресурсы на целевом оборудовании.
5. Разместите выходные файлы в предусмотренном хранилище и проверьте холодный запуск, повторное использование интерфейса, работу при нехватке памяти и обновление дисплея при одновременной активности Bluetooth или аудио.

GraphicsTool поддерживает распространённые форматы изображений, включая PNG, JPEG, WebP и AVIF, а также преобразует GIF, PNG и APNG в ресурсы eZip/eZip-A. Использовать преобразованный ресурс можно только в том случае, если целевое устройство и SDK поддерживают соответствующий путь декодирования.

Для других форматов статических изображений документированный порядок — сначала изменить размер и преобразовать изображение в PNG, затем закодировать eZip. Согласуйте формат цвета, обработку alpha и версию LVGL с целевой платформой. Пример командной строки SDK требует -winsize 2048 для SF32LB57x; другим семействам из таблицы этот параметр не нужен. Используйте sdk/tools/png2ezip/ezip.exe и сохраняйте точные аргументы вместе с созданными ресурсами.

Инструменты интеграции¶

SiFli предоставляет не только настольный GraphicsTool:

• Инструменты командной строки позволяют встроить преобразование eZip в сценарии подготовки ресурсов и сделать этот процесс воспроизводимым. Их можно использовать в локальных скриптах сборки или заданиях непрерывной интеграции, чтобы связь между исходной графикой в системе контроля версий и сгенерированными файлами eZip оставалась прослеживаемой.
• SDK для Android и iOS позволяют интегрировать eZip в мобильные приложения. Они полезны, когда сопутствующее приложение должно подготавливать, управлять, передавать или иным образом обрабатывать ресурсы eZip в рамках взаимодействия с устройством.

Храните профили преобразования, версии инструментов или SDK, контрольные суммы выходных файлов и требования совместимости с целевыми устройствами в системе контроля версий. Интеграции для мобильных приложений и командной строки должны использовать тот же утверждённый профиль ресурсов, что и встроенное изделие. Не предполагайте, что файл, подготовленный для одного чипа или конфигурации SDK, без изменений подойдёт для любого устройства SF32.

Рекомендации по проектированию и отладке¶

• Используйте eZip для ресурсов. Они могут находиться в NOR Flash, PSRAM, NAND или файловой системе, но декодер не интерпретирует пути к файлам. Драйвер хранилища должен предоставлять или загружать данные через поддерживаемый аппаратный путь доступа. HAL требует выравнивания входного буфера и выходного буфера AHB по 4 байтам. eZip не предназначен для сжатия конечного кадрового буфера.
• Учитывайте трафик передачи ресурсов. eZip может снизить его, но декодированные пиксели всё равно проходят через тракт отрисовки и вывода на дисплей, описанный в обзоре графики.
• Сохраняйте программный путь обработки на CPU. Не каждый тип ресурса, формат пикселей или UI-операция поддерживается аппаратным декодером или графическим трактом.
• Проверяйте размещение в памяти. Тестируйте ресурсы и буферы отрисовки во внутренней SRAM, NOR Flash, PSRAM и съёмном хранилище: каждый вариант меняет задержки и конкуренцию за шину.
• Проверяйте реальную нагрузку. Измеряйте время холодной загрузки, частоту обновления анимации, задержку интерфейса и энергопотребление при одновременной работе Bluetooth, аудио, датчиков и обновления дисплея.
• Зафиксируйте параметры преобразования до выпуска. Изменение версии инструмента или его параметров может повлиять на совместимость выходных файлов, качество, объём хранения и скорость декодирования.

Основные выводы¶

• eZip — формат сжатия графических ресурсов без потерь и аппаратно поддерживаемый путь декодирования на совместимых устройствах SF32.
• Для графических ресурсов используйте eZip, а для общих данных — режимы GZIP/LZ4 утилиты; степень сжатия общих данных зависит от источника и требует измерения.
• eZip-A предназначен для анимированных ресурсов; GraphicsTool создаёт ресурсы eZip/eZip-A из распространённых исходных изображений.
• SiFli также предоставляет инструменты командной строки и SDK для Android/iOS, позволяющие включать eZip в автоматизированные процессы и мобильные приложения-компаньоны.
• eZip может уменьшить объём ресурсов, трафик внешней памяти и нагрузку на CPU приложения при декодировании, но не заменяет ePicasso или контроллер дисплея.
• Выбирайте документированную реализацию и путь вывода, а не предполагаемую иерархию версий. Рассматривайте JPEGD отдельно от EZIP и используйте требуемое окно сжатия для SF32LB57x.
• Успешное применение eZip требует контролируемого процесса подготовки ресурсов: важны исходная графика, настройки преобразования, размещение в хранилище, интеграция с графикой и проверка на целевом устройстве.

Первичные источники¶

• GraphicsTool и подготовка ресурсов
• Режимы HAL EZIP, пути вывода, выравнивание и поддержка анимации
• Документация утилиты EZIP
• Режимы, выравнивание и анимация в HAL EZIP
• Пример LVGL eZip и параметры преобразования
• Документация мобильного SDK eZip
• Краткие описания продуктов: SF32LB52x, SF32LB55x, SF32LB56x, SF32LB58x
• Отдельный интерфейс JPEGD

Последнее обновление: 2026-10-12