eZipのロスレス圧縮とハードウェアデコード¶

はじめに¶

eZipは、SiFli独自のグラフィックスリソース向け可逆圧縮形式です。対応する機能を備えたSF32では、EZIPハードウェアブロックがeZip形式のグラフィックスリソースをデコードします。このブロックには汎用データ向けのGZIP/LZ4モードもあり、展開データはEPICへ直接送らず、AHB経由でメモリーに出力します。画面リソースをNOR Flash、PSRAM、ファイルシステムに非圧縮ビットマップのまま保存する代わりに、eZip形式で保存し、UIで必要になった時点でデコードできます。

eZip-Aは、アニメーションリソース向けの形式です。元の素材はビルド時またはリソース準備時に変換します。eZipは、実行時に任意のファイルを読み込める汎用画像デコーダーではありません。

OTAイメージなどの非グラフィックスデータでは、保存方法、整合性検証、互換性、想定する解凍経路を含め、更新処理全体を製品側で定義して検証する必要があります。グラフィックスフローは画面リソース向けであり、アプリケーション側の更新処理には適用されません。

グラフィックス製品では、ストレージから読み出すデータ量を減らし、アプリケーションCPUが同じリソースを何度も解凍するのを避けることが目的です。これにより、保存容量と外部メモリーへの転送量を削減し、UI、Bluetooth、オーディオ、その他のアプリケーション処理に余力を回せます。

ePicasso、TurboPixel、ディスプレイコントローラーに対するeZipの位置づけについては、グラフィックス概要を参照してください。このページはeZipのアセット準備、圧縮の挙動、デコードに焦点を当てています。

UIリソースがFlash容量を圧迫している、外部メモリー帯域を使い過ぎている、または再現性のある変換手順が必要な場合に参照してください。ここでは、TurboPixelで扱う最終フレームバッファー圧縮と、元データを保つリソース圧縮を区別します。

能力と境界¶

eZipは、場当たり的なファイル変換ではなく、量産向けのリソース生成工程で使うことを想定しています。

• **可逆のグラフィックス圧縮。**画像データを保ち、透過にも対応します。SiFliは一般的な圧縮率を定性的にPNGよりわずかに高いと説明しており、固定の数値は公表していません。
• 静止画とアニメーション。 GraphicsToolでPNG、GIF、APNGをeZip形式の静止画またはeZip-A形式のアニメーションに変換できます。
• **対応デバイスでのハードウェア支援デコード。**チップ、SDK、入力形式、ドライバー経路の対応状況によっては、アプリケーションCPUのデコード負荷を軽減できます。
• グラフィックスツールによる変換。 SiFli GraphicsToolは、一般的な入力形式の読み込み、画像サイズの変更、形式変換、一括処理、eZip/eZip-Aの生成に対応します。
• **対応デバイスでのePicasso連携。**直接出力では、デコード済みの元画像全体を保存するバッファーを省き、必要なバッファー容量とメモリー転送量を減らせます。

「ロスレス」は、エンコーダーに渡した画素データを圧縮で失わないという意味です。それ以前の変換まで無損失とは限りません。リサイズ、RGB888からRGB565への変換、アルファの削除で情報が失われることがあります。デコード結果は同じサイズ・画素形式のエンコーダー入力と比較し、透明度が必要ならアルファを保持してください。

圧縮率と汎用的な利用¶

グラフィックスリソースの比較には、実用上の基準としてPNGを使います。SiFliによると、eZipは画像データを劣化させず、透過情報も保持したまま、PNGよりわずかに高い圧縮率を実現します。ただし、実際のファイル削減量は画像サイズ、ピクセル形式、透過の有無、パレットの使い方、画像のディテールによって変わります。承認済みの変換プロファイルで代表的なリソースを測定し、単一の割合を前提に容量を見積もらないでください。

SiFliのEZIPツールは、汎用ファイルをGZIPまたはLZ4で圧縮することもできます。これはグラフィックスリソースをeZip形式に変換する処理とは別です。汎用データの圧縮率は入力によって異なり、繰り返しや規則性の多いデータはよく圧縮される一方、JPEG画像、MP4動画、ZIPアーカイブ、暗号化データなど、すでに圧縮されたファイルはほとんど小さくならないことがあります。非グラフィックスデータに使う場合は、出力サイズと対象デバイスが対応するデコードモードを事前に検証してください。

EZIP HALでは、画像用eZip、GZIP、LZ4は別の動作モードです。汎用のGZIP/LZ4展開はEPICへの直接出力ではなく、AHB経由でメモリーに出力します。OTA用の圧縮データは、選択したモードがサポートするフレーミングとサイズの制約に合わせる必要があり、画像用の.ezipファイルと任意の圧縮更新パッケージは互換ではありません。

代表画像のファイルサイズ比較（記入用）¶

この欄には、代表的な不透明画像とアルファチャンネル付きUI画像を同じ条件で測定した結果を記録します。承認済みのツールと設定を使って各画像を変換し、測定後に仮の値を置き換えてください。元画像の寸法、色形式、アルファの扱い、JPEGの品質設定も併記します。eZipとPNGは元画像の透過情報を保持しますが、JPEGにはアルファチャンネルがありません。そのため、透過画像をJPEGと比較する場合は、背景を合成した条件を記録し、アルファ保持の同等比較として扱わないでください。

BMPに対する相対値は、同じシナリオ内でfile size ÷ BMP file size × 100%として計算します。不透明画像とアルファチャンネル付き画像の結果を直接比較したり、この表を一般的な圧縮率の根拠として使ったりしないでください。これはあくまで測定用のひな形で、結果は画像素材、アルファの適用範囲、変換設定によって変わります。

eZipを使う理由¶

アセットストレージの削減¶

圧縮リソースは、非圧縮のピクセルバッファーに比べてNOR Flash、PSRAM、NAND、リムーバブルストレージの使用量を抑えられます。文字盤、多言語フォント、アイコン集、UIテーマ、アニメーションの多い画面で特に効果があります。

メモリーバストラフィックの削減¶

リソースを外部NOR FlashやPSRAMに置く場合、非圧縮ビットマップの読み出しだけで描画前に大きなバス帯域を消費することがあります。圧縮状態で転送し、グラフィックス処理の近くでデコードすれば、その通信量を抑えられます。効果は圧縮率、入力形式、画面更新パターン、ストレージインターフェースの速度によって変わります。

CPUの処理時間を確保する¶

ハードウェアデコードに対応する経路では、アプリケーションCPUが各リソースをソフトウェアで解凍する必要がありません。そこで得られた余力をUIの応答性向上や、無線、オーディオ、センサー、低消費電力制御に振り向けられます。

アセット配信の再現性を高める¶

変換ツールと管理対象のリソース形式を使えば、リリース工程を再現可能にできます。元の画像やアニメーション、変換設定、生成物、対象解像度のプロファイルをまとめてバージョン管理できます。手作業で変換したり、UI開発者が個別に画像設定を再現したりするより確実です。

eZipの実装比較¶

以下は製品概要とSDKで確認できる名称に基づく比較です。バージョン番号だけで共通の機能を想定せず、対象チップ、SDKの版、リソース形式、ボードのメモリー構成を確認してください。

EPICへの直接出力では、描画前にデコード済みの元画像全体を保存するバッファーを省けます。ただし、デコーダーの作業メモリーや最終的な描画バッファーまで不要になるわけではなく、JPEGデコードがEZIPの機能になるわけでもありません。独立したJPEGD経路は、対象ファミリーで文書化されたドライバーパイプラインに従ってください。

アセットの準備¶

編集可能な元画像やアニメーションはバージョン管理し、eZip出力はビルド成果物として生成してください。

1. 対象デバイスの画面解像度、ピクセル形式、アニメーション要件を定めます。
2. 元画像やアニメーションを使用時の寸法で用意し、素材のサイズ不足を実行時の拡大縮小で補わないようにします。
3. SiFli GraphicsToolで素材を変換・リサイズし、eZipまたはeZip-Aを生成します。
4. ツールのバージョンと変換プロファイルをプロジェクトに記録し、生成物を実機で検証します。
5. 出力を所定のストレージに配置し、コールドブート、UIの繰り返し使用、メモリー不足時の動作、Bluetoothやオーディオ処理と並行する画面更新をテストします。

GraphicsToolはPNG、JPEG、WebP、AVIFなどの一般的な画像形式に対応し、GIF、PNG、APNGをeZip/eZip-Aリソースに変換できます。変換したリソースを使えるのは、対象デバイスとSDKが設定したデコード経路に対応している場合に限られます。

他の静止画形式では、まず目的のサイズに調整してPNGに変換し、その後eZipにエンコードするのが資料に記載された手順です。出力の色形式、アルファの扱い、LVGLの版を対象に合わせてください。SDKのコマンドライン例ではSF32LB57x向けに-winsize 2048が必須です。表に挙げた他のファミリーでは不要です。sdk/tools/png2ezip/ezip.exeの実行引数を生成リソースとともに記録してください。

統合ツール¶

SiFliは、デスクトップ版GraphicsTool以外にも次のツールを提供しています。

• コマンドライン開発ツールを使うと、eZip変換をスクリプト化し、再現可能なリソース生成工程に組み込めます。ローカルのビルドスクリプトや継続的インテグレーションで利用すれば、バージョン管理された元画像と生成済みeZipの対応関係を追跡できます。
• AndroidおよびiOS SDKを使うと、モバイルアプリにeZipを組み込めます。コンパニオンアプリから、デバイス連携の一環としてeZipリソースを準備、管理、転送したり、その他の処理を行ったりする場合に便利です。

変換プロファイル、ツールやSDKのバージョン、出力のチェックサム、対象デバイスの互換性要件をバージョン管理してください。モバイル側とコマンドライン側の処理には、組み込み製品と同じ承認済みリソースプロファイルを使います。あるチップやSDK設定向けに生成したファイルが、すべてのSF32デバイスでそのまま動くとは限りません。

設計とデバッグのガイダンス¶

• リソースにeZipを使う。 NOR Flash、PSRAM、NAND、ファイルシステムに保存できますが、デコーダー自体はファイルパスを解釈しません。ストレージドライバーが、対応するハードウェアアクセス経路でデータを提供または読み込む必要があります。HALの入力バッファーとAHB出力バッファーは4バイト境界に配置する必要があります。eZipは最終フレームバッファーの圧縮形式ではありません。
• 転送帯域を見積もる。 eZipでリソース転送量を減らせますが、デコード後のピクセルにはグラフィックス概要で説明する描画・表示経路が必要です。
• **CPUフォールバック経路を用意する。**すべてのリソース形式、ピクセル形式、UI処理がハードウェアデコードやグラフィックス経路に対応するとは限りません。
• **メモリー配置を検証する。**アセットと描画バッファーを内部SRAM、NOR Flash、PSRAM、またはリムーバブルストレージでテストしてください。それぞれの選択がレイテンシとバスの競合を変化させます。
• 実際のワークロードで検証する。 Bluetooth、オーディオ、センサー、画面更新を同時に動かし、コールドロード時間、アニメーションの更新間隔、UIレイテンシ、消費電力を測定してください。
• **リリース前に変換設定を固定する。**ツールバージョンやパラメーターの変更は、出力の互換性、品質、ストレージ使用量、デコード性能に影響する可能性があります。

要点¶

• eZipは、対応するSF32デバイスにおける、SiFliの可逆ディスプレイアセット圧縮フォーマットおよびハードウェア支援デコードパスです。
• グラフィックスリソースにはeZip、汎用データにはツールのGZIP/LZ4モードを使います。汎用データの圧縮率は入力によって異なるため、実測が必要です。
• eZip-Aはアニメーション用のリソース形式です。GraphicsToolを使って、一般的な画像やアニメーション素材からeZip/eZip-Aリソースを生成できます。
• SiFliはまた、自動化およびモバイルコンパニオンアプリのワークフローにeZipを統合するための、コマンドラインツールとAndroid/iOS SDKも提供しています。
• eZipは、アセットストレージ、外部メモリートラフィック、アプリケーションCPUのデコード負荷を削減できますが、ePicassoやディスプレイコントローラーを置き換えるものではありません。
• 想定したバージョンの序列ではなく、資料で確認できる実装と出力経路を選んでください。JPEGDとEZIPは別に扱い、SF32LB57xでは指定の圧縮ウィンドウを使用してください。
• eZipを適切に活用する設計は、管理されたアセットパイプラインです。ソースアートワーク、変換設定、ストレージ配置、グラフィックス統合、実機テストのすべてが重要です。

一次資料¶

• GraphicsToolとリソース準備
• EZIP HALのモード、出力経路、アラインメント、アニメーション対応
• EZIPユーティリティのドキュメント
• EZIP HALのモード、アラインメント、アニメーション対応
• LVGL eZipの例と変換パラメーター
• モバイル向けeZip SDK
• 製品概要: SF32LB52x, SF32LB55x, SF32LB56x, SF32LB58x
• 独立したJPEGDインターフェース

最終更新: 2026-10-19