eZip 무손실 압축과 하드웨어 디코딩¶
소개¶
eZip은 그래픽 에셋을 위한 SiFli의 독자적인 무손실 압축 포맷입니다. 관련 기능을 지원하는 SF32 디바이스에서는 EZIP 하드웨어 블록이 eZip 그래픽 에셋을 디코딩합니다. 또한 일반 데이터용으로 별도의 GZIP 및 LZ4 모드를 제공하며, 압축 해제된 출력은 EPIC으로 직접 전달되지 않고 AHB를 통해 메모리에 기록됩니다. 모든 디스플레이 에셋을 압축되지 않은 비트맵으로 NOR 플래시, PSRAM 또는 파일 시스템에 저장하는 대신, 제품은 eZip 출력을 저장해 두었다가 UI가 필요로 할 때 디코딩할 수 있습니다.
eZip-A는 이에 대응하는 애니메이션 에셋 포맷입니다. 원본 에셋은 빌드 또는 에셋 준비 과정에서 변환됩니다. eZip은 런타임에 임의의 파일을 받아들이는 범용 이미지 디코더가 아닙니다.
OTA 이미지처럼 그래픽이 아닌 데이터의 경우, 제품이 저장, 무결성 검사, 호환성, 의도한 압축 해제 경로를 포함한 전체 업데이트 흐름을 정의하고 검증해야 합니다. 그래픽 흐름은 디스플레이 에셋에 적용되며, 그러한 애플리케이션 수준의 업데이트 워크플로에는 적용되지 않습니다.
그래픽 제품에서는 스토리지에서 읽어 오는 데이터량을 줄이고, 리소스를 반복해서 압축 해제하느라 애플리케이션 CPU 시간을 소모하지 않는 것이 중요합니다. 이렇게 하면 저장 공간 사용량과 외부 메모리 트래픽을 줄이고, UI, Bluetooth, 오디오, 애플리케이션 작업에 쓸 CPU 여유를 확보할 수 있습니다.
ePicasso, TurboPixel, 디스플레이 컨트롤러와 비교한 eZip의 위치는 그래픽 개요를 참고하십시오. 이 페이지는 eZip 에셋 준비, 압축 동작, 디코딩에 초점을 맞춥니다.
UI 에셋이 플래시나 외부 메모리 대역폭을 지나치게 많이 소비하거나, 반복 가능한 에셋 변환 워크플로가 필요할 때 이 페이지를 읽으십시오. 이 페이지는 원본 에셋의 무손실 압축과 최종 프레임버퍼 압축을 구분하며, 후자는 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 이미지와 알파가 있는 UI 이미지에 대해 동일 조건의 측정값을 기록하는 데 사용하십시오. 승인된 도구 버전과 설정으로 각 원본 이미지를 변환한 후 자리 표시자를 교체하십시오. 결과와 함께 원본 크기, 색상 포맷, 알파 처리 방식, JPEG 품질을 기록하십시오. eZip과 PNG는 원본의 투명도를 유지하지만 JPEG는 알파를 지원하지 않으므로, 투명 이미지의 비교에는 문서화된 사전 합성 배경을 사용해야 하며 알파를 보존하는 동등한 비교로 제시해서는 안 됩니다.
| 시나리오 | 포맷 | 인코딩 | 파일 크기 | BMP 대비 | 테스트 설정 / 참고 |
|---|---|---|---|---|---|
| 불투명 UI 이미지 | BMP | 비압축 기준 | TBD | 100% | 원본 이미지: TBD, 크기: TBD, 픽셀 포맷: TBD |
| 불투명 UI 이미지 | eZip | 무손실 | TBD | TBD | GraphicsTool 버전과 변환 프로파일: TBD |
| 불투명 UI 이미지 | PNG | 무손실 | TBD | TBD | 인코더와 설정: TBD |
| 불투명 UI 이미지 | JPEG | 손실 | TBD | TBD | 인코더와 품질 설정: TBD |
| 픽셀별 알파가 있는 UI 이미지 | BMP | 비압축 기준 | TBD | 100% | 정확한 BMP 변형 또는 알파 처리 방식을 명시: TBD |
| 픽셀별 알파가 있는 UI 이미지 | eZip | 알파를 포함한 무손실 | TBD | TBD | GraphicsTool 버전과 변환 프로파일, 투명한 가장자리 확인: TBD |
| 픽셀별 알파가 있는 UI 이미지 | PNG | 알파를 포함한 무손실 | TBD | TBD | 인코더와 설정: TBD |
| 픽셀별 알파가 있는 UI 이미지 | JPEG | 손실, 알파 없음 | TBD | TBD | 사전 합성 배경과 품질 설정을 기록. 알파를 보존하는 비교가 아님 |
BMP 대비는 같은 시나리오 안에서 file size ÷ BMP file size × 100%로 계산하십시오. 불투명 행과 알파가 있는 행을 직접 비교하거나 이 표를 일반적인 압축률 주장으로 사용하지 마십시오. 이 표는 의도적으로 측정 템플릿이며, 결과는 선택한 아트워크, 알파 범위, 변환 설정에 따라 달라집니다.
eZip을 사용하는 이유¶
에셋 저장 공간 줄이기¶
압축된 에셋은 원시 픽셀 버퍼보다 NOR 플래시, PSRAM, NAND 또는 이동식 스토리지 용량을 덜 차지할 수 있습니다. 이는 워치페이스, 다국어 폰트 팩, 아이콘 세트, UI 테마, 애니메이션이 많은 인터페이스에서 특히 가치가 있습니다.
메모리 버스 트래픽 줄이기¶
에셋이 외부 NOR 플래시나 PSRAM에 있을 때 압축되지 않은 비트맵은 그리기가 시작되기 전에 상당한 버스 대역폭을 소비할 수 있습니다. 압축된 에셋을 이동하고 그래픽 경로 가까이에서 디코딩하면 이 트래픽을 줄일 수 있습니다. 실제 이득은 압축률, 원본 포맷, 디스플레이 업데이트 패턴, 스토리지 인터페이스 속도에 따라 달라집니다.
CPU 시간 확보¶
하드웨어 디코딩 경로를 지원하는 경우 애플리케이션 CPU가 모든 에셋을 소프트웨어로 압축 해제할 필요가 없습니다. 확보된 여유는 UI 반응성을 높이거나 무선, 오디오, 센서, 저전력 스케줄링에 활용할 수 있습니다.
에셋 전달의 반복 가능성 확보¶
변환 도구와 규격화된 에셋 포맷을 사용하면 릴리스를 재현할 수 있습니다. 원본 아트워크, 변환 설정, 생성된 에셋, 대상 해상도 프로파일을 함께 버전 관리할 수 있습니다. 이는 수동 변환이나 UI 개발자가 이미지 설정을 재현하는 데 의존하는 것보다 신뢰할 수 있습니다.
eZip 구현 비교¶
이 표는 버전 번호를 보편적인 기능 보증으로 취급하지 않고, 주요 제품 브리프와 SDK가 뒷받침하는 이름을 사용합니다. 선택한 칩, SDK 릴리스, 에셋 포맷, 보드 메모리 구성을 확인하십시오.
| 구현 | 대표 SF32 제품군 | 문서화된 기능 | 실용적인 의미 |
|---|---|---|---|
| eZip | SF32LB55x | ePicasso와 직접 통합되는 무손실 그래픽 압축 해제. SDK는 이 제품군을 네이티브 eZip-A 지원에서 제외합니다. | 정적 eZip 에셋을 사용하십시오. 네이티브 eZip-A 애니메이션 지원을 가정하지 마십시오. |
| eZip 2.0 | SF32LB52x, SF32LB56x, SF32LB58x | 무손실 그래픽과 네이티브 eZip-A 애니메이션 지원. SF32LB58x에는 별도의 JPEG 코덱도 있습니다. | 애니메이션과 메모리 요구 사항을 검증하고, JPEG/MJPEG 처리는 별도의 미디어 경로로 취급하십시오. |
| EZIP | SF32LB57x | EPIC 직접 출력을 갖춘 eZip/eZip-A 디코딩. JPEGD는 별도의 JPEG 디코더이며, EZIP의 직접 출력 경로를 공유한다고 가정하지 마십시오. | 2048바이트 압축 윈도우로 호환 에셋을 생성하십시오. 이 사실만으로 완전한 MJPEG 재생 경로가 확립되지는 않으므로, 정확한 대상의 미들웨어와 디코더 지원을 확인하십시오. |
EPIC 직접 출력은 렌더링 전에 압축 해제된 eZip 원본 이미지 전체를 저장하는 일을 피합니다. 디코더 작업 메모리와 최종 렌더링 버퍼는 없애 주지 않으며, JPEG 디코딩을 EZIP의 일부로 만들지도 않습니다. 별도의 JPEGD 경로는 대상 제품군에 문서화된 드라이버 파이프라인에 따라 다루십시오.
에셋 준비¶
편집 가능한 원본 에셋은 버전 관리하에 두고, eZip 출력은 빌드 산출물로 생성하십시오.
- 선택한 디바이스의 대상 디스플레이 해상도, 픽셀 포맷, 애니메이션 요구 사항을 정의하십시오.
- 원본 이미지나 애니메이션을 의도한 크기로 준비하십시오. 아트워크 크기가 부적절한 것을 런타임 스케일링으로 보정하지 마십시오.
- SiFli GraphicsTool로 변환, 크기 조정, eZip 또는 eZip-A 출력을 생성하십시오.
- 도구 버전과 변환 프로파일을 프로젝트와 함께 기록한 다음, 대상 하드웨어에서 생성된 에셋을 검증하십시오.
- 출력을 의도한 스토리지 위치에 배치하고, 콜드 부트, 반복적인 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 출력의 추적성이 유지되도록 로컬 빌드 스크립트나 CI 작업에서 사용하십시오.
- Android 및 iOS SDK는 모바일 애플리케이션에서의 eZip 통합을 지원합니다. 컴패니언 앱이 디바이스 워크플로의 일부로 eZip 리소스를 준비, 관리, 전송하거나 달리 다루어야 할 때 유용합니다.
변환 프로파일, 도구 또는 SDK 버전, 출력 체크섬, 대상 디바이스 호환성 요구 사항을 버전 관리하에 두십시오. 모바일 및 명령줄 통합은 임베디드 제품과 동일한 승인된 에셋 프로파일을 사용하는 것이 좋습니다. 한 칩이나 SDK 구성용으로 생성한 파일이 모든 SF32 대상에서 변경 없이 동작한다고 가정하지 마십시오.
설계 및 디버깅 지침¶
- 에셋에는 eZip을 사용하십시오. 에셋은 NOR 플래시, PSRAM, NAND 또는 파일 시스템에 둘 수 있지만, 디코더는 파일 경로를 해석하지 않습니다. 스토리지 드라이버는 디코더가 접근할 수 있도록 지원되는 경로로 데이터를 제공하거나 로드해야 합니다. HAL에서 입력 버퍼와 AHB 출력 버퍼는 4바이트 정렬이 필요합니다. eZip은 최종 프레임버퍼 압축 포맷이 아닙니다.
- 에셋 전송 대역폭을 예산에 반영하십시오. eZip은 에셋 전송 트래픽을 줄일 수 있지만, 디코딩된 픽셀에는 여전히 그래픽 개요에 설명된 렌더링 및 디스플레이 경로가 필요합니다.
- CPU 폴백 경로를 유지하십시오. 모든 에셋 유형, 픽셀 포맷, UI 작업이 하드웨어 디코딩이나 그래픽 경로에 대응되는 것은 아닙니다.
- 메모리 배치를 검증하십시오. 에셋과 드로우 버퍼를 내부 SRAM, NOR 플래시, 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 인터페이스
최종 업데이트: